Claude Code 质量报告最新进展

过去一个月，我们一直在调查关于 Claude 部分用户响应质量下降的报告。我们追踪到了三个不同的变化，分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。

这三个问题已全部在 4 月 20 日（v2.1.116）得到解决。

在本文中，我们解释了我们发现的问题、修复内容，以及为防止类似问题重新发生将采取的不同措施。

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

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

改变 Claude Code 的默认 reasoning effort

3 月 4 日，我们将 Claude Code 的默认 reasoning effort 从 high 改为 medium，以减少某些用户在 high 模式下遇到的极长延迟——足以使 UI 冻结。这是错误的权衡。在用户告诉我们他们更倾向于默认使用更高的智能并为简单任务选择性降低努力级别后，我们在 4 月 7 日恢复了这项改变。这影响了 Sonnet 4.6 和 Opus 4.6。

3 月 26 日，我们推出了一项改动，清除会话中超过一小时未活动的旧 thinking，以减少用户恢复这些会话时的延迟。一个 bug 导致这个清除在会话的其余部分每一轮都发生，而不仅仅发生一次，这使 Claude 显得健忘且重复。我们在 4 月 10 日修复了它。这影响了 Sonnet 4.6 和 Opus 4.6。

4 月 16 日，我们添加了一条 system prompt 指令来降低冗长度。结合其他提示词改动，它损害了代码质量并在 4 月 20 日恢复。这影响了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

由于每项改动在不同的时间表上影响了不同的流量切片，总体效果看起来像是广泛的、不一致的下降。虽然我们在 3 月初开始调查报告，但起初它们难以与用户反馈的正常变化区分开来，我们的内部使用情况和评估都未能最初重现所识别的问题。

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

Claude Code 默认 reasoning effort 的改动

2 月我们在 Claude Code 中发布 Opus 4.6 时，将默认 reasoning effort 设置为 high。

不久后，我们收到用户反馈，在 high effort 模式下，Claude Opus 4.6 有时会思考太久，导致 UI 冻结并为这些用户造成了不成比例的延迟和 token 使用。

一般来说，模型思考的时间越长，输出质量越好。Effort 级别是 Claude Code 让用户设置这种权衡的方式——更多思考 vs 更低延迟和更少使用限额消耗。当我们为模型校准 effort 级别时，我们会考虑这种权衡，以选择沿测试时计算曲线上能为人们提供最佳选项范围的点。在产品层，我们选择沿这条曲线的哪个点作为默认值，这是我们发送给 Messages API 作为 effort 参数的值；我们通过 /effort 提供其他选项。

在我们的内部评估和测试中，medium effort 对大多数任务实现了略低的智能但显著更低的延迟。它也没有出现与偶发非常长尾思考延迟相同的问题，并且帮助最大化用户的使用限额。因此，我们推出了一项改动，使 medium 成为默认 effort，并通过产品内对话解释了理由。

推出后不久，用户开始报告 Claude Code 感觉不那么聪慧了。我们推出了一系列设计迭代，以使当前 effort 设置更加清晰，以便警告人们他们可以更改默认值（启动时的通知、内联 effort 选择器和恢复 ultrathink），但大多数用户保留了 medium effort 默认值。

听到更多客户的反馈后，我们在 4 月 7 日反转了这个决定。现在所有用户对 Opus 4.7 默认为 xhigh effort，对所有其他模型默认为 high effort。

一个丢弃先前 reasoning 的缓存优化

当 Claude 通过一项任务进行推理时，该推理通常保留在对话历史中，以便在之后的每一轮，Claude 都能看到为什么它进行了编辑和工具调用。

3 月 26 日，我们推出了一项旨在提高效率的改进。我们使用 prompt caching 为用户降低后续 API 调用的成本和速度。Claude 在发出 API 请求时将输入 token 写入缓存，然后在一段不活动期后提示从缓存中逐出，为其他提示腾出空间。缓存利用是我们仔细管理的事项（更多关于我们的方法）。

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

