获取开发者简报
产品更新、操作指南、社区聚焦等。每月发送至您的收件箱。
在过去一个月里，我们一直在调查有关部分用户反映 Claude 的回复质量下降的报告。我们已将这些报告追溯到三项不同的变更，它们分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork。API 未受影响。
截至 4 月 20 日（v2.1.116），所有三个问题均已解决。
在本文中，我们将解释我们发现了什么、修复了什么，以及我们将采取哪些不同的做法，以确保类似问题再次发生的可能性大大降低。
我们非常严肃地对待有关性能下降的报告。我们绝不会故意降低模型的能力，并且我们能够立即确认我们的 API 和推理层未受影响。
经过调查，我们确定了三个不同的问题：
high
到 medium
以减少部分用户在 high 模式下遇到的极长延迟——长到足以让 UI 看起来像卡死了一样。这是一个错误的权衡。在用户告诉我们他们更愿意默认使用更高的智能水平、并在简单任务上选择较低的努力程度后，我们于 4 月 7 日回退了这一变更。这影响了 Sonnet 4.6 和 Opus 4.6。由于每项变更在不同时间影响了不同的流量部分，综合效果看起来像是广泛且不一致的性能下降。虽然我们在三月初就开始调查相关报告，但起初很难将它们与用户反馈中的正常波动区分开来，而且我们的内部使用情况和评估最初都未能复现所发现的问题。
这不是用户应该从 Claude Code 中获得的体验。截至 4 月 23 日，我们将为所有订阅者重置使用限制。
当我们在二月份于 Claude Code 中发布 Opus 4.6 时，我们将默认推理努力程度设置为 high。
不久之后，我们收到用户反馈，称 Claude Opus 4.6 在高努力模式下偶尔会思考过长时间，导致 UI 看起来像卡死了一样，并给这些用户带来不成比例的延迟和 token 消耗。
一般来说，模型思考的时间越长，输出就越好。努力程度级别是 Claude Code 让用户设定这种权衡的方式——更多思考与更低延迟和更少触及使用限制之间的取舍。当我们为模型校准努力程度级别时，我们会考虑这种权衡，以便在测试时计算曲线上选取能为人们提供最佳选项范围的点。在产品层，我们随后选择将这条曲线上的哪个点设为默认值，这就是我们作为 effort 参数发送给 Messages API 的值；然后我们通过 /effort 提供其他选项。
在我们的内部评估和测试中，对于大多数任务，中等努力程度实现了略低的智能水平，但延迟显著降低。它也没有遭遇偶尔出现极长尾延迟的思考问题，并且有助于最大化用户的使用限制。因此，我们推出了一项变更，将中等努力设为默认值，并通过产品内对话框解释了理由。
推出后不久，用户开始反映 Claude Code 感觉不那么智能了。我们发布了多项设计迭代，使当前的努力程度设置更加清晰，以提醒人们可以更改默认值（启动时的通知、内联努力程度选择器，以及恢复 ultrathink），但大多数用户仍保留了中等努力程度的默认值。
在听取更多客户的反馈后，我们于 4 月 7 日撤销了这一决定。现在所有用户默认使用 xhigh
Opus 4.7 使用 high
努力级别，而所有其他模型使用 high
努力级别。
当 Claude 对一项任务进行推理时，该推理通常会保留在对话历史中，以便在之后的每一轮中，Claude 都能看到它为何做出那些编辑和工具调用。
3 月 26 日，我们发布了一项本意是对此功能进行效率改进的更新。我们使用提示缓存来让连续的 API 调用对用户来说更便宜、更快速。当 Claude 发起 API 请求时，它会将输入 token 写入缓存，然后在一段不活动时间后，该提示会从缓存中被逐出，为其他提示腾出空间。缓存利用率是我们会谨慎管理的事项（更多内容见我们的方法）。
该设计本应很简单：如果某个会话空闲超过一小时，我们就可以通过清除旧的思考部分来降低用户恢复该会话的成本。由于该请求无论如何都会是缓存未命中，我们可以从请求中修剪不必要的消息，以减少发送到 API 的未缓存 token 数量。然后我们会恢复发送完整的推理历史。为此，我们使用了 clear_thinking_20251015
API 头以及 keep:1
。
该实现存在一个 bug。它不是只清除一次思考历史，而是在该会话剩余时间的每一轮中都清除它。一旦某个会话越过空闲阈值一次，该进程剩余时间内的每个请求都会告诉 API 只保留最近的一块推理，并丢弃它之前的所有内容。这会不断累积：如果你在 Claude 正在进行工具使用的中途发送一条后续消息，那会在损坏的标志下开启新一轮，因此连当前轮的推理也会被丢弃。Claude 会继续执行，但越来越不知道自己为何选择正在做的事情。这表现为人们报告的健忘、重复和奇怪的工具有选择。
由于这会持续从后续请求中丢弃思考块，那些请求也会导致缓存未命中。我们相信这正是导致有关使用限制比预期更快耗尽这一单独报告的原因。
两个不相关的实验最初让我们难以复现该问题：一个仅限内部的、与消息排队相关的服务器端实验；以及我们在显示思考方式上的一项正交变更，它在大多数 CLI 会话中抑制了这个 bug，因此即使测试外部构建时我们也没有发现它。
这个 bug 位于 Claude Code 的上下文管理、Anthropic API 和扩展思考的交汇处。它引入的变更通过了多轮人工和自动化代码审查，以及单元测试、端到端测试、自动化验证和内部试用。再加上这只发生在一种边缘情况（陈旧会话）中，并且难以复现，我们花了一周多时间才发现并确认根本原因。
作为调查的一部分，我们使用 Opus 4.7 对涉事的拉取请求回测了 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。每个模型的行为都略有不同，我们会在每次发布前花时间针对它优化 harness 和产品。
我们有许多工具来减少啰嗦：模型训练、提示词，以及改进产品中的思考 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
命令向我们分享问题的人（或在网上发布具体、可复现示例的人）最终让我们得以识别并修复这些问题。今天，我们正在为所有订阅者重置使用限制。
我们对你们的反馈和耐心深表感激。
产品更新、操作指南、社区聚焦等。每月发送到您的收件箱。