AI 同事今天状态不好

最近看到一个很有意思的事。

Anthropic 发了一篇关于 Claude Code 质量问题的复盘，大概意思是，过去一段时间里，一些用户觉得 Claude Code 变差了。后来他们查下来，问题不是底层模型被“削弱”了，而是几个产品层面的变化叠在一起，让用户感知到了质量下降。

看到这里我第一反应不是“原来如此”，而是觉得这个标题终于可以成立了：

AI 同事今天状态不好。

以前我们很少这样形容一个工具。

浏览器不好用，是浏览器卡了。

IDE 不好用，是插件冲突了。

服务器不好用，是服务挂了。

但 AI Coding 工具不好用的时候，体感很不一样。

它不是简单的“坏了”。

它更像是：今天这个同事有点不在状态。

昨天它还能理解你的意思，今天突然开始绕弯子。昨天它写代码还挺稳，今天开始补一些奇怪的边界。昨天它能顺着上下文往下推，今天像是刚加入项目，什么都要重新解释一遍。

你说它不能用吧，也不是。你说它没问题吧，又确实不太对。

这件事最微妙的地方在于，我们已经开始把 AI Coding 当成一个有“手感”的东西了。

以前的工具，大部分是确定的。一个按钮就是一个按钮，一个命令就是一个命令。它不好用，大概率是配置错了、版本不兼容、网络不通，或者自己操作失误。

但 AI Coding 不一样。它背后可能变的是模型，可能是系统提示词，可能是 reasoning effort，可能是缓存策略，可能是上下文压缩方式，也可能是某个工具调用环节。最后落到用户这里，就变成一句很朴素的话：

怎么感觉它今天变笨了？

这个感觉其实挺重要的。因为它说明 AI Coding 已经不只是一个“偶尔用一下”的辅助工具了。

如果只是玩具，它状态好不好没那么重要。大不了换一个，或者今天不用。

但当它进入日常开发流程之后，事情就不一样了。一个工程师每天都在用它读代码、改代码、写测试、查 bug、解释报错。一个团队开始默认让它参与 PR、Review、重构和迁移。一个公司开始把它放进研发效率的预期里。

这时候，AI 同事的状态波动，就不只是体验问题了。它会变成生产变量。

人类同事状态不好，至少你还能看出来一点原因。昨天熬夜了，今天会慢一点。项目上下文不熟，先让他看两天代码。最近事情太多，安排少一点复杂任务。

但 AI 同事状态不好，你很难判断原因。是我 prompt 写得不好？是上下文太长了？是工具更新了？是模型策略变了？是厂商为了降低延迟调了参数？还是它真的今天不太行？

这个判断成本，会被悄悄转嫁给使用者。

有时候我觉得，这也是 AI Coding 很有意思的地方。它一边让工程师变快，一边又给工程师增加了一种新的感知负担。你不只是要判断代码对不对。你还要判断：今天这个 AI 值不值得信。

信多了，容易踩坑。信少了，又失去效率。

最麻烦的是，它不是一直稳定地好，也不是一直稳定地差。它会在某些任务上很聪明，在另一些任务上突然犯很低级的错。

这让人很难完全放手。

以前我们说“AI 不能替你负责”，更多是在讲代码质量和安全。但现在我觉得还有另一层意思：

AI 也不能替你判断它自己今天靠不靠谱。这个判断最后还是落在人身上。

所以“AI 同事今天状态不好”这个说法，听起来像玩笑，其实背后是个很现实的问题。

但只要团队开始依赖它，这种感觉就会变得越来越重要。因为未来的研发流程里，稳定的不只是系统，也包括那些帮我们写系统的 AI。

工具会更新。模型会变化。提示词会调整。产品策略会权衡延迟、成本和质量。

而我们在某个普通工作日里，突然发现：那个每天坐在旁边帮我们写代码的 AI 同事，今天状态好像不太好。