Anthropic 更新近期 Claude Code 质量问题报告

我们将近期关于 Claude Code 质量问题的报告追溯到了三项彼此独立的变更。下面说明发生了什么，以及我们将做出哪些调整。

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

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

在这篇文章中，我们会说明我们发现了什么、修复了什么，以及今后会采取哪些不同做法，以确保类似问题再次发生的可能性大幅降低。

我们非常重视任何关于性能退化的报告。我们从未有意降低模型表现，并且很快确认我们的 API 和推理层没有受到影响。

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

3月4日，我们将 Claude Code 的默认推理强度从 high 调整为 medium，以降低在 high 模式下部分用户遇到的极高延迟——这种延迟大到足以让界面看起来像是卡死了。这是一个错误的取舍。4月7日，在用户告诉我们，他们更希望默认获得更高的智能表现，并在简单任务中再选择较低强度后，我们撤回了这一改动。这影响了 Sonnet 4.6 和 Opus 4.6。

3月26日，我们发布了一项变更：清除在闲置超过一小时的会话中 Claude 的旧 thinking，以便在用户恢复这些会话时降低延迟。一个 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 月将 Opus 4.6 发布到 Claude Code 时，我们将默认的 reasoning effort 设为 high。

随后，我们收到了用户反馈，Claude Opus 4.6 在 high effort 模式下有时会思考过久，导致界面看起来像是卡死了，并给这些用户带来不成比例的延迟和 token 消耗。

一般来说，模型思考得越久，输出就越好。effort levels 是 Claude Code 让用户设定这种权衡的方式——更多思考，还是更低的延迟和更少触发使用上限。我们在为模型校准 effort levels 时，会把这种权衡考虑进去，以便在 test-time-compute 曲线上选出能为用户提供最佳选项范围的点。在产品层面，我们随后会选择这条曲线上的哪个点作为默认值，而这个值就是我们作为 effort 参数发送给 Messages API 的内容；同时，我们也会通过 /effort 提供其他选项。

在内部评测和测试中，medium effort 在绝大多数任务上的智能表现略低，但延迟显著更小。它也没有出现偶尔极长的思考尾延迟问题，并且有助于最大化用户的使用上限。因此，我们推出了将 medium 设为默认 effort 的改动，并通过产品内对话框说明了背后的原因。

发布不久后，用户开始反馈 Claude Code 感觉没那么智能了。我们进行了多轮设计迭代，让当前的 effort 设置更清晰，以提示用户他们可以更改默认值（包括启动时提示、行内 effort 选择器，以及重新提供 ultrathink），但大多数用户仍保留了 medium effort 作为默认设置。

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

当 Claude 推理一个任务时，这些推理内容通常会保留在对话历史中，因此在后续每一轮中，Claude 都能看到自己为什么做出了那些编辑和工具调用。

3 月 26 日，我们发布了一个原本旨在提升这一功能效率的改动。我们使用 prompt caching 来让连续的 API 调用对用户来说更便宜、更快。Claude 在发起 API 请求时，会把输入 token 写入缓存；随后在一段不活动时间后，prompt 会从缓存中被逐出，为其他 prompt 腾出空间。我们会非常谨慎地管理缓存利用率（更多内容见我们的方法）。

这个设计本应很简单：如果一个 session 空闲超过一小时，我们就可以通过清除旧的 thinking 部分，降低用户恢复该 session 的成本。因为这次请求本来就会是一次 cache miss，我们可以从请求中删去不必要的消息，减少发送到 API 的未缓存 token 数量。然后，我们再恢复发送完整的推理历史。为此，我们使用了 `clear_thinking_20251015` API header，并配合 `keep:1`。

实现里有一个 bug。它没有只清除一次思维历史，而是在这个会话剩余的每一轮都清除了它。一旦某个会话跨过空闲阈值，随后这个进程里的每次请求都会告诉 API 只保留最近一段推理，并丢弃其前面的全部内容。这个问题会叠加：如果你在 Claude 正在执行工具调用时发送一条跟进消息，那就会在这个有问题的标记下开启新一轮，因此连当前这轮的推理也会被丢掉。Claude 仍会继续执行，但会越来越不记得自己为什么要这样做。人们报告的健忘、重复，以及奇怪的工具选择，就是这样暴露出来的。

由于这会持续从后续请求中删除 thinking 块，这些请求也会导致缓存未命中。我们认为，这就是另一些关于使用额度比预期消耗更快的报告背后的原因。

两项互不相关的实验让我们一开始很难复现这个问题：一个是仅限内部的、与消息队列相关的服务端实验；另一个是展示 thinking 的方式发生了无关的改动，这在大多数 CLI 会话中掩盖了这个 bug，因此即使在测试外部构建时，我们也没有发现它。

这个 bug 处在 Claude Code 的上下文管理、Anthropic API 和 extended thinking 的交叉点上。它引入的改动先后通过了多轮人工和自动化代码审查，以及单元测试、端到端测试、自动化验证和 dogfooding。再加上它只会在一个边缘情况中出现（陈旧会话），而且问题很难复现，我们花了一个多星期才发现并确认根因。

作为调查的一部分，我们用 Opus 4.7 对这些有问题的 pull request 进行了回测，检查 Code Review 的表现。在提供了获取完整上下文所需的代码仓库后，Opus 4.7 找到了这个 bug，而 Opus 4.6 没有。为防止类似问题再次发生，我们现在正在支持将更多仓库作为代码审查的上下文。

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

我们的最新模型 Claude Opus 4.7 相较于前代有一个值得注意的行为特点：正如我们在发布时写过的那样，它往往相当啰唆。这让它在困难问题上更聪明，但也会产生更多 output tokens。

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

我们有不少办法来减少冗长：模型训练、提示词设计，以及在产品中改进思考体验。最终我们把这些手段都用上了，但系统提示词里的一条新增内容，却对 Claude Code 的智能表现产生了远超预期的影响：

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

经过数周的内部测试，以及我们所运行的一组评估中没有出现回归后，我们对这项改动有了把握，并于 4 月 16 日随 Opus 4.7 一同发布。

在这项调查过程中，我们使用更广泛的一组评估进行了更多消融实验（从 system prompt 中移除若干行，以了解每一行的影响）。其中一项评估显示，Opus 4.6 和 4.7 都下降了 3%。我们在 4 月 20 日的发布中立即回滚了这段 prompt。

我们将采取几项不同的做法来避免这些问题：我们会确保更多内部员工使用 Claude Code 的完全公开版本，而不是我们用来测试新功能的那个版本；同时，我们也会改进内部使用的 Code Review 工具，并把这个改进后的版本发布给客户。

我们也在加强对 system prompt 变更的管控。今后，Claude Code 的每一次 system prompt 变更，我们都会运行覆盖各模型的大范围 eval；继续通过 ablations 来理解每一行的影响；我们还开发了新的工具，让 prompt 变更更容易审查和审计。我们还在 CLAUDE.md 中补充了指导，确保针对特定模型的改动只在其目标模型上生效。对于任何可能以智能为代价的改动，我们都会增加 soak periods、更广泛的 eval 套件，以及渐进式 rollout，以便更早发现问题。

我们最近在 X 上创建了 @ClaudeDevs，给我们留出空间更深入地解释产品决策及其背后的理由。我们也会在 GitHub 上的集中线程中同步发布这些更新。

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

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

产品更新、使用指南、社区精选等内容，每月送达你的收件箱。