实现存在 bug。它没有只清除一次 thinking 历史，而是在会话的其余部分的每一轮都清除了。一旦会话越过闲置阈值一次，该过程其余部分的每个请求都告诉 API 仅保留最近的推理块并丢弃之前的一切。这会叠加：如果你在 Claude 正在进行工具使用的过程中发送后续消息，这会在损坏的标志下启动新的一轮，所以即使来自当前轮的推理也被丢弃了。Claude 会继续执行，但越来越没有记住为什么选择做它正在做的事情的记忆。这表现为人们报告的健忘、重复和奇怪的工具选择。

因为这会从后续请求中持续删除 thinking 块，这些请求也会导致缓存未命中。我们相信这就是导致使用限额消耗比预期更快的报告的原因。

两个无关的实验使我们最初很难重现该问题：一个仅限内部的与消息排队相关的服务器端实验；以及一个正交的改动，改变了我们显示 thinking 的方式，在大多数 CLI 会话中抑制了这个 bug，所以即使在测试外部构建时我们也没有捕获到它。

这个 bug 位于 Claude Code 的上下文管理、Anthropic API 和 extended thinking 的交叉点。它引入的改动通过了多个人工和自动化代码审查、单元测试、端到端测试、自动化验证和 dogfooding。结合这只在一个角落情况下发生（陈旧会话）和重现问题的困难，我们花了一周多时间才发现和确认根本原因。

作为调查的一部分，我们使用 Opus 4.7 对有问题的拉取请求进行了代码审查回测。当获得必要的代码库以收集完整上下文时，Opus 4.7 找到了 bug，而 Opus 4.6 没有。为防止这种情况再次发生，我们现在为代码审查提供额外仓库作为上下文的支持。

我们在 4 月 10 日的 v2.1.101 版本中修复了这个 bug。

降低冗长度的 system prompt 改动

我们最新的模型 Claude Opus 4.7 相对于其前身有一个显著的行为怪癖：正如我们在发布时所写的，它往往相当冗长。这使它在困难问题上更聪慧，但也产生了更多输出 token。

在我们发布 Opus 4.7 之前的几周，我们开始调整 Claude Code 以做准备。每个模型表现略有不同，我们在每次发布前花时间为它优化工具和产品。

我们有许多工具来降低冗长度：模型训练、提示词和改进产品中的 thinking UX。最终我们使用了所有这些，但对 system prompt 的一项添加对 Claude Code 的智能造成了超大影响：

在多周的内部测试和我们运行的评估集中无回归后，我们对改动感到自信并在 4 月 16 日与 Opus 4.7 一同推出。

作为这项调查的一部分，我们使用更广泛的评估集运行了更多消融（从 system prompt 中删除行以了解每行的影响）。这些评估之一显示了 Opus 4.6 和 4.7 的 3% 下降。我们立即作为 4 月 20 日发布的一部分恢复了提示词。

改进和防止措施

我们将采取几项不同的做法来避免这些问题：我们将确保更大比例的内部员工使用 Claude Code 的精确公开构建（而不是我们用来测试新功能的版本）；我们将改进我们在内部使用的代码审查工具，并向客户推出这个改进版本。

我们还在对 system prompt 改动添加更严密的控制。我们将为每个 system prompt 变更到 Claude Code 运行针对每个模型的广泛评估套件，继续消融以了解每行的影响，并且我们构建了新工具来使提示词改动更易于审查和审计。我们还向我们的 CLAUDE.md 添加了指导，以确保模型特定的改动被限制到它们针对的特定模型。对于任何可能权衡智能的改动，我们将添加 soak 周期、更广泛的评估套件和逐步推出，以便我们更早捕获问题。

我们最近在 X 上创建了 @ClaudeDevs，为我们深入解释产品决策及其背后的推理的空间。我们将在 GitHub 上的集中线程中分享相同的更新。

最后，我们想感谢我们的用户：使用 /feedback 命令与我们分享他们问题的人（或在线发布特定、可重现示例的人）是最终让我们能够识别和修复这些问题的人。今天我们正在为所有订阅者重置使用限额。

我们对你的反馈和耐心感到由衷感谢。