让 AI 替写代码结果得花更多时间审代码这事儿简直太离谱了

代码量暴增 120% 意味着什么？意味着你现在面对的 PR（Pull Request）可能不是在解决问题，而是在制造新的 Bug。最近看到一个挺有意思的趋势，现在很多公司已经陷入了所谓的「AI Slop」陷阱——AI 写的代码表面上干净得像教科书，但实际上隐藏了大量低级错误、安全漏洞或者只有在部署后才会爆出来的诡异 Bug。

这种现象在 Synthesia 这种公司里特别明显。他们 118 个工程师全员用 Claude Code 之后，代码量直接起飞，PR 数量同比涨了 120%，而且 95% 的 PR 里都有 AI 参与。最离谱的是，AI 因为上下文理解有限，经常写出重复函数。CTO Peter Hill 提到他们居然在代码库里发现了同一个功能的 10 个不同版本。这种「冗余代码」不仅没提高效率，反而让工程师得花大把时间去肉眼排查、删减，然后再重新训练 Agent 告诉它：别再写重复的了！

其实这反映了一个很残酷的现实：软件开发的瓶颈已经从「写代码」转移到了「审代码」。Sonar 做过一个 1100 人的开发者调研，数据挺扎心的：

• 代码贡献度： 约 42% 的共享代码库代码是由 AI 贡献的。
• 信任危机： 96% 的开发者并不完全信任 AI 的输出能正确运行。
• 审核成本： 38% 的人觉得审 AI 的代码比审同事写的代码更累。
• 可靠性： 61% 的人认为 AI 产出的代码看起来是对的，但实际不可靠。

现在的应对策略很有意思，大家不再是单纯地「写完再审」，而是把重心前移。比如亚马逊 Stores 的 McLaren Stanley 团队在给移动购物 App 做代码现代化时，工程师们把绝大部分精力花在「生成之前」的规划上，先定死逻辑，防止 AI 跑偏。

另外，现在出现了一批专门做 AI Code Review 的工具，比如 CodeRabbit 这种，估值已经冲到 15 亿美金了，号称每周处理 200 万次评审。虽然这种工具能帮着过滤一些常规错误，但真正核心的逻辑漏洞还是得靠人。

我比较担心的一点是，如果初级工程师每天的任务就是「审核 AI 代码」而不是「亲自写代码」，他们怎么培养那种对代码质量的直觉？如果一个新人习惯了在 AI 生成的代码里找错，而不是从零构建逻辑，那么未来可能真的会出现一批「只会点 Approve 但写不出复杂架构」的工程师。

说到底，AI 提升了产出速度，但并没有提升「正确率」。如果审代码的成本抵消了生成的效率，那这种所谓的生产力提升其实是个伪命题。