Anthropic 发布了一份详细的工程复盘,解释 Claude Code 从 3 月到 4 月中旬持续了六周的质量投诉。三个互不相关的产品层改动分别在 3 月 4 日到 4 月 16 日之间上线,每个按各自的时间表影响着不同的流量切片——这就是为什么用户报告的症状根据他们何时使用 Claude Code 以及依赖哪些功能,差异如此巨大。关键的一点是:API 和底层模型权重都没有受影响。三个问题在 4 月 20 日发布的 Claude Code v2.1.116 中全部解决,Anthropic 也已为所有订阅用户重置使用上限。这次诚实的披露是它与"我们正在改进产品"那种常见公关稿区分开来的地方:具体日期、具体 commit、具体质量数字、Claude Code 团队的可追责归属。
三个改动可以干净地拆开。第一,3 月 4 日,默认推理预算从 high 改到 medium,目的是修复长时间思考期间 UI 卡顿的问题——Anthropic 承认这是"错误的权衡",并于 4 月 7 日回滚。现在所有模型默认 high 或 xhigh。第二,3 月 26 日的一项优化,本是为了把已经闲置 1 小时以上的会话里的旧思考片段清掉(反正闲置那么久之后下次必然是完整 cache miss),却带了个 bug:本应只清一次,变成每一轮都清。Claude 仍然在执行,只是越来越没有"为什么走到当前路径"的记忆。Boris Cherny 在 Hacker News 上点出极端情况:一个上下文里有 90 万 token、闲置一小时的用户,下一条消息会撞到完整 cache miss,消耗掉相当可观比例的 rate limit——对 Pro 用户尤其明显。4 月 10 日修复。第三,4 月 16 日伴随 Opus 4.7 上线,Anthropic 给 system prompt 加了 verbosity 限制,指示模型"工具调用之间的文本不超过 25 词"以及"最终回复不超过 100 词"。内部测试没发现回归。事后的更广泛 ablation 揭示:Opus 4.6 和 4.7 都因此出现 3% 的质量下降。4 月 20 日回滚。一个有意思的 meta finding:Anthropic 自家的 Code Review 工具被回测了那几个引发问题的 PR——给足够的仓库上下文,Opus 4.7 找出了那个 cache bug,Opus 4.6 没找出来。
社区批评值得和复盘放在一起权衡。Hacker News 上有评论质疑:idle 会话剪枝的真正动机到底是降延迟,还是降成本而拿延迟做幌子。还有几条 flag 指出:用旧 system prompt 跑过的 benchmark 还挂着,新 system prompt 悄悄上线没披露——"感觉像是欺诈"。Fortune 报道一些用户因 Anthropic 最初的"什么事都没有"式回复而感到"被 gaslight"。Anthropic 回应 Fortune 时用了一句"算力是整个行业的约束",同时配上扩容合作伙伴的话术。复盘没回应、但值得继续跟踪的两个问题:Reddit 用户报告 Claude Code 把任务委派给更便宜的 Haiku 模型的频率比预期高得多——这只在 verbose 日志里可见——对自动化 pipeline 来说,这是一种沉默的质量风险类别,在交互式使用里就比较明显。至少有一位 Reddit 用户独立确认:即使官方 4 月 20 日宣布回滚 verbosity 指令,这些指令在 system prompt 里仍然留着;他写了一个 pre-tool hook 脚本,针对五个具体失败模式(跳过原文重读、自信但与源不一致的输出等)做对冲。这个由用户自己 build 的 workaround 能改善输出质量,本身就反过来印证了复盘对 verbosity 限制"降低质量"的诊断。
对生产环境跑 Claude Code 的 builder:canonical 修复版本是 v2.1.116。如果你在 3-4 月间跑过 CI 或自动化工作流,审一下输出有没有三个改动的指纹——尤其是长 idle 会话(cache bug),以及 4 月 16-20 日左右的输出(verbosity prompt)。对一般在做 LLM-backed 产品的 builder,直接可借用的工程教训:内部评测之所以一个问题也没抓到,是因为内部员工用的是和公开发布版不同的 build,cache bug 只在特定状态(过期 idle 会话)下显现、而那个状态在 eval 里没被覆盖,且评测套件本身太窄,抓不到 system prompt 改动带来的 3% 质量下降。Anthropic 表态要做的事——让内部员工用一模一样的公开 build、给每一次 system prompt 变更都跑更宽的 per-model 评测套件、加入 soak 期和分阶段 rollout、对 system prompt 变更做细致版本管理——是合理的行业基线。"算力是约束"那句承认也很关键:如果 Anthropic 正在做能可见地降低质量的成本/延迟权衡,那同一套逻辑对每个 vendor 都成立,产品采购团队应该在 vendor SLA 里明确问"延迟-vs-质量"的取舍是怎么决定的。