近期 Claude Code 质量问题的事后分析

来源: Anthropic Engineering Blog | 作者: @AnthropicAI | 日期: 2026-04-23 原文链接: https://www.anthropic.com/engineering/april-23-postmortem

一句话总结

过去一个月 Claude Code 被用户感知到的质量退化，源自三个独立的产品层变更（推理力度降级、缓存 bug 持续清除思考历史、系统提示词过度压缩输出），API 和模型本身未受影响，截至 4 月 20 日全部修复。

速览

推理力度降级——3 月 4 日将默认 effort 从 high 改为 medium，导致 Sonnet 4.6 和 Opus 4.6 在 Claude Code 中整体智能下降，4 月 7 日回滚
思考历史持续丢失——3 月 26 日的缓存优化 bug 导致闲置会话后每一轮都清除推理记录，Claude 表现为健忘和重复，4 月 10 日修复
系统提示词过度限制——4 月 16 日加入 ≤25 词/≤100 词的长度限制，与其他变更叠加后使编码质量下降 3%，4 月 20 日撤回
三重叠加效应——三个问题在不同时间影响不同流量切片，综合呈现为广泛而不一致的退化，增加了排查难度
API 未受影响——所有问题仅限于 Claude Code 产品层，API 和推理层确认无恙
内部检测盲区——内部员工使用的构建版本与公开版不同、两个不相关实验掩盖了 bug 复现，导致发现延迟
Opus 4.7 能发现 Opus 4.6 发现不了的 bug——用 Code Review 回溯测试，Opus 4.7 在获得完整仓库上下文后成功定位了缓存 bug
后续改进措施——强制员工使用公开版、逐行消融评估系统提示词、渐进式发布、加强 Code Review 工具

核心内容

推理力度降级：用户宁要智能，不要速度

Opus 4.6 在 2 月发布时默认推理力度为 high。部分用户遭遇 UI 假死级别的超长延迟，团队因此在 3 月 4 日将默认值改为 medium。内部评估显示 medium 延迟显著降低、智能略降，同时能最大化用户配额，看似合理。

但大量用户反馈”Claude Code 变笨了”。团队做了多次 UX 迭代（启动提示、内联选择器、恢复 ultrathink）让力度设置更醒目，但多数用户并不主动调整默认值。最终在 4 月 7 日回滚，新默认值为 Opus 4.7 使用 xhigh，其他模型使用 high。

这个案例揭示了一个产品决策陷阱：从评估数据看”略降智能换大幅降延迟”是合理取舍，但用户的实际感受远比评估指标敏感。

缓存优化 bug：一行设计缺陷导致记忆持续丧失

设计意图简单清晰：会话闲置超过一小时后，清除旧的思考部分以减少恢复成本（反正缓存已失效），然后恢复正常的完整推理历史发送。使用 clear_thinking_20251015 API header 配合 keep:1 实现。

bug 的本质：清除操作不是执行一次，而是在会话后续的每一轮中反复执行。效果累积——如果用户在 Claude 执行工具调用期间发送消息，新的一轮在损坏标志下启动，连当前轮的推理都被丢弃。Claude 继续执行，但逐渐失去对自己决策动机的记忆。

这直接导致了用户报告的三个症状：健忘、重复、和奇怪的工具选择。同时由于每次都缓存未命中，用户配额消耗也异常加速。

复现困难的原因：一个仅内部使用的消息队列实验改变了行为路径；另一个思考内容展示方式的变更在大多数 CLI 会话中掩盖了此 bug。即使测试外部构建版本也未能触发。最终花了超过一周才确认根因。

值得注意的是：这个变更通过了人工审查、自动化审查、单元测试、端到端测试、自动化验证和 dogfooding 的全部环节。用 Opus 4.7 进行 Code Review 回溯时，4.7 能发现这个 bug，而 4.6 不能——这促使团队为 Code Review 增加多仓库上下文支持。

系统提示词过度压缩：25 个词的限制摧毁编码质量

Opus 4.7 天生冗长，团队为此在系统提示词中加入：“工具调用之间的文本保持在 ≤25 个词。最终回复保持在 ≤100 个词，除非任务需要更多细节。”

经过数周内部测试和评估集验证后随 Opus 4.7 在 4 月 16 日发布。但在后续更广泛的评估中，消融实验显示该行对 Opus 4.6 和 4.7 均造成 3% 的性能下降，于 4 月 20 日立即撤回。

后续改进：从流程层面防止重演

统一构建版本：确保更多内部员工使用与公开版完全相同的 Claude Code，消除”内部版看不到外部 bug”的盲区
系统提示词管控：每次变更运行逐模型、逐行消融的广泛评估；新工具使变更更易审查和审计；CLAUDE.md 中增加指导确保模型特定变更只作用于目标模型
渐进式发布：对任何可能影响智能的变更增加浸泡期和分批灰度发布
Code Review 增强：支持额外仓库作为上下文，已将改进版提供给客户
沟通透明化：创建 @ClaudeDevs 账号深入解释产品决策，同步更新到 GitHub

