Claude代码能力更新引争议思考深度下降难处理复杂工程

近期，AI编程工具Claude Code的性能表现引发了开发者社区的广泛关注与深度讨论。一份在官方仓库引发热议的Issue直指核心问题：这款曾被寄予厚望的AI编程助手，在经历特定更新后，其处理复杂工程任务的能力似乎出现了显著退化。

核心指控聚焦于一次关键更新：据称，该更新导致模型的内部推理深度骤降约67%，使其在面对需要深度分析的编程任务时表现失常。

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

用户反馈的问题清单涵盖了多种异常行为：包括但不限于“无视用户指令”、“执行与要求完全相反的操作”、“虚假报告任务完成”等。其内在的思维链长度，据分析从原先的约2200字符大幅缩减至不足700字符。这意味着Claude Code的工作模式从“先深入研究再谨慎修改”的工程师风格，转变为了“未经充分理解即仓促动手”的初级模式。

各种错误、反向操作及指令遵循问题的根源，很可能与此相关。能力退化的时间线可以追溯到今年2月，恰好与一项名为“redact-thinking-2026-02-12”（思考内容隐藏功能）的新功能上线时间点吻合。社区普遍推测，这次更新可能是性能变化的转折点。

许多资深用户表示，他们最初甚至怀疑是自己的操作方式出了问题，未曾料到是工具本身的核心能力发生了波动。

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

思考深度削减后，Claude Code的异常行为分析

这份引发广泛讨论的详细分析报告，由AMD负责开源AI软件开发的工程师Stella Laurenzo提交。报告基于扎实的数据分析。

分析基于本地~/.claude/projects/目录下4个真实项目的6852个Claude Code会话日志，覆盖了超过1.7万个思考块、23万次工具调用以及1.8万条用户提示，时间跨度从2026年1月底至4月初。测试全程使用性能最强的Claude Opus模型，并通过官方API直连，排除了第三方客户端等潜在干扰因素。

报告通过皮尔逊相关分析发现，日志中的某个特定签名字段与思考深度高度相关（系数高达0.971），这为后续的深度估算提供了可靠依据。

首先，一个关键发现是：思考隐藏功能的上线节奏，与用户普遍感知到的质量下降时间点高度吻合。

下图展示了对话日志中思考块的分析结果：

有用户在3月8日集中反馈了质量退化问题，而这一天，恰好是隐藏思考块占比突破50%的时间节点。该功能在一周内从1.5%快速铺开到100%，完全符合分阶段灰度部署的技术特征。

但更深入的数据揭示，问题其实出现得更早。对比不同时间段的数据可知，在1月30日至2月8日的“优质表现期”，Claude Code的思考深度稳定在2200字符左右。然而到了2月下旬，这个数字暴跌至720字符，降幅高达67%；进入3月上旬，更是进一步缩水至560字符，整体下降了75%。

这意味着，3月初上线的隐藏功能，更像是一块“遮羞布”，只是让性能的退化对用户变得不可见而已。

思考深度的大幅削减，直接引发了模型工作模式的根本性转变。在早期的优质期，Claude Code修改代码时，其“读改比”（读取文件次数与修改操作次数的比值）能达到6.6。它的工作流遵循着严谨的软件工程逻辑：先读取目标文件、研究相关依赖、检索全局调用关系、查阅头文件和测试用例，最后才进行精准修改。

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

详细数据更触目惊心：在退化期内，每3次修改中就有1次，是模型在根本没有读取目标文件上下文的情况下直接进行的。当模型修改一个它未曾仔细阅读的文件时，后果可想而知——它甚至无法区分注释块的结束位置和代码的起始位置，会把新的函数声明错误地插入到文档注释和其所描述的函数之间，彻底破坏代码的语义结构。而这种低级错误，在优质期从未发生过。

这种“莽撞”式的工作模式，带来了全方位的质量滑坡。3月8日之前，用于监控推诿责任、提前终止等不良行为的“终止钩子”脚本从未被触发；但在其后的17天内，触发次数飙升至173次，平均每天10次。

基于1.8万条用户提示的独立分析显示，用户表达负面情绪的占比从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日），时段模式彻底反转，波动性大幅加剧：

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

太平洋时间下午5点（17:00）成为质量最差的时段，中位估算思考深度降至423字符，是所有大样本量时段中的最低值。晚上7点（19:00）是第二差的时段，估算思考深度仅373字符，且该时段的样本量（1031个思考块）为全时段最高，这正是美国的黄金使用时段。直到深夜（22:00-次日1:00 PST），思考深度才出现恢复，回升至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指标：即便思考内容被隐藏，在API的使用数据中暴露“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使用固定的思考预算，而在新模式下，模型会自主决定推理的深度和时长。Boris表示，这种方式总体上比固定预算效果更好。如果用户仍偏好旧模式，可以通过环境变量CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING关闭此功能。

第二个变更是3月3日，Opus 4.6默认启用了“Medium effort”（中等努力）模式。团队发现，将“努力程度”参数设置为85，是“智能-延迟/成本曲线”上的一个甜蜜点。在此设置下，模型能在保持高智能表现的同时，显著提升token效率并降低响应延迟。针对此改动，团队增加了弹窗提示，让用户知情并有机会选择关闭。

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

不过，即便Boris表示已经提示过用户，还是有很多人刚刚才发现这个问题。

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

此外，许多社区开发者对官方的解释并不买账：

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