2026 年 4 月 23 日，Anthropic 发布了一篇罕见的工程博客，详细解释了过去一个月用户反映 Claude Code 变笨、变重复、用量消耗异常的根本原因。三个独立问题叠加，造成了像是"广泛品质下降"的表象。所有问题已于 4 月 20 日（v2.1.116）修复完毕。
Anthropic 同时宣布：向所有订阅用户重置使用额度。
背景：用户反映了什么
过去一个月，大量用户反馈：
- Claude Code 感觉"变笨了"，不如以前聪明
- 在长对话里变得健忘，重复做已做过的事
- 奇怪的工具调用选择，像是"失忆"
- 使用额度消耗比预期快得多
Anthropic 立即展开调查，最终追踪到三个独立原因。
问题一：推理努力等级被悄悄调低
时间线：3 月 4 日调低 → 4 月 7 日恢复
发生了什么：
2 月发布 Opus 4.6 时，Claude Code 默认推理努力等级设为 high（高）。随后收到用户反馈：Opus 4.6 在高努力模式下偶尔会思考太久，导致 UI 看起来像是卡死，并产生过多的 Token 消耗。
Anthropic 内部评估认为，medium（中等）努力达到了"略低的智能，但显著更少的延迟"的权衡，对大多数任务足够好。于是在 3 月 4 日将默认值悄悄改为 medium，并通过产品内弹窗解释了原因。
问题在于：这个判断是错误的。用户开始反映 Claude Code 感觉"更笨了"，Anthropic 在 4 月 7 日听取了更多用户意见后，决定逆转这一决定。
当前状态：
- Opus 4.7 用户：默认
xhigh（超高）努力 - 所有其他模型：默认
high（高）努力
用户可以通过 /effort 命令手动调整努力等级。
问题二：缓存优化 Bug 导致推理记忆持续丢失
时间线：3 月 26 日引入 → 4 月 10 日修复（v2.1.101）
这是三个问题中技术上最复杂的一个，也是造成"Claude 突然失忆"现象的根本原因。
背景知识：当 Claude 推理一个任务时，它的推理过程会保存在对话历史里。这样在后续每一轮对话中，Claude 都能看到它为什么做了那些修改和工具调用。这个推理历史对保持连贯性至关重要。
设计意图：
Anthropic 决定做一个效率优化：如果一个会话已经空闲超过 1 小时，在用户恢复时可以清理旧的推理历史来节省成本（因为缓存已过期，重发这些内容是额外开销）。
具体实现使用了 clear_thinking_20251015 API 头部，配合 keep:1 参数——理论上只在空闲后清理一次旧推理，然后恢复正常。
实际上发生了什么：
实现有一个 Bug：本应只清理一次的操作，变成了每一轮都清理。
一旦会话越过空闲阈值，后续每个请求都会告诉 API"只保留最近一个推理块，丢弃之前所有的"。这会产生复合效应：
- Claude 执行任务时推理历史不断被清空
- Claude 在没有"记忆自己为什么做那些决定"的情况下继续执行
- 表现为：健忘、重复操作、奇怪的工具调用选择
为什么额度消耗也变快：
持续丢失推理块 → 持续产生缓存未命中 → 每次请求都要重新发送大量未缓存的 Token → 额度消耗加速。
为什么难以发现：
- 两个不相关的内部实验掩盖了问题
- 改变思考内容的显示方式在大多数 CLI 会话中抑制了这个 Bug
- 只在特定边界情况（空闲会话）才触发
- 通过了多轮人工代码审查、自动代码审查、单元测试、端到端测试和内部测试
修复后，Anthropic 用 Opus 4.7 对问题 PR 进行了代码审查测试：提供完整代码库上下文后，Opus 4.7 找到了这个 Bug，而 Opus 4.6 没有。这个发现驱动了后续改进代码审查工具的计划。
问题三：减少冗长的 System Prompt 修改影响了编程质量
时间线：4 月 16 日引入（随 Opus 4.7 发布）→ 4 月 20 日撤回（v2.1.116）
背景：Anthropic 在发布公告中已提到，Opus 4.7 有一个行为特点：相比 Opus 4.6 更冗长。这让它在难题上更聪明，但也产生更多输出 Token。
为了减少冗长，工程团队在 System Prompt 里加入了一行指令：
"Length limits: keep text between tool calls to ≤25 words. Keep final responses to ≤100 words unless the task requires more detail." （长度限制：工具调用之间的文字保持在 25 词以内。最终回复保持在 100 词以内，除非任务需要更多细节。）
经过多周内部测试，没有发现评估指标下降，于是随 Opus 4.7 一起在 4 月 16 日上线。
问题在于：这行指令与其他 System Prompt 修改组合后，对编程质量产生了超出预期的影响。更广泛的消融测试（逐行移除 System Prompt 来理解每行影响）显示对 Opus 4.6 和 4.7 都有 3% 的质量下降。
发现后立即在 4 月 20 日撤回。
为什么三个问题叠加看起来像"全面质量下降"
每个问题影响不同的用户群、在不同时间线生效：
- 推理努力降级：影响所有用 Sonnet 4.6 和 Opus 4.6 的用户
- 缓存 Bug：只影响有空闲会话（>1 小时）的用户，且随时间累积
- System Prompt 修改：影响所有 Sonnet 4.6、Opus 4.6 和 Opus 4.7 用户
三个问题的不同覆盖范围和时间分布，使聚合效果看起来像是"广泛、不一致的质量下降"，给排查增加了巨大难度。
Anthropic 承诺的改进措施
- 更多内部员工使用和外部完全相同的 Claude Code 构建版本（而非用于测试新功能的内部版本）
- 改进 Code Review 工具，用于内部 PR 审查，同时向用户开放
- System Prompt 变更的更严格控制：
- 每次 System Prompt 变更都运行完整的每模型评估套件
- 持续消融测试（理解每一行的影响）
- 新工具使 Prompt 修改更易于审查和审计
- CLAUDE.md 中新增指导：模型特定修改必须限定在目标模型
- 可能影响智能的变更：增加浸泡期、更广泛的评估套件、渐进式推出
- 在 @ClaudeDevs（X/Twitter）和 GitHub 集中线程分享产品决定和背后原因
对用户的影响和 Anthropic 的行动
- 所有问题已于 4 月 20 日（v2.1.116）完全修复
- 所有订阅用户的使用额度已重置（考虑到缓存 Bug 导致额度消耗加速）
- Opus 4.7 用户现在默认
xhigh推理努力，体验应显著优于 3-4 月期间
从这次事件学到什么（对用户的启示）
- 可以用
/effort手动控制推理深度：即使 Anthropic 调整了默认值，用户始终可以手动覆盖 - 长时间空闲后的会话异常已修复：如果你之前遇到"中途失忆"的情况，现在已解决
- 遇到质量问题时，反馈很重要：正是用户在
/feedback和公开帖子中的具体可复现反馈，帮助 Anthropic 定位了问题
来源：Anthropic Engineering Blog - April 23 Postmortem | 整理：ClaudeEagle