关于近期 Claude Code 质量反馈的更新说明

#关于近期 Claude Code 质量反馈的更新说明

我们已将近期关于 Claude Code 质量问题的反馈追溯到三处彼此独立的改动。下面说明究竟发生了什么，以及我们正在做出哪些改变。

在过去一个月里，我们一直在调查"Claude 对部分用户的回复变差了"这类反馈。我们把这些反馈追溯到了三处影响 Claude Code、Claude Agent SDK 和 Claude Cowork 的彼此独立的改动。API 未受影响。

截至 4 月 20 日（v2.1.116），这三个问题现已全部解决。

在本文中，我们会说明我们发现了什么、修复了什么，以及我们将做出哪些不同的做法，以确保类似问题再次发生的可能性大大降低。

我们极其严肃地对待关于质量下降的反馈。我们绝不会有意降低我们模型的表现，而且我们能够立即确认我们的 API 与推理层均未受影响。

经过调查，我们识别出三个不同的问题：

1. 3 月 4 日，我们把 Claude Code 的默认推理强度（reasoning effort）从 high 改为 medium，以降低部分用户在 high 模式下遇到的、长到足以让界面看起来像卡死了一样的延迟。这是一个错误的取舍。在用户告诉我们他们更希望默认使用更高的智能、并主动为简单任务选择较低强度之后，我们于 4 月 7 日回退了这项改动。这影响了 Sonnet 4.6 和 Opus 4.6。
2. 3 月 26 日，我们上线了一项改动，用于清除那些闲置超过一小时的会话中 Claude 较早的思考内容，以降低用户恢复这些会话时的延迟。一个缺陷导致这一动作在会话余下的每一轮都持续发生，而不是只发生一次，这使得 Claude 显得健忘而重复。我们于 4 月 10 日修复了它。这影响了 Sonnet 4.6 和 Opus 4.6。
3. 4 月 16 日，我们添加了一条系统提示指令以减少冗长。与其他提示改动叠加在一起时，它损害了编码质量，并于 4 月 20 日被回退。这影响了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

由于每一项改动都在不同的时间表上影响了不同的那一部分流量，其叠加效果看起来就像是大范围、不一致的质量下降。尽管我们在 3 月初就开始调查这些反馈，但起初它们很难与用户反馈中的正常波动区分开来，而且我们的内部使用和评测（evals）一开始都未能复现所识别出的问题。

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

对 Claude Code 默认推理强度的一处改动

当我们于 2 月在 Claude Code 中发布 Opus 4.6 时，我们把默认推理强度设为 high。

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

一般来说，模型思考得越久，输出就越好。推理强度档位（effort levels）正是 Claude Code 让用户设定这一取舍的方式——更多的思考，对应更低的延迟和更少的用量限额消耗。当我们为各款模型校准强度档位时，我们会把这一取舍纳入考量，以便在测试时计算（test-time-compute）曲线上挑选出若干点，为人们提供最佳的一组选项。在产品层，我们随后选定曲线上哪一个点作为默认值，而那正是我们作为 effort 参数发送给 Messages API 的值；我们接着再通过 /effort 提供其余选项。

在我们的内部评测和测试中，对于绝大多数任务，中等强度（medium effort）以显著更低的延迟实现了略低的智能水平。它也没有遭遇同样那些偶尔出现的、非常长的思考尾延迟问题，并且有助于把用户的用量限额利用到最大。因此，我们推出了一项把 medium 设为默认强度的改动，并通过产品内对话框解释了背后的理由。

上线后不久，用户开始反馈 Claude Code 感觉没那么聪明了。我们推出了若干设计迭代，好让当前的强度设置更清晰，以提醒人们他们可以更改默认值（启动时的提示、一个内联的强度选择器，以及把 ultrathink 带了回来），但大多数用户仍保留着 medium 的默认强度。

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

一处丢弃了先前推理内容的缓存优化

当 Claude 逐步推演一项任务时，那段推理内容通常会被保留在对话历史里，好让 Claude 在随后的每一轮都能看到它当初为何做出那些编辑和工具调用。

3 月 26 日，我们上线了一项本意是对这一功能做效率改进的改动。我们使用提示缓存（prompt caching）来让连续的 API 调用对用户而言更便宜、更快。Claude 在发起一次 API 请求时会把输入 token 写入缓存，随后在一段不活动时间之后，该提示会从缓存中被逐出，为其他提示腾出空间。缓存利用率是我们悉心管理的一件事（详见我们的做法）。

