在过去一个月里，我们一直在调查部分用户报告称 Claude 的回应质量下降的问题。我们将这些报告追溯到三项独立变更，它们分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。

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

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

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

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

1. 3 月 4 日，我们将 Claude Code 的默认推理强度从高调整为中等，以降低一些用户在高强度模式下遇到的极长延迟——长到足以让 UI 看起来像是冻结了。这是一个错误的取舍。在用户告诉我们他们更希望默认使用更高智能，并在简单任务中选择较低强度后，我们于 4 月 7 日撤销了这一更改。此更改影响了 Sonnet 4.6 和 Opus 4.6。
2. 3 月 26 日，我们发布了一项更改：清除 Claude 在闲置超过一小时的会话中的较早思考内容，以降低用户恢复这些会话时的延迟。一个 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 默认推理强度的一项更改

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

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

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

在我们的内部评估和测试中，对于大多数任务，medium effort 在智能水平略低的情况下显著降低了延迟。它也没有出现同样的偶发性思考超长尾延迟问题，并且有助于最大化用户的使用限制。因此，我们推出了一项更改，将 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 写入缓存，然后在一段时间不活动后，该提示会从缓存中逐出，为其他提示腾出空间。缓存利用率是我们会谨慎管理的事项（更多关于我们方法的内容）。

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

实现中存在一个 bug。它不是只清除一次思考历史，而是在会话剩余期间的每一轮都清除。在一个会话跨过一次空闲阈值后，该进程剩余期间的每个请求都会指示 API 只保留最近的一段推理，并丢弃其之前的所有内容。这种影响会叠加：如果你在 Claude 正处于工具使用过程中时发送了一条后续消息，这会在错误标志下开始新的一轮，因此连当前轮次的推理也会被丢弃。Claude 会继续执行，但会越来越不记得它为什么选择去做正在做的事情。这表现为人们报告的健忘、重复以及奇怪的工具选择。

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

两个不相关的实验使我们一开始很难复现该问题：一个是与消息队列相关的仅限内部使用的服务器端实验；另一个是我们在显示思考过程方式上的一项正交变更，该变更在大多数 CLI 会话中抑制了这个 bug，因此即使在测试外部版本时我们也没有发现它。

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

作为调查的一部分，我们使用 Opus 4.7 对涉事 pull request 进行了 Code Review 回测。在提供了收集完整上下文所需的代码仓库后，Opus 4.7 发现了该 bug，而 Opus 4.6 没有发现。为防止此类情况再次发生，我们现在正在加入对额外代码仓库作为代码审查上下文的支持。

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

一次旨在降低冗长程度的系统提示词变更

我们的最新模型 Claude Opus 4.7 相较于其前代有一个显著的行为特点：正如我们在发布时所写的那样，它往往相当冗长。这使它在处理难题时更智能，但也会产生更多输出 token。

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

我们有多种工具可以降低冗长程度：模型训练、提示词，以及改进产品中的思考 UX。最终我们使用了所有这些方法，但对系统提示词的一项新增内容对 Claude Code 的智能表现产生了格外显著的影响：

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

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

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

展望未来

为避免这些问题，我们将采取几项不同的做法：我们会确保更大比例的内部员工使用与公开版本完全相同的 Claude Code（而不是我们用于测试新功能的版本）；并且我们会改进内部使用的 Code Review 工具，并将这一改进版本提供给客户。

我们还在对系统提示词变更增加更严格的控制。对于 Claude Code 的每一次系统提示词变更，我们都会运行一套广泛的、针对各模型的评测，继续进行消融实验，以了解每一行的影响；并且我们已经构建了新的工具，使提示词变更更易于审查和审计。此外，我们还在 CLAUDE.md 中增加了指导，以确保特定于模型的变更仅限于其目标模型。对于任何可能以智能水平为代价的变更，我们将增加观察期、更广泛的评测套件以及渐进式发布，以便更早发现问题。

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

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

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