1. 当 AI 把代码产出速度拉满之后Review 为什么反而更紧先说结论AI 辅助开发这半年我们团队的人均 PR 量翻了三倍但线上事故并没有减少有些周甚至更多。原因很简单——AI 让“写出代码”变得便宜但让“确认这代码是对的”变得昂贵。以前手写代码一个人一天能产出几百行reviewer 逐行看也有压力但心里有底写代码的人至少知道每一行为什么存在。现在 AI 一口气给你生成一千行结构工整、命名规范、注释齐全乍一看比多数初级工程师写得还像样。但真正跑起来边界条件、异常链路、幂等设计、并发安全处处是坑。更麻烦的是这些坑长得特别“正经”——不是那种一眼就能看出来的拼写错误或空指针而是逻辑自洽但业务语义不对的“合理错误”。我遇到过一个特别典型的案例让 AI 写一个批量导入功能它非常顺利地把 Excel 解析、字段映射、逐行入库全写了代码风格也挑不出毛病。但我 review 的时候发现一个问题如果文件里有一行数据格式错误整批都会回滚而产品需求明确要求“跳过错误行、继续导入后面的数据”。AI 没有理解这个意图它只是按“最常规”的错误处理方式写了一个事务包裹。这种错误单测跑得过去联调未必暴露真正上线后用户导一次数据才发现全线崩掉。这就是为什么我越来越坚持AI 时代Review 不是可以削弱而是必须加强。它从“把关质量”变成了“核对意图”。代码生成的速度越快人类核对的速度就必须跟上否则就是在给线上埋雷。还有一个容易被忽视的维度AI 生成的代码把“代码审查”从技术活动变成了风险管理活动。以前 review 是看“有没有 bug”现在 review 是看“AI 有没有误会我的需求”——这是完全不同的审查思路。后者需要 reviewer 对业务上下文有更深理解而不只是会看语法。所以 Review 不是变简单了是变难、变重、变不可替代了。2. 三个“硬理由”为什么 AI 时代反而没人敢砍 Review2.1 概率生成的代码必须用“意图”校准大模型生成代码的本质是根据上下文预测最可能的 token 序列。它不知道你的业务目标是什么它只知道“这种写法最常见的后续是什么”。也就是说AI 生成的代码在统计意义上是“最像代码的代码”而不是“最符合你需求的代码”。这个区别特别关键。我经常打一个比方AI 写代码像是一个非常熟悉语法、看过大量范文的枪手替你写作文文笔流畅、结构完整但他不知道你这篇作文要论证什么观点。Review 要干的事就是拿着你的提纲去核对它的每段论证。具体到实操上审查 AI 代码时我会特别关注几个点**这个函数它为什么存在它解决的是我让它解决的问题还是它“以为”自己应该解决的问题**比如你让它“优化查询性能”它可能给你套了一层缓存但没考虑缓存与数据库的一致性你让它“加个用户状态字段”它可能同步帮你改了接口返回结构而前端还没有适配。所以现在我的团队里每个 PR 描述里必须写清楚业务上下文reviewer 第一件事不是看代码而是看“这个改动要达成什么业务目标”再回头看“代码有没有围绕这个目标展开”。这一步在 AI 时代是绝对不可省略的。2.2 AI 代码的错误更“隐蔽”测试也兜不住手写代码的错误往往来自打字失误、逻辑疏忽这类错误特征明显review 相对容易发现。AI 代码的错误则是另一个物种它在语法、风格、结构上高度自洽错误发生在“语义层”——要么是对需求的理解偏差要么是边界条件的处理过于“常规”而脱离实际场景。举个例子AI 生成的分页查询默认实现往往就是“LIMIT offset, size”它不会考虑深分页的性能问题AI 生成的删除接口默认实现就是 DELETE FROM它不会提醒你“这里有外键关联要不要软删除”AI 生成的上传接口默认接受所有文件类型它不会自动给你做内容校验。更麻烦的是测试用例本身也可能是 AI 生成的。如果你让 AI 写完功能再让 AI 写测试它通常会写“验证正常路径”的 happy path 用例而恰恰把异常路径、并发场景、数据一致性这些最需要覆盖的点漏掉。结果就是测试全绿上线出问题。所以现在我对团队的硬要求是AI 写功能代码可以但测试用例必须由人工设计核心场景AI 只能辅助补充细节。Review 的时候也必须重点看测试用例覆盖了什么、没覆盖什么而不是只看测试是否通过。2.3 安全与合规底线不能交给“概率”我审查过的 AI 生成代码里出现过几次很吓人的情况把数据库连接串直接写死在配置里、把用户明文密码打印到日志、前端代码里直接暴露了内部 API 的结构、没有做任何输入白名单过滤就开始拼接 SQL。这些都是安全红线AI 没有“红线意识”它只会按照最常见的写法输出——而最常见的写法往往就是“能跑就行”。具体到不同开发场景风险也不一样。比如我们内部有用 nginx 多端口做本地多站点开发的场景AI 生成的配置如果 rewrite 规则写错轻则多站点互相串重则把非预期资源暴露到外网再比如 ROS2 机器人开发的环境AI 生成的节点代码如果线程同步有问题真机上跑起来就是硬件事故还有前端项目里AI 生成的鉴权路由如果漏了守卫逻辑用户就能直接访问管理后台页面。这些场景的共同点是AI 生成的是“看起来正常”的代码但它的“正常”不包含你的安全约束、合规要求和组织规范。而这些约束恰恰是没办法写进 prompt 里的——至少目前还不能。所以 Review 的职责不仅是找 bug更是做安全评估、做合规判断这件事必须由人来兜底不能外包给概率模型。注意不是说你用了 AI 就意味着一定有安全问题而是说 AI 输出里出现安全问题的概率并不比你团队里初级工程师低甚至更高——因为它不会“心虚”不会在不确定的地方停下来问你。3. 我重建 Review 流程的完整方案三层分级与核心清单3.1 把人工精力用在刀刃上三层分级审查面对 AI 带来的代码量暴增如果还像以前一样“每个 PR 都逐行人工审”团队根本扛不住。我的做法是把 Review 分成三层每一层针对不同类型的风险人工只在最关键的地方发力层级审查内容执行方式主要目标L0 自动拦截格式、lint、复杂度、重复代码、明显的 anti-patternCI 脚本 / 静态检查工具把低级问题挡在人工之前L1 快速走查业务逻辑与需求的一致性、核心分支处理、异常路径资深开发逐个 PR 粗看 diff发现“AI 理解偏差”类问题L2 专项评审架构合理性、安全风险、数据一致性、性能隐患定向邀请只审关键 PR识别系统性风险和长期隐患这个分层的核心逻辑是不要让人的注意力被机械劳动淹没。AI 生成的大量代码里格式问题、命名问题、无伤大雅的重复代码静态工具几分钟就扫完了人工再看就是浪费生命。人的精力要留给“机器看不懂的东西”——业务意图对不对、边界情况漏没漏、这个方案选型在长远看是否合理。L1 是我最强调的一层。因为 AI 生成的代码最常见的毛病不是“写错”而是“想错了”。比如需求是“查询最近一个月的数据”AI 可能给你写成“查询最近 30 天”看起来差不多但如果业务是用自然月统计这就是 bug。这种差异静态工具永远查不出来只有知道业务上下文的人才能发现。L2 专项评审则用于高风险的 PR涉及数据库表结构变更、权限模型调整、支付相关逻辑、第三方 API 对接这类“炸一次就完蛋”的改动绝不走普通流程必须指定专人对架构和安全部分做定向评审。AI 在面对跨模块、长链路、多系统交互的复杂改造时表现会尤其不稳定这一层是最后的防线。3.2 给 Reviewer 减负让 AI 去审 AI 生成的代码我知道很多人听到这句话会皱眉“让 AI 审查 AI那不是自己人审自己人约等于没审”一开始我也这么想但实践下来发现AI 审查 AI 生成代码这件事是值得做的关键取决于怎么用它。我的用法是让 AI 当“第一道筛子”专门负责那些模式识别类的工作。比如把 PR diff 丢给 AI让它标记出所有改动文件里“高风险区域”——涉及并发操作、涉及外部输入、涉及全局状态修改、涉及密钥或敏感数据操作的代码块。它会给出一个列表和理由然后人工 reviewer 拿着这个列表开始 L1 走查。这其实不是让 AI 替代人做判断而是让 AI 帮人缩小范围。我可以很明确地说人工走查一个 500 行的 PR和人工走查一个“AI 已经帮你把 3 个疑点标出来”的 500 行 PR效率差距是 3 倍以上。因为 AI 的“疑点标定”虽然会有误报但该看的地方它基本都能圈出来剩下的事情才是人真正该做的。还有一类工具是“AI Review 助手”它会自动对每个 PR 生成评论命名建议、复杂度提示、潜在空指针、重复代码。说实话这类建议里大概有一半是噪声刚开始会把 PR 评论区刷得很热闹。我踩过这个坑后来定了个规矩AI 评论只允许出现在 diff 的特定位置并且不允许在评论区喋喋不休——要么直接 resolve 掉要么由人工 reviewer 决定是否当成一条正式评论。不然 PR 评论区就是 AI 在自言自语很干扰。提示如果你的工具链里有静态扫描SonarQube 这类和 AI 生成代码的检测能力务必把它配置成“信息源”而不是“仲裁者”。AI 的输出只作为参考是否封版、是否修改始终由人决定。3.3 我贴在屏幕上的 12 条 Review 硬标准随着 AI 代码占比越来越高我总结了一份 Review 检查清单不再只盯“这个 bug 该不该修”而是重点看 AI 最容易出问题的方面。贴在工位屏幕旁边每天过一遍序号检查项说明1这段代码有没有重复造轮子AI 经常生成一套全新的工具函数而项目里明明已有现成的2错误处理是否符合业务预期失败了是重试、跳过、回滚还是报警AI 默认只会抛异常3并发场景有没有做保护共享变量、全局状态、数据库行锁AI 经常忽略4敏感数据有没有进日志密钥、token、用户隐私字段带星号代替都不行最好不进日志5外部输入有没有做校验文件类型、参数范围、内容长度AI 默认信任一切输入6数据库查询有没有性能隐患有没有深分页、N1 查询、缺少索引7是否引入了不必要的依赖AI 图省事可能为了一个工具函数装一个 npm 包8代码是否符合团队既有规范目录结构、命名风格、模块边界AI 不知道你们团队的约定9有没有删掉 AI 生成的死代码AI 经常生成“备选方案”但忘了删除导致一堆没人调用的函数10注释是否真实反映了代码行为AI 的注释特别容易和实际逻辑对不上11是否有隐藏的时序依赖比如“先调 A 再调 B”的隐式约定AI 生成的代码不会自己维护12有没有破坏既有接口的兼容性AI 可能会直接改函数签名而调用方根本不知道这份清单最大的价值不在于“每一条都很精妙”而在于把隐性风险变成显性问题。AI 生成的代码不会主动坦白它的顾虑审查者就得有一份明确的“逼供清单”一条条问过去。4. 实战记录AI 生成代码的三个典型翻车现场4.1 翻车现场一逻辑严密的“死循环陷阱”有一次让 AI 写一个重试机制需求是“调用外部接口失败后最多重试 3 次每次间隔递增”。AI 生成的代码非常工整for attempt in range(3): try: result call_external_api() return result except Exception as e: if attempt 2: time.sleep(attempt * 2) else: raise e表面看没错重试 3 次、间隔递增、最后一次失败抛出异常。但 review 时我追问了一句“如果第一次调用就成功了这个循环是不是再跑两次每次都会 sleep 吗”——答案是否定的return 会直接退出函数循环不会继续。所以逻辑上没有大问题。可真正的坑在另一个地方如果外部接口很慢每次超时要 30 秒重试 3 次就意味着最坏情况要卡 90 秒。这在同步调用链路上会拖垮整个线程池。AI 不会替你考虑这些容量层面的问题它只保证“逻辑上符合描述”。这类“能跑但会在极端场景下拖垮系统”的代码恰恰是 review 的重点对象。我后来给团队的提示是重试机制一定要同时考虑重试次数、超时时间、调用方式同步/异步、流量峰值。AI 只会给你一个机械的重试模板这些工程判断必须人来补。4.2 翻车现场二API 幻觉——调用了不存在的函数这个案例我觉得特别值得写AI 生成代码时调用了某个第三方 SDK 的函数但我们项目里那个 SDK 的版本根本没有这个函数。编译不报错因为它是运行时动态调用的一跑到那行就直接炸。排查过程很有意思报错信息指向代码里的一行调用我们最初以为是参数传错了翻文档发现这个函数压根不存在。后来才意识到AI 是从训练语料里“见过”这个函数——它可能在其他项目里存在或者某个新版本里有但当前项目的依赖版本没有。这种问题最麻烦的点在于AI 不会告诉你它不确定它只会用非常笃定的姿态生成一段代码。这也再次印证了那句“AI 输出的是概率不是事实”。Review 时但凡涉及第三方库调用都值得去文档里核对一下函数签名和版本兼容性——尤其是你不熟悉的库。4.3 翻车现场三AI“好心”把密钥写进了日志这是一个影响最恶劣的案例。我们让 AI 写一个支付回调的日志记录功能它为了“方便排查”把完整的请求体都输出到了日志里包括用户银行卡后四位、手机号、支付 token。按合规要求这些字段属于敏感数据日志系统里根本不应该出现。AI 不是不懂安全而是它的优化目标里“方便排查”优先级很高——很多开源项目就是这么写日志的。但业务合规的约束不在它的考虑范围内。这类问题最危险的是它不会立刻暴露出来而是会静静躺在日志文件里直到某天日志管理平台被扫出漏洞数据泄露事件爆发。这个案例给我最大的教训是Review 时对“日志输出”这个动作要特别敏感。每个 log 语句都要想一遍“这条日志会不会记录敏感数据如果这个系统被攻破日志文件会变成什么”这不是技术问题是合规意识和底线判断。4.4 团队节奏怎么平衡Review 不应该是“最后一道工序”很多团队把 Review 放在开发完、提交 PR 之后这其实不是最优解。尤其 AI 时代等你写完一千行 AI 代码再 review成本已经很高了。我的建议是把 Review 前置到“开发中”——在 AI 开始生成代码之前先跟它“对齐需求”让它在生成时自带一些约束。具体做法是维护一份团队级 AI 编码约定文件内容包括项目使用的语言、框架、版本禁止使用的 API必须使用的日志规范敏感数据的处理要求异常处理的优先级是失败快速返回还是重试项目已有的工具函数清单等。这份文件不用多一页之内但每次让 AI 写代码之前先喂给它能显著降低“AI 自由发挥”的概率。还有一个很实用的技巧是控制每次让 AI 生成的范围。不要一次让 AI 生成一个完整模块而是拆成小函数、小类每次生成几十行人工 review 一眼就能看完错误发现率会高很多。AI 生成范围越小它的输出越可控review 的负担也就越小——这其实比讨论“要不要用 AI”更值得思考和落实。5. 让 Review 这事“可度量”我用哪些指标管理团队Review 落到团队管理层面光喊口号不够得有指标。我用了四个指标来度量和推动团队 Review 这件事指标统计方式我关心的原因Review 覆盖率实际被 Review 的 PR 数量 / 全部 PR 数量有没有漏审的改动流进主干人均 Review 时长总评审时长 / 评审次数每个人到底花了多少心思在 Review 上Review 发现率Review 中发现的 bug 数 / 总缺陷数Review 是不是真的在起作用缺陷逃逸率上线后才发现的问题数 / 总缺陷数前两道防线是不是有漏洞其中我最看重的是缺陷逃逸率。它直接反映 Review 体系在前端把住了多少问题如果这个数字居高不下那说明 review 要么流于形式要么没有审到关键点。我见过有的团队 review 覆盖率接近 100%但缺陷逃逸率依旧很难看——因为大家都在“走过场”review 时只是点个“approve”根本没认真看。这种情况在 AI 生成代码后更加危险因为表面上 PR 太整齐了整齐到让 reviewer 放松警惕。我处理这个问题的办法是不只统计“有没有 review”还统计“review 时提了多少条有效评论”。如果一个人连续很多 PR 都是一个 approve、零评论那我会找他单独聊聊——是真的看懂了一切还是根本没看。“零评论”本身不一定是问题但值得确认一下。另外有一个很反直觉的经验不要追求 100% 的 PR 都走同一套严格 review。有的脚本类改动、纯格式调整、文档修改让 L0 自动检查过了就行人工盯那些真正有风险的改动已经够了。Review 资源是有限的把它花在刀刃上比平均用力更有效。6. Review 的“文化问题”比流程更难的是让大家愿意较真流程、指标、清单这些都是工具真正决定 Review 效果的是团队文化——大家愿不愿意“较真”。AI 时代这个问题被放大了因为 AI 生成的代码太“整齐”了很多人会下意识地信任它觉得“大模型都这么写了应该没问题吧”。这种心态是 Review 最大的敌人。我做过一个实验把 AI 生成的代码和人类写的代码混在一起发给团队 review大家普遍认为 AI 代码质量更高、更规范但真正跑起来AI 代码里藏的那些逻辑错误边界、异常、业务语义很难被发现。结论很明显人对“漂亮代码”有天然的好感而这恰恰是最危险的信号。所以我在团队里反复强调一个观点“代码写得漂亮”不等于“代码写得对”。Review 时要带着挑刺的心态去找问题——它不是对同事的不尊重而是对共同成果的负责。我们甚至培养了一个小习惯review 的时候先假设“这里一定有问题”然后去找证据推翻这个假设而不是默认“这里没问题”。这样一个“有罪推定”式的审查心态能显著提高问题发现率。另外也要奖励“敢说”的人。Review 不是做绩效考评不是指责谁写错了代码特别是 AI 时代——review 的问题对象常常不是某个人而是 AI 的输出。同事之间很容易因为“你怎么写了个 bug”而尴尬但如果把它改成“这段 AI 生成的代码有问题我们一起看下”压力感就小很多讨论的氛围也更健康。最后我想说Review 这件事不酷但它极其重要。AI 让“写”变得更便宜后“确认”这个动作就变成了最稀缺的环节。我们不可能完全相信 AI 的输出也不可能回到手写每一个字符的时代——唯一的路是把 Review 体系做好让它成为 AI 和高质量交付之间的那层保护网。根据我这半年的实操经验如果你团队里 AI 生成的代码占比已经超过 50%而 review 流程还停留在“有人看一眼、点个 approve”的状态我强烈建议你从本周开始重新设计。不用一次到位先从上面那份 12 条清单开始再搭一个三层分级框架至少能把最危险的几类问题挡住。等流程跑顺了你就会发现AI 不是让你失业而是让你把精力从“写代码”挪到更重要的“确认代码真的对”上。 1. 当 AI 把代码产出速度拉满之后Review 为什么反而更紧先说结论AI 辅助开发这半年我们团队的人均 PR 量翻了三倍但线上事故并没有减少有些周甚至更多。原因很简单——AI 让“写出代码”变得便宜但让“确认这代码是对的”变得昂贵。以前手写代码一个人一天能产出几百行reviewer 逐行看也有压力但心里有底写代码的人至少知道每一行为什么存在。现在 AI 一口气给你生成一千行结构工整、命名规范、注释齐全乍一看比多数初级工程师写得还像样。但真正跑起来边界条件、异常链路、幂等设计、并发安全处处是坑。更麻烦的是这些坑长得特别“正经”——不是那种一眼就能看出来的拼写错误或空指针而是逻辑自洽但业务语义不对的“合理错误”。我遇到过一个特别典型的案例让 AI 写一个批量导入功能它非常顺利地把 Excel 解析、字段映射、逐行入库全写了代码风格也挑不出毛病。但我 review 的时候发现一个问题如果文件里有一行数据格式错误整批都会回滚而产品需求明确要求“跳过错误行、继续导入后面的数据”。AI 没有理解这个意图它只是按“最常规”的错误处理方式写了一个事务包裹。这种错误单测跑得过去联调未必暴露真正上线后用户导一次数据才发现全线崩掉。这就是为什么我越来越坚持AI 时代Review 不是可以削弱而是必须加强。它从“把关质量”变成了“核对意图”。代码生成的速度越快人类核对的速度就必须跟上否则就是在给线上埋雷。还有一个容易被忽视的维度AI 生成的代码把“代码审查”从技术活动变成了风险管理活动。以前 review 是看“有没有 bug”现在 review 是看“AI 有没有误会我的需求”——这是完全不同的审查思路。后者需要 reviewer 对业务上下文有更深理解而不只是会看语法。所以 Review 不是变简单了是变难、变重、变不可替代了。2. 三个“硬理由”为什么 AI 时代反而没人敢砍 Review2.1 概率生成的代码必须用“意图”校准大模型生成代码的本质是根据上下文预测最可能的 token 序列。它不知道你的业务目标是什么它只知道“这种写法最常见的后续是什么”。也就是说AI 生成的代码在统计意义上是“最像代码的代码”而不是“最符合你需求的代码”。这个区别特别关键。我经常打一个比方AI 写代码像是一个非常熟悉语法、看过大量范文的枪手替你写作文文笔流畅、结构完整但他不知道你这篇作文要论证什么观点。Review 要干的事就是拿着你的提纲去核对它的每段论证。具体到实操上审查 AI 代码时我会特别关注几个点**这个函数它为什么存在它解决的是我让它解决的问题还是它“以为”自己应该解决的问题**比如你让它“优化查询性能”它可能给你套了一层缓存但没考虑缓存与数据库的一致性你让它“加个用户状态字段”它可能同步帮你改了接口返回结构而前端还没有适配。所以现在我的团队里每个 PR 描述里必须写清楚业务上下文reviewer 第一件事不是看代码而是看“这个改动要达成什么业务目标”再回头看“代码有没有围绕这个目标展开”。这一步在 AI 时代是绝对不可省略的。2.2 AI 代码的错误更“隐蔽”测试也兜不住手写代码的错误往往来自打字失误、逻辑疏忽这类错误特征明显review 相对容易发现。AI 代码的错误则是另一个物种它在语法、风格、结构上高度自洽错误发生在“语义层”——要么是对需求的理解偏差要么是边界条件的处理过于“常规”而脱离实际场景。举个例子AI 生成的分页查询默认实现往往就是“LIMIT offset, size”它不会考虑深分页的性能问题AI 生成的删除接口默认实现就是 DELETE FROM它不会提醒你“这里有外键关联要不要软删除”AI 生成的上传接口默认接受所有文件类型它不会自动给你做内容校验。更麻烦的是测试用例本身也可能是 AI 生成的。如果你让 AI 写完功能再让 AI 写测试它通常会写“验证正常路径”的 happy path 用例而恰恰把异常路径、并发场景、数据一致性这些最需要覆盖的点漏掉。结果就是测试全绿上线出问题。所以现在我对团队的硬要求是AI 写功能代码可以但测试用例必须由人工设计核心场景AI 只能辅助补充细节。Review 的时候也必须重点看测试用例覆盖了什么、没覆盖什么而不是只看测试是否通过。2.3 安全与合规底线不能交给“概率”我审查过的 AI 生成代码里出现过几次很吓人的情况把数据库连接串直接写死在配置里、把用户明文密码打印到日志、前端代码里直接暴露了内部 API 的结构、没有做任何输入白名单过滤就开始拼接 SQL。这些都是安全红线AI 没有“红线意识”它只会按照最常见的写法输出——而最常见的写法往往就是“能跑就行”。具体到不同开发场景风险也不一样。比如我们内部有用 nginx 多端口做本地多站点开发的场景AI 生成的配置如果 rewrite 规则写错轻则多站点互相串重则把非预期资源暴露到外网再比如 ROS2 机器人开发的环境AI 生成的节点代码如果线程同步有问题真机上跑起来就是硬件事故还有前端项目里AI 生成的鉴权路由如果漏了守卫逻辑用户就能直接访问管理后台页面。这些场景的共同点是AI 生成的是“看起来正常”的代码但它的“正常”不包含你的安全约束、合规要求和组织规范。而这些约束恰恰是没办法写进 prompt 里的——至少目前还不能。所以 Review 的职责不仅是找 bug更是做安全评估、做合规判断这件事必须由人来兜底不能外包给概率模型。注意不是说你用了 AI 就意味着一定有安全问题而是说 AI 输出里出现安全问题的概率并不比你团队里初级工程师低甚至更高——因为它不会“心虚”不会在不确定的地方停下来问你。3. 我重建 Review 流程的完整方案三层分级与核心清单3.1 把人工精力用在刀刃上三层分级审查面对 AI 带来的代码量暴增如果还像以前一样“每个 PR 都逐行人工审”团队根本扛不住。我的做法是把 Review 分成三层每一层针对不同类型的风险人工只在最关键的地方发力层级审查内容执行方式主要目标L0 自动拦截格式、lint、复杂度、重复代码、明显的 anti-patternCI 脚本 / 静态检查工具把低级问题挡在人工之前L1 快速走查业务逻辑与需求的一致性、核心分支处理、异常路径资深开发逐个 PR 粗看 diff发现“AI 理解偏差”类问题L2 专项评审架构合理性、安全风险、数据一致性、性能隐患定向邀请只审关键 PR识别系统性风险和长期隐患这个分层的核心逻辑是不要让人的注意力被机械劳动淹没。AI 生成的大量代码里格式问题、命名问题、无伤大雅的重复代码静态工具几分钟就扫完了人工再看就是浪费生命。人的精力要留给“机器看不懂的东西”——业务意图对不对、边界情况漏没漏、这个方案选型在长远看是否合理。L1 是我最强调的一层。因为 AI 生成的代码最常见的毛病不是“写错”而是“想错了”。比如需求是“查询最近一个月的数据”AI 可能给你写成“查询最近 30 天”看起来差不多但如果业务是用自然月统计这就是 bug。这种差异静态工具永远查不出来只有知道业务上下文的人才能发现。L2 专项评审则用于高风险的 PR涉及数据库表结构变更、权限模型调整、支付相关逻辑、第三方 API 对接这类“炸一次就完蛋”的改动绝不走普通流程必须指定专人对架构和安全部分做定向评审。AI 在面对跨模块、长链路、多系统交互的复杂改造时表现会尤其不稳定这一层是最后的防线。3.2 给 Reviewer 减负让 AI 去审 AI 生成的代码我知道很多人听到这句话会皱眉“让 AI 审查 AI那不是自己人审自己人约等于没审”一开始我也这么想但实践下来发现AI 审查 AI 生成代码这件事是值得做的关键取决于怎么用它。我的用法是让 AI 当“第一道筛子”专门负责那些模式识别类的工作。比如把 PR diff 丢给 AI让它标记出所有改动文件里“高风险区域”——涉及并发操作、涉及外部输入、涉及全局状态修改、涉及密钥或敏感数据操作的代码块。它会给出一个列表和理由然后人工 reviewer 拿着这个列表开始 L1 走查。这其实不是让 AI 替代人做判断而是让 AI 帮人缩小范围。我可以很明确地说人工走查一个 500 行的 PR和人工走查一个“AI 已经帮你把 3 个疑点标出来”的 500 行 PR效率差距是 3 倍以上。因为 AI 的“疑点标定”虽然会有误报但该看的地方它基本都能圈出来剩下的事情才是人真正该做的。还有一类工具是“AI Review 助手”它会自动对每个 PR 生成评论命名建议、复杂度提示、潜在空指针、重复代码。说实话这类建议里大概有一半是噪声刚开始会把 PR 评论区刷得很热闹。我踩过这个坑后来定了个规矩AI 评论只允许出现在 diff 的特定位置并且不允许在评论区喋喋不休——要么直接 resolve 掉要么由人工 reviewer 决定是否当成一条正式评论。不然 PR 评论区就是 AI 在自言自语很干扰。提示如果你的工具链里有静态扫描SonarQube 这类和 AI 生成代码的检测能力务必把它配置成“信息源”而不是“仲裁者”。AI 的输出只作为参考是否封版、是否修改始终由人决定。3.3 我贴在屏幕上的 12 条 Review 硬标准随着 AI 代码占比越来越高我总结了一份 Review 检查清单不再只盯“这个 bug 该不该修”而是重点看 AI 最容易出问题的方面。贴在工位屏幕旁边每天过一遍序号检查项说明1这段代码有没有重复造轮子AI 经常生成一套全新的工具函数而项目里明明已有现成的2错误处理是否符合业务预期失败了是重试、跳过、回滚还是报警AI 默认只会抛异常3并发场景有没有做保护共享变量、全局状态、数据库行锁AI 经常忽略4敏感数据有没有进日志密钥、token、用户隐私字段带星号代替都不行最好不进日志5外部输入有没有做校验文件类型、参数范围、内容长度AI 默认信任一切输入6数据库查询有没有性能隐患有没有深分页、N1 查询、缺少索引7是否引入了不必要的依赖AI 图省事可能为了一个工具函数装一个 npm 包8代码是否符合团队既有规范目录结构、命名风格、模块边界AI 不知道你们团队的约定9有没有删掉 AI 生成的死代码AI 经常生成“备选方案”但忘了删除导致一堆没人调用的函数10注释是否真实反映了代码行为AI 的注释特别容易和实际逻辑对不上11是否有隐藏的时序依赖比如“先调 A 再调 B”的隐式约定AI 生成的代码不会自己维护12有没有破坏既有接口的兼容性AI 可能会直接改函数签名而调用方根本不知道这份清单最大的价值不在于“每一条都很精妙”而在于把隐性风险变成显性问题。AI 生成的代码不会主动坦白它的顾虑审查者就得有一份明确的“逼供清单”一条条问过去。4. 实战记录AI 生成代码的三个典型翻车现场4.1 翻车现场一逻辑严密的“死循环陷阱”有一次让 AI 写一个重试机制需求是“调用外部接口失败后最多重试 3 次每次间隔递增”。AI 生成的代码非常工整for attempt in range(3): try: result call_external_api() return result except Exception as e: if attempt 2: time.sleep(attempt * 2) else: raise e表面看没错重试 3 次、间隔递增、最后一次失败抛出异常。但 review 时我追问了一句“如果第一次调用就成功了这个循环是不是再跑两次每次都会 sleep 吗”——答案是否定的return 会直接退出函数循环不会继续。所以逻辑上没有大问题。可真正的坑在另一个地方如果外部接口很慢每次超时要 30 秒重试 3 次就意味着最坏情况要卡 90 秒。这在同步调用链路上会拖垮整个线程池。AI 不会替你考虑这些容量层面的问题它只保证“逻辑上符合描述”。这类“能跑但会在极端场景下拖垮系统”的代码恰恰是 review 的重点对象。我后来给团队的提示是重试机制一定要同时考虑重试次数、超时时间、调用方式同步/异步、流量峰值。AI 只会给你一个机械的重试模板这些工程判断必须人来补。4.2 翻车现场二API 幻觉——调用了不存在的函数这个案例我觉得特别值得写AI 生成代码时调用了某个第三方 SDK 的函数但我们项目里那个 SDK 的版本根本没有这个函数。编译不报错因为它是运行时动态调用的一跑到那行就直接炸。排查过程很有意思报错信息指向代码里的一行调用我们最初以为是参数传错了翻文档发现这个函数压根不存在。后来才意识到AI 是从训练语料里“见过”这个函数——它可能在其他项目里存在或者某个新版本里有但当前项目的依赖版本没有。这种问题最麻烦的点在于AI 不会告诉你它不确定它只会用非常笃定的姿态生成一段代码。这也再次印证了那句“AI 输出的是概率不是事实”。Review 时但凡涉及第三方库调用都值得去文档里核对一下函数签名和版本兼容性——尤其是你不熟悉的库。4.3 翻车现场三AI“好心”把密钥写进了日志这是一个影响最恶劣的案例。我们让 AI 写一个支付回调的日志记录功能它为了“方便排查”把完整的请求体都输出到了日志里包括用户银行卡后四位、手机号、支付 token。按合规要求这些字段属于敏感数据日志系统里根本不应该出现。AI 不是不懂安全而是它的优化目标里“方便排查”优先级很高——很多开源项目就是这么写日志的。但业务合规的约束不在它的考虑范围内。这类问题最危险的是它不会立刻暴露出来而是会静静躺在日志文件里直到某天日志管理平台被扫出漏洞数据泄露事件爆发。这个案例给我最大的教训是Review 时对“日志输出”这个动作要特别敏感。每个 log 语句都要想一遍“这条日志会不会记录敏感数据如果这个系统被攻破日志文件会变成什么”这不是技术问题是合规意识和底线判断。4.4 团队节奏怎么平衡Review 不应该是“最后一道工序”很多团队把 Review 放在开发完、提交 PR 之后这其实不是最优解。尤其 AI 时代等你写完一千行 AI 代码再 review成本已经很高了。我的建议是把 Review 前置到“开发中”——在 AI 开始生成代码之前先跟它“对齐需求”让它在生成时自带一些约束。具体做法是维护一份团队级 AI 编码约定文件内容包括项目使用的语言、框架、版本禁止使用的 API必须使用的日志规范敏感数据的处理要求异常处理的优先级是失败快速返回还是重试项目已有的工具函数清单等。这份文件不用多一页之内但每次让 AI 写代码之前先喂给它能显著降低“AI 自由发挥”的概率。还有一个很实用的技巧是控制每次让 AI 生成的范围。不要一次让 AI 生成一个完整模块而是拆成小函数、小类每次生成几十行人工 review 一眼就能看完错误发现率会高很多。AI 生成范围越小它的输出越可控review 的负担也就越小——这其实比讨论“要不要用 AI”更值得思考和落实。5. 让 Review 这事“可度量”我用哪些指标管理团队Review 落到团队管理层面光喊口号不够得有指标。我用了四个指标来度量和推动团队 Review 这件事指标统计方式我关心的原因Review 覆盖率实际被 Review 的 PR 数量 / 全部 PR 数量有没有漏审的改动流进主干人均 Review 时长总评审时长 / 评审次数每个人到底花了多少心思在 Review 上Review 发现率Review 中发现的 bug 数 / 总缺陷数Review 是不是真的在起作用缺陷逃逸率上线后才发现的问题数 / 总缺陷数前两道防线是不是有漏洞其中我最看重的是缺陷逃逸率。它直接反映 Review 体系在前端把住了多少问题如果这个数字居高不下那说明 review 要么流于形式要么没有审到关键点。我见过有的团队 review 覆盖率接近 100%但缺陷逃逸率依旧很难看——因为大家都在“走过场”review 时只是点个“approve”根本没认真看。这种情况在 AI 生成代码后更加危险因为表面上 PR 太整齐了整齐到让 reviewer 放松警惕。我处理这个问题的办法是不只统计“有没有 review”还统计“review 时提了多少条有效评论”。如果一个人连续很多 PR 都是一个 approve、零评论那我会找他单独聊聊——是真的看懂了一切还是根本没看。“零评论”本身不一定是问题但值得确认一下。另外有一个很反直觉的经验不要追求 100% 的 PR 都走同一套严格 review。有的脚本类改动、纯格式调整、文档修改让 L0 自动检查过了就行人工盯那些真正有风险的改动已经够了。Review 资源是有限的把它花在刀刃上比平均用力更有效。6. Review 的“文化问题”比流程更难的是让大家愿意较真流程、指标、清单这些都是工具真正决定 Review 效果的是团队文化——大家愿不愿意“较真”。AI 时代这个问题被放大了因为 AI 生成的代码太“整齐”了很多人会下意识地信任它觉得“大模型都这么写了应该没问题吧”。这种心态是 Review 最大的敌人。我做过一个实验把 AI 生成的代码和人类写的代码混在一起发给团队 review大家普遍认为 AI 代码质量更高、更规范但真正跑起来AI 代码里藏的那些逻辑错误边界、异常、业务语义很难被发现。结论很明显人对“漂亮代码”有天然的好感而这恰恰是最危险的信号。所以我在团队里反复强调一个观点“代码写得漂亮”不等于“代码写得对”。Review 时要带着挑刺的心态去找问题——它不是对同事的不尊重而是对共同成果的负责。我们甚至培养了一个小习惯review 的时候先假设“这里一定有问题”然后去找证据推翻这个假设而不是默认“这里没问题”。这样一个“有罪推定”式的审查心态能显著提高问题发现率。另外也要奖励“敢说”的人。Review 不是做绩效考评不是指责谁写错了代码特别是 AI 时代——review 的问题对象常常不是某个人而是 AI 的输出。同事之间很容易因为“你怎么写了个 bug”而尴尬但如果把它改成“这段 AI 生成的代码有问题我们一起看下”压力感就小很多讨论的氛围也更健康。最后我想说Review 这件事不酷但它极其重要。AI 让“写”变得更便宜后“确认”这个动作就变成了最稀缺的环节。我们不可能完全相信 AI 的输出也不可能回到手写每一个字符的时代——唯一的路是把 Review 体系做好让它成为 AI 和高质量交付之间的那层保护网。根据我这半年的实操经验如果你团队里 AI 生成的代码占比已经超过 50%而 review 流程还停留在“有人看一眼、点个 approve”的状态我强烈建议你从本周开始重新设计。不用一次到位先从上面那份 12 条清单开始再搭一个三层分级框架至少能把最危险的几类问题挡住。等流程跑顺了你就会发现AI 不是让你失业而是让你把精力从“写代码”挪到更重要的“确认代码真的对”上。