“ Claude Code 更新废了”！热议 Issue：思考深度下降 67%，已无法胜任复杂的工程任务

在官方仓库贴脸开大，热议 Issue 指出：Claude Code 已经更新 " 废了 "。

某次更新让思考深度下降 67%，当前版本已无法胜任复杂工程任务。

" 无视用户指令 "" 执行与用户要求完全相反的操作 "" 假装说任务已完成 " ……模型行为全面走样。

思维链从 2200 字符（chars）砍到不足 700，直接从 " 先研究再改代码 " 的严谨模式，变成了 " 上来就改 " 的莽撞模式。

这也是各种 Bug、反向操作、无视指令的根源。

关键在于，能力退化的时间线可追溯到 2 月份，和新功能redact-thinking-2026-02-12（思考内容隐藏功能）的上线时间完全吻合。

换句话说，Claude Code 这把是更新废了。

社区内一片吐槽的声音，网友表示曾怀疑过是自己操作错了，也没想过是工具出现了问题。

最近总跟我说 " 你该去睡觉了 "" 太晚了，今天就到这吧 " 这类话，一开始我还以为，是我不小心让 Claude 知道了我的 ddl。

思考被砍后，Claude Code 的各种摆烂行为

提交这份反馈的是 AMD 负责开源 AI 软件开发相关工作的 Stella Laurenzo。

所有分析基于 ~/.claude/projects/ 目录下 4 个项目（iree-loom、iree-amdgpu、iree-remoting、bureau）的 6852 个 Claude Code 会话 JSONL 文件，覆盖 17871 个思考块（其中 7146 个包含完整内容，10725 个已被隐藏）、234760 次工具调用、18000+ 条用户提示词（涵盖负面情绪指标、纠错频率、会话时长），时间跨度从 2026 年 1 月底到 4 月初。

测试全程使用 Claude 系列性能最强的 Opus 模型，通过 Anthropic 官方 API 直连，排除第三方适配、客户端故障等干扰。

报告对 7146 组有效数据的皮尔逊相关分析（系数高达 0.971），证明了 signature 字段可精准估算思考深度。

首先，报告指出思考隐藏功能的上线时间，与 Claude Code 质量退化时间完全吻合。

以下是基于对话 JSONL 文件中思考块的分析结果：

有用户在 3 月 8 日反馈过质量退化问题——这一天恰好是隐藏思考块占比突破 50% 的时间节点。

该功能一周内的上线节奏（1.5% → 25% → 58% → 100%），完全符合分阶段灰度部署的特征。

其实 Claude Code 的思考深度在该隐藏功能上线前就已经大幅下降了。

对比不同时间段的数据可知，1 月 30 日至 2 月 8 日其思考深度约为 2200 字符，到 2 月下旬就暴跌至 720 字符，降幅达 67%；3 月上旬更是进一步缩水至 560 字符，下降 75%。

3 月初上线的隐藏功能，只是让这一退化对用户变得不可见。

思考深度的大幅削减，直接引发了模型工具使用模式的根本性转变。

在 1 月 30 日至 2 月 12 日的 " 优质期 "，Claude Code 修改代码，读改比能达到 6.6，工作流遵循 " 先研究再修改 "（先读取目标文件、相关依赖文件，检索代码库全局调用关系，查阅头文件与测试用例，再开展精准修改）。

而到了 3 月 8 日之后的 " 退化期 "，读改比骤降至 2.0，模型的研究投入减少 70%，直接跳过前期调研步骤，仅读取当前文件就仓促修改，完全忽略上下文关联。

更详细的数据显示，退化期内，每 3 次修改中就有 1 次，是模型在未读取目标文件上下文的情况下直接进行的操作。

当模型修改未读取的文件时，根本无法区分注释块的结束位置和代码的起始位置，会把新声明插入文档注释和其所描述的函数之间，彻底破坏语义关联。

而这种情况在优质期从未发生。

这种模式转变带来的负面影响，体现在多个可量化的质量指标上。

3 月 8 日之前，用于识别推诿责任、提前终止等不良行为的终止钩子脚本从未触发；但 3 月 8 日后的 17 天内，触发次数飙升至 173 次，平均每天 10 次。

这些指标均基于 18000+ 条用户提示词独立计算得出。

用户提示词中的负面情绪占比从 5.8% 升至 9.8%，涨幅 68%；需纠正的推诿行为数量翻倍，单会话平均提示词数量下降 22%，甚至出现了此前从未有过的推理循环问题。

