Claude Code 变差不是错觉：底模没退，外层框架把重度用户坑了

Anthropic 对 Claude Code 近期质量投诉做了复盘。结论很直：用户不是集体心理暗示，Claude Code 过去两个月确实出了问题。

但锅不在底层模型。Anthropic 指向的是 Claude Code 的 harness，也就是包在模型外面的执行框架：会话状态、上下文处理、工具调用、恢复逻辑这些胶水层。

更关键的补充在于影响对象被钉得更准了。一个被点名的 3 月 26 日改动，专门打中了长会话用户：会话空闲超过一小时后，系统本来只该清理一次旧 thinking 来降低恢复延迟，结果 bug 让清理动作在后续每一轮都继续发生。于是 Claude 看起来健忘、重复，像突然不认识刚才的项目。

这不是一个小众边角。Simon Willison 提到，他经常把 Claude Code 会话放置一小时，甚至一天后再回来；发文时机器上还有 11 个 Claude 进程，还是刚关掉几十个之后。很多重度用户的真实工作流，正是“开一堆长期会话，隔一阵回来接着干”。

发生了什么：三处 harness 问题，把 Claude Code 的体验拧坏了

Anthropic 的复盘称，Claude Code harness 中有三个独立问题直接影响了用户体验。公开材料里最醒目的一个，是 3 月 26 日的长会话恢复 bug。

压缩成一张速读卡片：

这几个细节把争议从“Claude 是不是退化了”拉回到更准确的问题：Claude Code 的外层系统能不能稳定维持一次复杂任务的现场。

模型没有在真空里回答问题。它看到什么文件、记住什么上下文、继承什么会话状态、能调用什么工具，全部由 harness 决定。这里一乱，底模再强也会像拿着残缺卷宗办案。

为什么重要：Agent 产品的命门不只在模型榜单

用户当然会骂模型。回答差，骂模型；代码改乱，骂模型；上下文丢了，也骂模型。

但这次更像一次拆箱验尸。坏掉的不是大脑本体，而是神经系统和工作台：状态管理、上下文裁剪、会话恢复、执行编排。

“差之毫厘，谬以千里。”这句话用在 Agent 系统上很贴切。传统 IDE 里，一个缓存 bug 可能只是索引慢一点；在 coding agent 里，一个上下文清理 bug 会改变模型理解整个项目的方式。

模型不是在同一个世界里表现变差。它是被产品层反复塞进一个被剪坏的世界。

这也是为什么 Cursor、GitHub Copilot、Claude Code、OpenAI Codex 这类产品的竞争，不能只看底层模型谁更强。真正决定重度用户留不留下来的，是一整套脏活能不能做稳：

• 长会话能不能接上；
• 跨文件修改能不能维持一致；
• 工具调用失败后能不能恢复；
• 上下文裁剪能不能被监控；
• 会话状态能不能回放、灰度、定位。

早期铁路也是这个逻辑。车头马力很重要，但调度、电报、道岔、时刻表任何一环乱了，乘客不会研究蒸汽机参数，只会说这条铁路不可靠。今天的 coding agent 也一样。底座再聪明，调度层出错，用户感受到的就是笨。

这个类比不完全一样。铁路是确定性系统，LLM 天生带随机性。但正因为模型已经不够确定，外层工程更不能跟着玄学化。模型会飘，产品层就更要硬。

谁最受影响：不是浅尝用户，而是把 Claude Code 当工作台的人

普通用户偶尔开一个短会话，让 Claude 改几段代码，未必明显踩中这个坑。

最难受的是重度开发者：长期会话、多任务并行、隔夜回来继续、让 agent 逐步理解仓库结构。这批人不是在玩 demo，他们是在把 Claude Code 当半个工作台。

这类用户的损失也更隐蔽。不是一次回答差那么简单，而是信任成本上升：

• 你开始怀疑它是不是忘了刚才的约束；
• 你不得不重复解释项目结构；
• 你要额外检查它有没有改错上下文；
• 你会缩短会话，减少授权，降低依赖。

Agent 产品最怕的不是用户骂两句。最怕用户开始“防着用”。

一旦用户不敢给长任务，不敢让它跨文件动手，不敢让它保留上下文，coding agent 就退回成一个更贵的聊天补全工具。产品价值直接塌半截。

我更在意的不是道歉，而是 Anthropic 能不能把胶水层工程化

Anthropic 这次至少做对了一件事：没有把问题含糊塞回“模型行为复杂”。它承认了产品工程层的问题。

这很重要。因为 AI 公司最容易走的一条懒路，就是把所有坏体验都归因于模型非确定性。反正模型黑箱，反正用户无法验证，反正“生成式 AI 有波动”听起来也合理。

但这次不是抽象波动。3 月 26 日的 bug 有明确机制：为降低延迟而清理旧 thinking，本该一次，结果每轮触发。目标是性能优化，代价是上下文受损。

这才是 Agent 产品里最危险的交易：为了让系统快一点、便宜一点、轻一点，偷偷动了用户以为还在的记忆。

天下熙熙，皆为利来。放在这里不是说 Anthropic 有恶意，而是提醒一点：所有 AI 产品都会面对成本、延迟、上下文长度、体验稳定性的权衡。用户看到的是“它怎么变笨了”，团队内部看到的可能是“恢复速度优化”“资源占用下降”“会话负载降低”。

问题不在于做权衡。问题在于权衡有没有被监控，有没有灰度，有没有长会话回放测试，有没有在真实重度工作流里压过一遍。

对构建 agentic systems 的团队，这比一次产品事故更有参考价值。模型非确定性已经够烦了。就算先把模型波动放一边，harness 自己也能制造足够复杂的灾难。

更麻烦的是，这类 bug 不一定会在常规指标里大声报警。延迟可能下降了，资源可能省了，短会话测试可能过了，用户却在长会话里感觉“它越来越没脑子”。

这不是失误那么简单。这暴露了一个行业通病：AI 产品太爱展示聪明，太少证明可靠。

接下来该盯什么：长会话质量，而不是新模型口号

对重度用户，现实建议很朴素：如果你依赖 Claude Code 做长任务，最近一段时间要更谨慎地处理隔夜会话和多进程并行会话。关键任务前，最好让它重新确认当前仓库状态、目标文件、约束和已有修改。

这不是让用户替产品擦屁股。但在工具信任还没完全恢复前，这是降低损失的做法。

对采购团队或工程负责人，别只看一次性 demo。demo 里生成一段漂亮代码不难。难的是隔天回来还能接住同一条线，跨文件修改还不乱，失败重试还能解释自己刚才做了什么。

接下来要看 Anthropic 三件事：

• 是否公开更多 harness 问题的修复边界，而不只讲一个典型 bug；
• 是否建立长会话、空闲恢复、上下文裁剪的质量指标；
• 是否让这类变更可回放、可灰度、可定位，而不是等 Hacker News 和博客用户喊疼。

AI 编程工具正在从“问答产品”变成“执行系统”。这一步很大，也很残酷。

问答产品答错了，用户重问一次。执行系统记错了，用户要收拾残局。

Claude Code 这次给整个行业提了个醒：模型强不是免死金牌。外层系统如果管不好记忆、状态和工具，所谓智能就会变成一种高效率的失忆。