Anthropic 复盘 Claude Code 质量问题：三项变更已修复，API 未受影响

过去一个月，我们一直在调查一些用户关于 Claude 回答质量下降的反馈。我们追查发现，这些反馈源于三项不同的变更，影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。

截至 April 20（v2.1.116），这三个问题均已解决。

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

我们非常重视有关质量下降的反馈。我们从不故意降低模型质量，而且我们立即就确认了 API 和推理层未受影响。

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

March 4，我们将 Claude Code 的默认推理强度从 high 改为 medium，以减少一些用户在 high 模式下遇到的极长延迟——这种延迟足以让界面看起来像是卡住了。这是一次错误的取舍。用户告诉我们，他们更希望默认采用更高的智能水平，并在处理简单任务时自行选择较低的推理强度，因此我们于 April 7 撤销了这项变更。这影响了 Sonnet 4.6 和 Opus 4.6。
March 26，我们推出了一项变更，清除闲置超过一小时的会话中 Claude 较早的思考内容，以减少用户恢复这些会话时的延迟。一个缺陷导致这一清除操作并非只执行一次，而是在该会话余下的每一轮中持续发生，使 Claude 显得健忘且反复重复。我们于 April 10 修复了这个问题。这影响了 Sonnet 4.6 和 Opus 4.6。
April 16，我们在系统提示词中添加了一条减少冗长表述的指令。它与其他提示词变更共同作用，损害了编码质量，因此于 April 20 被撤销。这影响了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

由于每项变更都在不同的时间影响了不同部分的流量，综合起来看，就像是出现了广泛且不一致的质量下降。虽然我们在 March 初便开始调查这些反馈，但起初很难将其与用户反馈中的正常波动区分开来，而且我们的内部使用和评估最初都未能复现后来发现的问题。

这不是用户使用 Claude Code 时应有的体验。截至 April 23，我们正在为所有订阅用户重置使用限额。

Claude Code 默认推理强度的一项变更

我们在 February 于 Claude Code 中发布 Opus 4.6 时，将默认推理强度设为 high。

不久之后，我们收到用户反馈，称 Claude Opus 4.6 在高推理强度模式下偶尔会思考过久，导致界面看起来像是卡住了，并给这些用户带来不成比例的延迟和 token 用量。

一般来说，模型思考的时间越长，输出质量就越好。Claude Code 通过推理强度级别让用户自行权衡：是让模型思考更多，还是降低延迟并减少触及使用限额的次数。我们在校准模型的推理强度级别时，会考虑这一取舍，以便在测试时计算量曲线上选出能为用户提供最佳选择范围的点。在产品层面，我们随后会选择将这条曲线上的哪个点设为默认值，并将该值作为 effort 参数发送给 Messages API；然后，我们通过 /effort 提供其他选项。

在我们的内部评估和测试中，对于大多数任务，中等推理强度下的智能表现略低，但延迟显著降低。它也没有出现同样的推理耗时偶尔极长的长尾延迟问题，而且有助于让用户的使用额度得到最大限度的利用。因此，我们推出了一项变更，将中等设为默认推理强度，并通过产品内对话框解释了原因。

推出后不久，用户开始反馈 Claude Code 感觉变笨了。我们进行了多轮设计迭代，让当前的推理强度设置更加醒目，以提醒用户可以更改默认设置（包括启动时的提示、内嵌的推理强度选择器，以及重新引入 ultrathink），但大多数用户仍保留了中等推理强度这一默认设置。

在听取更多客户的反馈后，我们于 April 7 撤销了这一决定。现在，所有用户使用 Opus 4.7 时的默认推理强度均为 xhigh，使用其他所有模型时的默认推理强度均为 high。

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

当 Claude 对任务进行推理时，这些推理内容通常会保留在对话历史中，以便在后续每一轮交互中，Claude 都能看到自己为何进行了此前的编辑和工具调用。

