上周五晚上我对着一个AI生成的数据同步模块做code review从入口函数一路翻到数据库操作层函数写得很干净类型标注也挑不出明显问题。就在我以为“这轮AI质量还不错”的时候最后一个状态机分支把我拉回现实它把已经取消的订单恢复成了等待支付注释里还写着“补发漏掉的事件”。那一瞬间我特别想砸键盘倒不是气AI写得不对而是气自己花了整整三个小时逐行审完以后最核心的业务规则还是漏了。类似的经历多了以后我开始认真反思一个问题很多开发者的code review习惯还停留在“审核人类写的代码”这套思路上可被审的对象已经变了。AI生成代码的占比越来越高一次PR里的几百行可能都不是人敲出来的而是模型在一个生成会话里快速补全的。如果继续用一行一行精读的方式去耗投入产出比会迅速崩塌。如果你正被一波又一波AI生成的PR淹没或者刚把AI编码接进团队流程这篇文章想跟你聊的不是“要不要审”而是“怎么审才有效”。我后面会用一个真实的重试中心模块案例回放整个评审过程也会把我自己踩过的几个坑和一个用来替代逐行精读的“三层定位法”完整讲一遍。核心结论先说在前面AI生成的代码必须审但它的defect pattern和人类代码完全不同继续逐行review约等于拿着十年前的武器打今天的仗看起来在防守实际每一刀都砍在空处。1. 为什么逐行审AI代码审完照样翻车1.1 那一次“审完等于没审”的复盘那次让我破防的同步模块代码本身非常能迷惑人。它在取消订单的入口处有一个明显的判断注释里写着“已取消订单不应再同步”switch分支也处理了CANCELLED状态。如果只读单个文件任谁都会觉得这地方没问题。但问题出在另一个文件里有一段“重放最近事件”的逻辑在状态判断之前就把已取消订单重新塞进了事件队列末端又走了一个default分支把订单改成待支付。两个文件分开看都合理合在一起就形成了业务漏洞。我后来复盘时想明白一件事逐行阅读会对人产生一种“全局完型”的错觉。你从第一行读到最后一行的过程里大脑会自动帮你脑补那些没写出来的约束条件于是每一段代码看起来都“差不多合理”。读得越久这种“差不多”的感觉越强真正需要绷紧神经的地方反而被稀松平常的代码盖过去了。对人工写的代码这种风险相对可控因为人类很少有动机把业务规则拆得这么散但AI生成代码时是按token接力的没有任何“全局约束”概念它天然就会把关联逻辑拆散、写重、写到自相矛盾。1.2 低级错误少了高级错误藏得更深先说个反直觉的观察AI生成的代码低级语法错误反而比人类少得多。它不会漏写分号不会把变量名拼错——模型在预训练阶段见过海量高质量代码局部语法层面对它来说几乎是肌肉记忆。所以传统code review里最花时间的拼写检查、逻辑短路、空指针防御放到AI代码里已经不是主要矛盾。它的主要问题出在“上下文理解”上。模型做的是逐token预测下一个最可能的词它会先观察你的项目路径、函数名、上面的注释、最近几行代码然后生成最像“标准答案”的后续。这意味着它擅长“下一句怎么接”但并不真的理解“这个系统承诺了什么”。我见过太多AI函数单独拎出来都有模有样但放到整个调用链里它根本不知道调用者对它的期待是什么。一个函数该返回null还是空列表它不知道一个状态机该不该允许从CANCELLED跳回PENDING它也不知道。这些全是语义层的错误而逐行阅读恰恰是最难发现语义层错误的审法。1.3 注意力预算被低风险代码吃光了另一个容易忽略的问题是专注力分配。人的审阅注意力是有限的消费品一个下午能真正维持高强度的代码判断可能只有两个小时。逐行review会把这两个小时平均拆到几百行代码里等走到那些真正需要做语义判断的边界条件时大脑已经累到只想划水。我给自己做过一次粗略统计同样一个模块用逐行方式读完全部文件需要三个小时但真正决定这个模块能不能上线的高风险判断点用手指头数得过来大概只占全部代码的20%。其余80%都是数据搬运、简单分支、样板调用。逐行review本质上是在用80%的时间去看低风险区域再用剩下的疲惫去处理那真正重要的20%顺序完全反了。决定AI代码能不能上线关键不在“它每一行是否写得规矩”而在“它有没有在关键路径上违背业务语义”。抓住后者比扫完全部代码重要得多。2. AI生成代码的“缺陷DNA”变了观察点也得跟着变2.1 三个逃不掉的特征局部幻觉、上下文衰减、无重构动机要审好AI代码先得接受它的生成机制带来的一系列特征。第一个特征是局部幻觉。模型会把一个函数或一个类的内部填充得特别有模有样但它可能在引用一个并不存在的辅助类、一个从来没被定义的枚举值。这些幻觉往往不是大的语法错误而是“看起来像真代码但其实不存在的东西”。如果你对项目本身不够熟很容易被这种合理感带偏以为是自己没见过的内部封装。第二个特征是上下文衰减。无论模型宣称多长的上下文窗口实际生成到第几百行以后它对开头提示词里约束的执行力度都会肉眼可见地减弱。你让它“用户状态只用枚举UserStatus”生成前200行没问题到了文件尾部它突然开始写字符串active就是因为早期的指令已经不在当前生成的注意力里了。第三个特征是没有重构动机。人写代码时会主动抽取重复逻辑因为人讨厌重复劳动AI没有这种“讨厌”的情绪它只会顺着局部模式继续复制。于是你会看到同一个分页逻辑出现在七八个类里每个文件的实现还略有差异。逐行阅读的时候每个文件都合理将来要改统一规则的时候才知道什么叫痛。2.2 一份“缺陷观察清单”帮我把review目标排序既然AI代码的缺陷分布和人类代码完全不同我就照着实际踩坑经验整理过一份观察清单。遇到AI生成的PR我会先对照这张表判断风险区在哪而不是立刻开始读代码缺陷类型典型表现检测手段人工参与程度目标理解错位实现局部自洽但整体行为和验收要求相反对照需求用例和验收条件必须人工裁断契约不一致函数A假设非空入参函数B却可能传null类型检查、跨模块走查高重点看调用边界边界假设过强默认分支吞掉异常失败后无限重试异常分支核查高需要业务经验判断幻觉依赖引用了不存在的类/方法/第三方接口编译、import检查、IDE诊断低工具基本能拦截重复与臃肿大量结构相同的代码仅字段和枚举不同复杂度报告、diff统计中需要判断抽象时机上下文衰减前面统一用枚举后面突然用魔法字符串常量扫描、关键枚举静态检查中检查涉及业务标识的字段这张表对我的用处是强迫“先归类、再细看”。看到一个AI提交我会先问自己它最容易从哪一类上翻车如果是数据导出这类大面积样板代码重点放在重复和跨模块一致如果是订单状态机这类强业务逻辑重点放在目标理解和边界假设。分类完之后再去精读精度会高很多。2.3 Reviewer的角色变了从校验者变成语义裁断官顺着上面的观察清单能得出一个结论在新场景里人工review的核心价值不是替AI检查低级错误而是做语义裁断。AI可以帮你生成一个完整的状态机类但它无法替你回答“失败到底应该静默重试还是抛给用户”“已取消的订单碰到漏网事件时系统该补偿还是该丢弃”这类问题。所以我会反复跟团队强调一个点如果你在review AI代码时满屏都在改缩进、改命名、补注释那你这个reviewer是可以被工具替代的。但如果你能在代码里指出“这条路径缺少行为测试”“这个状态在某个入口没被重置”“这里默认执行的retry为什么不需要用户确认”那你做的是真正意义上的人工评审。AI生成代码并不会让code review这个动作消失它只是把人的工作重心往上推了一层。3. 我用“三层定位法”取代逐行精读现在讲我自己实操下来最管用的一套方法。核心思路很简单不要把review当成“阅读所有代码”而是当成“用代码回答几个提前设计好的问题”。我把它拆成三层每一层解决一种类型的风险。3.1 第一层先立验收标准再做“对号入座”很多reviewer拿到AI生成的PR后第一反应是打开diff从头往下滚。我的习惯是先忍住不看代码回到需求描述里把这次变更必须满足的行为逐条列下来。比如“取消后的订单在任何入口都不能触发补发事件”“重试超过5次必须进入死信队列”“同一个业务事件不能因为重复提交被执行两次”。这些条目甚至不需要写得很精确能让自己知道“哪些行为绝对不能错”就够了。列出验收标准之后再带着这些标准去代码里“对号入座”。我会用IDE的全局搜索搜状态字段的赋值点、事件发送点、关键常量的引用位置直接跳到相关代码块去看。这种方法的好处是你用需求索引代码而不是让代码牵着你的注意力走。上次审那个同步模块时如果我先写出“已取消订单不能触发任何事件”这条规则再搜索这个规则对应的所有入口大概率一眼就能看到那个重放事件的文件而不是被前面几十行规矩代码耗掉耐心。3.2 第二层只追踪从入口到核心状态变更的“轨迹”单个文件的代码只是一个点业务风险往往藏在一整条“从入口到状态变更”的路径上。所以第二层我建议顺着运行轨迹走查而不是把每个文件从头到尾读一遍。具体做法是在diff里找到最外层的入口函数然后顺着调用关系跳到下一个真正修改业务状态的位置中途那些简单的路由方法、数据映射方法能略过就略过。这个思路有点像剪辑片子你不需要看每一帧只需要盯着关键镜头的衔接。拿状态机来说重点关注“状态字段在哪几行被修改”“修改之前有没有进入条件”“跨文件调用时传入的状态和接收方预期是否一致”。很多AI代码的问题不是单点写错而是A文件写进去的状态B文件按照完全相反的语义去解读。只有沿着运行轨迹把两个点串起来才能抓得住这种错位。3.3 第三层外部I/O、并发和不可逆操作必须进人工必审区有一些代码不管AI写得多流畅我都强制自己逐行细看。这类代码有一个共同特点一旦出错后果不是“功能不对”而是“钱算错、数据删了、消息发了两次、权限绕过去了”。具体包括外部API调用、文件删除、数据库批量更新、支付回调、消息发送、异步任务调度、以及一切并发状态竞争。之所以要单独开一个“必审区”是因为这些场景恰恰是AI理解最薄弱的地方。模型对超时、重试、幂等、分布式锁这些概念知道的都是常规套路但它不知道你的下游系统到底支不支持幂等不知道你的数据库隔离级别是什么更不知道你的运维规范要求所有外部调用必须带超时。这些“只有项目内部才知道的约定”AI是看不见的所以必须靠人工补位。实际做法是做一个固定的checklist外部调用有没有设置超时失败后是重试还是快速失败幂等键用的是什么并发写同一个状态有没有版本号或锁删除操作是不是软删除有没有操作日志每次审AI代码都把这些项过一遍虽然啰嗦但能拦下大部分会酿成线上事故的隐患。提示上面这三层不是严格串行的。如果发现某个验收标准特别容易出问题可以直接跳到第三层优先把高风险路径看完再回头处理其他部分。4. 避坑实录最容易骗过肉眼Review的四类问题与我的排查链路理论讲了半天还是得落到真实问题的排查链路上。下面四个坑都是我在review AI生成代码时实际遇到过、且大概率会反复遇到的。每条我都按“现象、排查过程、最终处理方式”串起来写。4.1 幻觉依赖API很合理但项目里根本不存在第一次遇到幻觉依赖时我非常震惊。那次让AI补一个批量导出接口它生成了一段看起来特别规范的代码内部调用一个叫DataExportCenter.batch_send(...)的类方法自带回调参数。我第一眼看到的时候甚至怀疑是自己对代码库不够熟还专门去翻了一下结果整个项目里压根没有这个类。AI凭局部上下文“脑补”出一个接口然后顺着模式往下写写出来的调用代码自然语法正确。完整排查链路是这样的第一层交给编译器和IDE做正常情况下Python的import错误、Java的符号解析错误都会在编译阶段暴露所以第一步永远是让CI把编译和静态检查跑完。第二层用依赖层面的扫描工具查未定义引用。但真正想避免这类问题最关键的是不要用肉眼去验证“这个类是否真实存在”因为AI的幻觉太流畅人会不自觉被带偏。工具亮红灯就相信工具工具没亮红灯但你对某个调用有“陌生感”时也要强制去定义处捅一下而不是默认它存在。4.2 修复污染让AI修一个bug它把整条逻辑都改了这个坑比幻觉依赖更难防。有一次我指出AI代码里“取消订单后不应继续补发消息”的问题它给出的修复方案是在handleCancel方法开头加了一个提前return。表面看问题解决了但它在同一个补丁里顺手把另外几个无关方法的默认参数也改了还调整了一个正常状态下的提示文案。结果就是单测依然全绿因为那些被改到的方法也有对应的mock数据但线上某个操作路径的提示语变了用户立刻感知到异常。这类问题的排查非常依赖“diff上下文”和“回归思维”。我的处理方式是先看AI给的补丁里所有与目标问题无关的改动凡是“顺手修改”一律打回。更重要的是review提示必须带上范围约束。让AI修改代码时不能只给“这里有bug”一句话而要明确说“只允许修改能说明根因的分支不要动其他公共方法的签名和默认行为”。如果AI做不到就退回自己改不要跟它在局部补丁上反复拉扯。4.3 重复蔓延它不是写错而是写了几十份类似但不完全一样的实现AI生成数据访问层时特别喜欢对每张表都生成一份独立的CRUD。一次PR里可能多出二三十个文件每个文件都实现了自己的分页逻辑有的用offset有的用cursor默认排序字段也各不相同。逐行看每个文件都觉得没毛病可一旦要统一加一个全局逻辑光是把这些重复实现找出来就要半天。我的排查步骤是先看diff统计不要急着进代码。如果一次AI提交的文件数量异常多而且大量文件之间的差异只有表名和字段名基本可以判定是重复蔓延。然后我会抽两三个文件做并排对比确认它们是否是同一个模式的复制确认后直接在评论里要求重构而不是在每一个文件里分别提意见。对AI代码来说重复不是“小瑕疵”它会在日后的维护里持续放大所以看到这种雏形就要趁早处理掉。4.4 上下文衰减前面还是个枚举后面突然变成魔法值上下文衰减这个现象我在比较长的AI生成任务里遇得很多。最典型的是做用户状态模块时AI开头的代码规规矩矩用UserStatus.ACTIVE这种枚举到了文件后段突然冒出字符串active。由于项目里恰巧也有人这么写过单测没有报任何错真正出问题是在排查线上数据异常时才发现同一张表里同一个状态字段混着两种表示法。这事的排查链路很大程度靠静态扫描。第一个动作是给关键业务状态和枚举建唯一来源禁止在代码里散落魔法字符串第二个动作是在PR检查里加一条“grep关键枚举对应的字面量”看是否有绕过枚举直接写常量的情况第三个动作是如果项目规模足够大可以直接写一条简单的静态检查规则让CI去跑。靠人眼在一两百行代码里发现一个字符串和枚举混用是有可能的但如果这个文件已经上千行还是别拿眼睛硬扛了。5. 把Review改成分层流水线工具先扫人工再判断既然AI代码量大、缺陷分布又和人类代码不同就不能把Review当成一个“人一次性完成的黑盒动作”而要拆成一条流水线。我的排序原则是让工具先吃掉那些确定的、不需要业务经验的缺陷再让人工把有限的精力投到语义裁断上。5.1 评审之前的机械关卡怎么搭一个最小可用的前置关卡大致分四层。第一层是编译和类型检查负责拦截幻觉依赖和明显的签名不匹配第二层是Lint和格式检查把缩进、未使用变量、过于复杂的圈复杂度这类问题先揪出来第三层是跑已有的自动化测试第四层是依赖和过时API扫描。我经常跟团队说AI生成的代码必须经过这套检查否则根本不要进入人眼review环节。用一段简单的命令来代表这套关卡大概是这样# 以Python项目为例评审AI代码前至少跑这些 python -m compileall app ruff check app --select E9,F63,F7,F82 pytest -x -q没用花里胡哨的东西但能挡住大部分低层级的“看着像代码其实编译不过”的问题。人工review只处理这些关卡无法回答的问题这个状态流设计对不对这个失败行为是否符合业务预期这部分重复代码现在要不要抽象。工具能做的判断交给工具人工才有余力做工具做不了的判断。5.2 行为测试优先于代码阅读没有测试就不进入人工审很多AI代码的测试是“配套生成”的但那些测试往往和实现使用同一套错误假设看起来覆盖率高实际上测了个寂寞。所以我把“先看测试有效性”放在“先看实现代码”前面。毕竟行为测试是对需求的编码如果测试能明确表达这次变更要保证什么行为人工审实现时只需要确认“实现是否让这些行为成立”效率会高很多。一个非常实用的检验技巧是我从变异测试思路里简化出来的看到一个测试后你可以刻意把被测实现里的某个关键判断改成相反值比如把status CANCELLED临时改成status ! CANCELLED然后跑测试。如果测试照样通过说明这个测试根本没用它和实现是“同谋”关系而不是在验证行为。让AI补测试很简单但让测试真正有断言力还是需要人工看一眼。5.3 人工Review的原则是“可以否决不用逐行证明”新场景下的人眼review更像是一道“关卡审批”而非“全文校对”。我需要确认的是这个PR在关键路径上是否违反了既有约束有没有哪个状态会被非法置入外部调用有没有不可控风险如果这些都没有我不会为了“显得认真”去逐行挑刺。这个原则也改变了我写review评论的方式。以前我可能会说“第120行命名不好建议改成xxx”现在我更常写“这条路径缺少测试不是缺注释而是缺一个失败场景的验证”或者“这里的状态在另一个入口没有被重置建议补充一个断言”。把评论从行级纠错提升到设计和行为层面团队里读评论的人也会更清楚应该改什么而不是机械地帮我调整那一行。6. 给PR加一个“AI信息区”让Review从读代码变成读上下文如果只有我一个人用这套review方法效率提升始终有限。真正让团队整体跑起来的关键是从流程上把AI生成的上下文显式写进PR里让reviewer不用靠猜去还原AI当初的想法。6.1 一个可复用的PR描述模板我对团队的建议是在PR描述里增加一个固定区域用来声明这个PR和AI的关系。模板大致如下## AI 信息 - 本PR由什么工具/模型辅助生成 - AI生成代码占比约x% - 生成前已经给出的关键约束 1. 用户状态只能使用 UserStatus 枚举 2. 所有外部调用必须设置超时 3. 重试超过5次进入DEAD状态 - 人工修改部分 - 尚未验证的风险第一次让团队填这个模板时很多人会觉得麻烦。但填过几次就会发现这份声明其实是把“模型在生成代码时得到的上下文”固化成一个可review的对象。reviewer不需要再花半小时从代码里反推AI理解了什么、忽略了什么直接看声明和约束就够了。6.2 Review的阅读顺序也应该变有了AI信息区之后reviewer的自然阅读顺序会从前到后变成先读约束声明再读变更意图描述最后才看代码改动。这样做有个很大的好处你先知道了AI被要求做什么再检验它做没做到而不是先看代码效果再猜需求。这个顺序上的差异能让很多隐藏的上下文衰减问题在对比约束时直接暴露出来。比如说约束里明确写了“用户状态只能使用UserStatus枚举”那么reviewer在看到代码里出现active时可以立即判断这是AI在长文件后段把约束丢了。没有这份声明时看到字符串active你可能还会想“是不是项目历史就这么写”。有了声明之后判断就是一件非常确定的事。6.3 团队清单要动态维护不能只列一次AI工具发展太快代码缺陷模式也在变。我觉得团队应该维护一份内部动态清单定期把新踩到的AI代码问题补充进去。比如某次我们发现长任务生成到第400行时容易把幂等键写成随机值就把“幂等键来源”列入重点检查项另一次发现模型在处理超时异常时喜欢吞掉错误继续重试就把它列成“默认分支要重点看”的一类。这份清单不需要设计得很花哨一个共享文档或PR模板里的一段checklist就够。关键是每次有人踩到新的AI生成代码坑都要及时把案例沉淀回去而不是让下一个人再交一遍学费。7. 回放一次“不逐行”Review事件重试中心的30分钟光说不练没什么意思我用一个事件重试中心模块的评审来演示这套方法在实际项目里长什么样。模块本身不复杂但涵盖状态机、重试、并发等高风险因素很适合当样本。7.1 拿到PR后我先写下四个验收问题需求是提供一个事件重试中心功能包括提交事件、查询事件状态、手动触发重试、取消任务。事件状态包括WAITING、RUNNING、SUCCEEDED、DEAD四种并且要求同一个业务事件不能因为重复提交被执行两次失败超过5次要进入DEAD状态取消任务必须能阻止正在运行的任务后续被重新入队。我在打开diff前把验收标准压缩成了四个问题状态字段在哪些位置被更新是否允许非法状态跳转幂等键如何生成能不能挡住同一业务事件的重复提交失败重试路径怎么走超过5次是否真的进入DEAD取消接口除了改状态是否真的影响到了正在运行任务的后续行为。带着这四把尺子我开始对着代码找答案。7.2 沿着运行轨迹看到的问题清单我先从入口提交方法开始顺着状态更新点往下跳。很快就发现同一业务事件在入队时生成了一个全新的task_id每次都用uuid.uuid4()幂等键根本没有跟业务事件ID关联起来。这意味着同一个订单取消通知即使提交两次系统也会当成两件完全独立的事。这个P0级问题如果靠逐行读文件可能要读到数据库层才会被发现但沿着“提交事件后幂等键怎么生成”这条轨迹走一眼就能命中。接着我检查失败分支。AI代码里用了一个try-except异常发生时进入一个else分支做的事情是把事件重新塞回队列头部。代码本身写得很干净注释也很完整可整个文件从头到尾都没有DEAD状态的处理。超过5次失败之后它只是无限重试。换句话说模型把“重试”理解成了“永不放弃”但这显然不符合需求。这类业务语义偏差不站在验收标准的层面看很难从单个函数内部发现。再看取消逻辑发现取消接口只更新了数据库里的状态但并没有告知正在运行的任务执行器。只要执行器里已有任务被拉起来即使状态已经被改成CANCELLED它也会继续执行到完成并在下一次扫描时再次入队。更麻烦的是完成回调和取消操作在并发场景下没有任何版本号或锁两个操作可能互相覆盖状态造成“已经取消的任务最终显示成SUCCEEDED”的情况。7.3 这30分钟里我到底“省”在哪了整个评审我只花了大概30分钟但这30分钟里抓到的东西比我之前花三小时逐行读一个普通模块时还要多。不是因为我看得更快而是我把读代码的目的从“检查每行的正确性”变成了“验证状态轨迹是否满足业务约束”。一旦review带着明确的检查目标AI代码的结构混乱不仅不是干扰项反而会逼着你更快地定位“它在这个节点做了什么假设而这个假设是否被允许