AI 助手今天不在状态

最近发现了一件挺有趣的事情。

Anthropic 发布了一份针对 Claude Code 质量状况的复盘报告，核心内容是，在前段时间，部分用户反馈 Claude Code 的表现有所下滑。经过排查，原因并非底层模型能力被“阉割”，而是多项产品层面的调整叠加，导致用户产生了质量降低的感觉。

读到这里，我首先想到的不是“恍然大悟”，而是觉得这个说法终于有了依据：

AI 助手今天发挥失常。

过去我们极少用这种方式来描述一款工具。

浏览器不顺畅，那是浏览器卡顿了。

IDE 难操作，那是插件有冲突。

服务器不响应，那是服务宕机了。

然而当 AI 编程工具不好用时，给人的感觉截然不同。

这并非单纯的“故障”。

这更像是：今天这位同事有些不在状态。

昨天它还能领会你的意图，今天突然就开始兜圈子。昨天它写代码还算靠谱，今天却开始补充一些怪异的边界情况。昨天它还能顺着上下文逻辑推进，今天却像刚进组的新人，什么都需要重新解释。

说它没法用吧，倒也不是。说它没毛病吧，又确实感觉不对劲。

这件事最微妙之处在于，我们已开始将 AI 编程视为一种有“手感”的事物。

以往的工具，大多是确定性的。一个按钮仅代表一个功能，一条命令仅执行一个操作。它不好用，大概率是配置有误、版本冲突、网络断连，或者是用户操作不当。

但 AI 编程则不同。其背后变化的可能是模型，可能是系统提示词，可能是推理力度，可能是缓存机制，可能是上下文压缩算法，亦或是某个工具调用环节。最终反馈到用户端，就成了一句很直白的话：

怎么感觉它今天变蠢了？

这种感觉其实相当关键。因为它表明 AI 编程已不再仅仅是一个“偶尔使用”的辅助手段。

若只是玩具，其状态优劣并不重要。大不了换一个，或者今天暂且不用。

然而当它融入日常开发流程后，情况便截然不同。一位工程师每日都利用它阅读、修改代码，编写测试，排查 bug，解析报错。一个团队开始默认让它参与 PR、Review、重构及迁移。一家公司开始将其纳入研发效率的预期之中。

此时，AI 助手的状态起伏，就不再仅仅是体验问题，而是会转化为生产变量。

人类同事状态欠佳，至少你还能察觉出些许缘由。昨天熬夜了，今天动作会慢些。对项目上下文不熟，先让他研读两天代码。近期事务繁杂，就少安排些复杂任务。

但 AI 助手状态不佳时，你很难判断缘由。是我提示词写得差？是上下文过长？是工具更新了？是模型策略调整了？是厂商为降低延迟修改了参数？还是它今天确实表现不行？

这种判断成本，会被悄然转移给使用者。

有时我觉得，这也是 AI 编程的有趣之处。它既让工程师效率提升，又给工程师增添了一种新的感知负担。你不仅要判断代码正确与否，还要判断：今天这个 AI 是否值得信赖。

信多了，容易掉坑。信少了，又损失效率。

最棘手的是，它并非一直稳定地优秀，也非一直稳定地糟糕。它会在某些任务上表现聪慧，却在另一些任务上突然犯下低级错误。

这让人难以完全放手。

以前我们讲“AI 不能替你负责”，更多是指代码质量与安全。但现在我认为还有另一层含义：

AI 也无法替你判断它今天是否靠谱。这个判断最终还是要由人来承担。

所以“AI 助手今天不在状态”这种说法，听起来像玩笑，实则背后是个很现实的问题。

但只要团队开始依赖它，这种感觉就会愈发重要。因为在未来的研发流程中，需要稳定的不仅是系统，还包括那些协助我们编写系统的 AI。

工具会迭代。模型会演变。提示词会优化。产品策略会权衡延迟、成本与质量。

而我们在某个普通的工作日中，突然察觉：那位每天坐在身旁协助我们写代码的 AI 助手，今天状态似乎不太佳。