上周三，一个看起来再正常不过的代码变更，让我重新理解了AI辅助编程这件事。这个变更涉及一次API响应的逻辑重写，代码写得非常干净，单元测试全部通过，注释也写得像教科书一样标准。参与审查的工程师和我都点了通过，没有看出什么不对劲。

直到几周后，用户反馈某个行为与预期完全不符，我们才发现这段代码在接收到的可选字段缺失时，把整个响应路径带偏了。它完美地处理了“快乐路径”，却在边缘状态上埋下一个安静的坑。没有爆炸，没有宕机，只有一个逻辑错误被轻巧地藏在了看起来很可信的代码里。

打开网易新闻 查看精彩图片

回想起来，那一刻真正让我困扰的不是bug本身——这种缺陷从来都能修好。困扰我的是：我们批准了一段自己根本没有审透的代码。包括我在内，没有人对这段AI加速写出的逻辑真正深挖，因为我们默认它长得像合格代码，就认为它值得信任。

这件事之后，我反复在内部讨论中提到同一个观察：AI让编写代码的速度前所未有地快，这是事实。骨架搭建、样板代码、初稿成型、甚至新手工程师也能提交出看起来很漂亮的变更——那些过去要耗费半天时间的任务，现在二三十分钟就能搞定。但软件的整体拥有成本，并没有跟着降下来。

我原本也曾被那种叙事说服过：既然写代码快了这么多，软件自然也会变得更便宜。更多产出，更快的pull request，更好看的一稿，似乎都指向一个高效而省钱的未来。但后来我渐渐意识到，这套推论是用代码生成的速度，偷换了对“软件便宜”的真正定义。

软件里昂贵的部分从来都不是打字。真正烧钱和考验工程水平的事情，是后期理解代码、真正意义上的审查、在复杂信号中安全地变更，以及在出故障时快速定位和恢复。这些事没有因为生成速度快而变得更简单——它们需要推理、需要上下文、需要同行之间那种花时间的评判，而这些依然是顽固的人类专属。

现在，当团队讨论要不要把AI工具作为标准流程时，我很少再问“它能不能帮我们写得更快”。我转而问另一个问题：当代码生成的成本急剧下降，而理解和验证代码的成本几乎原地不动时，整体工程会朝哪个方向演化？如果最容易的部分被不断加速，最困难的部分——推理、审查、维护和信任——仍然需要我们慢下来，那我们是否在一味追求快的过程中，把风险也成倍地堆到了后面？

这个问题并没有标准答案。但至少，那个小小的API处理缺陷提醒我，看起来更可信的代码，并不等于更安全。而工程判断这件事，在AI时代反而变得更加不能省。