AI 代码能跑也先别合:这 5 个拒收信号,比 CI 绿灯更重要

AI 写代码越来越快以后，真正累人的地方反而变了。

以前我们卡在实现：查上下文、想方案、试几条路、慢慢把代码写出来。现在 Agent 很快能给你一大段 diff，测试也可能是绿的，页面看起来也能跑。问题是，你真的知道它为什么这么改吗？

这就是最近 Hacker News 上那篇《When I reject AI code even if it works》能冲到高热的原因。它戳中的不是“AI 会不会写代码”，而是另一个更现实的问题：

代码能跑，不代表你应该合。

我更愿意把这件事理解成：AI 编程把瓶颈从“写代码”推到了“验收代码”。谁能判断一段 AI diff 是否值得留下，谁才真正掌握这条流水线。

AI 生成代码有个很迷惑人的地方：它经常看起来很完整。

变量名像那么回事，分层也挺整齐，测试能跑，甚至还顺手补了注释。可你一旦要向同事解释“为什么要这么设计”，脑子里突然空了一块。

这时候就该停。

如果你不能用自己的话解释这段改动，它就还不是你的代码。哪怕它能跑，后面线上出了问题，你也不知道从哪里下手。

一个简单判断：

AI 时代的 Code Review，不只是看代码有没有问题，还要看你有没有重新获得理解权。

很多 AI diff 的第一眼很爽：改了十几个文件，抽了几个 helper，顺手统一命名，还补了一个通用抽象。

但如果原始问题只是一个边界条件、一个字段映射、一个按钮状态，这种“大扫除式修复”就很危险。

代码库不是越整齐越好，尤其不是由一个还没完全理解业务的 Agent 一口气整齐。

我看到 AI diff 时，会先问三个问题：

这里别省。

越大的 diff，越容易把“解决问题”和“制造新维护成本”混在一起。AI 很擅长把代码写得像系统工程，但它不一定知道你的系统到底需要多少工程。

AI 很爱抽象。

这不是坏事。坏的是，它经常在证据不够的时候抽象。

比如需求只出现了一次，它先做一个策略模式；只接一个外部服务，它先封一个 provider 层；只是一个页面状态，它先抽一套状态机。

这些东西不是不能要，但需要理由。

我通常会把 AI 新增抽象分成三类：

工程里最贵的不是少写一个抽象，而是背着一个没人敢删、没人敢改、没人知道边界的抽象活很久。

AI 生成的抽象尤其要严审。它写出来很便宜，你维护起来不便宜。

CI 通过，只能说明已有检查没有抓到问题。

它不能说明设计合理，不能说明边界清楚，不能说明未来改需求时不痛苦，也不能说明这个方案和团队的代码风格一致。

这就是“AI 代码验收”必须比“测试通过”更宽的原因。

我建议把验收拆成四层：

很多团队现在的问题，是只让 AI 帮忙写代码，没有让人重新建立验收标准。

这会让“能跑”变成一种麻醉。

原文里有个很有共鸣的点：作者说自己经常会拒掉 AI 第一轮代码，然后重新开始。

这听起来像浪费，其实很正常。

第一轮 AI 代码的价值，未必是直接合并。它更像一次快速探路：让你看见代码库里的入口、隐含约束、可能方案和坑位。等你理解问题以后，第二轮再驱动 Agent，质量往往会明显上去。

也就是说，不要把 Agent 的第一版当交付物，要把它当调研材料。

一个更稳的工作流是：

这套流程慢一点，但它能避免你被 Agent 反向牵着走。

以后看到 AI 生成的 diff，可以先过这张表：

如果有两项以上答不上来，别合。

不是永远拒绝，而是先把理解补回来。

AI 编程不会消灭工程判断，反而会放大它。

因为代码生成成本下降以后，烂方案出现得更快，过度抽象出现得更快，大 diff 出现得更快，CI 绿灯带来的误判也出现得更快。

以前一个坏方案可能要写两天才暴露。现在半小时就能摆在你面前，还附带一段自信满满的解释。

所以别把“接受 AI 代码”当成效率。

真正的效率，是你能快速看出哪些代码不该进仓库。

AI 可以写得很快，但合不合，还是你负责。