近期 Claude Code 质量问题复盘¶
原文发布于 2026 年 4 月 23 日
概要¶
我们追踪到近期 Claude Code 质量下降的报告源于三个独立的变更，API 未受影响，所有问题已在 v2.1.116 中修复。 过去一个月，Anthropic 调查了部分用户反馈的 Claude 响应质量下降问题，最终定位到三个分别影响 Claude Code、Claude Agent SDK 和 Claude Cowork 的变更。API 和推理层均未受影响。
我们从不会故意降低模型能力。以下是发现的问题、修复方案，以及我们将如何改进流程。
三个问题总览¶
| # | 变更日期 | 问题 | 影响模型 | 修复日期 |
|---|---|---|---|---|
| 1 | 3 月 4 日 | 默认推理努力等级从 high 改为 medium |
Sonnet 4.6, Opus 4.6 | 4 月 7 日 |
| 2 | 3 月 26 日 | 缓存优化 bug 导致每轮都清除推理历史 | Sonnet 4.6, Opus 4.6 | 4 月 10 日 (v2.1.101) |
| 3 | 4 月 16 日 | 系统提示词中的字数限制指令削弱编码能力 | Sonnet 4.6, Opus 4.6, Opus 4.7 | 4 月 20 日 |
由于每个变更影响的用户群和时间段不同，叠加后的效果看起来像是"广泛且不一致的整体退化"，早期难以与正常波动区分开，内部评估和使用也未能复现问题。
截至 4 月 23 日，所有订阅用户的用量限额已重置。
问题一：默认推理努力等级变更¶
为解决高努力模式下的延迟问题而降低默认值，结果牺牲了智能——这是一个错误的权衡。 2 月 Opus 4.6 上线 Claude Code 时，默认推理努力等级设为 high。但用户反馈在 high 模式下，Opus 4.6 偶尔会思考过久，导致 UI 看起来像是卡住了，延迟和 token 消耗也不成比例。
推理努力等级的本质¶
更长的思考通常产出更优的结果。努力等级让用户自行在"更多思考"和"更低延迟/更少配额消耗"之间做取舍。在产品层面，我们选择一个默认值通过 effort 参数发送给 Messages API，用户也可以通过 /effort 命令自行调整。
为何做了这个变更¶
内部评估显示，medium 努力在大多数任务上"智能略低但延迟显著减少"，且没有 high 模式那样的长尾延迟问题，还能帮用户最大化用量配额。于是我们将 medium 设为默认值，并通过产品内弹窗向用户说明。
用户反馈与回滚¶
用户开始反馈"Claude Code 变笨了"。我们做了多轮设计迭代（启动提示、内联选择器、恢复 ultrathink），但大多数用户仍保留在 medium 默认值。
在更多客户反馈后，4 月 7 日回滚了这一决定。当前默认值：Opus 4.7 使用 xhigh，其他所有模型使用 high。
问题二：缓存优化 bug 丢失推理历史¶
本意是在会话空闲超过一小时后清理旧推理以节省成本，但 bug 导致此后每一轮都在清除推理历史，Claude 逐渐丧失了自己为何这样做的记忆。
背景¶
Claude 进行推理时，推理内容会保留在对话历史中，以便后续轮次可以参考之前的决策依据。我们使用 Prompt Caching 使连续 API 调用更快更便宜——Claude 会将输入 token 写入缓存；一段时间不活跃后缓存被驱逐。
设计意图¶
如果会话空闲超过一小时，缓存已经失效，此时清除旧的 thinking 区块以减少恢复成本是合理的。之后再恢复发送完整推理历史。技术上使用 clear_thinking_20251015 API header 并设置 keep:1（只保留最近一个推理块）。
Bug 的表现¶
"本应只清除一次推理历史，结果变成了会话后续每一轮都在清除。"
一旦跨过空闲阈值，后续每个请求都会告诉 API 只保留最近的推理块、丢弃之前所有内容。这还会叠加——如果在工具调用期间发送后续消息，新的 turn 在 broken flag 下开始，甚至连当前轮的推理也被丢弃。
Claude 会继续执行，但"越来越不记得自己为什么选择做当前正在做的事"。外在表现为：健忘、重复、以及奇怪的工具选择。
由于 thinking 块被持续丢弃，请求不断产生 cache miss。我们相信这也是部分用户反馈"用量配额消耗比预期快得多"的原因。
为何难以发现¶
两个无关的内部实验增加了复现难度：一个是与消息队列相关的服务端实验（仅内部），另一个是 thinking 展示方式的改动恰好在大多数 CLI 会话中抑制了 bug 的表现——即使在外部构建测试中也无法检测到。
这个 bug 处于上下文管理、Anthropic API 和 extended thinking 的交叉点。相关变更通过了"多轮人工和自动化代码评审、单元测试、端到端测试、自动验证以及内部试用"。加之它只在长时间空闲的会话中触发且难以复现，从发现到定位根因花了一周多。
一个有趣的发现¶
我们用 Opus 4.7 对出问题的 PR 进行了事后 Code Review。当提供了获取完整上下文所需的代码仓库后，Opus 4.7 发现了这个 bug，而 Opus 4.6 没有。 我们正在为 Code Review 工具增加"额外仓库作为上下文"的支持。
4 月 10 日在 v2.1.101 中修复。
问题三：系统提示词减少冗长度¶
一条看似无害的字数限制指令，在更大范围的评估中导致了 3% 的智能下降。 Claude Opus 4.7 有一个已知特征：正如发布时所说，"它倾向于非常冗长"。这在难题上使它更聪明，但也产生更多输出 token。
处理方式¶
为 Opus 4.7 发布做准备时，我们用了多种方式降低冗长度：模型训练、prompt 调优、改进 thinking UX。其中一条系统提示词造成了不成比例的负面影响：
"Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail."
发现与回滚¶
经过数周内部测试，评估集中未见回归，于 4 月 16 日随 Opus 4.7 一起发布。但在此次调查中，我们用更大范围的评估集做了消融实验，发现这条指令在 Opus 4.6 和 Opus 4.7 上均导致 3% 的智能下降。随即在 4 月 20 日的发布中回滚。
后续改进¶
从流程和工具两方面入手，确保类似问题更早被发现。
| 改进方向 | 具体措施 |
|---|---|
| 内部使用 | 确保更多内部员工使用与公开版完全相同的 Claude Code 构建，而非测试新功能的内部版本 |
| Code Review | 改进内部使用的 Code Review 工具，并向用户提供改进版本；支持额外仓库作为上下文 |
| 系统提示词管控 | 每次系统提示词变更都跑广泛的 per-model 评估套件；持续做消融实验理解每行 prompt 的影响 |
| 变更审计 | 构建新工具，方便 prompt 变更的 review 和审计 |
| 模型特异性 | CLAUDE.md 中增加指引，确保模型特定的变更只影响目标模型 |
| 发布流程 | 对影响智能的变更增加观察期(soak period)、更广的评估套件和渐进式发布 |
| 沟通渠道 | 通过 @ClaudeDevs 和 GitHub 集中讨论串解释产品决策 |
致谢¶
感谢使用 /feedback 命令或在网上发布具体可复现案例的用户——正是这些反馈最终帮助我们定位和修复了这些问题。
"We're immensely grateful for your feedback and for your patience."