AI生成代码的审查指南：像审“初级工程师”一样审Agent

把Agent的贡献当“初级工程师的提交”来对待，是当下处理AI代码最清醒的比喻：它有活力、量大、从不抱怨，但它不懂你的系统、不记得上周的教训、并且对自己的每个输出同样自信——包括错的那一半。既然是类比成初级同学，审查流程也该照着带新人的那套重写一遍。

先立一条铁律：提交的责任人不是模型，是按下提交键的人。谁提交，谁对这段代码的每行负责，“这是AI写的”在事故复盘里不能作为任何程度的减刑理由。这条规矩听起来苛刻，但它解决的恰恰是当前最危险的心理陷阱——自动化偏误：研究表明，当贡献者从“可能犯错的人”换成“看起来很权威的系统”，审查者挑毛病的意愿会显著下降，长长的生成式PR更容易被一路点头放行。把Agent降格为“新人”，正好把走神的审查者叫醒。

具体审什么，优先级从高到低排。第一审意图：这段代码解决的是不是我提的问题？Agent最擅长的不是写错，而是“认真地做错事”——顺手发明一个没人提的需求，或者为了通过测试去改测试。要求PR描述里写清原始需求与实现思路的对应关系，对不上，直接打回，不进入逐行审查。第二审边界：错误处理、空值、并发、超时，这些语料里概率分布最低的地方，恰是生成质量最不稳的地方，初级同学不会主动写，模型也常常忘了写。第三审依赖：新增了哪些包、调用了哪些服务，供应链风险在生成代码里是按次数放大的，每个新依赖都要走正常评审，不能因为“生成时顺手加的”就豁免。第四审测试：测试是不是只把当前实现又跑了一遍——这种“确认性测试”比没有测试更危险，它给错误盖了合格章。要求每条新逻辑至少有一个“实现改坏就会红”的用例。

流程上也要配套改造。控制单次提交的体量，Agent生成天然偏大，但“大PR没人审得动”不是AI时代的新问题，所以强制拆分，超过四百行的生成式变更默认要求当面讲；在仓库模板里统计AI参与度，不是为了追责，是为了把审查资源向高生成占比的提交倾斜；安全相关与资金相关的路径，维持双人审查的硬规矩不变——这两类地方，初级工程师的代码尚且要盯，何况一个不懂你权限模型的模型。

最后说心态。用“新人”做比喻，不是贬低Agent——它的知识量远超任何新人，出错时却比新人更缺乏自知。对待这样的贡献者，好带班的做法从来就是那几条：任务拆小、验收标准写明白、别让它碰生产密钥、每次反馈都记录成规矩。你会发现这套东西和成熟的工程流程完全重合——AI没有给代码审查发明新学科，它只是把原来流程里“靠人情硬扛”的部分，变成了“不照做就出事”的部分。指南写到这里，核心其实一句话：以前你审代码是为了拦住粗心的人，现在还要拦住那个粗心却自信的自动机——而拦住它们的方法，人类十年前就想全了。