1. 为什么AI写的代码更需要Code Review很多人有个错觉AI生成的代码看起来结构清晰、命名规范、注释齐全应该比人写的更靠谱。我一开始也这么想直到有一次让AI帮我写一个数据聚合脚本跑测试全绿上线第二天数据对不上排查了半天才发现它在处理空列表时返回了默认值而不是抛异常把上游一个真实的空数据当成了正常情况静默吞掉了。这个bug人眼扫一遍代码根本看不出来因为逻辑太顺了。这就是AI代码的典型特征表面完美边界脆弱。它擅长生成happy path上的代码对异常分支、并发竞争、资源释放、类型边界这些地方的处理往往是看起来有但经不起推敲。所以Code Review在AI辅助开发的时代不但没有过时反而变得更重要了——因为代码产出速度上去了如果审查环节跟不上技术债的积累速度是以前的几倍。这一篇是我自己在团队里推行AI代码审查流程的完整总结。核心想聊的不是要不要Review这种废话而是AI写的代码到底该重点看什么、怎么看出问题、用什么流程保证不漏。适合已经在用AI写代码但心里没底的开发者也适合带团队、需要建立审查规范的技术负责人。先说一个反直觉的结论审查AI代码时最该警惕的不是它写错的地方而是它写得太顺的地方。人写代码卡壳的地方往往是难点你会本能地多看一眼AI写代码一路流畅你的警惕性反而会下降。下面我把这套方法论拆开讲。2. AI代码的六类高频隐患与识别方法2.1 边界条件空值、空集合、零值、极值AI最常翻车的地方就是边界。它默认输入是正常的对空、零、负数、超大值、超长字符串的处理经常是缺失或者想当然的。举个我实际遇到的例子。让AI写一个计算订单平均金额的函数它写出来大概是这样def avg_order_amount(orders): total sum(o.amount for o in orders) return total / len(orders)逻辑没错但orders为空时直接除零崩溃。更隐蔽的是如果业务上空订单列表应该返回0而不是报错那这个实现就是错的。AI不会问你业务语义它只保证数学上平均值的定义是对的。审查这类问题的实操方法拿到AI代码后先不看主逻辑直接找所有涉及索引、除法、解引用、类型转换的地方逐个问自己这里输入为空/为零/为负会怎样。我一般会在脑子里过一遍这个清单检查点典型问题验证方式集合操作空集合求平均、求最大传空列表跑一次索引访问越界、负索引传边界长度除法运算除零分母传0类型转换字符串转数字失败传非数字字符串字典取值key不存在传缺失key这张表我基本是条件反射地在用看AI代码时对着扫一遍能拦下至少一半的隐患。2.2 异常处理吞异常与假处理AI特别喜欢写try...except但它的异常处理经常是假处理——捕获了异常却什么都不做或者打印个日志继续往下跑把错误状态带到了下游。try: result process(data) except Exception as e: print(fError: {e}) return result # result可能根本没被赋值这段代码有两个问题一是except太宽把所有异常都吞了二是异常发生后result未定义后面直接NameError。AI生成这种代码是因为它在训练数据里见过大量防御性编程的写法但它不理解防御的目的是让程序在异常时进入一个明确可控的状态而不是假装没事。审查要点每一个except块都要问捕获之后程序处于什么状态这个状态是合法的吗。如果答案是不确定那这个异常处理就是有害的。正确的做法要么是让异常向上传播要么是在except里做明确的降级或补偿并且记录足够的上下文。2.3 并发与状态看不见的竞态这个是最难查的因为AI生成的并发代码在单线程测试下完全正常。我见过AI写的一个缓存更新逻辑用了全局字典加锁看起来没问题但它把检查是否存在和写入分成了两个独立的加锁操作中间有个窗口期高并发下会出现重复计算甚至数据覆盖。if key not in cache: with lock: cache[key] compute(key)正确写法应该是把检查和写入放在同一个锁里或者用setdefault这类原子操作。AI不会主动考虑这种检查-使用之间的时间窗口因为它的训练样本里大部分是单线程场景。审查这类代码我的经验是只要看到共享可变状态全局变量、类属性、缓存、连接池就假设它有竞态然后去找所有访问它的地方看有没有读-改-写被拆开的情况。这个排查过程很费脑子但比线上出问题后半夜爬起来查日志划算得多。2.4 资源管理文件、连接、锁的释放AI写文件操作经常忘记关或者用open不用with。写数据库连接经常忘记在异常路径上释放。这类问题在脚本里跑几次看不出来跑久了就是句柄泄漏、连接池耗尽。f open(data.txt) content f.read() # 中间如果抛异常f永远不会关闭 process(content) f.close()审查方法很直接搜所有open、connect、acquire、lock看它们有没有对应的close、release以及释放是否在finally或with里。AI现在对with的用法已经比较熟练了但在复杂逻辑里还是会漏尤其是多个资源嵌套的时候。2.5 依赖与版本隐形的环境炸弹AI生成代码时会引用各种库但它对版本的敏感度很低。它可能用了某个库的新API而你的环境里是旧版本或者它引入了一个你根本没装的依赖代码在你机器上跑不起来。我遇到过一次AI写了个日期处理用了zoneinfo这是Python 3.9才有的标准库而我们的生产环境还是3.8。代码在开发机上跑得好好的部署上去直接ImportError。审查要点对AI引入的每一个新import确认三件事——这个库在目标环境里存在吗、版本对吗、许可证合规吗。尤其是公司项目引入新依赖可能涉及安全审计不能AI说用就用。2.6 安全漏洞注入、越权、敏感信息AI生成的代码在安全上经常有惊喜。SQL拼接、命令拼接、路径拼接不做转义用户输入直接进查询这些经典漏洞AI都会犯因为它学的是能跑通的代码不是安全的代码。query fSELECT * FROM users WHERE name {name}这种写法在AI输出里出现的频率高得吓人。审查时所有涉及外部输入的地方都要过一遍SQL、shell命令、文件路径、模板渲染、反序列化。这块我建议直接上静态扫描工具兜底人眼容易漏。3. 把审查流程拆成可执行的检查清单光知道隐患类型不够实际审查时人容易走神、漏项。我的做法是把审查拆成几个固定阶段每个阶段有明确的关注点这样即使代码量大也不会乱。3.1 第一遍只看意图不看实现拿到AI代码先别急着看细节。花两分钟搞清楚这段代码想干什么、输入输出是什么、在系统里处于什么位置。这一步的目的是建立预期后面看实现时才能发现实现和意图不符的地方。我经常在这一步就发现问题AI理解的需求和实际需求有偏差。比如我要的是去重后计数它写成了计数后去重逻辑完全不同。这种偏差在细节审查时反而容易被忽略因为代码本身是自洽的。3.2 第二遍对着隐患清单扫边界和异常这一遍就是上面第2节那六类隐患的逐项排查。我一般会打开一个固定的checklist文档边看边勾。重点看所有函数入口的参数校验所有集合操作的空值处理所有异常捕获的合理性所有共享状态的并发安全所有资源的释放路径所有外部输入的转义这一遍最枯燥但最值钱。我统计过自己拦下的AI代码bug大概七成是在这一遍发现的。3.3 第三遍跑测试尤其是AI没写的测试AI生成的代码经常自带测试但它的测试往往只覆盖happy path。我会做两件事一是看它自带的测试有没有覆盖边界二是自己补几个刁钻的测试用例——空输入、超大输入、非法输入、并发调用。这里有个技巧让AI自己写边界测试然后你审查测试。因为AI写正常逻辑很顺写边界测试时反而会暴露它自己没想到的边界。我试过让AI给一个排序函数写测试它写了正序、逆序、重复元素但没写空列表和单元素这两个恰恰是最容易出问题的。3.4 第四遍看可维护性别让AI代码变成黑盒AI代码有个通病能跑但难改。它可能把一堆逻辑塞在一个大函数里变量命名虽然规范但缺乏业务语义注释写了等于没写将a加到b这种。审查时问自己三个月后另一个人或者我自己来改这段代码能不能快速理解。如果答案是不能就该要求重构。具体标准函数是否单一职责超过50行就要警惕变量名是否体现业务含义而不是data、result、temp这种关键决策点是否有注释说明为什么而不是是什么是否有魔法数字、硬编码路径3.5 审查记录把每次发现变成团队资产这一步很多人跳过但我觉得最重要。每次审查发现的问题我会记到一个共享文档里按类型归类。积累一段时间后这份文档就成了团队的AI代码避坑指南新人上手时直接看这个比看任何规范都管用。我们团队现在的做法是每周把本周审查发现的AI代码问题汇总一次提炼出新的检查项更新到checklist里。这样checklist是活的会随着AI模型的变化和项目的特点不断进化。4. 工具链怎么配让机器干机器的活人眼审查有极限尤其是代码量大的时候。我的策略是能自动化的绝不靠人把人的精力留给机器判断不了的地方。4.1 静态分析第一道防线静态分析工具能在几秒内扫出语法级、模式级的问题这些不该浪费人的时间。我常用的组合linter管代码风格、未使用变量、可疑写法。AI代码经常有未使用的import和变量linter一扫就出来。类型检查如果项目用TypeScript或Python的类型注解类型检查能抓出一批AI的类型错误。AI对类型的理解经常是看起来对实际不匹配。安全扫描专门扫注入、硬编码密钥、不安全反序列化。这块AI代码的命中率不低。配置这些工具时有个坑规则别开太严否则噪音太多人会麻木。我一般先开最核心的规则跑一段时间后根据实际发现的bug逐步加规则让每一条规则都有明确的它拦下过什么的记录。4.2 测试覆盖率看AI没测到哪覆盖率工具本身不判断对错但它能告诉你哪些代码路径从来没被执行过。AI代码的覆盖率往往呈现两极分化主逻辑100%异常分支0%。看到这种分布就知道该重点补哪些测试。我一般要求AI生成的代码分支覆盖率不低于80%且所有异常分支必须有测试。这个标准比很多团队对人写代码的要求还高但我觉得合理——因为AI代码的异常分支本来就是重灾区不测等于没写。4.3 差异审查只看改动别被全量淹没AI改代码时经常是重写而不是修改导致diff特别大审查时容易看花眼。我的做法是要求AI尽量做最小改动如果它非要重写我会让它先解释为什么不能增量修改。审查diff时我会特别关注被删除的代码。AI有时候会顺手删掉一些它认为没用的代码但那些代码可能有历史原因。删掉的每一行都要问为什么可以删。4.4 自动化门禁不合格的代码进不了主干最后一道保险是CI门禁。我配置的规则是静态分析有error、测试不通过、覆盖率低于阈值、有高危安全告警任何一条触发就阻止合并。这样即使审查时人漏了机器也能兜住。门禁规则要定期review太松了没用太紧了大家会想办法绕过。我的经验是门禁只拦确定是问题的不确定的降级为warning让人判断保持门禁的权威性。5. 团队协作审查不是一个人的事个人审查能力再强也有盲区尤其是AI代码这种看起来都对的东西一个人看久了容易产生信任惯性。团队协作能有效对冲这个问题。5.1 交叉审查换个人换双眼睛我们团队的规矩是AI生成的代码必须由至少一个非作者的人审查。原因很简单作者对AI代码有我写的心理认同容易护短而且作者已经看过一遍第二次看会跳过很多细节。交叉审查时我会给审查者一个明确的指引重点看边界、异常、并发、安全这四块风格问题交给linter。这样审查者有焦点不会漫无目的地看。5.2 审查会议疑难代码集体过对于核心模块或者特别复杂的AI代码我们会开个短会集体审查。流程是作者先讲这段代码要解决什么问题、AI是怎么实现的、自己已经查过哪些点然后大家提问。这个会最大的价值是暴露作者以为没问题但实际有问题的地方。我见过好几次作者讲的时候自信满满讲到某个边界时突然卡住然后发现AI那里确实处理错了。集体智慧在这时候特别管用。5.3 责任归属AI写的代码人负责这一点必须在团队里说清楚AI是工具代码的责任在人。不能因为这是AI写的就降低标准也不能出了问题甩锅给AI。我们团队的要求是提交AI代码的人必须能解释每一行的意图解释不了的就重写。这个原则听起来严但实际执行下来大家反而更愿意用AI了——因为知道有人兜底用起来更放心。关键是别让AI成为降低代码质量的借口。5.4 知识沉淀把审查发现变成规范每次审查发现的新问题我们都会问一句这个问题能不能变成一条规则。能自动化的写成lint规则不能自动化的写进checklist需要培训的做成案例分享。这样做的结果是团队的审查能力在持续提升而不是每次都在重复发现同样的问题。我印象很深的是我们最开始审查AI代码时空值问题每周都能发现好几个三个月后基本绝迹了——因为checklist里有linter也加了规则新人上手就知道要查。6. 几个我踩过的坑和对应的解法6.1 坑一过度信任AI的测试刚开始用AI写代码时我看它自带测试就放心了结果有次一个函数测试全绿但线上出错。后来发现AI的测试和实现是配套的——实现里有个bug测试里恰好绕过了那个bug的触发条件。解法AI的测试只作为参考必须自己补边界测试。我现在的要求是AI代码的测试用例里至少有三个是我自己加的而且这三个必须覆盖AI没想到的场景。6.2 坑二审查时被代码风格带偏AI代码风格通常很统一容易让人产生这代码质量不错的错觉。我有段时间审查时花大量时间在命名、格式上结果真正的逻辑bug漏了。解法风格问题全部交给linter和formatter人只看逻辑。我把这条写进了团队规范审查时如果发现风格问题直接让工具修不占用人的注意力。6.3 坑三AI改代码引入回归让AI修一个bug它改完之后原来的功能坏了。这种情况我遇到过好几次因为AI修改时只关注当前问题不理解代码的整体约束。解法AI改代码后必须跑全量回归测试而且diff要重点看它有没有动到不相关的地方。我现在会让AI改完后自己说明改了哪些地方、为什么这些改动是必要的说不清楚的就打回。6.4 坑四审查标准不一致团队里每个人对AI代码的审查标准不一样有人严有人松导致代码质量参差。这个问题在团队规模变大后特别明显。解法把审查标准写成文档并且用实际案例校准。我们每季度会做一次审查校准拿同一段AI代码让几个人分别审然后对比发现的问题讨论哪些该报哪些不该报逐步统一标准。6.5 坑五审查成为瓶颈AI产出代码快如果审查慢整个流程就卡在审查上。我有段时间成了团队的瓶颈所有AI代码都等我审积压严重。解法分级审查。低风险的代码比如纯工具函数、无外部依赖走轻量审查看一遍加跑测试就行高风险的代码涉及资金、权限、核心数据走完整流程。分级标准写清楚大家按标准执行不用每件事都问我。7. 我个人的一点体会用AI写代码这一年多我最大的感受是AI没有让Code Review变得不重要而是让它的重点变了。以前审查主要看逻辑对不对、实现好不好现在更多看边界全不全、异常稳不稳、安全有没有漏。前者靠经验后者靠清单和工具。我现在审查AI代码的速度比审查人写的代码快因为我知道该看哪里——就那六类隐患扫一遍跑测试看覆盖率基本就清楚了。但前提是这套清单得自己踩坑踩出来别人给的清单你不会有感觉。最后分享一个我一直在用的小技巧让AI自己审查自己的代码。具体做法是把AI生成的代码再喂回去问它这段代码有哪些边界情况没处理、哪些异常可能被吞掉、有没有并发问题。它经常能发现自己第一次写时漏掉的东西。当然它的回答不能全信但作为审查的起点能帮你快速定位可疑区域效率提升很明显。