在 March 26，我们推出了一项本意是提高该功能效率的改进。我们使用提示词缓存，让用户连续进行的 API 调用成本更低、速度更快。Claude 在发起 API 请求时会将输入 token 写入缓存，随后在一段时间没有活动后，提示词会被移出缓存，为其他提示词腾出空间。我们会仔细管理缓存利用率（更多信息请参阅我们的方法）。

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

实现中存在一个缺陷。它并非只清除一次思考历史，而是在该会话剩余的每一轮交互中都会清除。会话一旦超过闲置时间阈值，该进程后续的每个请求都会要求 API 仅保留最近一个推理块，并丢弃此前的所有推理内容。问题还会叠加：如果你在 Claude 使用工具的过程中发送后续消息，就会在这个有问题的标志下开启新一轮交互，因此连当前这一轮的推理内容也会被丢弃。Claude 会继续执行，但会越来越记不清自己为什么选择执行当前的操作。这就表现为用户所反馈的健忘、重复和奇怪的工具选择。

由于这会持续从后续请求中丢弃思考块，这些请求也无法命中缓存。我们认为，这就是另一些用户反馈使用额度消耗速度超出预期的原因。

两项互不相关的实验使我们起初难以复现这一问题：一项是仅在内部开展、与消息排队有关的服务端实验；另一项则是对思考内容显示方式所做的独立改动，它在大多数 CLI 会话中抑制了这一缺陷，因此即使在测试对外发布的版本时，我们也没有发现它。

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

作为调查的一部分，我们使用 Opus 4.7，针对引发问题的拉取请求，对 Code Review 进行了回溯测试。在提供了收集完整上下文所需的代码仓库后，Opus 4.7 找到了这个 bug，而 Opus 4.6 没有。为防止此类问题再次发生，我们正在落实相关支持，以便在代码审查时将更多仓库用作上下文。

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

为减少冗长输出而修改系统提示词

相较于前代，我们的最新模型 Claude Opus 4.7 有一个显著的行为特点：正如我们在发布时撰文提到的那样，它往往相当啰嗦。这让它在处理难题时更聪明，但也会产生更多输出 token。

在发布 Opus 4.7 前几周，我们就开始调整 Claude Code，为发布做准备。每个模型的行为都略有不同，因此每次发布前，我们都会花时间针对模型优化运行框架和产品。

我们有多种减少冗长输出的手段：模型训练、提示词，以及改善产品中的思考过程用户体验。最终我们采用了所有这些手段，但系统提示词中新增的一项内容对 Claude Code 的智能表现产生了过大的影响：

“长度限制：工具调用之间的文本保持在 ≤25 词。最终回复保持在 ≤100 词，除非任务需要更详细的内容。”

经过数周的内部测试，我们运行的一组评估均未出现性能退化，因此我们对这项改动有了信心，并于 April 16 随 Opus 4.7 一同发布。

作为此次调查的一部分，我们使用更广泛的一组评估，进行了更多消融实验（从系统提示词中删除某些行，以了解每一行的影响）。其中一项评估显示，Opus 4.6 和 4.7 的表现均下降了 3%。我们立即在 April 20 的版本发布中撤销了这项提示词改动。

今后的做法

为避免这些问题，我们将调整几项做法：确保更大比例的内部员工使用与公开发布版本完全一致的 Claude Code（而不是我们用来测试新功能的版本）；改进我们内部使用的 Code Review 工具，并向客户发布改进后的版本。

我们还将加强对系统提示词改动的管控。对于 Claude Code 的每一次系统提示词改动，我们都会针对各个模型运行一套广泛的评估，并继续开展消融实验，以了解每一行的影响；我们还构建了新工具，让提示词改动更易于审查和审计。此外，我们已在 CLAUDE.md 中添加指导，确保针对特定模型的改动仅对其目标模型生效。对于任何可能以智能表现为代价的改动，我们都会增加持续观察期、扩大评估范围并逐步推出，以便更早发现问题。

我们最近在 X 上创建了 @ClaudeDevs，让我们有空间深入解释产品决策及其背后的考量。我们也会在 GitHub 上的集中讨论串中分享相同的更新。

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

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