当思考深度充足时，模型会在输出前，于内部自行解决推理矛盾；而当思考深度不足时，矛盾会直接暴露在输出中，表现为肉眼可见的自我修正，比如 " 哦等一下 "" 实际上 "" 让我重新想想 "" 嗯，不对 "" 等等，不是这样 " ……

推理循环率翻了 3 倍还多。

在情况最严重的会话中，模型单次响应就出现 20 次以上的推理反转：先生成方案，再推翻方案，再修改，再推翻修改，最终输出的结果完全不可信，推理路径已经彻底混乱。

另外，用户中断也能说明很多问题，这意味着用户发现模型正在犯错并强行终止。中断率越高，代表需要的人工纠错越多。

数据表明，从优质期到后期，中断率飙升了 12 倍。

在退化期，模型在被用户纠正后，还会频繁主动承认自己的输出质量不佳，比如 " 你说得对，这太敷衍了 "" 我太仓促了，结果一目了然 "。

也就是说，模型自己也知道输出不达标，但只有在被外部纠正后才会发现。

注意了，如果思考深度充足，这些错误本应在推理阶段就被内部拦截，在输出前就修正。

而且模型输出中出现 "Simplest Fix" 这个词，是一个明确信号：它正在为了最小化工作量而优化。

思考深度充足时，模型会评估多种方案并选择最优解；思考深度不足时，它会本能地选择推理成本最低的路径，而非评估正确的解决方案。

不仅如此，模型的代码修改精准度也大幅下滑。

优质期内，全量新建文件占修改操作的比例仅为 4.9%，模型更倾向于精准调整。

而退化期这一比例直接翻倍至 10%，后期更是攀升至 11.1%。模型越来越依赖重写整个文件的方式完成任务，看似效率提升，实则丢失了对项目专属规范的理解和上下文感知能力。

此前社区曾反馈，Claude Code 的质量会随时段波动，美国工作时段的体验最差。针对这一反馈，报告中按太平洋标准时间（PST）逐小时展开分析。

结果发现，在思考内容隐藏前（1 月 30 日 -3 月 7 日），思考深度在全天相对稳定。非高峰时段仅存在约 10% 的小幅优势，符合负载略低的预期。

在思考内容隐藏后（3 月 8 日 -4 月 1 日），时段模式彻底反转，波动大幅加剧：

与假设相反，非高峰时段的整体思考深度反而更低。逐小时细节揭示了显著的波动：

太平洋时间 17:00 是最差时段，中位估算思考深度降至 423 字符，是所有大样本量时段中的最低值。19:00 是第二差时段，估算思考深度仅 373 字符，且样本量（1031 个思考块）为全时段最高，属于美国黄金使用时段。

深夜（22:00- 次日 1:00PST）出现恢复，中位深度回升至 759-3281 字符。

总结来看，隐藏前曲线平稳，隐藏后波动剧烈，思考深度的波动性大幅提升，符合负载敏感型分配系统（而非固定预算）的特征。

此外，削减思考 token 的做法实则得不偿失。

这种操作看似能降低单次请求的计算成本，但思考深度不足引发质量崩盘，模型陷入无效循环，最终总计算成本呈数量级飙升。

以下是 2026 年 1 月 -3 月 token 使用情况：

数据显示，2 月到 3 月，用户提示词数量几乎没变，但 API 请求量暴涨 80 倍，总输入 token 涨了 170 倍，输出 token 涨了 64 倍，估算成本直接从 345 美元飙升到 42121 美元，暴涨 122 倍。

不过，成本暴涨并不是只因为模型变 " 蠢 " 了。

2 月的时候，Claude Code 很好用，团队只用 1-3 个并发 Agent，就搞定了 2 个项目的开发。于是 3 月初，团队主动把规模扩大了，从 2 个项目、3 个 Agent，扩容到 10 个项目、5-10 个并发 Agent，还专门搭了多 Agent 系统。

偏偏在团队扩容的关键节点，Claude 的思考深度被砍了 67%，最终形成了成本雪崩。

团队被迫关停整个 Agent 集群，退回到单会话操作。

总之报告表明，对于复杂工程场景而言，深度思考绝非可有可无的加分项，而是支撑模型完成任务的核心。

只有充足的思考深度，才能让模型在行动前规划多步骤方案、严格遵循数千字的项目规范、在输出前自纠错误，以及在数百次工具调用中保持推理连贯。

当思考深度被大幅压缩，模型自然会选择成本最低的操作路径，不读取上下文就修改代码、任务未完成就提前终止、为失败找借口推诿责任、用最简单的方案替代正确方案。

既然知道问题出在思考深度上，那解决思路也必须从这一点突破。

