核验日期：2026-07-08

内容来源：Anthropic Engineering 官方技术博客。本文先作为 Claude Code 专区后台草稿入库，发布前应由内容人员复核标题、摘要、图片、来源链接与是否需要补充本站实践说明。

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

我们将近期关于 Claude Code 质量问题的报告追溯到三个彼此独立的变更。本文说明发生了什么，以及我们将如何改进。

来源：https://www.anthropic.com/engineering/april-23-postmortem
发布日期：2026-04-23

过去一个月里，我们一直在调查一些用户反馈的 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 模式下遇到的超长延迟，这种延迟长到足以让 UI 看起来像是冻结了。这是一个错误的权衡。4 月 7 日，在用户告诉我们他们更希望默认保持更高智能、并在简单任务上主动选择较低 effort 后，我们回滚了这个变更。它影响了 Sonnet 4.6 和 Opus 4.6。
2. 3 月 26 日，我们发布了一项变更：对于空闲超过一小时的 session，清理 Claude 较早的 thinking，以降低用户恢复这些 session 时的延迟。一个 bug 导致这项清理不是只发生一次，而是在该 session 后续每一轮都持续发生，使 Claude 显得健忘且重复。我们在 4 月 10 日修复了它。它影响了 Sonnet 4.6 和 Opus 4.6。
3. 4 月 16 日，我们添加了一条系统 prompt 指令来降低冗长程度。它与其他 prompt 变更结合后，损害了编码质量，并于 4 月 20 日被回滚。它影响了 Sonnet 4.6、Opus 4.6 和 Opus 4.7。

由于每个变更在不同时间表上影响了不同流量切片，汇总起来的效果看起来像是广泛且不一致的质量退化。虽然我们在 3 月初就开始调查相关反馈，但一开始很难把它们与用户反馈中的正常波动区分开来，而且我们的内部使用和 evals 最初也没有复现已识别的问题。

这不应该是用户从 Claude Code 中预期得到的体验。截至 4 月 23 日，我们正在为所有订阅者重置使用限制。

Claude Code 默认 reasoning effort 的一次变更

我们在 2 月于 Claude Code 中发布 Opus 4.6 时，把默认 reasoning effort 设为 high。

不久之后，我们收到用户反馈：Claude Opus 4.6 在 high effort 模式下偶尔会思考太久，导致 UI 看起来像是冻结了，并给这些用户带来不成比例的延迟和 token 使用量。

通常来说，模型思考得越久，输出就越好。Effort level 是 Claude Code 让用户设置这种权衡的方式，也就是更多思考和更低延迟、更少触发使用限制之间的取舍。在为模型校准 effort level 时，我们会考虑这种权衡，以便沿着 test-time-compute 曲线选择一些点，给用户提供最好的选项范围。在产品层，我们随后选择这条曲线上的哪个点作为默认值，并把它作为 effort 参数发送给 Messages API；其他选项则通过 /effort 提供。

在我们的内部 evals 和测试中，对于多数任务，medium effort 以显著更低的延迟实现了略低的智能水平。它也不会出现同样偶发的超长尾部思考延迟问题，并且有助于最大化用户的使用限制。因此，我们推出了一项变更，把 medium 设为默认 effort，并通过产品内对话解释了原因。

推出后不久，用户开始反馈 Claude Code 感觉不那么聪明了。我们做了多轮设计迭代，让当前 effort 设置更清楚，以提醒人们可以修改默认值（启动时通知、内联 effort selector，以及恢复 ultrathink），但大多数用户仍保留了 medium effort 默认值。

在听到更多客户反馈后，我们在 4 月 7 日撤销了这个决定。现在所有用户在 Opus 4.7 上默认使用 xhigh effort，在其他所有模型上默认使用 high effort。

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

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

3 月 26 日，我们发布了一项本意是改进该功能效率的变更。我们使用 prompt caching 来让连续 API 调用对用户来说更便宜、更快。Claude 在发起 API 请求时会把输入 token 写入缓存，然后在一段时间不活跃后，该 prompt 会从缓存中淘汰，为其他 prompt 腾出空间。缓存利用率是我们会谨慎管理的事情（更多内容见我们的方法）。

