自今年2月以来，Claude思维深度下降了67%，问题：Claude Code 在 2 月份更新后无法用于复杂的工程任务！点击标题见问题描述！
从2026年2月开始，Anthropic在Claude Code里面偷偷摸摸搞了好几个机制变化，这些变化导致模型在处理复杂工程任务的时候，推理深度直接跳水。这可不是什么偶然抽风，而是能反复测出来、能量化算出来、能稳定复现的系统性能力崩塌。
你问我崩塌成什么样？就像把一位资深工程师的脑子换成了刚学会写Hello World的新手，还得是在咖啡因戒断第三天的状态下干活。
更狠的一个事实是，这种退化根本不是普通人理解的那种“变笨了”。模型的行为模式发生了结构性突变：
- 以前是“我先读一遍所有相关文件，琢磨一下怎么改最稳妥”，现在直接变成“哪行看着不顺眼我就改哪行”。
- 以前是“我尽量自己把整个任务干完，别烦用户”，现在变成“每走三步就问用户一次，我是不是该往左拐”。
- 以前是“我得遵守项目里的代码规范，不能瞎写”，现在变成“注释随便写，缩进无所谓，能跑就行”。
这一切都说明问题不出在模型学过的知识上，而是出在它用来做推理的那块计算资源被克扣了。
推理内容隐藏与能力变化的时间线重合
报告通过分析session日志里面的thinking blocks，发现了一个特别讽刺的事实：官方把推理过程藏起来不让看的时间点，跟用户吐槽模型变差的时间点，几乎是完美重合的。这可不是那种“大概差不多”的模糊相关，而是精确到“当隐藏比例超过百分之五十的那一刻，质量报告就开始雪崩”。就像一个正在做手术的医生，你突然把他手里的内窥镜屏幕关掉，他当然会切错地方，但你非要说“只是不让你看画面而已，手术刀还是那把刀”。
从百分之一点五到百分之百的逐步隐藏，整个过程只花了一周时间就搞定了。这节奏太熟悉了，就是大厂标准的灰度发布流程：先放百分之五的用户试试水，没问题就扩到百分之二十，再扩到百分之五十，最后全量上线。所以这不是什么随机波动，更不是个别用户网络不好导致的幻觉，而是一次精心策划的系统级部署。官方回应还特别强调“隐藏只是UI变化，不影响推理本身”，但用户那边的日志分析直接甩出一个打脸的数据：在隐藏开始之前，推理深度就已经下降了大约百分之六十七。这说明什么？说明问题根本就不是“看不见推理过程”，而是“推理过程本身就已经被砍了一大截”。
推理深度下降的量化证据与计算方法
报告用了一个特别硬核但又非常合理的办法来估算推理深度：通过signature字段和thinking长度之间高达零点九七一的皮尔逊相关性，间接推断那些被藏起来的部分到底有多长。这个方法本质上就是在数据被人为挖掉一大块的情况下，通过剩下的痕迹来重建原来的趋势。你可以理解为，虽然有人把犯罪现场的监控录像删了，但硬盘上的磁记录残留还能还原出当时发生了什么。这种做法在数据科学里叫做建立代理变量，非常成熟也非常可靠。
结果清晰得让人想骂人：从基准期大概两千两百字符的推理长度，直接掉到大约六百字符，整体跌幅超过百分之七十。这种幅度的下降，如果哪个产品经理敢管它叫“优化”，那他就应该被拉去优化一下自己的职业生涯。对于“今天天气怎么样”这种级别的问答，推理长度从两千二掉到六百，可能确实没啥区别。但对于那种要改十五个文件、还得兼容三个版本、最后还要跑通两千个测试用例的复杂工程任务，这七百字的推理缺失，就意味着模型根本没能力规划好步骤。原本可以在内部完成的逻辑检查、错误预判、规范匹配，现在全部溢出到用户这边，变成了“你帮我看看这个对不对”“你帮我确认一下那个行不行”。
行为退化的核心表现：从工程师退化为脚本生成器
报告最有价值的地方，就是它没有停留在“模型变差了”这种模糊抱怨上，而是把抽象的质量下降拆解成了具体的行为指标。这些指标全部来自真实日志数据，不是那种“我感觉它变差了”的主观感受。这就好比医生诊断病情，不是说“你身体不舒服”，而是说“你的白细胞计数从五千升到了一万五，体温三十八度九，C反应蛋白超过正常值十倍”。每一个数字都是实锤。
最关键的一个指标是Read:Edit比例，也就是模型在修改代码之前，读取相关文件的次数和直接修改次数的比值。这个比例从六点六直接掉到了二点零。六点六意味着每改一次代码，模型会先读六到七次相关文件来理解上下文；二点零意味着每改一次代码，只读两次甚至更少。这直接破坏了软件工程最基本原则：你连代码都没读懂，你改个锤子？后果就是改完的代码破坏了原有逻辑，重复的函数定义满天飞，注释跟代码完全对不上号。
另一个特别扎眼的变化是整文件重写比例翻倍了。模型越来越倾向于“我把整个文件给你重新生成一遍”，而不是“我只改那三行有问题的代码”。这种行为本质上是为了减少推理成本，因为局部修改需要精确理解上下文，你得知道改这一行会不会影响下一百行。而整体重写就简单多了，模型只需要根据提示词生成一堆看起来差不多的文本就行。这是教科书级别的“算力不足导致行为降级”：当脑子不够用的时候，就用蛮力代替巧劲。用户层面的反馈也把这些变化量化成了真实的痛苦：中断次数增加了十二倍，纠错需求暴涨，任务完成率直线下降。这些都不是体验层面的小抱怨，而是工程生产力的直接受损。
python
# 示例：推理不足导致的典型错误模式
def add_feature():
# 原本应该先读取整个文件内容
# 结果直接开始修改
return "new code" # 忽略了原有逻辑
推理不足导致的典型错误模式拆解
报告在附录里系统总结了推理不足导致的各种奇葩行为模式，这部分实际上是在给一个“低推理模型”画行为画像。你可以把这当成一份诊断手册，以后看到模型犯这些错误，就能立刻判断出它的推理预算又被砍了。
最典型的是“先改再说”模式，就是模型在没有读取相关文件的情况下，直接上手改代码。比如你让它修一个登录页面的按钮样式，它可能直接就把CSS文件里的背景色从蓝色改成了红色，但完全没注意到这个按钮的样式还被另外三个组件继承。在正常的工程环境里，这种行为几乎不可接受，因为代码的语义完全依赖上下文。缺乏上下文理解，必然导致错误。这就好比一个外科医生没看X光片就直接开刀，切完了才发现肿瘤在另一边。
另一个明显的特征是“自我否定循环”。模型在输出里频繁出现“oh wait”“actually”“sorry, let me correct that”这类修正语句。这就像一个人说话的时候每说两句就要自己打自己脸，说明他脑子里根本就没把逻辑理顺。正常的推理过程应该是：模型先在内部把各种可能性推演一遍，找到最合理的那个，然后一次性输出。但现在推理预算不够了，内部还没推完就被迫输出结果，输出到一半发现错了，赶紧在外部打补丁。这种现象本质就是推理预算不足导致的中断，就像你写作文写到一半发现跑题了，只能划掉重写。
还有一个特别有意思的信号词叫“simplest”。这个词的出现频率暴涨了好几倍，说明模型在主动选择“最省推理成本”的方案，而不是“最正确”的方案。比如你让它实现一个排序功能，正常的模型会先判断数据规模、数据分布、内存限制，然后选择合适的排序算法。但推理不足的模型会直接说“我们用最简单的冒泡排序吧”，完全不管数据量是一百万条还是只有十条。这是优化目标从正确性转向计算效率的直接体现，模型不是在帮你解决问题，而是在帮它自己省算力。
bash
$ grep -r "simplest" session_logs/ | wc -l
# 输出：127（比基准期增加了15倍）
工程工作流为何依赖深度推理
报告明确指出，这类高复杂度的工程场景有几个共同特征：同时修改多个文件、任务运行时间长、项目有严格的代码规范、依赖大规模上下文信息。这些场景本质上要求模型具备两种能力：规划能力和自检能力。规划能力就是先想好“我要改哪几个文件，按什么顺序改，改完之后怎么验证”；自检能力就是改的过程中不断问自己“我刚才改的这一行会不会把别的地方搞崩”。
推理过程在整个工作流里承担的角色非常关键。它要决定先读取哪些文件、哪些文件可以暂时不看；它要把一个大任务拆解成若干个小步骤，并且判断每个步骤的执行条件；它要在修改代码之前先对照一遍项目规范，看看自己准备写的代码符不符合要求；它还要知道什么时候该停下来，而不是无限循环地改下去。这些都不是简单的文本生成能解决的问题，而是需要持续的内部推理来支撑的。
当推理深度下降之后，这些能力全部丢失。模型只能选择“成本最低的动作”：直接编辑文件而不先读取、提前终止任务并说自己完成了、把责任推给用户说“这个需要你手动确认一下”。这些行为在报告里全部被观测到，并且跟推理深度下降的时间点高度一致。你可以想象一个场景：你让一个实习生去修一台服务器，结果他既不先看监控面板，也不检查日志，直接开始敲命令行，敲到一半发现不对，又不敢继续，就每隔三十秒问你一次“我该按哪个键”。这就是推理不足的AI在做工程任务时的真实写照。
官方解释与用户数据之间的关键冲突
来自Anthropic工程师的回应提供了两个关键解释。
第一个是thinking隐藏只是UI层面的变化，不影响模型内部的推理过程。
第二个是他们引入了一套叫做adaptive thinking的机制，并且把effort参数的默认值设成了八十五。
这两个解释听起来都很合理，但问题在于它们无法完全覆盖用户观测到的现象。尤其是“推理深度在隐藏之前就已经开始下降”这个事实，说明adaptive thinking策略本身可能就在主动压缩推理长度，而不是保持推理质量不变。
effort等于八十五被官方定义为“效率最优点”。但对于那些高复杂度的工程任务，这种面向平均场景的“最优”设定，在实际使用中就变成了“严重不足”。打个比方，你在市区开车，平均时速三十公里，这时候一辆车的经济油耗时速是六十公里，那这辆车对你来说就是费油的。同样，一个effort八十五的模型在处理普通问答时确实很高效，但一旦遇到需要极端推理能力的复杂工程任务，它就彻底歇菜了。因为这类任务需要的是“不管花多少算力，先把问题正确解决了再说”，而不是“在算力和质量之间找一个平衡点”。
这就形成了一个非常经典的冲突场景：平台方在优化的是整体用户体验和整体运营成本，追求的是让百分之九十九的用户都觉得“够用”。而那些重度用户需要的却是稳定且高强度的推理资源，哪怕为此多付钱也行。两者的目标函数完全不一致，最终导致能力错配。
平台觉得自己做了合理的优化，重度用户觉得模型就是变傻了，两边说的都是事实，但鸡同鸭讲。这种冲突在高科技产品里太常见了，就像航空公司优化了座椅间距，普通乘客觉得没变化，但身高两米的篮球运动员觉得这航班就是地狱。
python
# adaptive thinking 配置示例
config = {
"effort": 85, # 默认值，面向平均场景
"adaptive": True
}
# 对于复杂工程任务，该配置导致推理深度下降67%
成本与效率的反直觉结论
报告最后给了一个非常反直觉的结论，这个结论可能会让很多人的脑子转不过弯来：减少推理不但没有降低成本，反而让总成本暴涨。原因特别简单粗暴：推理减少导致错误率飙升，错误率飙升导致用户疯狂重试、疯狂纠错、任务频繁中断，所有这些都需要消耗更多的计算资源。就像一个项目，你为了省钱只雇了一个初级程序员，结果他写出来的代码全是bug，测试通不过，上线就崩溃，最后你不得不花三倍的时间和一个高级程序员一起帮他擦屁股。
数据显示，API请求数量增加了八十倍，token使用量增加了六十四倍，而用户输入几乎没有变化。这说明所有额外的消耗都来自于“模型做错事之后的修复成本”。模型每犯一次错，用户就要重新描述一遍问题，模型就要重新读一遍上下文，然后很可能再次犯错，再次重试。这就形成了一个恶性循环：越省推理，错误越多；错误越多，总消耗越大；总消耗越大，平台越想省推理。最后系统就在这个正反馈循环里彻底崩溃。
本质逻辑其实非常简单：一次正确推理的成本，远远低于十次错误尝试的总成本。这个道理在多代理系统里会被无限放大，因为一个代理的错误可能会被其他代理继承和放大，最后整个系统需要付出指数级的代价来纠偏。就像一个传话游戏，第一个人把“明天下午三点开会”说成“明天下午三点开派对”，传到第十个人的时候就变成了“后天早上八点去野餐”。每个环节错一点点，最后的结果就完全不可用。对于大模型驱动的工程系统来说，推理深度就是那个防止信息失真的核心保障。
Reddit社区的核心观察：模型行为从“深思熟虑”转向“条件反射”
在 Reddit 讨论中，大量用户提到一个非常直观的变化：模型过去像一个会思考的工程师，现在更像一个条件反射的代码生成器。这个描述虽然口语化，但和日志分析结果完全一致。
有用户指出，过去模型在动手修改代码之前，会主动读取多个相关文件、理解调用关系、检查测试用例，然后才进行精确修改。现在则经常出现“刚看到一个函数就直接改”的情况，甚至完全忽略依赖关系，导致修改后代码立即崩溃。
还有用户总结了一句非常形象的话：模型现在不是在解决问题，而是在“对提示做最短路径响应”。这句话直接点出了问题本质——优化目标从“正确性”变成了“最小计算成本”。
关于“simplest fix”的社区共识：低推理状态下的行为信号
Reddit 中反复出现一个关键词：“simplest fix”。用户普遍观察到，模型越来越频繁使用这个表达，并且往往伴随着错误或不完整的解决方案。
有用户明确指出，当模型说“the simplest fix is…”时，后面通常不是正确解法，而是一个绕开问题的临时补丁。这种模式在复杂系统中尤其危险，因为它会引入隐性错误，而不是解决根因。
还有讨论进一步指出，这种行为并不是随机的，而是稳定复现的。一些用户甚至把“simplest”当作风险信号，一旦出现就立即中断模型执行。这种从“信任输出”转向“防御输出”的转变，说明用户已经不再把模型当作可靠协作者。
多代理系统崩溃的真实反馈：规模放大后的灾难效应
在涉及多代理（multi-agent）工作流的讨论中，问题被放大到了更严重的层级。有用户分享，原本可以同时运行多个代理进行并行开发，但在模型退化后，这种架构完全失效。
典型反馈是：每个代理都在独立犯错，而且错误类型高度一致。比如全部跳过阅读步骤、全部提前停止、全部选择错误路径。这种“同步退化”导致系统从并行加速器，变成并行错误放大器。
更严重的是，人类监督成本急剧上升。用户需要频繁中断每个代理，逐个纠正错误，最终比单线程人工开发还慢。这一点与报告中的“中断率上升12倍”形成直接呼应。
关于推理隐藏与真实能力的争议：社区普遍不接受官方解释
针对 Anthropic 提出的“thinking隐藏只是UI变化”的解释，Reddit社区整体持怀疑态度。用户的核心反驳逻辑非常直接：如果只是隐藏，不应该影响行为表现。
有用户提出一个关键观察：即使不看thinking内容，仅从输出质量、步骤完整性、错误率等指标，也能明显感知能力下降。这说明问题不在“看不看得到推理”，而在“推理是否发生”。
还有讨论指出，如果模型真的仍在进行深度推理，那么行为模式不应该发生如此剧烈变化。尤其是Read:Edit比例下降、错误类型集中化等现象，无法用“UI变化”解释。
关于adaptive thinking的社区反馈：动态分配在复杂任务中失效
针对adaptive thinking机制，Reddit用户普遍认为它在简单任务中有效，但在复杂工程任务中存在明显问题。核心原因在于：模型低估了任务复杂度，从而分配了不足的推理预算。
有用户举例说明，同一个复杂任务，在不同时间运行，表现差异极大。有时可以完成，有时完全失败。这种不稳定性被认为是动态推理分配机制导致的，因为资源分配依赖于模型的内部判断，而这个判断本身并不可靠。
还有观点指出，adaptive thinking更适合短任务优化，而不是长链路工程问题。因为复杂任务需要“预先规划”，而不是“边做边想”。一旦初始推理不足，后续步骤就会持续偏离正确路径。
时间段差异的真实体验：负载影响推理质量的社区验证
关于时间段影响，Reddit用户的实际体验与数据分析高度一致。很多人提到，在特定时间段（尤其是美国晚间高峰），模型表现明显变差。
有用户分享经验：在深夜或清晨使用时，模型更稳定、更愿意深入分析问题。这与报告中“晚间推理恢复”的数据完全一致。
这种现象被普遍解读为资源竞争问题，也就是推理预算在高负载时被压缩。这进一步强化了一个结论：推理能力已经从“固定能力”，变成“动态分配资源”。
用户行为变化：从协作转向控制
Reddit讨论中还有一个非常重要的变化：用户交互方式发生了明显转变。过去是“给目标，让模型执行”，现在变成“逐步控制模型行为”。
有用户总结现在的使用方式：必须明确指示“先读文件”“不要修改”“继续执行”“不要停”，甚至需要反复强调。这种控制方式，本质上是在替代模型原本应该具备的推理能力。
还有用户提到，他们开始拆分任务，把一个复杂问题拆成多个极小步骤，逐步执行。这种做法虽然可以提高成功率，但大幅降低效率，也违背了使用AI的初衷。
工程现实结论：推理能力是唯一瓶颈，不是模型规模或知识
综合报告数据与Reddit社区反馈，可以得出一个非常清晰的工程结论：当前问题的核心不是模型知识不足，也不是代码能力下降，而是推理预算成为瓶颈。
模型仍然“知道怎么做”，但无法“完成思考过程”。这就像一个经验丰富的工程师，被强制要求在极短时间内做复杂决策，结果必然是频繁出错。
这也解释了为什么模型会在被纠正后承认错误。因为知识仍然存在，只是推理过程被压缩，导致无法在输出前完成自检。
实际应对策略：强制恢复推理深度才能恢复工程能力
结合官方说明与社区经验，一个现实可行的策略是：主动提高推理强度设置，例如使用high或max模式。这一操作的本质，是人为恢复被压缩的推理预算。
同时，复杂任务必须避免依赖adaptive thinking默认判断，而是显式要求深度推理。这可以显著降低“误判任务复杂度”的风险。
如果不做这些调整，那么所有复杂工程任务都会持续面临同一个问题：模型不是不会做，而是没有“算力时间”去正确完成。