这个设计本应很简单：如果一个会话已经闲置超过一小时，我们就可以通过清除旧的思考段落，来降低用户恢复该会话的成本。由于该请求无论如何都会是一次缓存未命中（cache miss），我们可以从请求中裁剪掉不必要的消息，以减少发送给 API 的未缓存 token 数量。随后我们会恢复发送完整的推理历史。为此，我们使用了 clear_thinking_20251015 这个 API 头部，并搭配 keep:1。

实现中存在一个缺陷。它没有只清除一次思考历史，而是在会话余下的每一轮都清除。一旦某个会话越过了闲置阈值一次，该进程在其余时间里的每一次请求都会告诉 API 只保留最近的那一段推理，并丢弃它之前的一切。这会不断累积：如果你在 Claude 正处于一次工具调用中途时发送了一条后续消息，那就在缺陷标志下开启了一个新的一轮，于是连当前这一轮的推理也被丢弃了。Claude 会继续执行，但对"它当初为何选择要做它正在做的事"却越来越没有记忆。这就表现成了人们所反馈的健忘、重复和古怪的工具选择。

由于这会持续地从后续请求中丢弃思考块，那些请求也因此导致缓存未命中。我们相信，这正是驱动那些"用量限额消耗得比预期快"的独立反馈的原因。

有两个互不相关的实验，使得我们一开始难以复现这个问题：一个是仅限内部的、与消息排队相关的服务器端实验；另一个是我们在思考内容展示方式上的一处正交改动，它在大多数 CLI 会话中抑制了这个缺陷，因此即便我们在测试对外构建版本时也没有捕捉到它。

这个缺陷位于 Claude Code 的上下文管理、Anthropic API 与扩展思考（extended thinking）三者的交汇处。它引入的那些改动通过了多轮人工和自动化的代码评审，以及单元测试、端到端测试、自动化验证和内部试用（dogfooding）。再加上这只在一个边角情况（陈旧会话）下才发生，且该问题难以复现，我们花了一周多才发现并确认根本原因。

作为调查的一部分，我们用 Opus 4.7 对那些出问题的拉取请求（pull requests）回测了 Code Review。在提供了收集完整上下文所必需的代码仓库时，Opus 4.7 找到了这个缺陷，而 Opus 4.6 没有。为防止此类情况再次发生，我们现在正在落地"把额外仓库作为代码评审上下文"的支持。

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

一处旨在减少冗长的系统提示改动

我们最新的模型 Claude Opus 4.7，相对于其前代有一个引人注目的行为怪癖：正如我们在发布时所写，它倾向于相当冗长。这让它在困难问题上更聪明，但也会产生更多的输出 token。

在我们发布 Opus 4.7 之前的几周，我们开始为它调优 Claude Code。每款模型的行为都略有不同，我们会在每次发布前花时间针对它优化好这套脚手架（harness）和产品。

我们有许多减少冗长的工具：模型训练、提示，以及在产品中改进思考的用户体验。最终我们把这些都用上了，但对系统提示的一处添加，却对 Claude Code 中的智能产生了超乎比例的影响：

_"Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail."_

在数周内部测试、且我们所运行的那组评测没有出现任何回归之后，我们对这项改动感到有信心，并于 4 月 16 日随 Opus 4.7 一同上线。

作为本次调查的一部分，我们使用一组更广泛的评测运行了更多消融实验（ablations，即从系统提示中移除若干行，以理解每一行的影响）。其中一项评测显示 Opus 4.6 和 4.7 都出现了 3% 的下降。我们立即把该提示作为 4 月 20 日发布的一部分回退了。

未来展望

我们将做出若干不同的做法以避免这些问题：我们会确保更大比例的内部员工使用与公开版本完全一致的 Claude Code 构建（而不是我们用来测试新功能的那个版本）；我们会对我们内部使用的 Code Review 工具做出改进，并把这个改进后的版本提供给客户。

我们还对系统提示改动增加了更严格的管控。对于 Claude Code 的每一处系统提示改动，我们都会运行一整套广泛的、按模型划分的评测，持续做消融实验以理解每一行的影响，并且我们已经构建了新工具，让提示改动更易于评审和审计。此外，我们还在 CLAUDE.md 中加入了指引，以确保特定于模型的改动被限定在它们所针对的那一款具体模型上。对于任何可能与智能做取舍的改动，我们都会加入浸泡期（soak periods）、一组更广泛的评测套件，以及灰度发布（gradual rollouts），以便我们更早地捕捉到问题。

我们最近在 X 上创建了 @ClaudeDevs，好让我们有空间去深入解释产品决策及其背后的推理。我们会在 GitHub 上以集中式的讨论串分享同样的更新。

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

我们对你们的反馈和耐心深怀感激。

PRIMARY_SOURCE: https://www.anthropic.com/engineering/april-23-postmortem