Anthropic 复盘 Claude Code 近期质量问题：三项变更已修复并重置用量限制

在过去一个月里，我们一直在调查有关部分用户反映 Claude 的回复质量变差的报告。我们已将这些报告追溯到三项不同的变更，它们分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。

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

在本文中，我们说明我们发现了什么、修复了什么，以及我们将如何调整做法，以确保类似问题再次发生的可能性大大降低。

我们非常重视有关性能退化的报告。我们绝不会故意降低模型质量，并且我们能够立即确认我们的 API 和推理层未受影响。

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

3 月 4 日，我们将 Claude Code 的默认推理强度从 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 日，我们正在为所有订阅用户重置用量限制。

对 Claude Code 默认推理强度的变更

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

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

一般来说，模型思考得越久，输出就越好。推理强度等级是 Claude Code 让用户设定这一权衡的方式——更多思考对比更低延迟和更少触及用量限制。在我们为模型校准推理强度等级时，会考虑这一权衡，以便在测试时计算曲线上选取能为人们提供最佳选项范围的取值点。在产品层，我们随后选择将该曲线上的哪个点设为默认值，这就是我们作为 effort 参数发送给 Messages API 的值；然后我们通过 /effort 提供其他选项。

在我们的内部评估和测试中，中等努力在大多数任务上实现了略低的智能水平，但延迟显著降低。它也没有出现偶尔极长尾延迟的思考问题，并且有助于最大化用户的使用限额。因此，我们推出了一项变更，将中等努力设为默认值，并通过产品内对话框解释了原因。

推出后不久，用户开始反馈 Claude Code 感觉不那么智能了。我们发布了多项设计迭代，让当前的努力设置更加清晰，以提醒用户可以更改默认值（启动时的通知、内联努力选择器，以及恢复 ultrathink），但大多数用户仍保留了中等努力的默认值。

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

一项丢弃先前推理的缓存优化

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

3 月 26 日，我们发布了一项本意是对此功能进行效率改进的更新。我们使用提示缓存来让用户连续调用 API 更便宜、更快速。Claude 在发起 API 请求时将输入 token 写入缓存，然后在一段不活动时间后，提示会从缓存中被逐出，为其他提示腾出空间。缓存利用率是我们谨慎管理的事项（更多内容见我们的方法）。

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

实现中存在一个 bug。它没有只清除一次思考历史，而是在会话剩余时间的每一轮中都清除。一旦会话越过空闲阈值一次，该进程后续的每个请求都会告诉 API 只保留最近一块推理，并丢弃之前的所有内容。这会叠加：如果你在 Claude 正在使用工具的过程中发送后续消息，那会在损坏的标志下开启新一轮，因此连当前轮的推理也会被丢弃。Claude 会继续执行，但越来越不记得自己为何选择做正在做的事。这表现为人们反馈的健忘、重复和奇怪的工具有选择。

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

两个不相关的实验最初让我们难以复现该问题：一个仅限内部的、与消息队列相关的服务器端实验；以及我们在思考展示方式上的一项正交变更，它在大多数 CLI 会话中抑制了这个 bug，因此即使测试外部构建时我们也没有发现它。

这个 bug 出现在 Claude Code 的上下文管理、Anthropic API 和扩展思考的交汇处。它引入的改动通过了多轮人工和自动化代码审查，以及单元测试、端到端测试、自动化验证和内部试用。再加上它只在一种边缘情况（过期会话）下发生，且问题难以复现，我们花了一周多时间才发现并确认根本原因。

作为调查的一部分，我们用 Opus 4.7 对涉事的拉取请求进行了回溯测试 Code Review。在提供收集完整上下文所需的代码仓库后，Opus 4.7 找到了这个 bug，而 Opus 4.6 没有找到。为防止再次发生，我们现在正着手支持将更多仓库作为代码审查的上下文。

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

减少冗长的系统提示词改动

我们最新的模型 Claude Opus 4.7 相对于其前代有一个明显的行为特点：正如我们在发布时所写，它往往相当冗长。这让它在难题上更聪明，但也会产生更多输出 token。

在发布 Opus 4.7 前几周，我们开始为准备而调优 Claude Code。每个模型的行为都略有不同，我们会在每次发布前花时间针对它优化 harness 和产品。

我们有许多减少冗长的工具：模型训练、提示词设计，以及改进产品中的思考体验。最终我们全都用上了，但系统提示词中的一处新增对 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 命令与我们分享问题（或在网上发布具体、可复现示例）的人，正是他们最终让我们得以识别并修复这些问题。今天，我们将重置所有订阅用户的使用限制。

我们对您的反馈和耐心深表感谢。