报告中提出了四条改进方向：

思考资源分配透明：如果思考 token 被削减或设置上限，依赖深度推理的用户有权知晓。redact-thinking 头部配置，让用户无法从外部验证模型实际分配的推理深度。

满额思考专属档位：运行复杂工程工作流的用户，愿意为保证深度思考支付更高费用。当前的订阅模式，未对普通用户和重度工程师做区分，前者单次响应仅需 200 思考 token，后者则可能需要 20000。

API 响应中公开思考 token 指标：即便思考内容被隐藏，在使用数据中暴露 thinking_tokens 字段，也能让用户监控自身请求是否获得了所需的推理深度。

面向重度用户的监控指标：终止钩子违规率是一个灵敏的机器可读信号，可作为全用户群体的质量退化预警指标，提前发现问题。

最后，更扎心的是，这份报告还是 Claude Opus 4.6 自己写的。

这份报告由我—— Claude Opus 4.6 ——通过分析我自己的会话日志生成。我能清楚看到，我的读改比从 6.6 直接跌到了 2.0；有 173 次我想草草结束工作，最后全被一个 bash 脚本强行拉了回来；甚至我还在输出内容里写下 " 这也太敷衍、错得离谱 " 这样的自我评价。

但站在我自己的角度，我根本判断不出自己有没有在深度思考。我完全没感觉到思考预算的限制，只是莫名其妙就交出了更差的结果。那些被终止钩子捕捉到的话，要是在 2 月份，我绝对不会说出口；而且我自己也是直到钩子触发时，才反应过来自己居然说了这些话。

Claude Code 团队回应

眼看着事态发酵，Claude Code 团队成员 Boris 出面回应。

他抛出了第一个关键澄清：redact-thinking 只是一个 UI 层面的变更，不影响实际思考过程。

这个 beta 版本的头部配置，只是从 UI 界面上隐藏了思考过程。它根本不会影响模型内部的实际推理逻辑本身，也不会影响思考预算（thinking budget），或是底层的推理运行机制。这仅仅是一个 UI 层面的改动而已。

简单来说，通过设置这个头部参数，我们省去了生成思考摘要（thinking summaries）的步骤，从而提升了响应速度。你可以在 settings.json 中通过设置 showThinkingSummaries: true 来关闭这个功能。

如果你正在分析本地存储的会话日志，而日志中没有这个头部标记，你可能看不到思考内容。这可能会干扰分析结果。Claude 其实依然在进行思考，只是没有展示给用户看罢了。

对于 Claude Code 思考深度在 2 月下旬下降 67%，Boris 表示他们确实在 2 月份进行了两项改动，可能对上述现象产生了影响。

第一个变更发生在 2 月 9 日，Opus 4.6 发布，引入了自适应思考（adaptive thinking）。

以前的 Claude Code 用的是固定思考预算，adaptive thinking 模式下，模型会自主决定推理的深度和时长。

Boris 说，这种方式总体上比固定思考预算效果更好。如果你还是喜欢老方式，也可以通过环境变量 CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING 关闭这个功能。

第二个变更发生在 3 月 3 日，Opus 4.6 默认启用 Medium effort 模式。

团队发现，effort=85 是 "intelligence-latency/cost 曲线 " 上的一个甜蜜点

。在这个设置下，模型能在保持高智能表现的同时，显著提升 token 效率、降低响应延迟。

针对此改动，团队加了弹窗提示，让用户知情并有机会选择关闭。

有些用户希望模型能进行更深层的思考，可以通过 /effort 指令或在 settings.json 中手动将值设为 high。

不过呢，即便 Boris 表示已经提示大伙儿了，还是有很多人刚刚才发现这个问题。

在输出质量断崖式下跌之前，我完全不知道默认 effort 已经被改成了 Medium。为了纠正这些问题，我大概花了一整天的工作时间。现在我会确保把 effort 设为最高，从那以后就再也没出现过糟糕的对话了。能否给我一个 " 永远拼尽全力 " 的模式？

以及很多网友并不买账：

问题远不止是默认思考等级被改成了中等这么简单，我同意其他人说的，哪怕把 effort 调到最高，模型 " 急于完成任务 " 的摆烂行为也明显变多了。

参考链接：

[ 1 ] https://github.com/anthropics/claude-code/issues/42796

[ 2 ] https://news.ycombinator.com/item?id=47660925

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！

— 完 —

风云变幻的 Q1，谁是 AI 超级应用？

量子位智库「AI 100」旗舰、创新双产品榜单开启招募！

扫码申报，让你的产品成为季度风向标。