Opus 4.6连续降智翻车一个月，Anthropic终于公开认错：三个Bug叠加，用户白白损失额度

A厂承认Opus降智了，巧合的是降智报告发布和GPT-5.5发布是同一天，确认降智就是从3月4号开始的，Mythos这个模型2月就练好了，秒天秒地，没有用这个模型来找降智原因？网上各种怨声载道，一个多月过去了，才终于承认了？可能是感受了OpenAI的这几天发布强度！

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

持续发酵近一个月的Claude Code“降智”风波，Anthropic终于给出了官方解释。这事儿说来也巧，官方报告发布的日子，正好撞上了GPT-5.5的亮相日，而问题被确认的起点，则要追溯到3月4日。这就难免让人产生联想：是不是迫于竞争对手的发布压力，才加快了回应速度？毕竟，社区里早已是怨声载道。

根据Anthropic的说明，问题根源并非模型本身能力倒退，而是三个在不同时间点上线、相互独立的工程变更，意外叠加在了一起，最终给用户造成了“全面退化”的糟糕体验。目前，这三个问题均已在4月20日的版本（v2.1.116）中得到修复。当然，这份经过精心梳理的报告，其背后真实的原因可能更为复杂，我们不妨先看看官方是怎么说的。

第一个问题：把推理强度悄悄调低了

时间回到今年2月，Anthropic在Claude Code中推出了Opus 4.6模型，并将其默认的推理强度（reasoning effort）设置为高档。然而，上线后很快收到用户反馈：在高强度模式下，模型偶尔会“思考”过久，界面看起来像卡死了一样，不仅延迟高，token消耗也远超预期。

面对这种情况，团队做了个权衡。内部测试数据显示，如果将默认强度调至中档，在大多数任务上，模型的智能水平仅有轻微下降，但延迟会显著减少，也能避免极端的超长推理情况，更重要的是——能为用户节省不少使用额度。基于这个“性价比”判断，Anthropic在3月4日果断将默认推理强度从高档下调至中档，并通过产品内的弹窗向用户说明了理由。

但调整的后果立竿见影。用户很快开始抱怨Claude Code“变笨了”。为了应对，Anthropic尝试了几轮界面优化，比如增加启动提示、内联切换器，甚至重新支持了ultrathink模式，试图让推理强度的设置更显眼。可惜，大多数用户依然维持着中档的默认值，体验下滑的感知并未消除。

在听取了更广泛的用户反馈后，Anthropic于4月7日撤销了这一决定。目前，Opus 4.7已默认使用“xhigh”强度推理，其他模型则默认使用“high”。

第二个问题：缓存优化出了Bug，Claude变得健忘

Claude在推理时，其历史思考内容本应保留在对话记录中，这是为了确保后续每一轮对话都能“记得”自己之前的操作逻辑和工具调用原因。

然而，3月26日上线的一项旨在提升效率的优化，却意外捅了篓子。这项优化的逻辑是：如果一个会话空闲超过一小时，就在用户恢复对话时，先清除旧的思考内容以减少缓存开销，待后续交互时再恢复发送完整的推理历史。其技术实现依赖于 `clear_thinking_20251015` API header 配合 `keep:1` 参数。

设计思路看似清晰，但实现中藏了一个致命的Bug。正确的逻辑本应是：只在会话首次跨越空闲阈值时清除一次旧内容。但实际的代码却导致：之后每一轮对话都在执行清除操作，API被告知只保留最近一个思考块，而丢弃之前所有的。更糟糕的是，这个效果还会叠加——如果用户在Claude正进行工具调用时发送消息，新启动的对话轮次也会带上这个错误标记，导致连当前轮的推理内容也被丢弃。

结果就是，Claude看起来仍在“努力”执行任务，却越来越“健忘”，完全不记得自己为什么要这么做。用户反馈的重复操作、奇怪的工具选择等问题，根源正在于此。由于思考块被持续丢弃，后续请求不断遭遇缓存未命中，这也部分解释了为何有用户反映使用额度消耗得比预期更快。

