关于近期 Claude Code 质量问题报告的更新
我们将近期关于 Claude Code 质量问题的报告追溯到了三项彼此独立的变更。以下是事情经过，以及我们将做出的调整。
在过去一个月里，我们一直在调查一些用户反馈，称 Claude 的回答质量有所下降。我们已将这些报告追溯到三项分别影响了 Claude Code、Claude Agent SDK 和 Claude Cowork 的独立变更。API 未受到影响。
截至 4 月 20 日（v2.1.116），这三个问题现已全部解决。
在这篇文章中，我们会说明我们发现了什么、修复了什么，以及我们将如何改变做法，以确保类似问题今后再次发生的可能性大幅降低。
我们非常严肃地对待关于性能退化的报告。我们从不会故意降低模型质量，而且我们也能够立即确认，我们的 API 和推理层并未受到影响。
经过调查，我们识别出了三个不同的问题：
- 3 月 4 日，我们将 Claude Code 的默认推理强度从
high调整为medium，以减少部分用户在high模式下遇到的超长延迟——长到足以让 UI 看起来像是卡死。这是一个错误的权衡。在用户告诉我们，他们更希望默认获得更高智能，并在简单任务中自行选择较低强度后，我们于 4 月 7 日回滚了这一变更。此问题影响了 Sonnet 4.6 和 Opus 4.6。 - 3 月 26 日，我们上线了一项变更：对于闲置超过一小时的会话，清除 Claude 较早的思考内容，以减少用户恢复这些会话时的延迟。一个 bug 导致这一操作并非只执行一次，而是在该会话剩余的每一轮对话中持续发生，这让 Claude 显得健忘且重复。我们于 4 月 10 日修复了该问题。此问题影响了 Sonnet 4.6 和 Opus 4.6。
- 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 时，我们将默认推理强度设为 high。
不久之后，我们收到用户反馈称，Claude Opus 4.6 在高强度模式下有时会思考过久，导致 UI 看起来像是卡住了，并给这些用户带来不成比例的延迟和 token 使用量。
总体而言，模型思考得越久，输出通常越好。强度等级就是 Claude Code 让用户设定这种权衡的方式——更多思考，还是更低延迟和更少触发使用限额。在为模型校准强度等级时，我们会考虑这种权衡，以便在测试时计算曲线上选择能为用户提供最佳选项范围的点。在产品层，我们随后决定将这条曲线上的哪个点设为默认值，并将该值作为 effort 参数发送给 Messages API；然后再通过 /effort 提供其他选项。
在我们的内部评测和测试中，对于大多数任务而言，medium 强度以显著更低的延迟换来了略低一些的智能水平。它也不会像高强度那样偶尔出现极长尾的思考延迟，并且有助于最大化用户的使用限额。因此，我们逐步推出了一项变更，将 medium 设为默认强度，并通过产品内对话框解释了这样做的理由。
在变更推出后不久，用户开始反馈 Claude Code 感觉没那么聪明了。我们进行了多轮设计迭代，以更清楚地展示当前的强度设置，从而提醒用户他们可以更改默认值（包括启动时提示、内联强度选择器，以及重新加入 ultrathink），但大多数用户仍然保留了 medium 这一默认强度。
在听取更多客户反馈后，我们于 4 月 7 日撤销了这一决定。现在，所有用户在使用 Opus 4.7 时默认采用 xhigh 强度，而其他所有模型默认采用 high 强度。
一项导致先前推理被丢弃的缓存优化
当 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 和扩展思考功能的交叉点上。它所引入的变更通过了多轮人工和自动化代码审查，以及单元测试、端到端测试、自动验证和内部试用。再加上它只会发生在一个边缘场景（陈旧会话）中，而且问题难以复现，我们花了一周多时间才发现并确认根本原因。
作为调查的一部分，我们使用 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 命令向我们反馈问题的人（或者在线发布了具体、可复现示例的人），正是他们最终帮助我们识别并修复了这些问题。今天，我们正在为所有订阅用户重置使用限额。
我们对你们的反馈和耐心深表感激。
获取开发者新闻通讯
产品更新、操作指南、社区聚焦等更多内容。每月发送到你的收件箱。
如果你希望接收我们的每月开发者新闻通讯，请提供你的电子邮件地址。你可以随时取消订阅。