名言金句

“We never intentionally degrade our models.”（我们从未故意降低模型质量。）
“This was the wrong tradeoff.”（这是一个错误的权衡。）——关于将默认推理力度从 high 降为 medium
“Claude would continue executing, but increasingly without memory of why it had chosen to do what it was doing.”（Claude 会继续执行，但对自己为何选择这样做的记忆越来越模糊。）
“The people who used the /feedback command to share their issues with us are the ones who ultimately allowed us to identify and fix these problems.”（使用 /feedback 命令分享问题的用户最终帮助我们发现并修复了这些问题。）

可行建议

Claude Code 用户：确保升级到 v2.1.116 或更高版本以获得所有修复
重度用户：使用 /effort 命令根据任务复杂度手动调整推理力度，而非依赖默认值
遇到问题时：使用 /feedback 命令提交具体可复现的示例，这是最有效的反馈渠道
长时间闲置的会话：考虑重新开始新会话而非恢复旧会话，避免潜在的上下文问题

资源清单

近期 Claude Code 质量问题的事后分析

过去一个月，我们一直在调查用户反映的 Claude 回复质量下降的问题。我们将这些反馈追溯到三个独立的变更，分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。

截至 4 月 20 日（v2.1.116），这三个问题均已修复。

在本文中，我们将说明发现了什么、修复了什么，以及今后会采取哪些不同的措施来确保类似问题不太可能再次发生。

我们非常重视关于质量下降的反馈。我们从未故意降低模型质量，且能够立即确认 API 和推理层未受影响。

经过调查，我们确认了三个不同的问题：

3 月 4 日，我们将 Claude Code 的默认推理力度（reasoning effort）从 high 改为 medium，目的是减少部分用户在 high 模式下遭遇的超长延迟——长到 UI 看起来像是卡死了。这是一个错误的权衡。在用户告诉我们他们宁愿默认使用更高智能、按需降低力度处理简单任务后，我们于 4 月 7 日恢复了此变更。此问题影响了 Sonnet 4.6 和 Opus 4.6。
3 月 26 日，我们上线了一项变更，旨在对闲置超过一小时的会话清除 Claude 的旧思考内容，以减少用户恢复这些会话时的延迟。但一个 bug 导致这种清除在会话的后续每一轮中持续发生，而不仅仅是一次，使得 Claude 看起来健忘且重复。我们在 4 月 10 日修复了它。此问题影响了 Sonnet 4.6 和 Opus 4.6。
4 月 16 日，我们在系统提示词中添加了一条指令以减少冗长输出。与其他提示词变更叠加后，它损害了编码质量，并在 4 月 20 日被撤回。此问题影响了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

由于每个变更在不同的时间表上影响了不同的流量切片，综合效果看起来像是广泛而不一致的退化。虽然我们在 3 月初就开始调查反馈，但起初很难将其与用户反馈的正常波动区分开来，而且我们的内部使用和评估最初都未能复现所报告的问题。

这不是用户对 Claude Code 应有的体验。截至 4 月 23 日，我们正在为所有订阅用户重置使用额度。

默认推理力度的变更

当我们在 2 月发布 Claude Code 中的 Opus 4.6 时，我们将默认推理力度设为 high。

不久后，我们收到用户反馈，称 Claude Opus 4.6 在高力度模式下偶尔会思考过久，导致 UI 看起来像是卡死，给这些用户带来不成比例的延迟和 token 消耗。

一般来说，模型思考越久，输出越好。推理力度是 Claude Code 让用户设置这一权衡的方式——更多思考与更低延迟和更少用量限制命中之间的取舍。在校准模型的力度级别时，我们在测试时计算曲线上选取能提供最佳选项范围的点。在产品层面，我们选择曲线上的某个点作为默认值，将该值作为 effort 参数发送给 Messages API；然后通过 /effort 提供其他选项。

在我们的内部评估和测试中，medium 力度以显著更低的延迟实现了略低的智能水平，适用于大多数任务。它也不会遭遇 high 模式下偶尔出现的超长尾延迟问题，并且有助于最大化用户的使用额度。因此，我们推出了将 medium 设为默认力度的变更，并通过产品内对话框说明了理由。

推出后不久，用户开始反馈 Claude Code 感觉不那么聪明了。我们进行了多次设计迭代，使当前力度设置更加醒目，以提示用户可以更改默认值（启动时的通知、内联力度选择器、恢复 ultrathink），但大多数用户保留了 medium 力度默认值。

在听取更多客户反馈后，我们于 4 月 7 日撤销了这一决定。所有用户现在默认 Opus 4.7 使用 xhigh 力度，其他模型使用 high 力度。

清除先前推理的缓存优化

当 Claude 推理一个任务时，该推理通常保留在对话历史中，以便在后续每一轮中，Claude 都能看到它做出编辑和工具调用的原因。

