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 月份将 Opus 4.6 发布到 Claude Code 时，我们将默认推理强度设为 high。

此后不久，我们收到了用户反馈：Claude Opus 4.6 在高强度模式下有时会思考过久，导致 UI 看起来像是卡死，并为这些用户带来过高的延迟和 token 使用量。

总体而言，模型思考得越久，输出通常就越好。强度等级就是 Claude Code 让用户设定这种权衡的方式——更多思考，还是更低延迟和更少触发使用限额。在为模型校准强度等级时，我们会考虑这种权衡，从而在测试时计算曲线上选择能为用户提供最佳选项范围的点。在产品层面，我们随后会决定将这条曲线上的哪个点设为默认值，而这就是我们作为 effort 参数发送给 Messages API 的值；然后我们再通过 /effort 提供其他选项。

在我们的内部评估和测试中，对于大多数任务，medium effort 以显著更低的延迟换来了略低的智能水平。它也没有出现相同的偶发性超长思考尾部延迟问题，并且有助于最大化用户的使用限额。因此，我们推出了一项变更，将 medium 设为默认 effort，并通过产品内对话框解释了这样做的原因。

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

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

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

当 Claude 对一项任务进行推理时，这些推理通常会保留在对话历史中，这样在之后的每一轮里，Claude 都能看到自己为什么进行了那些编辑和工具调用。

3 月 26 日，我们上线了原本旨在提升这一功能效率的改动。我们使用 prompt caching，让连续的 API 调用对用户来说更便宜、更快。Claude 在发起 API 请求时会将输入 tokens 写入缓存，随后在一段时间未活动后，该 prompt 会被逐出缓存，为其他 prompts 腾出空间。缓存利用率是我们会谨慎管理的事情（更多内容见我们的方法）。

这个设计本应很简单：如果一个 session 空闲超过一小时，我们可以通过清除旧的 thinking 段落来降低用户恢复该 session 的成本。由于该请求无论如何都会是一次 cache miss，我们可以从请求中剪掉不必要的消息，以减少发送给 API 的未缓存 tokens 数量。之后我们会恢复发送完整的推理历史。为此，我们配合 keep:1 使用了 clear_thinking_20251015 API header。

实现中有一个 bug。它不是只清除一次 thinking history，而是在该 session 余下的每一轮都清除它。一旦某个 session 一次跨过了空闲阈值，在那个进程余下的每个请求中，都会告诉 API 只保留最新的一块推理，并丢弃此前的所有内容。这个问题会不断叠加：如果你在 Claude 正在使用工具的过程中发送一条跟进消息，那就会在这个损坏的标志下开启新的一轮，因此就连当前这一轮的推理也会被丢弃。Claude 会继续执行，但会越来越不记得自己当初为什么选择去做正在做的事情。这表现为人们报告的健忘、重复和奇怪的工具选择。

由于这会持续从后续请求中丢弃 thinking 块，这些请求也都会导致 cache miss。我们认为，这正是另一类关于使用限额消耗速度快于预期的反馈背后的原因。

两个无关的实验让我们起初很难复现这个问题：一个是仅限内部的、与消息排队有关的服务端实验；另一个是在我们展示 thinking 方式上的一次正交改动，它在大多数 CLI session 中抑制了这个 bug，因此即使在测试外部构建版本时，我们也没有发现它。

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

作为此次调查的一部分，我们使用 Opus 4.7 对相关 pull request 回测了 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 和产品。

我们有多种方法来降低冗长度：模型训练、提示词设计，以及改进产品中的思维 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 中加入了指导，以确保针对特定模型的改动只会被限制到它们所针对的特定模型。对于任何可能以智能为代价的变更，我们都会增加 soak period、更广泛的评估套件以及渐进式发布，以便更早发现问题。

我们最近在 X 上创建了 @ClaudeDevs，以便有更多空间深入解释产品决策及其背后的理由。我们也会在 GitHub 的集中主题帖中分享同样的更新。

最后，我们想感谢我们的用户：那些使用 /feedback 命令与我们分享他们所遇到问题的人（或在网上发布了具体、可复现示例的人），正是他们最终帮助我们识别并修复了这些问题。今天，我们将为所有订阅者重置使用限制。

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