Claude Opus 系列代码质量下滑事件复盘：不同版本表现差异与修复前后对比

这个简单提问，能有效过滤掉很多低价值动作。

月4日，Anthropic对Claude Code默认推理努力进行了调整，将其从high切换到medium。这一变化主要影响Sonnet 4.6和Opus 4.6模型，核心目的是缓解高努力模式下偶尔出现的极长思考尾部延迟，避免界面长时间无响应，同时降低token消耗。用户很快在Hacker News和Reddit等社区反馈编码质量感知下滑，模型在复杂任务中更倾向简单修复而非深度链式思考。

第二处是 3 月 26 日的缓存优化引入 bug，本想仅清理闲置 session 的旧 thinking，却因实现错误在每轮对话中反复触发，导致遗忘、重复和 cache miss 激增，加速限额消耗；

大多数用户和社区的直观感受集中在代码智能下降、会话健忘以及token异常消耗上。复杂任务的规划不再像以前那样稳健，长对话中上下文丢失频繁，工具链调用也变得莫名其妙。早期不少人以为这是暂时的波动或单一故障，但主流观点的盲区在于未能注意到三个变更的分时段影响：3月初的推理努力调整主要波及默认设置用户，3月底的缓存bug则在长会话中逐步显现，而4月中旬的提示限制又叠加在特定模型版本上。

第二个变更源于缓存优化的bug。3月26日上线的优化，本意针对闲置超过一小时的会话，清除旧thinking内容以减少恢复延迟和token负担，采用clear_thinking头和keep:1参数。但实际执行出错，清除动作并非仅一次触发，而是每轮对话都发生，导致累积的reasoning历史逐步丢失。上下文渐失后，模型继续任务时容易重复思考，工具调用出现异常，前后逻辑不连贯。会话越长、工具链越复杂，影响越显著。

大多数开发者最初观察到的，是Claude Code在复杂编码任务中表现出的间歇性下滑：原本高效的多文件重构开始出现重复思考，生成的代码逻辑不够连贯。社区如Hacker News、Reddit和Twitter上，主流声音倾向于猜测模型被偷偷降配或整体智能退化。这些反馈有其合理性，却忽略了一个关键盲区——问题主要出在Claude Code的harness、SDK和Cowork组件上，而非核心推理引擎本身。

从Claude Code延迟优化角度，这次事件提醒行业，单纯追求低延迟可能牺牲编码智能影响。许多开发者在架构设计或复杂重构中，需要模型进行更长的思考链。medium努力虽更快，却让输出显得浅显，缺少“多想一步”的深度。值得持续跟踪，现在下结论为时尚早。

内部评估显示，medium能在多数任务上实现略低智能但显著更快的响应，然而用户很快在Hacker News和Reddit等社区反馈编码质量感知下降，模型更倾向简单修复而非深度链式思考。

月 16 日追加的系统提示变更进一步放大了问题，为减少 Opus 4.7 的 verbosity，明确限制工具调用间文本不超过 25 词、最终响应不超过 100 词。这一意图明确的优化在内部 ablation 测试中显示，对 Opus 4.6 和 4.7 的编码相关 eval 分数造成约 3% 的可衡量下降，直到 4 月 20 日随 v2.1.116 版本回滚。

表面上，用户在Hacker News、GitHub issues和Reddit上集中反馈的，是Claude Code在长会话后半段“变笨”的现象。有人提到多文件依赖分析做到一半，模型就忘了前面梳理的跨文件关系；有人抱怨重构建议反复循环，输出质量明显下滑；还有人观察到原本够用一段时间的额度，几天内就快速见底。主流看法多归因于模型整体退化或单纯的latency优化牺牲，但这些解读往往忽略了缓存机制与上下文状态维护之间的深层交互。

月23日，Anthropic发布了一篇详细的postmortem，明确指出模型权重并未发生变化，底层API也未受影响。问题集中在Claude Code、Agent SDK以及Cowork所依赖的harness层，三处具体变更叠加后引发了系统性体验下降。4月20日，这些变更已全部回滚，并为订阅用户重置了使用限额。

现阶段，保持克制的乐观和持续的跟踪是最务实的态度。