在官方仓库贴脸开大，热议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