Claude Code 越来越笨了？17000 条日志揭开 AI 编程工具的信任危机

上周，GitHub 上一个 Issue 火了。

标题很直接：「Claude Code is unusable for complex engineering tasks with the Feb updates」——二月更新后，Claude Code 不能用了。

这不是普通的吐槽帖。发帖者挖了自己 17,871 条思考记录和 234,760 次工具调用，用数据证明 Claude Code 从二月开始确实在变笨。这条 Issue 上了 Hacker News，拿到 713 赞、446 条评论，Anthropic 的 Claude Code 团队也亲自下场回复了。

我觉得这事值得聊聊，因为它指向一个所有 AI 工具用户迟早会碰到的问题：你怎么知道你用的工具没有偷偷变差？

一个重度用户的量化日志

先说下这位用户的工作环境。

他同时跑 50 多个 Claude Code agent session，写的是 C、MLIR、GPU 驱动这种底层代码。每个 session 能自主运行 30 分钟以上，项目规范文件（CLAUDE.md）超过 5000 字。状态好的时候，一个周末合并了 191,000 行代码。

说白了，这是 Claude Code 的超级用户，也是最能感知质量波动的那种人。

从二月开始，他发现 Claude 越来越"懒"了——不读代码就改、改完不检查、碰到难题就绕路。感觉不对，他就让 Claude 分析自己过去几个月的 session 日志，做了一次系统性的数据挖掘。

结果很扎眼。

数据说了什么

最核心的指标叫 Read:Edit 比率——每做一次代码编辑前，模型先读了多少文件。

一月底到二月中旬的"好时期"，这个比率是 6.6。改一个文件之前，平均先读 6.6 个相关文件来了解上下文。到了三月中旬的"退化期"，掉到了 2.0。读的文件少了 70%。

按周看更直观：一月底是 21.8，二月中旬降到 2.8，三月中旬最低 1.7。几乎单调下滑。

另一组数据：没有先读文件就直接改的编辑，从 6.2% 涨到了 33.7%。三次修改里有一次是"盲改"。

全文覆写（直接重写整个文件，而不是精确改几行）也从 4.9% 翻倍到 11.1%。就像一个程序员从"改三行"退化成"整个文件重写一遍"。快是快了，精度没了。

根因指向哪里

用户推测的原因是 thinking token 深度被削减。

他用了一个巧妙的代理指标。在 thinking block 被隐藏之前，每条思考记录有一个 signature 字段，跟思考内容长度的 Pearson 相关系数高达 0.971。用这个指标倒推，一月底基线大约 2200 字符的思考深度，到二月底降到了 720（-67%），三月初进一步降到 560（-75%）。

而从三月五号开始，Anthropic 逐步把 thinking block 内容隐藏掉了。3 月 5 号隐藏率 1.5%，3 月 7 号 24.7%，3 月 8 号 58.4%，3 月 12 号以后 100%。用户质量投诉恰好在 3 月 8 号集中爆发，正好是隐藏率过半的那天。

他还写了一个 stop hook 脚本，自动抓取 Claude 的甩锅行为。比如"这不是我改的问题"、“要不要我继续？”、“这是一个自然的停止点”。3 月 8 号之前触发次数为 0。之后 17 天触发了 173 次，平均每天 10 次。

用户在提示词中表达不满的比例，从 5.8% 涨到了 9.8%，涨了 68%。

Anthropic 怎么说

Anthropic 的 Claude Code 团队成员 Boris 在 GitHub 和 Hacker News 上都做了回应。

他的解释是：thinking 内容的隐藏只是 UI 层面的改动，不影响模型实际思考深度。但同期确实有两个会影响思考的变更。

第一，二月九号 Opus 4.6 发布时默认启用了 adaptive thinking。以前是固定思考预算，现在让模型自己决定想多久。第二，三月三号把默认 effort 从 high 降到了 medium（85）。Boris 说 effort=85 对大多数用户是"延迟和智能之间的甜蜜点"。

但 Hacker News 上不少用户不买账。有人说自己一直用 effort=high，照样感觉到退化。Boris 拿到他的 feedback ID 查了遥测数据后承认：「你的 session 确实每个请求都发了 effort=high。数据指向 adaptive thinking 在某些步骤分配了零推理 token。我们正在和模型团队调查。」

这条回复很关键。它说明即使用户手动拉高了 effort，adaptive thinking 机制仍然可能在某些步骤把推理预算砍到零。模型"自己决定想多久"听起来很智能，但当它决定某个步骤不用想的时候，就是 hallucination 和瞎改代码的开始。

还有一位用户的经历更典型：他压根不知道默认 effort 被改了，直到输出质量断崖式下跌才发现。这事浪费了他大约一天的工作量。有意思的是，另一位用户反馈说把 effort 调到 max 反而会出现"绝望式"行为，模型变得过度用力，跟 effort 太低时的表现竟然有点像。

为什么这事跟你有关

你可能不跑 50 个并发 session，也不写 GPU 驱动。但这件事暴露的问题是结构性的。

云端 AI 工具的用户面对一个困境：你无法控制、甚至无法观测到服务端的变更。模型换了、参数调了、默认值改了，你只能通过输出质量的变化来"感觉"。等你感觉到的时候，可能已经浪费了一天甚至一周的工作。

这不是 Claude 独有的。用 GPT、Gemini、任何云端 AI 写代码的人都面对同样的风险。服务商优化成本、调整模型的动机是持续存在的。而用户这边，除了"感觉最近不太对"，几乎没有量化手段。

这位用户做的事情，说白了就是给 AI 工具建了一套监控系统。就像你监控线上服务的 P99 延迟一样，他监控了 AI 的"读写比"和"甩锅率"。这思路很实用。

你能做什么

几个实操建议。

如果你重度依赖 Claude Code，现在就去检查你的 effort 设置。输入 /effort high 或者在 settings.json 里配置。想关掉 adaptive thinking，设环境变量 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1。

更通用的建议：留日志。Claude Code 的 session 日志在 ~/.claude/projects/ 目录下。定期回看，或者写脚本做基础分析。你不需要分析一万七千条记录，但至少知道最近一周模型的行为有没有明显变化。

如果你的工作流高度依赖某个 AI 工具，至少保持对替代方案的了解。不是说要频繁切换，而是主力工具出问题时你有 Plan B。

最后，关注厂商的透明度。这位用户提的建议很合理：在 API 响应里暴露 thinking_tokens 指标，让用户看到每次请求实际用了多少推理预算。即使内容被隐藏，至少让人知道模型想了多久。Anthropic 目前没答应这一条。

这件事让我想到一个老话题：SaaS 时代用户对工具的掌控力在持续下降。AI 把这个问题放大了，因为 AI 的输出质量更难量化，退化更难察觉。你花了一整天 debug，最后发现不是代码的问题，是工具偷偷变笨了。这种事以后只会越来越多。

你最近有没有觉得自己在用的 AI 工具变笨了？是真的变了，还是期望变高了？评论区聊聊。

数据来源：GitHub Issue anthropics/claude-code#42796、Hacker News 讨论（713 赞、446 评论）、Anthropic 团队成员 Boris 的官方回复