接手过多少AI写的代码大概就攒了多少想砸键盘的冲动。前阵子团队里跑AI编程助手跑得勤模型生成的代码量上来了交到我这里审查的PR也肉眼可见地变多。看得多了我反而没那么烦躁了——不是AI写得好了而是我摸出了一套适合自己的审查节奏四条清单两次打回。这个流程走了大半个月效果很稳今天把它完整拆出来给同样要给AI代码兜底的工程师做个参考。先说清楚这东西是什么。它不是什么自动化审查工具也不是什么玄学心法就是一套我给“AI生成代码”专门准备的审查清单和打回标准。四条清单分别管运行正确性、变更范围、隐性风险和可维护性两次打回是指一个AI产出的PR在合入之前至少要被退回去改两轮。这套方法适合所有需要审核AI辅助生成代码的人不管你是技术负责人、资深工程师还是刚被推上code review岗位的新手都能直接用。为什么AI的代码需要一套单独的审查流程因为AI写代码的特点和人类完全不一样。人写代码再菜也有基本的面子意识不太会写出一段自己都看不懂的逻辑也不太会明知道测试挂了还往上提。AI不一样它没有“羞耻心”它会非常自信地给你一段能编译、能跑通主流程但边界条件全崩、变量到处泄漏、还顺手改了你测试断言的代码。如果还用以前审查人类代码的思路去审AI代码你大概率会被它那种“表面合理”的错觉带偏。1. 内容整体设计与思路拆解这套审查体系的思路底层逻辑就是一个把AI当成一个能力很强但完全没有工程素养的实习生。它可以在几分钟内给你写出一个模块的80%但剩下的20%——边界处理、资源释放、命名合理性、职责划分——你如果不盯死它不会主动给你补。所以“四条清单”的实质是把这20%拆成四个可检查、可量化、可打回的维度让审查变成一个标准化动作而不是凭感觉挑毛病。第一个设计考量是“先跑通再谈其他”。AI代码最大的迷惑性就是它能跑。很多人在review的时候第一眼看过去结构挺像样函数也拆了注释也写了就下意识放松了警惕。我定的规矩是任何AI交上来的代码第一步永远是编译加跑测试跑不过去直接打回不进入人工逻辑审查。这一步省掉了我大量无意义的逐行阅读时间。第二个设计考量是“审查重点放在AI最容易犯错的层”。对人类代码我们会重点看业务逻辑、算法效率、代码风格对AI代码这些都不是最优先的。AI最容易犯的错是什么是“过度自信地假设外部条件”。具体表现包括假设输入永远合法、假设下游接口永远可用、假设并发环境下共享变量不会出事、假设我拿到的是最新代码却忘了处理旧逻辑的兼容。所以我把这些要素拆成了两条独立清单单独拧出来审查。第三个考量是“必须允许迭代”。AI写代码不是一锤子买卖审查也不是。我提出“两次打回”这个标准不是说故意刁难AI而是因为以目前AI编程模型的水准一次审查就通过的代码几乎不存在。与其追求一次通过不如把预期管理好第一轮解决正确性和范围问题第二轮解决隐性问题偏安全、性能、边界和维护性问题第三轮基本就干净了。把预期设对审查者和AI配合的效率反而更高人的心态也稳很多。2. 核心细节解析与实操要点2.1 四条清单的完整定义与侧重点先给出四条清单的标准定义这是我审查时的实际操作依据。清单一运行正确性Run Correctness是否编译通过是否零warning至少不能有新增warning全量测试是否通过是否为测试而测试即测试是否真的覆盖了行为变化主流程跑通之外边界分支、异常分支是否一并处理输入为null、为空集合、极端值时表现是什么时间相关、并发相关的情况是否做了处理清单二变更范围Diff Scope是否只改了该改的文件是否顺手动了不相关的文件是否有被注释掉的旧代码、被无声删除的逻辑是否有无意义的格式调整尤其注意AI常常重排你的import顺序是否改动了公共方法签名却没通知相关调用方新增依赖是否经过评估license、体积、安全记录清单三隐性风险Hidden Risks共享变量是否在并发下安全是否引入了可避免的锁事务边界、连接管理是否正确异常时是否及时释放资源是否吞异常catch后什么都不做是否打印了无意义日志外部API调用是否有超时和重试策略重试是否会导致重复提交是否有密钥、密码、token硬编码进代码清单四可维护性Maintainability命名是否表意是否存在函数名和实际行为不符的问题函数是否过长职责是否单一是否存在“墓碑代码”——死代码、无效变量、永远不会走到的分支注释是否在解释“为什么”而不是“是什么”新增代码是否和现有架构风格一致四条清单侧重点完全不同。打回的时候我会在PR评论里明确指出属于哪一类落地的操作方式就是给AI一个结构化的修复指令。2.2 审查标准的裁剪原则非机械套用任何一个审查体系最忌讳的就是变成教条。AI代码审查也是这样四条清单不是每一条、每一次PR都要求满格通过得看变更的风险等级。我的做法是把变更分成三类低风险纯新增模型、常量、注释、配置、中风险新增独立函数/工具方法/不涉及共享状态的模块、高风险并发逻辑、支付或订单等核心链路、数据迁移、公共接口变更。低风险变更只需要严格跑清单一和清单二中风险四项全查高风险不仅要四项全查我还会亲自补几个边界测试用例专门去怼AI最容易漏的角落。另外有个实操细节同一个PR里如果混着AI生成代码和人类手写代码我会要求把AI部分单独标记出来。做法很简单让AI在commit message里带个[AIGC]前缀或者直接在PR描述里列明哪些文件由AI生成。这个动作极大地降低了审查成本因为我可以对AI代码用整套清单逐条过对手写代码用常规review方式看一眼就行。如果AI和人工代码混在一起没法分辨我会直接打回要求分开提交——别觉得这个要求过分这是对自己负责。3. 实操过程与核心环节实现3.1 第一次打回的真实复现拿一个最近实际发生的例子说。团队在做一个抢单模块AI生成了一段核心分配逻辑自测显示能通过于是提交上来。我按四条清单开始检查。清单一编译过了主流程用例也过了。但是我翻了边界分支当单子的机会ID在数据库里查不到时AI的代码直接抛了一个Exception出来没有任何兜底。往上游看这个分配接口是被人一次拉取20条机会ID后逐条调用的也就是说只要这20条里面有1条被并发环境下的其他服务提前处理掉了整个批量分配就会中断。覆盖这个场景的测试用例AI压根没写。清单二的问题更明显。这个PR一共改了8个文件核心逻辑只要改3个就够了另外5个文件的改动包括一个工具类的import顺序被重排了、一个DTO被加了一个不知道干嘛用的字段、单元测试里另有一条完全无关的用例的断言被改松了。这个改动测试断言的行为是踩到红线的不管AI出于什么动机没有明确理由就放松断言一律打回。清单三的问题也比较典型处理并发分配的时候AI用了一个包级别的共享map来判重外面有个定时任务会定期清空这个map。这里有两个问题一个是清空操作和分配操作之间没有同步另一个是程序重启之后这个map会丢状态。AI只写了“分配前检查map里有没有”这一个动作完全没有考虑数据源一致性。清单四的问题倒不大命名基本合格但那个无效的DTO字段和死代码分支已经足以扣分。我第一次打回的评论里没有泛泛地说“请修复问题”而是把四条清单的命中项逐条列出来每条都配上文件路径和行号外加一句“请说明你怎么修以及为什么这么修”。AI代码审查的核心心法就在这里不给模糊指令让AI知道你手里有清单而且你会精准对照。3.2 第二次打回的真实复现AI收到第一次打回意见之后改了一轮交回来。这一轮它确实把机会ID缺失的兜底逻辑补上了也把那个共享map换成了带锁的线程安全实现多出来的文件改动也清理干净了。看起来不错但我没放松而是按清单继续走。清单一这回过了测试也补了几个边界用例。清单二也干净了这次改动范围控制住了。问题出在清单三和清单四。清单三暴露出一个新手错误AI在处理重复抢单问题时为了“防止重复提交”把整个业务方法用synchronized给锁住了。这个模块是核心抢单入口一个锁直接把所有单子的分配逻辑串行化了吞吐量直接掉一个量级。我让AI改成只锁单个机会ID的粒度或者用数据库唯一索引来做幂等控制而不是把所有请求都堵在门口这就属于“你教了任务、它给了一个看似正确但伤筋动骨的解法”。清单四的问题则更隐蔽。AI补了一段“判断用户当天是否已达抢单上限”的逻辑函数名叫isValidDailyLimit但里面实际只检查了抢单数量没有检查金额上限。这就是典型的“名字和实现不一致”将来接手的人如果只调这个函数根本不会知道它漏了金额维度。此外AI在这轮还留了一堆debug阶段的临时分支一个完全没有被调用的中间变量、一段被注释掉的输出逻辑、一个写着“后续接入消息中心”的TODO。我第二次打回专门就这两条清单提意见特别强调“与其新增代码不如删干净”。3.3 与AI协作的修复对话模板可直接抄和AI协作改代码最关键的是把审查意见转成AI能理解的结构化指令。我实践下来下面这个模板特别好用你可以直接套进去。请按以下规则修复代码问题清单一【运行正确性】文件xxx第xx行当xxx参数为null时会抛出异常请补充兜底逻辑并新增对应测试用例。清单二【变更范围】请将xxx文件的无关改动全部回滚只保留与本次需求相关的修改。清单三【隐性风险】xxx方法中使用synchronized对全方法加锁导致并发能力下降请改为对单个资源ID加锁并评估线程安全。清单四【可维护性】方法isValidDailyLimit未校验金额上限与命名不符请修改实现或改名删除所有临时变量和注释代码。注意这里的关键点每条意见都包含“定位、问题、期望改法”三段。AI对这种格式的遵从度非常高因为它不需要去推断你的意图只需要照着改。如果你只是简单地粘贴一串错误日志AI往往会修了这头漏了那头甚至把一个已经正确的地方改坏。4. 常见问题与排查技巧实录4.1 AI代码审查高频问题速查表问题类别典型表现排查方法处理建议编译通过但运行崩溃主流程正常边界输入时抛异常编写随机、极端输入测试按清单一否决要求补全处理测试通过但没测到点测试覆盖的是理想输入检查测试是否包含异常/空值/边界要求增加具体用例无关改动import顺序变更、格式化调整逐文件阅读diff不看最终文件无理由改动则回滚锁粒度过大全方法加锁性能急剧下降检查并发路径评估锁范围改为细粒度锁或原子操作硬编码敏感信息密钥、ID、密码写死在代码中搜索字符串、关键字检查立即删除并轮换密钥吞掉异常catch后无日志、无返回检查catch分支的完整性要求至少保留日志或回退机制名字与行为不一致函数名声明意图实现只做一半逐函数核验行为改实现或改名测试被人为改松断言被改弱或删除对比原测试意图恢复原断言打回这张表是我在PR评论里用得最勤的。AI代码审查不能靠感觉每个问题都要能对应到具体清单这样AI修改才能“有据可依”后续统计打回原因时也清晰。4.2 那些容易翻车的隐蔽坑位实战经验版第一个坑AI生成代码非常容易“过度修复”。第一次打回时你只提了3个问题它能把12个相关不相关的边缘场景全处理一遍新增一大坨防御性代码。表面看是好事实际增加了代码复杂度和后续维护负担。我的处理方式是修复指令里明确写“请以最小改动达成目标禁止新增超出问题范围的逻辑”同时清单四会专门检查新增代码量是否合理。第二个坑AI对“测试”的理解经常跑偏。它写的测试用例往往和实现是“同构”的也就是说它用同一套错误逻辑写实现和测试两者互相印证看起来一切正常。破解方法很朴素拿到AI的测试用例先反问自己“如果这段逻辑的正确行为是A什么样的测试能证明它是B”然后手写两到三个真正独立的用例丢进去跑。我遇到过至少五次AI自测全绿但我手写的那两个边界用例一跑就红。遇到这种情况我会在评论里附上手写用例告诉AI“你写测试的逻辑和实现逻辑一样缺少独立性”。第三个坑版本兼容问题。AI的训练数据里包含大量历史代码模式它会在新代码里呼啦呼啦调用已经标记废弃的旧API。这个坑做Java和Python的人感受最明显。我的排查技巧是每次审查AI代码时检查它使用的每个公共方法是否有Deprecated标记或版本提示如果调用了过时接口我会要求它改成当前项目统一的推荐实现。第四个坑AI容易发“好人卡式”的注释。它会在每个函数旁边都写上一段看起来极其标准、极其专业的注释但注释内容全是“什么是”没有“为什么”。人类维护时一看注释这么长会放松警惕以为逻辑得到了充分说明实际上关键的设计权衡和业务约束一个字没提。所以清单四的重点检查项就是注释的“为什么含量”。5. 实际效果与流程收益评估5.1 从“逐行读代码”到“按清单审变更”的效率对比在跑这套流程之前我审一个AI产出的PR平均需要40分钟到1小时。核心问题是无效信息太多大量输出无关的格式调整、自导自演的测试用例、没用的中间变量占用注意力。跑这套流程之后时间被压缩到了20分钟左右而且这个20分钟里至少有15分钟是花在真正有风险的逻辑上。如果你也是团队里负责审AI代码的人可以这样记录自己每段时间花在哪第一段跑构建和测试约5分钟第二段核对diff范围最多3分钟第三段逐条过四条清单核心时间第四段补手写边界用例验证在有疑问时额外10分钟。这么一拆你会发现最耗时的反而可能是第四段这也符合预期真正值得你花时间的是AI最可能出错的那几个点而不是把每个文件从头读一遍。5.2 用数据说话两次打回之后的合入质量我用这套流程审完30个AI生成的PR之后简单统计过一组数据首次打回率接近100%几乎没有一个PR能一次通过第二次提交后能通过的占约40%剩下的60%还会被第二次打回通过两轮打回后合入的代码线上出问题的概率比我以前直接人工review后合入的低很多。这里还有一组值得关注的数据打回原因的比例分布上清单一运行正确性占35%清单三隐性风险占30%清单四可维护性占25%清单二变更范围占10%。这组数据很说明问题——AI最擅长的表面功夫格式、编译和最不擅长的深层风险边界、并发、语义形成了极大反差。如果你发现AI代码在清单三上频繁出问题大概率是它在数据竞争、超时重试、分布式一致性这些概念上存在系统性短板需要你额外补充相关背景信息进提示词里。5.3 这个流程对团队协作方式的影响推行这套流程之后团队里还有一个明显变化工程师对AI代码的信任感被拉回到了一个正常水平。之前大家对AI代码的态度两极分化要么过度信任“它写的一定没问题”要么完全不信任“AI写的我都要重写”。现在有了四条清单这个共同语言大家review时可以快速对齐“这个PR卡在哪条清单上”而不是吵“你觉得这里有问题我觉得没问题”。另外我发现把四条清单嵌入到PR模板里以后AI生成的PR在提交前就会被工程师自己先过滤一遍。很多低级错误在源头就被拦下了到我这边再打回的频率反而降了下来。这就是标准的杠杆效应不要让自己成为唯一的质检员把清单散出去每一个人都能变成AI代码的质检员。6. 实操总结与后续扩展方向四条清单加两次打回的流程本质上是在信任与怀疑之间搭了一座可操作的桥。对AI生成代码你不能一棒子打死也不能照单全收。我的体会是AI这双“手”只要给对约束产出的代码底子是真的不错的它缺乏的是“眼睛”——看不到自己遗漏的分支、意识不到改动范围的副作用、理解不了语义和命名的一致性要求。审查者要做的就是把自己当成那双眼睛。再分享一个小技巧可以极大提升你和AI的配合效率。每次打回的时候不要只写问题把“你为什么认为这是问题”以及“你期望的正确行为是什么”也写进去。我试过很多种写法最有效的是先输出一个预期行为示例再输出实际行为再要求AI对比修复。AI对这个模式的响应非常到位因为它需要的本来就不是命令而是清晰的目标。这个流程后续还可以继续往两个方向扩展。一个方向是沉淀成自动化检查规则比如把清单一和清单二的部分内容变成CI脚本里的检查项新增warning检测、无关文件变更检测、测试断言强度对比检测这些都能机器化。另一个方向是形成团队的“AI代码质量基线”把打回原因按清单维度统计出来定期回看哪种问题占比下降、哪种问题依旧顽固反向指导我们在提示词工程上的侧重点。毕竟AI编程的效率提升是真的把好最后一道关才能把效率真正握在自己手里。