关于近期 Claude Code 质量报告的更新

# 关于近期 Claude Code 质量报告的更新 来源：https://www.anthropic.com/engineering/april-23-postmortem 过去一个月，我们一直在调查部分用户反馈 Claude 回复质量下降的问题。我们已将这些问题追溯到三项独立的变更，它们分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。 截至 4 月 20 日（v2.1.116），这三个问题均已修复。 在这篇文章中，我们将解释我们的发现、修复内容，以及我们将如何改进以避免类似问题再次发生。 我们非常重视关于质量下降的报告。我们从未故意降低模型性能，并且我们能够立即确认我们的 API 和推理层未受影响。 经过调查，我们识别出三个不同的问题： 1. 3 月 4 日，我们将 Claude Code 的默认推理 effort 从 `high` 改为 `medium`，原因是部分用户在 `high` 模式下遇到了极长的延迟——甚至导致 UI 出现卡死。这是一个错误的权衡。在用户反馈表示他们更希望默认使用更高智能、并主动选择更低 effort 来完成简单任务后，我们于 4 月 7 日撤销了这一变更。这影响了 Sonnet 4.6 和 Opus 4.6。 2. 3 月 26 日，我们上线了一项变更，用于清除闲置超过一小时的会话中的历史思考内容，以降低用户恢复会话时的延迟。但一个 bug 导致该操作在会话后续的每一轮中持续触发，而非仅执行一次，这使得 Claude 显得健忘且重复。我们于 4 月 10 日修复了该问题。这影响了 Sonnet 4.6 和 Opus 4.6。 3. 4 月 16 日，我们添加了一条系统提示指令以减少冗长。结合其他提示变更，这损害了代码质量，并于 4 月 20 日撤销。这影响了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。 由于每项变更在不同时间影响了不同的流量切片，综合效果表现为广泛且不一致的质量下降。虽然我们在 3 月初就开始调查相关反馈，但起初难以将其与正常的用户反馈波动区分开来，且我们的内部使用和评估最初也未能复现所识别的问题。 这不是用户应从 Claude Code 获得的体验。截至 4 月 23 日，我们将为所有订阅者重置使用额度。 ## Claude Code 默认推理 effort 的变更 今年 2 月在 Claude Code 中发布 Opus 4.6 时，我们将默认推理 effort 设置为 `high`。 不久后，我们收到用户反馈，称 Claude Opus 4.6 在 high effort 模式下偶尔会思考过久，导致 UI 出现卡死，并造成不成比例的延迟和 token 消耗。 一般而言，模型思考时间越长，输出质量越好。Effort 等级是 Claude Code 让用户设置这一权衡的方式——更多思考 vs. 更低延迟和更少使用额度消耗。在调校模型的 effort 等级时，我们会考虑这一权衡，以在测试时计算曲线上选择能为用户提供最佳选项范围的点。在产品层，我们再选择曲线上的哪个点作为默认值，即作为 effort 参数发送至 Messages API 的值；然后通过 `/effort` 提供其他选项。 在我们的内部评估和测试中，对于大部分任务，medium effort 以显著更低的延迟实现了略低的智能水平。它也没有出现 high 模式下偶尔出现的极长尾延迟问题，并且有助于最大化用户的使用额度。因此，我们推出了将 medium 设为默认 effort 的变更，并通过应用内弹窗解释了理由。 上线后不久，用户开始反馈 Claude Code 显得不够智能。我们进行了多次设计迭代，使当前 effort 设置更加醒目，以提醒用户可以更改默认设置（启动时的通知、内联 effort 选择器、以及恢复 ultrathink），但大多数用户仍保持 medium effort 的默认设置。 在听取更多客户反馈后，我们于 4 月 7 日撤销了这一决定。现在所有用户默认对 Opus 4.7 使用 `xhigh` effort，对其他所有模型使用 `high` effort。 ## 一项丢弃先前推理的缓存优化 当 Claude 对任务进行推理时，这些推理通常会保留在对话历史中，以便在后续每一轮中，Claude 都能看到它为何做出那些编辑和工具调用。 3 月 26 日，我们上线了一项旨在提升该功能效率的改进。我们使用提示缓存来让连续的 API 调用对用户而言更便宜、更快。Claude 在发起 API 请求时将输入 token 写入缓存，一段时间不活动后，提示会从缓存中逐出，为其他提示腾出空间。缓存利用率是我们谨慎管理的（更多关于我们的方法，请参见 https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything）。 设计本应是简单的：如果会话已闲置超过一小时，我们可以通过清除旧的思考部分来降低用户恢复该会话的成本。由于请求本来就会缓存未命中，我们可以从请求中剪除不必要的消息，以减少发送至 API 的未缓存 token 数量。然后我们恢复发送完整的推理历史。为此，我们使用了 `clear_thinking_20251015` API 请求头以及 `keep:1`。 实现中存在一个 bug。它本应在会话恢复时只清除一次思考历史，但实际上却在会话后续的每一轮中都进行了清除。一旦会话跨越了闲置阈值，该进程后续的每个请求都会告诉 API 只保留最近的推理块，并丢弃之前的所有内容。这会产生叠加效应：如果你在 Claude 正在使用工具时发送了跟进消息，这会在损坏的标志下开启新一轮，因此就连当前轮次的推理也会被丢弃。Claude 会继续执行，但越来越不记得它为何选择做正在做的事情。这表现为人们反馈的健忘、重复和奇怪的工具选择。 由于这会持续丢弃后续请求中的思考块，这些请求也会导致缓存未命中。我们认为这正是使用额度消耗快于预期的独立反馈的原因。 两个无关的实验起初让我们难以复现该问题：一个是内部仅限服务端的消息队列实验；另一个是我们展示思考内容的方式的正交变更，在大多数 CLI 会话中抑制了这个 bug，因此即使测试外部构建时我们也没有发现。 这个 bug 位于 Claude Code 的上下文管理、Anthropic API 和扩展思考的交叉点。它所引入的变更通过了多轮人工和自动代码审查，以及单元测试、端到端测试、自动验证和内部试用。加上这仅发生在边缘情况（过期会话）中，且问题难以复现，我们花了一周多时间才发现并确认根本原因。 作为调查的一部分，我们对相关 pull request 使用 Opus 4.7 进行了 Code Review（https://code.claude.com/docs/en/code-review）的回溯测试。在提供必要的代码仓库以获取完整上下文时，Opus 4.7 发现了该 bug，而 Opus 4.6 没有。为防止此类问题再次发生，我们现在正在为代码审查添加对额外仓库作为上下文的支持。 我们于 4 月 10 日在 v2.1.101 中修复了该 bug。 ## 一项减少冗长的系统提示变更 我们的最新模型 Claude Opus 4.7 相对于其前代有一个显著的行为特点：正如我们在发布时所写（https://www.anthropic.com/news/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（https://code.claude.com/docs/en/code-review）工具，并将改进后的版本提供给客户。 我们还将对系统提示变更施加更严格的控制。对于 Claude Code 的每项系统提示变更，我们将为每个模型运行广泛的评估套件，持续进行消融实验以理解每行的影响，并已构建新工具使提示变更更易于审查和审计。我们还向 CLAUDE.md 添加了指导，确保针对特定模型的变更仅作用于其目标模型。对于任何可能与智能产生权衡的变更，我们将增加浸泡期、更广泛的评估套件和渐进式 rollout，以便更早发现问题。 我们最近在 X 上创建了 @ClaudeDevs 账号，以便深入解释产品决策及其背后的 reasoning。我们将在 GitHub 的集中线程中分享相同的更新。 最后，我们要感谢我们的用户：那些使用 `/feedback` 命令向我们反馈问题的人（或在网上发布具体、可复现示例的人），正是他们最终让我们能够识别并修复这些问题。今天，我们将为所有订阅者重置使用额度。 我们非常感谢您的反馈和耐心。