设计本应很简单：如果一个 session 已经空闲超过一小时，我们可以通过清理旧 thinking section 来降低用户恢复该 session 的成本。由于请求无论如何都会是一次 cache miss，我们可以从请求中裁剪不必要的消息，减少发送给 API 的未缓存 token 数量。之后我们会恢复发送完整推理历史。为此，我们使用了 clear_thinking_20251015 API header，并配合 keep:1。

实现中有一个 bug。它不是只清理一次 thinking history，而是在该 session 后续每一轮都清理。一个 session 只要跨过一次空闲阈值，该进程后续的每个请求都会告诉 API 只保留最近一个推理块，并丢弃此前的一切。这种影响会叠加：如果你在 Claude 正处于工具使用中途时发送了一条后续消息，它会在损坏的标志下开始新一轮，因此甚至当前轮的推理也会被丢弃。Claude 会继续执行，但越来越不记得自己为什么选择做正在做的事情。这表现为人们报告的健忘、重复和奇怪的工具选择。

由于这会持续从后续请求中丢弃 thinking blocks，这些请求也会导致 cache miss。我们认为，这就是另一些关于使用限制比预期更快耗尽的报告的原因。

两个无关实验让我们一开始很难复现这个问题：一个是仅限内部的服务端实验，与消息队列有关；另一个是我们显示 thinking 的方式发生了正交变化，在大多数 CLI session 中抑制了这个 bug，因此即使测试外部 build，我们也没有捕捉到它。

这个 bug 位于 Claude Code 的上下文管理、Anthropic API 和 extended thinking 的交汇处。它引入的变更通过了多轮人工和自动代码审查，也通过了单元测试、端到端测试、自动验证和内部试用。再加上它只发生在一个边界情况（陈旧 session）中，并且问题很难复现，我们花了一周多才发现并确认根因。

作为调查的一部分，我们使用 Opus 4.7 对相关 pull request 进行了 Code Review 回测。当提供收集完整上下文所需的代码仓库时，Opus 4.7 找到了这个 bug，而 Opus 4.6 没有。为了防止这种情况再次发生，我们现在正在为代码审查落地对额外仓库作为上下文的支持。

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

一项用于降低冗长程度的系统 prompt 变更

我们的最新模型 Claude Opus 4.7，相比前代有一个显著的行为特点：正如我们在发布时写到的，它往往相当冗长。这让它在困难问题上更聪明，但也会产生更多输出 token。

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

我们有多种工具可以降低冗长程度：模型训练、prompting，以及改进产品中的 thinking UX。最终我们使用了所有这些方法，但对系统 prompt 的一项新增内容，对 Claude Code 中的智能表现造成了过大的影响：

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

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

作为本次调查的一部分，我们使用更广泛的一组评估运行了更多 ablation（从系统 prompt 中移除不同语句，以理解每行的影响）。其中一项评估显示 Opus 4.6 和 4.7 都下降了 3%。我们立即在 4 月 20 日发布中回滚了该 prompt。

接下来

我们将以几种不同方式避免这些问题：我们会确保更多内部员工使用 Claude Code 的确切公开 build（而不是我们用于测试新功能的版本）；并且我们会改进内部使用的 Code Review 工具，同时把这个改进版本交付给客户。

我们还在为系统 prompt 变更增加更严格的控制。对于 Claude Code 的每一次系统 prompt 变更，我们都会运行覆盖更广的、按模型划分的 evals，继续通过 ablation 理解每一行的影响，并且已经构建了新的工具，让 prompt 变更更容易审查和审计。我们还在 CLAUDE.md 中添加了指导，确保特定模型的变更只作用于其目标模型。对于任何可能与智能表现产生权衡的变更，我们会增加 soak period、更广泛的 eval suite 和渐进式发布，以便更早发现问题。

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

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

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