调查过程也颇费周折。当时还有两个无关的内部实验干扰了问题复现：一个是服务端仅内部使用的消息队列实验；另一个是改变了思考内容显示方式的变更，这个变更在大多数CLI会话中意外地掩盖了上述Bug，导致即使在测试外部版本时也没能及时发现。

这个Bug处于Claude Code上下文管理、Anthropic API和扩展思考三者的交叉地带，它成功地绕过了多轮人工与自动化代码审查、单元测试、端到端测试乃至内部“狗粮测试”。加之它只在“陈旧会话”这类边缘场景触发，复现困难，团队花了超过一周时间才最终定位并确认根因。

事后，Anthropic用最新的Opus 4.7模型对相关PR进行了回溯测试。在提供了完整的代码库上下文后，Opus 4.7成功发现了这个Bug，而Opus 4.6则没有。为防止类似问题再度发生，Anthropic正在为其代码审查工具增加对更多代码仓库的上下文支持能力。该Bug已在4月10日的v2.1.101版本中修复。

第三个问题：一行压缩输出的提示词，把代码质量搞坏了

最新的Claude Opus 4.7有一个鲜明的行为特点：相比前代，它的输出更为详尽和冗长。这让它在处理复杂难题时显得更“聪明”，但也导致了输出token数量的增加。

在Opus 4.7发布前的几周，Anthropic照例开始针对新模型优化Claude Code。每个模型的行为模式都有细微差别，发布前都需要专门的调优。为了控制输出长度，团队有多种手段：模型训练、提示词优化，以及改进产品中的思考内容展示体验。这些方法最终都被用上了，但其中一条加入系统提示词的指令，却对Claude Code的智能水平产生了超出预期的负面影响。

这条指令内容是：“工具调用之间的文字保持在25个词以内，最终回复保持在100个词以内，除非任务本身需要更多细节。”

经过多周的内部测试，在当时的评估集上并未发现模型能力有明显退化，Anthropic认为已经足够稳妥，便随Opus 4.7于4月16日一同上线。

问题在事后进行消融测试时暴露出来。当团队使用更广泛的评估集，并逐行删除系统提示词以评估每行指令的影响时，发现正是这行关于字数的限制，导致Opus 4.6和4.7在某一项关键评估指标上下降了3%。Anthropic随即将其回滚，作为4月20日版本更新的一部分。

为什么看起来像全面降智

那么，为什么用户会觉得模型出现了全面、一致的退化呢？原因在于这三个变更各自影响的流量切片不同、发生的时间段也不同。它们像三波不同方向的浪潮，接连拍打在用户体验的岸堤上，叠加起来的效应，就模拟出了一种广泛而不一致的“退化”假象。

Anthropic方面表示，其实从3月初就开始调查相关用户反馈，但初期很难将这些反馈与正常的用户反馈波动区分开来，内部使用场景和当时的评估集也未能第一时间复现这些问题。

接下来的改进

针对此次事件，Anthropic宣布了一系列后续改进措施：

首先，将让更大比例的内部员工日常使用与公众完全相同的Claude Code正式版本，而非用于测试新功能的内部版本，以更早感知真实用户体验。

其次，改进内部使用的代码审查工具，并计划向用户开放升级后的版本。作为调查的一部分，Anthropic已经用Opus 4.7回溯测试了相关PR；在提供完整代码库上下文后，Opus 4.7成功找到了Bug，而Opus 4.6未能发现。这凸显了工具能力升级的必要性。

第三，对系统提示词变更实施更严格的管控。未来，每次系统提示词变更都需要对每个模型运行全套评估，并继续进行消融测试。团队还构建了新的工具，以方便审查和审计提示词变更。同时，在CLAUDE.md中添加了明确指引，确保针对特定模型的变更只对该模型生效。对于任何可能牺牲智能水平的变更，将增加浸泡期、采用更广泛的评估集和分阶段灰度发布，以尽早发现问题。

此外，为了增进与开发者社区的沟通，Anthropic在X平台创建了 @ClaudeDevs 账号，用于深入解释产品决策背后的思考逻辑，同样的更新也会在GitHub的集中帖中同步。

最后，作为对此次事件影响的补偿，Anthropic宣布为所有订阅用户重置使用额度。

本文来源：AI寒武纪