本页目录10
- 用户反馈的「变笨了」并非错觉,而是三个独立系统改动叠加造成的真实质量回归,API 本身未受影响
- 推理力度从 high 降为 medium 换取延迟,是一次带来「错误权衡」的改动,后来已恢复
- 一个本意为清理过期思考片段的缓存优化 bug,导致每次请求都丢弃此前推理内容,使 Claude 表现出遗忘与重复
- 给系统提示加一条「精简回复字数」的指令,内部测试没发现问题,但更大范围评估后发现对 Opus 4.6/4.7 有约 3% 的下降
- 后续改进聚焦系统提示改动前做逐模型评估和逐行消融分析,及对潜在影响智能度的改动采用浸泡期与灰度发布
本文是对 Anthropic 官方文章「Update on recent Claude Code quality reports」的中文要点摘要,完整内容以原文为准:https://www.anthropic.com/engineering/april-23-postmortem
事件背景
过去一个月,不少用户反映 Claude 的响应质量在下降——回答变笨、容易遗忘上下文、行为不稳定。Anthropic 调查后确认这不是错觉,而是三个彼此独立的系统性改动叠加导致的真实回归,影响范围集中在 Claude Code、Claude Agent SDK 和 Claude Cowork,底层 API 本身没有问题。
时间线
| 日期 | 事件 |
|---|---|
| 3月4日 | 调低 Claude Code 默认推理力度(reasoning effort) |
| 3月26日 | 上线一项缓存优化功能 |
| 4月7日 | 恢复默认推理力度 |
| 4月10日 | 修复缓存 bug(v2.1.101) |
| 4月16日 | 给系统提示加入新指令 |
| 4月20日 | 三个问题全部修复(v2.1.116) |
| 4月23日 | 重置所有订户的使用限额作为补偿 |
三个根本原因
一、推理力度被误调
为了降低延迟,团队把默认推理力度从「high」改成了「medium」。这个改动被官方形容为造成了「错误的权衡」——用户明显感觉到智能程度下降。4月7日已恢复到之前的高推理力度模式。
二、缓存优化里的一个 bug
(本站解读)官方原文并未对三个问题做严重性排序,但这一环最隐蔽,症状也与用户吐槽最吻合。设计初衷很简单:如果一个会话超过一小时没有活动,就清理掉过期的思考片段(thinking blocks),降低用户恢复会话的成本。
但实现有缺陷:这个「清理」逻辑本应只在会话确实空闲超时后触发一次,结果却在每次请求时都执行了一遍。后果是——每一次请求都会告诉 API 只保留最近的推理块,把之前所有的推理上下文都丢弃掉。这直接表现为 Claude 在长会话里逐渐「失忆」,出现遗忘上下文、重复劳动等典型症状,和很多开发者吐槽的现象吻合。
三、系统提示的一条新指令带来隐性下降
4月16日,团队给系统提示加了一条指令,要求工具调用之间的文本控制在 25 字以内、最终回复控制在 100 字以内,目的是让输出更简洁。这条改动在内部经过了数周测试都没发现问题,但上线后经过更大范围、逐模型的评估才发现:它对 Opus 4.6 和 Opus 4.7 都造成了约 3% 的能力下降。
影响范围
- Sonnet 4.6、Opus 4.6 受问题一和问题二影响
- Sonnet 4.6、Opus 4.6、Opus 4.7 受问题三影响
- API 和底层推理层未受影响
- 不少用户反映使用限额(usage limits)消耗得比平时更快
修复与补偿
- 4月10日,缓存 bug 在 v2.1.101 中修复
- 4月20日,系统提示的问题指令在 v2.1.116 中撤回
- 4月23日,Anthropic 对所有订户重置了使用限额,作为对这段时间体验下降的补偿
后续改进措施
Anthropic 在文中给出了几条具体的流程改进承诺:
内部 dogfooding 加强
- 让更多内部员工日常使用公开发布版本的 Claude Code,而不是内部特殊版本,以便更快发现面向用户的真实问题
- 改进内部使用的 Code Review 工具,并计划把这些工具能力开放给客户
系统提示改动的管制
- 此后每次系统提示的改动都要跑一轮「广泛的逐模型评估」,而不是仅凭内部小范围测试
- 持续做逐行消融分析(line-level ablation),量化系统提示里每一行具体贡献了多少影响
- 建立新的内部工具,方便对系统提示改动做审查和审计
变更发布节奏
- 对于任何可能影响模型「智能程度」的改动,采用浸泡期(soak period)加逐步灰度发布,而不是一次性全量上线
- 针对特定模型的改动,严格限定只作用于目标模型,避免像本次系统提示改动那样意外波及多个模型版本
对开发者的启示
这次事故的核心教训是:看似无害的性能优化(缓存清理逻辑)可能比模型本身的改动更容易悄悄拖垮体验,而且很难被常规的模型评估捕捉到,因为问题出在请求构造层面,不是模型权重本身。如果你在自己的 Claude Code / Agent SDK 集成中也做了类似的上下文裁剪或缓存策略,值得对照检查一下触发条件和执行频率是否符合预期。