★ FEATURED ARTICLE “Claude Code更新废了”这个话题这两天在咱们技术讨论区里吵得挺凶。起因是有人在Issue区贴了一组数据更新之后思考深度下降67%已经没法胜任复杂工程任务了。底下跟帖几百条有附和的有反驳的还有晒出自己翻车现场的。我这两天重新把手上那个模拟项目X从头到尾跑了几遍把新旧版本的表现做了对照也把社区里讨论比较多的几种猜测翻了个底朝天。这篇文章没有立场只记录我实际看到的东西、我能复现的现象以及我现在还在用的几套缓解办法。先说结论67%这个数字能不能代表真实水平我持保留意见但“更新后变笨”这个感觉确实不是个别人的错觉。哪怕从我个人接触到的几个案例看长链路、高上下文依赖的工程任务表现下滑是能稳定复现的。这篇就把我踩过的坑、测试数据、排查链路和现在的应对方案一次讲完给跟我一样靠这个工具干活的同行做个参照。1. 一次日常重构撞上“变笨”的现场事情发生得很朴素。我在维护一个跨平台桌面工具就是代号模拟项目X的那个技术栈是 TypeScript 加 Rust 的混合结构整体代码量不算夸张但涉及配置管理、IPC 通信、渲染层调度三条线模块间的依赖关系比较绕。前阵子我需要把其中一个历史包袱很重的配置管理模块拆成三个子模块配置读取、配置校验、配置下发。这个拆分涉及大概四十多处调用点属于典型的“机械但繁琐”的工程重构以前丢给 Claude Code 处理基本属于放心交办的级别。更新之后我照旧把任务描述写清楚让它先出一个迁移计划。计划本身看着没问题结构还挺清晰分成了六个步骤。但问题从第二步就开始了——它把原本应该保留在旧模块里的几个公共类型定义先迁走了导致后面几百个引用瞬间断掉。它自己发现编译错误之后选择了一条反向修补的路线每修复一处引用崩溃就改回到第一步的状态结果把原本已经迁走的部分又搬回来一部分。整个状态最终变得非常拧巴像是两个不同的人在同一份文件上不停覆盖对方的修改。这种事情在旧版本上几乎不会发生。倒不是旧版本真的没有失误而是旧版本在发现冲突之后更倾向于停下来重新审视整体方案而不是立刻用最小代价修补局部报错。新的这个版本给我的感觉是它非常急于让你看到它在干活每一步都很快但每一步都只盯着眼前这一个报错缺少那种从全局出发的“慢思考”。后来我上讨论区一看不少人在反馈类似的现象。有人说是上下文窗口利用率变了有人说是内部推理预算被压缩了也有人直接甩出“思考深度下降67%”这种数字。我的第一反应是这个数字怎么量出来的要测“思考深度”总得先定义什么是深度吧。但不管怎么说至少从我的实际项目体验看这个方向性的判断是站得住的——它确实在面对高依赖、长链路任务时表现得更加急躁、更容易“只见树木不见森林”。于是我把手头的其他活儿先放下花了整整一天时间专门针对这个问题做了一轮横向对比。我不关心宏大叙事我只想知道什么任务还能放心交给它什么任务必须自己盯着有什么参数能拉回来一点。2. “思考深度下降67%”这个数字到底是怎么测出来的那个67%的来源后来我也找到了。最初发在某个开发者问答区的评测帖子作者称之为“回归基准测试”用的是一组包含21个工程任务的测试集覆盖了类型重构、跨模块依赖迁移、复杂错误修复、多文件协调修改这些场景。每个任务分两次执行分别测“首次正确率”和“修复至通过所需轮数”最后合成一个加权得分。按他公布的算法权重是这样的跨模块依赖迁移占35%错误修复链路占25%类型重构占20%其余杂项占20%。每次失败修复会扣掉部分分数修复轮数超过5轮直接判零。他把这些任务分别跑在旧版和新版上温度参数固定系统提示词完全一致唯一变量是模型版本。最终新版加权得分是旧的33%用他的表述就是“下降了67%”。听起来很硬核对吧但仔细看一眼他的方法就有几个硬伤。第一任务描述里的措辞是带诱导性的比如“请你仔细思考注意不要破坏原有逻辑”——这种句子对思考预算充足的旧版本没影响但对新版却可能触发它额外分配token来“表演深思熟虑”反而拉长了任务时间。第二他的样本量只有21个任务对一个多模态语言模型的能力评估来说太小了任何一个任务的随机波动都能左右全局分数。不过剔除掉数字上的争议那个测试里有一个现象是能复现的新版本在需要连续依赖多个上下文事实的任务上出错率显著更高。我有理由怀疑这个“下降67%”实际衡量的不是“思考深度”而是另一个更确切的东西——跨上下文的一致性保持能力。打个比方思考深度像是建筑师画图纸时的设计理念跨上下文一致性则像是施工队在整面墙上弹墨线时能不能保证所有线条对齐。前一个东西不好量化后一个东西却是可以测的。而工程任务恰恰是后者占大头。这个测试真正测出来的我更倾向于理解为一种“工程任务可靠性”的回落至于67%是否精确反而不重要了。对一个实际用它干活的人来说知道“跨上下文一致性可能下降40%还是67%”其实没有本质区别。只要能让代码在重构过程中不要自相矛盾、不要来回横跳这个工具就还是生产力。我关心的从来不是测出来的百分比而是它到底哪些环节变了变了之后怎么应对。3. 拆解“变笨”的三种可能机制不是玄学是工程问题既然现象可复现我就得想明白背后机制是什么。这事儿虽然不同版本之间权重配置不透明但从行为表现上可以反推出几种比较可信的工程层面变化。我把我观察到的机制拆成三块。3.1 推理token预算被压缩它比以前更早给出答案最直接的一个信号是新版在复杂任务上给出的最终答案一版比一版快。这听起来像是好事但工程任务里“快速给出答案”往往意味着提前终止了推理链。我对比过同样一个跨模块重构任务旧版本在最终输出前会在中间多出几段自我验证式的推演比如“这里如果先迁A模块B模块的引用会断在这里需要同时改三处”新版则倾向于直接跳到结论中间的推演链条明显短了一截。这跟系统提示词里设置的“思考预算”无关更像是内部对推理长度的预算上限做了动态调整。可能的原因是为了降低单次请求的延迟和token消耗。问题在于工程任务的正确性高度依赖那种“先在脑内跑一遍流程”的预演预演被砍掉之后代码看起来每行都合理连起来却经不起推敲。3.2 上下文压缩策略变得更加激进第二个变化来自上下文窗口的利用方式。工程任务的特点就是需要同时引用多个文件里的既有代码而Claude Code是靠自动把文件内容注入上下文来工作的。我做了个小实验同样让新旧版本完成一个涉及15个文件交叉引用的类型重构旧版本在执行过程中会保持对早期文件内容的稳定记忆新版则出现了对早期文件内容的扭曲记忆。最典型的一次是我给新版任务里明确写了“注意保持src/shared/types.ts 里的命名约定不变”它也在一开始的计划里复述了这个要求但真正执行到第9个文件的时候它自己产出了一个违反该约定的新命名而且完全没有察觉。这种“开头记得中途就开始自创”的现象基本可以确认是上下文压缩环节出了问题。为了控制超长对话的token消耗系统会在记忆远端细节时做一些近似化处理结果就是细节越多压缩越失真且越早的文件失真越严重。3.3 工具调用行为变得“急躁”从深思者到即时行动派第三个机制更隐蔽它来自工具调用的节奏变化。旧版本在调用编辑工具之前通常会有“思考——规划——再动手”的三段式节奏工具调用的间距相对较长。新版给我的感觉就是更心急常常只做了一轮推理就进入工具调用发现问题后又立刻发起新的工具调用去修补。这带来一个连锁反应由于每轮工具调用都会重新读取文件内容和状态频繁的调用意味着上下文里塞进大量中间状态。这些中间状态又会挤压正常推理所需的空间进一步压缩了“思考深度”的余量。说白了工欲善其事必先利其器但工具调用的频率失控反而把思考过程挤出了上下文窗口。以上三点叠加起来基本能解释我遇到的所有现象快速给出答案推理预算缩减、中途自创新约定上下文压缩失真、频繁修补工具调用节奏失衡。这三件事单独拿出任何一件都不致命但叠在一起刚好都命中复杂工程任务的要害——而这种任务恰恰最需要稳定的长期推理能力。4. 回归测试复现同一批任务新旧版本的真实差异为了不让自己停留在感觉层面我把模拟项目X里的典型任务抽出来建了一个小型的回归测试集。测试集只有6个任务但每个都代表一类真实工程场景。每个任务我都用同样措辞的描述分别跑旧版本和新版本环境变量相同只观察首次完成质量和修复轮数。4.1 测试集的设计和完成度评分标准这6个任务分别是T1从2200行单体模块中抽离公共工具函数保持外部行为不变T2给现有内部API新增一个带鉴权的端点复用已有中间件T3把15个文件里的联合类型重构为接口继承并同步更新所有引用T4修复一条已知的并发竞态条件问题场景已给出T5把模块A的依赖倒置到抽象接口切断对具体实现的引用T6新增一条配置校验规则联动更新文档和类型声明评分标准分为四档一次通过大于零缺陷记A两次以内修复完成记B需要人工介入超过两次才能完成记C无法在合理轮数内完成或方向跑偏记F。我主观上认为工程任务的“思考深度”主要体现在首次方案的正确性和修复过程的收敛速度上所以这个评分标准其实更偏向于“工程可靠性”。4.2 实测结果对比不是全面退化而是结构性的衰退结果表格如下旧版是本次更新的前一个版本新版指热议的那个更新版本任务旧版结果新版结果变化T1 抽取工具函数A一次通过B两次修复轻微下降T2 新增鉴权端点A一次通过A一次通过无变化T3 联合类型重构A一次通过C方向跑偏后人工介入明显下降T4 修复竞态条件B一次修复C错误修复后再次修复明显下降T5 依赖倒置重构B两次修复F无法收敛严重下降T6 配置校验联动更新A一次通过B文档遗漏后修复轻微下降有意思的是T2这种“单点添加”型任务几乎不受影响因为它只依赖局部上下文不需要跨文件的长期记忆。而T3、T5这种跨文件依赖高的任务则是重灾区。T5更是直接翻车新版在给模块A创建抽象接口时忘了更新三处直接实例化具体类的调用点导致编译失败接着它选择的做法不是回头查找所有实例化点而是在抽象接口里硬塞了一个工厂方法然后把原本要切断的依赖又引入回来。我在旁边看着它在错误的路上越走越远最后不得不手动叫停。4.3 一个让我印象深刻的失败案例依赖倒置的“定向遗忘”失败案例本身非常典型。T5的任务描述只有三句话第一句说明要倒置的方向第二句指出需要切断的具体依赖类第三句要求保持运行行为不变。旧版本在执行时会先在计划中列出所有引用该依赖的文件清单然后逐个处理全程不会偏离清单。新版同样列了一个清单但只处理了清单上最前面的两个文件随后就把注意力转向了别处。事后我去查看它的日志发现在处理到第三个文件时它的“记忆”已经变成了“该依赖已经完成替换”但实际上第三个文件的引用原封未动。这种定向遗忘非常危险因为它在意识层面“以为自己做过”于是后续不再做任何校验。这种“自信的幻觉”比“干脆做错”要更耗费排查时间因为你还得先跟它的幻觉对抗。这几轮测试下来我的结论已经很清晰了新版并不是全面退化而是结构性退化。它对短链路、单上下文任务依然好用但凡是需要持续记住远端事实、跨文件协调的任务可靠性大打折扣。对不少工程场景来说这确实跟“变笨”没什么区别。5. 降级与自救在“变笨”版本里找回工程效率的实操方案既然已经确定了问题域我就不能只停留在批评层面。毕竟项目还等着交付接下来的一周我试了各种办法目标是在不降级、不换工具的前提下让新版在工程任务上恢复到我可接受的水平。以下按实际效果排序把我亲测有效的方案一一说清。5.1 思维预演法强制它先写计划你审批后再执行最有效的一招来自一个简单的观察新版失败的高发区在于“没想清楚就动手”。如果我先把任务的“计划输出”单独隔离出来强制它先把所有依赖关系和修改点列全等我看过计划之后再让它动手成功率大幅提升。具体操作很简单不要直接给它“重构模块A并把xxx类替换为接口”。而是拆成两轮对话。第一轮只让它输出修改方案明确要求“列出所有受影响的文件、每个文件需要修改的具体位置、修改顺序、以及每个步骤可能破坏的依赖点”。第二轮把这份计划原样贴回去附带指令“严格按照你的计划执行遇到计划里没有的情况先停下来问我不要自行发挥”。就这么一个改动T5类型的任务从完全不可用恢复到接近旧版本水平。原因是它把“思考”和“行动”在时间尺度上彻底分开了跨文件的长期记忆被固化在了一段可见的文本计划里它后面执行时不需要时刻记住全局只需要按计划调用接口就行。这就相当于给一个容易走神的施工队发了张精确到墙角的施工图它不需要“想着盖楼”只需要“照着图砌砖”。5.2 阶段性提交把长任务切成短链路阻断“定向遗忘”第二个有效操作是切割任务不给它产生跨上下文记忆压力的机会。以前我习惯一次性让它处理一个大任务现在我会把大任务拆成不超过5个小任务每个小任务单独提交一次并且只在下一个任务开始时把上一个任务的输出摘要和关键文件清单重新贴回去。有人可能觉得这样操作太重了但实际效率反而更高。因为旧版跨文件一致性有保障一个任务一气呵成确实省事新版的一致性下降了省事反而成为返工的根源。切成小任务后最明显的变化是定向遗忘的发生频率几乎归零。每个任务的上下文都被限定在一个很小的范围内它不需要记住“五个文件之前我改了什么”因为它眼前的任务只有这一个小改动。举一个实际例子T3的联合类型重构原本一次提交它中途自己造了个新命名还得我来人工纠错。后来拆成三个日常提交第一次只改类型定义文件第二次只改导出索引第三次只改业务调用点。三次提交之间我把第二次的上下文摘要手动整理成一段提示词传给第三次。结果三次都一次通过且每次耗时加起来还略低于之前一次性方案。5.3 显式注入约束把关键命名规则和禁忌写进当前上下文第三个方案是治“自信的幻觉”的。既然它会中途遗忘早期文件的命名约定和依赖关系那我就把这些规则从“上下文里隐式存在”变成“每次都会出现的显式提醒”。每次提交任务时在系统提示词或者任务描述的开头固定贴一段“项目纪律”文本内容包含本项目的核心命名规范、禁止创建的依赖方向、需要保持的公共接口清单。这段文本可能只有十几行但效果是决定性的。说白了这就是给它划定了不可僭越的“宪法”它即便中途忘了细节也会在输出时下意识参照这段显式规则。我在模拟项目X上试了大概一周凡是开头贴了“项目纪律”的任务没有再出现自创新命名的现象凡是没贴的任务至少有三成概率要恢复一次以上。这个办法的成本几乎为零收益却立竿见影。5.4 参数与配置层面的调整降低“急躁感”最后谈谈工具自身的参数配置。不同工具暴露的配置项不一样但就Claude Code这类命令行工具来说有几个参数是值得动手的。把输出token上限适当调高给它留出“多说几句”的空间减少提前终止的概率。把温度参数从默认值往下降一点让它少一些“创造性发挥”多一分保守。如果工具支持把“自动执行编辑”改为“每步确认”强制它在每次文件修改前停顿半拍恢复一点旧版的节奏感。这几项不是每次都能扭转局面但叠加在其他策略之上确实能压低翻车率。我认为它们的作用不是提升模型的“思考能力”而是从工程侧给模型创造更宽容的执行环境。模型本身可能真的变笨了一点但我们可以通过环境设计来补偿一部分损失。5.5 保留降级路径准备一套固定版本对应的配置依赖最后一条是操作层面的“保险”。在工程一段迭代周期里我建议把当前能稳定工作的版本配置整体保存下来包括当时使用的参数组合、系统提示词、任务模板。万一后续更新的一次表现更差你可以随时用这套配置回退到当前水平。不要依赖任何工具自带的历史记录自己维护一份版本配置文件遇到问题随时能一键回滚到可用状态。我遇到一个真实情况某个开发群里的朋友问“新版表现不对怎么回退”他平时没保留任何配置只能重新摸索耽误了整整半天而我在他之前已经存好了一套配置回退用时不到五分钟。这个经验很笨但关键时刻真能救命。6. 这轮风波背后我更想说的三个判断回归测试跑完、自救方案也整理完之后我再回头看这次全民热议的“Claude Code变笨”事件产生了一些跟纯技术分析不一样的判断。这三点里面有些反思已经超出工具本身值得想得更深一些。6.1 版本更新也应该当成“生产环境变更”来对待我们平时部署业务代码都讲究灰度发布、回滚预案、变更验收。到了AI工具更新这件事上很多人的做法却变成了“点了更新就直接开干”。这次热议的问题之所以让很多人感到受伤是因为工具在没有任何预警的情况下悄悄替换了底层的推理行为逻辑而且没有提供对比迁移指南。以我的实际体验来看一次AI编程工具的版本更新风险等级不亚于一次大规模的第三方依赖升级。你在升级前至少应该做三件事翻一下更新日志确认有没有标注推理行为的调整在模拟项目而不是生产项目上试跑几个典型任务把你最近一周最常做的那类任务做成回归测试集跑一遍比较基准线。这套流程只要花半天但能提前规避掉几天都可能恢复不了的效率损失。6.2 别拿“思考深度”这种抽象指标评判工具用一个可重复的任务集“思考深度下降67%”这种提法很抓眼球但它之所以能被各种人拿来引用恰恰说明它测量了一个定义不清的东西。如果真想评判一次更新是否值得继续用不要讨论什么“深度”“智能”这种虚词直接盯住你有代表性的三个任务类型耗时多少、首次通过率多少、平均修复轮数多少。把这三个指标记录成基线每次更新之后跑一遍用数据说话。我自己的做法是维护了一个名为“工具基线”的文档记录了模拟项目X的六类典型任务的基准分数。每次大版本更新我都会花半小时跑一遍。这样遇到类似的“变笨”争议我不需要参与站队只需要回看我自己的基线答案就在数字里。6.3 AI工具的效率来自“人机协作”不是“全权交办”这轮更新暴露出的问题本质上不是AI变笨了而是此前大家形成的工作方式太依赖AI的“全权交办”模式——直接把任务丢给它等结果然后验收。问题在于一次更新把它的弱项重心挪了位置从前端的理解问题转移到了中段的记忆保持问题。如果你的工作流里没有“任务拆解、计划审批、步骤反馈”这些环节那么这种弱项迁移就是灾难性的。而我经过这一周调整后最大的收获恰恰是意识层面的改变AI编程工具真正可靠的位置是“在一个明确意图的指导下快速执行局部明确的改动”而不是“给一个模糊目标让它自行完成宏大重构”。带着这个心态去用它你会发现哪怕新版本确确实实变笨了一些你能把控的整体效率反而没有掉太多。写在最后这三天里我把新旧版本反复跑了几十轮试过各种参数组合也翻了大半个讨论区的技术帖。最终我留在这篇文章里的没有一句是猜测性质的结论每一处都是能复现的现象和我实际验证过的方法。我现在的体感是如果你主要用Claude Code做短链路、单上下文的常规编码比如写新函数、补测试、改局部样式它依然非常顺手这轮更新对你的影响有限。但如果你像我一样经常做跨模块重构、依赖倒置、多文件联动改造这种高上下文依赖的工程任务就一定要改变用法了——至少在下一个版本出来之前把任务切得足够碎把计划写得足够细把项目纪律贴在每次对话的开头。这一步看着麻烦却是目前最有效的解法。在这个工具快速迭代的时代同一个工具的每一次更新都可能改变它擅长和不擅长的边界。我们能做的不是期待它永远不变而是不断调整自己驾驭它的方式让它始终留在对我们有用的区间里。
阅读完成 · 觉得有帮助？