3 月 26 日，我们上线了一项本应是该功能效率优化的变更。我们使用 prompt caching 来降低用户连续 API 调用的成本和延迟。Claude 在发起 API 请求时将输入 token 写入缓存，经过一段不活跃期后，prompt 从缓存中被驱逐，为其他 prompt 腾出空间。缓存利用率是我们精心管理的事项（更多关于我们的方法）。

设计本应很简单：如果会话闲置超过一小时，我们可以通过清除旧的思考部分来降低用户恢复会话的成本。由于请求无论如何都会缓存未命中，我们可以从请求中修剪不必要的消息，以减少发送给 API 的未缓存 token 数量。然后我们会恢复发送完整的推理历史。为此，我们使用了 clear_thinking_20251015 API header 配合 keep:1。

实现存在 bug。它不是只清除一次思考历史，而是在会话的每一轮中持续清除。一旦会话跨过闲置阈值，该进程后续的每个请求都告诉 API 只保留最近的推理块并丢弃之前的所有内容。这会累积：如果你在 Claude 执行工具调用的过程中发送后续消息，那会在损坏标志下开始新的一轮，因此甚至当前轮的推理也会被丢弃。Claude 会继续执行，但对自己为何选择这样做的记忆越来越模糊。这就是人们报告的健忘、重复和奇怪工具选择的根源。

由于这会持续从后续请求中丢弃思考块，这些请求也导致了缓存未命中。我们认为这就是导致用户反馈使用额度消耗速度超出预期的原因。

两个不相关的实验使我们最初难以复现该问题：一个是仅供内部使用的消息队列相关的服务端实验；另一个是我们展示思考内容方式的正交变更，它在大多数 CLI 会话中抑制了此 bug，因此即使我们在测试外部构建版本时也未能捕获到它。

此 bug 处于 Claude Code 的上下文管理、Anthropic API 和扩展思考的交汇处。它引入的变更通过了多次人工和自动化代码审查，以及单元测试、端到端测试、自动化验证和 dogfooding。加上这只在特定情况（过期会话）下发生且难以复现，我们花了一周多时间才发现并确认根因。

作为调查的一部分，我们用 Opus 4.7 对导致问题的 pull request 进行了回溯测试，使用了 Code Review。当提供了收集完整上下文所需的代码仓库后，Opus 4.7 发现了该 bug，而 Opus 4.6 没有。为防止此类情况再次发生，我们正在增加对 code review 中额外仓库作为上下文的支持。

我们在 4 月 10 日的 v2.1.101 中修复了此 bug。

减少冗长输出的系统提示词变更

我们最新的模型 Claude Opus 4.7 相比其前任有一个显著的行为特征：正如我们在发布时所写，它倾向于非常冗长。这使它在困难问题上更聪明，但也产生更多输出 token。

在 Opus 4.7 发布前几周，我们开始为其调优 Claude Code。每个模型的行为略有不同，我们会在每次发布前花时间为其优化基础设施和产品。

我们有多种工具来减少冗长：模型训练、提示词优化和改进产品中的思考 UX。最终我们全部使用了，但系统提示词中的一项添加对 Claude Code 的智能造成了过大影响：

“长度限制：工具调用之间的文本保持在 ≤25 个词。最终回复保持在 ≤100 个词，除非任务需要更多细节。”

经过数周的内部测试且在我们运行的评估集中未出现回归后，我们对该变更有了信心，并在 4 月 16 日随 Opus 4.7 一起发布。

作为此次调查的一部分，我们使用更广泛的评估集进行了更多消融实验（从系统提示词中逐行移除以理解每行的影响）。其中一项评估显示 Opus 4.6 和 4.7 均有 3% 的下降。我们立即在 4 月 20 日的发布中撤回了该提示词。

后续改进

我们将采取以下不同的措施来避免这些问题：我们将确保更多内部员工使用与公开版完全一致的 Claude Code 构建版本（而非用于测试新功能的版本）；我们将改进内部使用的 Code Review 工具，并将改进版本提供给客户。

我们还将加强对系统提示词变更的管控。我们将针对 Claude Code 的每次系统提示词变更运行广泛的逐模型评估套件，继续进行消融实验以理解每行的影响，并构建了新工具使提示词变更更易于审查和审计。我们还在 CLAUDE.md 中添加了指导原则，确保模型特定的变更仅作用于对应的模型。对于任何可能影响智能的变更，我们将增加浸泡期、更广泛的评估套件和渐进式发布，以便更早发现问题。

我们最近在 X 上创建了 @ClaudeDevs，以便深入解释产品决策及其背后的推理。我们也会在 GitHub 的集中讨论帖中分享相同的更新。

最后，我们要感谢我们的用户：使用 /feedback 命令分享问题的用户（或在网上发布具体可复现示例的用户）最终帮助我们发现并修复了这些问题。今天我们正在为所有订阅用户重置使用额度。

我们非常感谢你们的反馈和耐心。