近期Claude Code质量报告更新

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

所有三个问题已于 4 月 20 日（v2.1.116）得到解决。

在这篇文章中，我们将说明我们的发现、修复的内容，以及我们将采取哪些不同措施，以确保类似问题不太可能再次发生。

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

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

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

这并非用户应从 Claude Code 获得的体验。自 4 月 23 日起，我们将重置所有订阅用户的使用限制。

当我们在 2 月份于 Claude Code 中发布 Opus 4.6 时，我们将默认推理强度（reasoning effort）设置为高（high）。

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

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

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

推出后不久，用户开始报告 Claude Code 感觉变笨了。我们发布了一系列设计迭代，使当前强度设置更清晰，以提醒用户可以更改默认值（启动时通知、内联强度选择器，以及恢复 ultrathink），但大多数用户仍保留了中等强度默认值。

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

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

3 月 26 日，我们发布了一项本意是提高此功能效率的改进。我们使用 prompt caching 来使用户的连续 API 调用更便宜、更快。Claude 在发出 API 请求时将输入 token 写入缓存，然后在一段时间不活动后，该 prompt 会从缓存中逐出，为其他 prompt 腾出空间。缓存利用率是我们精心管理的内容（更多关于我们的方法）。

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

实现中存在一个 bug。它没有一次性清除思考历史，而是在会话的剩余部分中，在每一轮都清除它。一旦会话超过空闲阈值，该进程后续的每个请求都告诉 API 只保留最近的推理块，并丢弃之前的所有内容。这会产生叠加效应：如果你在 Claude 进行工具调用时发送了一条后续消息，这会在错误标志下开始新的一轮，因此即使是当前轮的推理也会被丢弃。Claude 会继续执行，但越来越不清楚自己为何选择做正在做的事情。这表现为用户报告中的健忘、重复和奇怪的工具选择。

由于这会持续从后续请求中丢弃思考块，这些请求也会导致缓存未命中。我们认为这就是导致用户报告使用限制消耗比预期更快的单独原因。

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

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

作为调查的一部分，我们使用 Opus 4.7 对有问题的拉取请求进行了回溯性代码审查。当提供了收集完整上下文所需的代码仓库时，Opus 4.7 发现了这个 bug，而 Opus 4.6 没有。为防止此类问题再次发生，我们现在正在支持将更多仓库作为代码审查的上下文。

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

我们最新的模型 Claude Opus 4.7 与其前身相比有一个显著的行为特点：正如我们在发布时所述，它倾向于非常冗长。这使得它在处理难题时更聪明，但也会产生更多的输出 token。

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

我们有许多减少冗长的工具：模型训练、prompt 设计，以及改进产品中的思考 UX。最终我们使用了所有这些方法，但系统 prompt 中的一个新增内容对 Claude Code 的智能水平产生了过大的影响：

经过数周的内部测试，并且在我们运行的一组评估中没有出现回归，我们对这一变更充满信心，并于 4 月 16 日随 Opus 4.7 一起发布。

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

我们将采取几项不同的措施来避免这些问题：我们将确保更大比例的内部员工使用与公共版本完全相同的 Claude Code 构建（而不是我们用于测试新功能的版本）；我们将对我们内部使用的 Code Review 工具进行改进，并将改进后的版本交付给客户。

我们还将对系统 prompt 的变更实施更严格的控制。对于 Claude Code 的每次系统 prompt 变更，我们都会运行一套针对每个模型的广泛评估，继续进行消融实验以了解每行的影响，并且我们已构建了新工具，使 prompt 变更更易于审查和审计。我们还向 CLAUDE.md 添加了指导，以确保针对特定模型的变更仅应用于该目标模型。对于任何可能影响智能水平的变更，我们将增加观察期、更广泛的评估套件和逐步推出，以便更早发现问题。

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

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

我们无比感激您的反馈和耐心。