AI 写出来的代码，能跑，CI 也绿了。

但如果你解释不清它为什么这么写，要不要合并？开发者 Vini Brasil 在一篇文章里给出的答案很硬：不要合并。哪怕它看起来已经完成任务。

他讨论的不是同事提交的 PR，而是自己让 coding agent 完成任务后留下的 git diff。更反常的是，他已经用了 plan mode，也会拆任务、小步提交。可一旦改动超出自己的理解范围，review 还是会变成认知过载。

这篇文章真正有意思的地方在这里：AI 编码的瓶颈，正在从“能不能生成代码”，转向“人类还能不能判断这段代码该不该进系统”。

能跑，不代表团队能拥有

作者并不反对 AI 编程。

他的判断更像一个老工程问题的新版本：代码不是写完就结束，而是从合并那一刻开始，被团队长期维护。AI 让实现提前发生，但没有替工程师完成问题理解、方案取舍和复杂度控制。

所以他会拒绝一些“已经工作”的 AI 代码。拒绝标准不是模型名，也不是生成速度，而是自己能不能承担这段代码进入系统后的后果。

该拒绝的信号表面看起来真正的问题
说不清方案功能跑通，但无法用自己的话解释维护责任失控
diff 过大一次改动覆盖太多文件review 成本上升，回滚变难
过早抽象先搭框架，再找需求匹配复杂度被提前固化
代码绕远CI 通过，但逻辑难读后续排障和交接变慢
信输出超过信理解依赖模型判断“应该没问题”人类变成橡皮图章

这里有个细节很重要。作者提到，第一次用 AI 做大任务，结果常常会被丢掉；第二次反而更好。

不是模型突然升级了。

更可能是人变清楚了。第一次生成让工程师看到了问题边界、坑位和错误方向。到了第二次，人能给出更好的约束，也更知道哪些方案不该要。

这说明 AI coding agent 需要优秀工程师引导。它不是把工程判断外包出去，而是把工程判断提前暴露出来。

CI 通过，只证明它通过了已有检查

很多团队容易被绿色 CI 安慰。

但 CI 验证的是已有测试、lint、构建流程能不能通过。它不负责证明抽象是否合适，也不负责判断边界条件是否完整，更不负责告诉你这段代码三个月后还好不好改。

AI 代码尤其容易卡在这个缝里。

它可以很快补测试、修 lint、让流水线变绿。可它也可能把复杂度藏进更深的调用链、更泛的抽象层，或者一个看似通用、其实没人需要的框架里。

这也是 Copilot、Cursor、Claude Code 这类工具变得更像“会改项目代码的同事”之后，团队必须面对的现实约束：工具越能动手，review 越不能只看结果。

AI review 可以帮忙找明显问题，比如遗漏文件、简单 bug、风格不一致。但它不能替代强制人工 review。原因很朴素：线上故障、接口演进、下一个需求，最后还是人来负责。

对比一下，问题会更清楚：

检查方式擅长什么不擅长什么
CI验证已有测试和构建规则判断设计质量、抽象边界
AI review快速扫常见错误和一致性问题承担维护责任、理解业务取舍
人工 review判断方案是否该进系统需要时间，也会受认知负担限制

所以，“CI 通过”只能作为入门门槛。

真正的合并门槛应该再往前一步：提交者能不能解释方案，reviewer 能不能判断取舍，团队能不能承受这段代码带来的长期成本。

受影响最大的是写代码的人和合并代码的人

对正在使用 AI coding agent 的软件工程师，这件事意味着一个很具体的动作：不要把 agent 生成结果直接当成自己的方案。

更稳妥的做法，是限制单次 diff，要求自己写清楚方案取舍。看不懂的部分不要靠“模型应该懂”带过去。必要时直接丢掉，带着第一次暴露出来的问题重新生成。

这会让人不舒服。因为表面上，AI 已经把代码写完了；实际上，工程师还要补上理解、筛选和解释的账。

对技术负责人，重点不是禁止 AI，也不是鼓励大家多生成代码。

更现实的动作有几类：限制单次 agent diff 的规模；要求 PR 描述写清“为什么这样改”；对新增抽象设置更高门槛；核心模块保留人类 reviewer 的否决权；AI review 只能做辅助，不应成为免人工审查的理由。

这不是流程洁癖。

如果团队只奖励“更快提交”，不约束“更容易理解”，AI 带来的速度会转成另一种排队成本：代码已经写完，人还在排队弄明白它为什么存在。

接下来最该看的，也不是哪款模型又快了多少。

更值得看的变量是三个：团队能不能把任务拆小；工程师能不能解释 AI diff；负责人敢不敢拒绝已经通过 CI、但设计说不清的代码。

回到开头那一幕：CI 绿了，功能也跑了。问题并没有结束。真正的问题刚开始——这段代码，团队到底能不能接得住。