内心os难怪之前的opus4.6不如之前聪明了Anthropic 公开承认了 Claude Code 过去一个月的质量下降并把它拆解成了三个独立事故、三种不同根因。看完这份报告我的感受是大厂翻车不可怕可怕的是翻车之后不知道怎么复盘。Anthropic 这份手术刀式的复盘值得所有做 AI 产品的团队抄作业。上周五Anthropic 悄悄更新了一篇工程博客标题很朴素《An update on recent Claude Code quality reports》。翻译成人话就是我们要解释一下为什么最近有用户说 Claude 变笨了。说实话我看到这篇博客的第一反应是终于承认了。过去一个月Twitter、Hacker News、Reddit 上关于Claude Code 变差了的讨论就没断过。有人吐槽它开始健忘有人抱怨它执行到一半就卡住有人说它变得特别话痨问东问西还有人说它推理时间变短了但质量也跟着跳水。Anthropic 的工程师们没有在社交媒体上跟用户对线而是闷头查了一个月最后交出了这份报告。一、三件事三个问题三种教训报告最核心的价值是把质量下降这个模糊投诉拆解成了三个独立的、因果关系完全不同的事故。这个拆解本身就很有价值。因为很多团队在面对产品变差了这种复合投诉时习惯性地会去找一个统一的原因——模型变差了、RLHF方向歪了、数据污染了。但 Anthropic 的工程师发现这三个问题根本不是同一个原因它们只是恰好在时间线上重叠了所以看起来像是全面退化。事故一默认推理档位从高调成中3月4日 → 4月7日修复Claude Code 在2月发布 Opus 4.6 时把默认推理档位设成了 high。工程师们的解释是Opus 4.6 在 high 模式下有时候会想太久导致用户界面看起来像死机了一样。所以他们改了——把默认档位调成 medium理由是内部测试显示 medium 能在稍微降低一点智能的前提下大幅降低延迟而且不会遭遇偶发的超长尾延迟还能帮用户省着用 token 上限。这个决策听起来是合理的对吧甚至有点像在做用户调研后的理性优化。但问题来了用户在评论区直接开骂了。用户反馈的核心是我不介意等我宁愿等久一点拿到的结果更好你们凭什么替我选省 token而不是要质量4月7日Anthropic 把默认档位改回去了。Opus 4.7 默认 xhigh其他型号默认 high。教训一产品档位设计是用户体验不是技术决策。让用户为延迟付出代价是用户的权利不要替他们做这个权衡——除非你真的做过足够大的用户调研并且有数据支撑。事故二缓存优化把历史推理内容清空了3月26日 → 4月10日修复这个事故最有技术含量也是造成健忘投诉的直接原因。先科普一个背景Claude Code 在执行任务时会把推理过程写入对话历史这样下一轮对话时 Claude 能记着自己之前为什么选了某个方案、为什么排除了其他选项。这个推理历史是上下文的一部分对保持任务连贯性非常重要。Anthropic 的工程师在3月26日做了一个优化他们在 API 请求里加了一个缓存层用来在用户恢复一个超过1小时不活跃的会话时减少 token 消耗。设计上很简单——如果一个会话已经idle超过1小时下次请求反正会 cache miss那不如直接把旧的推理历史清理掉减少传到 API 的 token 数量这样既能省钱又能降低延迟。实现方式是调用clear_thinking_20251015这个 API header配合keep:1参数意思是只保留最近一段推理。代码逻辑写的是如果 session idle 超时就清理一次历史推理。但实际跑起来变成了每次请求都在清理历史推理。Bug 在于那个idle超时的判断条件被设计成每次请求都检查而不是每个session只检查一次。所以一旦 session 跨过 idle 阈值后续的每一次请求都会触发清理逻辑把历史推理一块一块地蚕食掉。更糟糕的是这个清理动作还会导致 cache miss——因为 cache 的 key 包含了请求内容清理后下次请求内容变了所以 cache 失效。这直接造成了另一个副作用用户报告的 token 消耗比预期快。Anthropic 自己在报告里承认这个 bug 经过了多层检查——人类代码 review、单元测试、端到端测试、自动化验证、内部 dogfooding——全部通过了但还是漏了。为什么因为两个不相关的独立实验干扰了问题复现一个是内部消息队列相关的纯服务端实验另一个是 thinking 显示逻辑的改动在大多数 CLI session 里掩盖了这个 bug。再加上这个 bug 只在一个边角case旧 session 恢复才会触发而这个场景在常规测试里很少被覆盖。教训二测试的边界条件永远小于产品实际运行的边界条件。你的单元测试、集成测试、dogfooding 测试本质上都是在你已知的路径上打转。真正的问题往往藏在正常使用不会触发、但用户实际环境会触发的边角 case 里。事故三减少冗长的 system prompt 把代码质量搞差了4月16日 → 4月20日修复第三个事故是4月16日引入的4月20日回滚只存在了4天。Anthropic 在 system prompt 里加了一条指令让 Claude减少冗长输出。这个改动的出发点是好的——确实有用户抱怨 Claude 在代码任务里太话痨一边写代码一边解释为什么要这么写用户体验不好。但问题在于这条减少冗长的指令跟其他已有的 prompt 改动叠加在一起产生了一个副作用——Claude 在代码任务里变得过于追求简洁以至于开始跳过必要的解释、减少测试用例的生成、删掉了那些虽然长但有用的推理过程。这又是一个典型的组合效应。单独看减少冗长这条指令没什么问题。单独看其他 prompt 优化也没太大问题。但放在一起——尤其是跟medium 推理档位叠加——直接影响了代码输出质量。教训三prompt 的改动具有组合效应单点测试看不出全局影响。每次改 system prompt本质上都是在对模型的整个行为空间做扰动。你加的一句话可能在某个维度上压制了模型的某项能力而那个维度恰好是用户最依赖的。二、这份复盘报告为什么值得学复盘报告我见过很多大多数长这样由于 XX 原因导致了 YY 问题。我们已经修复并加强了测试。以后会继续努力为用户提供高质量的服务。这种报告的废话含量极高看了等于没看。Anthropic 这份报告不一样。它有几个特征第一它承认了内部测试没发现问题这个事实但没有用它当挡箭牌。很多公司的复盘会强调我们做了充分测试言下之意是用户有问题是他们运气不好。Anthropic 反而花了大量篇幅解释测试为什么没拦住这个 bug以及未来打算怎么补上测试覆盖的盲区。第二它没有甩锅给外部因素。不是说LLM本身有随机性不是说算力不足影响模型表现不是说用户使用方式不符合预期。每一个问题都被精确定位到了具体的代码改动、具体的决策逻辑、具体的测试盲区。第三它给出了具体的结构性改进行动而不是泛泛的加强测试。比如报告里提到要 back-test 那些有问题的 PR用 Opus 4.7 对着代码仓库做完整的上下文理解然后对比修复前后的输出差异。这个做法本质上是把 AI 模型当成了代码审查工具——用更强的模型来审查改动的安全性。三、钱学森框架下的系统稳定性分析如果用钱学森《工程控制论》的视角来看这次 Claude Code 事件它本质上是一个控制系统在受到多重扰动后失去稳态的过程。Claude Code 的稳态是什么是用户在代码任务上的满意度以及模型输出的质量基线。这个稳态被三个扰动同时冲击扰动1推理档位下移降低了智能输出的上界扰动2推理历史被清空破坏了上下文连续性导致重复劳动扰动3冗长抑制prompt压制了必要输出降低了任务完整性三个扰动各自独立但在时间线上重叠后它们的组合效应导致了系统整体的发散——用户感知到的不是三个小问题而是Claude 整体变差了。工程控制论的核心问题是怎么让系统在扰动存在的情况下依然保持稳定Anthropic 给出的答案是单点修复不够需要系统级的测试和监控。他们提到要建立back-test机制用更强的模型Opus 4.7来审查改动的安全性。这本质上是在系统中加入了前馈控制——在改动上线前通过模拟的方式提前预测可能的偏差而不是等用户报告了再补救。四、从这次事件看 AI 工程化的真实挑战Claude Code 这次翻车折射出一个正在成为行业共识的深层矛盾AI 产品在工程层面极度复杂但在发布节奏上又被要求快速迭代。Claude Code 是一个运行在用户本地机器上的 CLI 工具它需要跟 Anthropic 的 API、用户本地的开发环境、不同型号 Claude 的特性、推理档位机制、上下文管理逻辑做复杂的交互。每一个维度都有大量的参数和边界条件。在这种复杂度下想要通过人工代码 review 常规测试来保证每次改动都不引入退化本质上是一个不可能完成的任务。那怎么办答案可能就在 Anthropic 报告的最后那段话里用更强的模型来审查改动的安全性。这本质上是用 AI 辅助 AI 开发——用 Opus 4.7 充当代码审查员在改动上线前做全面的影响评估。这个方向很值得跟进。但它也带来了新的问题当 AI 开始审查 AI 的代码时谁来审查审查者的判断回到钱学森的那句话用不太可靠的元件可以做出非常可靠的系统。 Anthropic 的工程师们大概也有类似的认知——他们没有把 Claude Code 定位成完美的代码助手而是承认它会出问题、会退化、需要持续监控和修复。真正重要的是系统有没有自我感知和自我修正的能力这次翻车证明了 Claude Code 至少还有这个能力——它能发现问题能定位根因能回滚改动能向用户解释原因。这比很多装死的系统已经强太多了。五、给所有 AI 开发团队的 checklist基于这次事件我整理了一个行动清单供做 AI 产品开发的团队参考发布前检查每个 prompt 改动都要做组合影响分析而不是单点测试边界条件测试要覆盖旧 session 恢复长时间 idle 后继续等边角场景用更大规模的模型对有问题的 PR 做 back-test模拟完整上下文理解档位/参数改动要给用户明确的 opt-in/opt-out 机制不要替用户做质量/速度权衡发布后监控建立用户反馈的实时告警机制而不是等周会汇总对核心指标任务完成率、用户满意度、平均轮次做持续监控和同比环比当多个维度同时出现下降趋势时要警惕组合效应而不是孤立分析组织层面复盘报告要刨根问底不要用模型有随机性来搪塞区分bug导致的退化和设计决策导致的体验变化处理方式不同保持用户沟通渠道透明翻车不可怕装死才可怕