用 AI 辅助编程刚满两个月的时候我一度觉得开发这事儿要“飞起来”了原来磨一个下午的接口层现在把需求描述清楚半天就能把代码、测试、注释全部生成完。提交代码的那一刻我甚至有种“以后是不是可以提前下班”的错觉。直到第一次让同事帮我 Review 一个 AI 大比例生成的功能模块我才被现实狠狠拍醒表面上看这个模块逻辑完整、注释齐全但一深挖事务边界缺失、异常被吞掉、一个已经被标记废弃的 API 版本被当成可用版本接进来。更让我后背发凉的是这些问题如果不靠人工 Review我可能完全发现不了——因为 AI 写出来的代码实在是太“像样”了。这让我认真想明白了一件事AI 让开发“飞起来”根本不是终点Review 必须被重新放回第一优先级。而且这个时代的 Review 和以前完全不是一回事。它不止是“挑毛病”而是人类工程师在 AI 大量产出代码之后对系统负起最终责任的唯一关口。这篇文章想跟你聊聊为什么我会有这个判断以及我又是怎么把 Review 重新设计成一套可落地的流程的。无论你是个体开发者、技术负责人还是正在观望 AI 辅助编程的初学者这部分经验都值得认真参考。1. 当 AI 取代“写码”后问题从哪来在聊 Review 为什么重要之前我们得先看清一个问题AI 提效的真实代价到底在哪。1.1 AI 提效的账要这么算开发速度与审查速度的剪刀差以前写一个模块100 行代码你可能要写两小时现在你把需求描述清楚AI 帮你写 500 行只要半小时。看起来速度翻了不止一倍但你有没有想过人类阅读和理解代码的速度并没有同比提升。这就形成了一个典型的“剪刀差”产出端极速膨胀审查端原地踏步。我见过不止一个团队AI 贡献的代码占比已经接近一半但真正被人完整读过的代码可能不到一成。代码库里的“AI 痕迹”越来越多被人类真正理解、认可、兜底的部分却越来越少。这个剪刀差才是质量问题的源头不是 AI 本身。更麻烦的是AI 生成的代码有一种“语法正确但语义存疑”的特性。它很会写“看起来正确的代码”比如一个 for 循环、一个异常捕获、一个异步调用单拎出来每个语法都对但组合在一起可能漏了幂等判断、忘了资源释放、没考虑并发冲突。这些组合层面的大坑藏在流畅的表面之下恰恰是传统 Review 最容易忽略的盲区。1.2 我观察到 AI 生成代码的三大新风险第一类是幻觉 API 和不存在的库。AI 很擅长一本正经地引用一个“现成的工具类”但这个类在你的工程里根本不存在或者说它把某个开源库的私有实现当成了公共 API。我踩过最典型的坑是AI 推荐我用一个“分布式锁工具类”我照着改完编译直接报红一查发现那个类压根不在当前依赖里。第二类是安全与权限边界丢失。AI 生成的代码经常在业务逻辑上做到“自洽”但把权限校验写在了错误的位置或者把敏感信息直接打进了日志。这类问题比缺少某个方法更隐蔽因为它不报错甚至能跑通功能测试只有做安全审查时才能暴露出来。第三类是重复与泛化代码膨胀。AI 对老代码没有全局记忆于是反复生成相似的工具函数、HTTP client 封装、状态枚举定义。结果就是代码库开始“虚胖”可维护性断崖式下降。这个问题不是 bug但比 bug 更折磨人因为每一次重构都要在一堆重复代码里翻找真正的“事实来源”。1.3 为什么传统 Review 节奏不再够用以往的 Review 节奏是线性的写完代码、提交 PR、别人审查、你修改然后再合入。当 AI 把你的提交频率从一天一次提升到一天三四次之后这个线性流程会直接把人逼疯——审查者根本看不过来。更本质的问题是传统 Review 侧重“这段代码对不对”比如逻辑是否正确、是否符合编码规范。但现在我们必须转向“这段代码为什么值得存在、它和系统其他地方如何保持一致性”。AI 能轻松写出局部正确的代码却对团队约定一无所知。比如我们团队约定支付回调统一走事件总线AI 根本不知道这个约定直接在 Controller 里 new 了一个 Service 就开始调用。这种从“对不对”到“为什么存在”的审查视角转变才是整个行业必须面对的新考题。不解决这个问题AI 带来的开发速度越快代码腐烂的速度就会越快。2. Review 第一优先级背后的三个核心理由既然问题的来源清楚了接下来聊聊为什么我认定 Review 一定是第一优先级。2.1 Review 是从“AI 建议”到“工程决策”的唯一转换阀AI 本质上是“给建议”而不是“做决策”。它的输出基于概率分布背后没有你对业务场景的真实理解也没有你对系统未来演进的判断。它给你的每一个代码片段本质上和同事跑过来跟你说“这样写应该可以”一样只是建议不是结论。而 Review就是这个把“AI 建议”转换成“工程决策”的唯一转换阀。只有在审查环节人类工程师才有机会判断这个建议要不要采纳是原样采纳还是调整后采纳或者干脆整个推翻。这个转换阀一旦失灵AI 的“建议”就会直接流进生产环境那才是真正的失控。我越来越觉得Review 不只是质量检查它是人类工程师对系统的最终“署名权”。你审过、改过、想清楚的代码才真正算你“写”的代码。2.2 防止架构腐化AI 不会记得你两周前定义的边界我给 AI 辅助编程的新手打过一个很形象的比方AI 像一个知识面非常广、非常健谈、但记性很差的实习生。给它一个明确的小任务它干得像模像样但如果你问它“统一下单状态的枚举定义在哪个包里”它大概率会建议你“新建一个”。这种“无记忆”特性直接后果就是架构边界在不知不觉中被侵蚀。系统架构最珍贵的东西比如模块间依赖规则、数据流向约束、公共组件使用规范都存在人的脑子和团队文档里。AI 对这些完全没概念它只会根据你当前这段话去猜测你想要的“最标准答案”。所以如果没有人做 Review 来把关AI 生成的每一段代码理论上都有可能把架构向“熵增”方向推进一步。你可能觉得一次两次没关系但每天几十次“没关系”的累积足以在几周内把一套漂亮的架构变成依赖混乱的“大泥球”。Review 在这里起的就是对抗“架构熵增”的作用这是任何自动化工具都替代不了的。2.3 团队心智拉齐Review 正在成为最便宜的知识同步通道当 AI 让每个人的个人产出都变多时团队内部的知识差也在快速拉大。以前一个团队一个星期合并的代码量有限大家互相瞟一眼就能大概跟上进度现在 AI 让每个人的产出翻了好几倍A 写的代码 B 已经跟不上了C 用 AI 生成的一堆新工具函数A 根本不知道它们的存在。这种时候Review 反而是最便宜的“强制同步机制”。你不需要组织专门的培训不需要写冗长的文档只要保证每个 PR 都被认真讨论过一轮团队对系统现状的共同理解就会一点点长回来。我以前经常用“代码是写给人看的”这句话来推动团队做 Review现在我会更直白地说Review 是唯一能抵抗“AI 个体产出爆炸”导致团队割裂的手段。它不只是为了质量问题更是为了整个团队还能作为一个整体往前走。3. 我把 Review 前置到开发流程中的实操方案认知到位之后更重要的是怎么落地。我把这套方案做成了一种固定的工作流分享给有同样困扰的人。3.1 “写码前先写 Review 清单”的工作流改造我现在最关键的改变是把 Review 从“代码写完以后”提前到“写码之前”。具体操作是每个功能开始动工之前先花 5 到 10 分钟写一份 Review 清单。这份清单不是需求文档而是“这个 PR 合入时我必须重点检查什么”。比如这个功能里的事务边界是否和既有的事务注解冲突磁盘缓存有没有过期清理机制外部服务返回的错误码上层是否能正确处理而不是直接吞掉这次改动会不会破坏另一个模块对同一函数的调用假设然后把这份清单直接贴给 AI让它带着这些审查项去写代码。你可能会有疑问让 AI 带着清单写代码它就能避开所有坑吗当然不能。但效果非常明显AI 生成的代码会收敛很多因为它至少知道哪些点是“被关注的雷区”。更重要的收获是我审查的时候有了明确的抓手不再需要从头到尾把几百行代码读完才能判断好坏。我可以直接对照清单逐项核验这一项过了下一项有问题标出来返回修改。Review 从一件“压力很大的无边界任务”变成了“有明确检查项的核对工作”效率提升是肉眼可见的。3.2 用 AI 做“反向审查”一份可以直接抄的审查任务卡既然 AI 能写代码那它能不能帮忙审查我的答案是能但前提是方法要对。我现在会在代码写完后把完整 diff 贴给另一个独立的 AI 会话让它扮演“最挑剔的资深审查者”按一个固定框架找问题。下面是一份我可以直接拿出来分享的提示词模板你现在是一名拥有十年一线经验的资深软件架构师。请审查这份代码 diff严格按以下顺序检查安全和权限问题有没有密钥硬编码、越权访问、敏感数据泄漏到日志资源和连接泄漏有没有未关闭的连接、未释放的锁、未清除的定时器异常处理和边界条件有没有空指针风险、越界访问、被吞掉的异常API 兼容性有没有破坏既有调用方、使用已废弃接口、改变参数语义可读性与维护性有没有重复代码、命名混乱、职责不清的函数 每个问题请给出具体行号、问题原因以及一句修改建议。如果没有问题请回答“当前 diff 未发现明显缺陷但需要人工确认业务逻辑”。这里有一个非常关键的操作细节不要让同一个 AI 会话“边写边审”。比如你用 Cursor 生成了代码然后就问同一个对话“这代码写得怎么样”这时候 AI 大概率会自我辩护因为它会倾向维护自己刚产出的“作品”。你要做的是把 diff 单独复制到一个全新会话里用上面的 prompt 让它“冷酷”地审一遍。AI 审查的结果当然不完美经常会有误报但它能帮你发现那些“人眼已经麻木”的问题。比如一个 for 循环里反复创建对象的小毛病人看五遍可能都注意不到AI 一眼就给你标出来了。我的经验是AI 负责“扫雷”人负责“排雷”两者配合审查的效率和深度都能上一个台阶。3.3 三个真实场景下的 Review 关注点对比不同场景下Review 的关注点差异很大。我把自己经常遇到的三种场景列成了一个对照表方便直接参考。场景核心关注点典型翻车示例重构老模块是否破坏原有行为、是否静默删掉边界兼容逻辑AI 把旧代码里的一个特殊分支当成“冗余”删掉导致历史数据的兼容逻辑失效新接口开发API 语义、错误码设计、字段命名是否与现有规范一致AI 生成了新的错误枚举但语义和旧的重复调用方根本分不清跨服务分布式改动超时设置、重试策略、幂等设计、消息顺序AI 把远程调用从并行改成串行接口响应时间直接翻三倍针对重构场景我在 Review 时一定会做一件事把原有代码的关键路径先写出来然后逐条对照 AI 重构后的代码确保每条路径都还在。这听起来很笨但效果极好因为 AI 重构时最喜欢“优化掉冗余”——但它分不清“看着冗余但实际上是兼容逻辑”的代码。针对分布式场景我会重点盯一个点AI 有没有在“处理失败”的代码里偷偷把重试策略变成了无限重试或者把超时时间设成了完全不合理的数值。这类问题在单测里根本测不出来只有 Review 时靠人工经验和系统现状判断。4. 踩过的坑与排查经验实录理论讲完讲讲实操中最真实的东西。这些坑每一个都是我和团队用线上故障和加班时间换来的。4.1 常见问题速查表我把这段时间最常遇到的问题整理成了一张速查表方便大家在 Review 时对照排查。现象原因应对方法编译通过但运行时报NoSuchMethodErrorAI 用了一个被移除的旧版本 APIReview 时全文搜索关键函数确认当前依赖版本仍支持catch 块空实现或只打一行日志AI 为了“让代码显得完整”自动补了 catch但没补处理逻辑在审查清单中固定要求所有 catch 必须给出处理方式不允许空吞硬编码的 AK/SK、数据库地址AI 把示例配置当成了真实配置Review 时跑一次全文密钥扫描同时在清单里固定加“扫密钥”一项AI 生成的新类与已有类功能重复AI 不了解现有代码库Review 时先搜索“这类东西是不是已经存在”再决定去重方向多线程环境下共享变量被直接修改AI 生成的代码没有考虑并发访问控制重点审查所有被多线程调用的方法要求补上同步或锁机制测试用例全过但覆盖率造假AI 生成的测试只测了 happy pathReview 时看测试里有没有边界值、异常分支、空响应用例这张表里的问题有一个共同特征单看每一行代码都没毛病但放在系统的上下文里就是暗雷。这也是为什么我始终强调Review 不能只看“代码本身”更要看“代码和系统的关系”。4.2 Review 中我坚持的几条铁律吃过亏之后我给自己定了几条铁律每条都对应一次真实的教训。第一条AI 生成的代码不允许直接 Approve。无论 AI 生成了多漂亮的代码至少要完整读一遍核心路径并在评论里写清楚“我读过这段代码确认它符合 xxx 约定”。这条铁律不是不信任 AI而是强制自己不要被“代码看起来很专业”这种表象催眠。第二条一个 PR 里必须写清楚“哪些是 AI 生成的、哪些是手工改的”。这个信息对审查者极其重要因为它决定了审查者需要用多大警惕度去看这个 diff。如果整个 PR 都是手写代码审查者的心态可以放松一些如果 80% 是 AI 生成那必须用最挑剔的眼光逐行审。第三条超过 400 行的 diff必须拆成多个 PR。以前我觉得拆 PR 浪费时间后来我发现超过 400 行的 diff 根本没有人愿意认真看大家只会粗略扫一眼就合入。AI 时代这个问题尤其严重因为 AI 生成大段代码的能力太强了。拆 PR 不是形式主义它是逼着你把一次大改动拆成多个可独立验证的小步骤每个步骤都能被完整审查。4.3 一个四口小组的量化观察Review 前置到底改变了什么理论吹得再好不如看数据。我拿自己所在的四人小组举例我们主要做后端业务同时兼顾一部分前端。过去两周我们把“Review 清单前置 AI 反向审查 强制拆 PR”这套流程完整跑了一遍这里有三组我很想分享的观察数据。指标调整前调整后平均每周 PR 数约 13 个约 9 个但每个粒度更小平均单 PR Review 耗时约 40 分钟约 25 分钟线上问题issue / 缺陷每周 3 到 5 个每周 0 到 1 个需要返工重写的 PR 比例约 15%约 4%这个数据的样本量不算大但趋势非常明显。最让我惊喜的不是线上问题数下降而是“发现问题的时间点变了”——以前很多问题是在测试阶段甚至上线之后才暴露现在绝大多数问题在 Review 阶段就被拦下来了。返工成本从“改线上代码 补数据 向业务方解释”变成了“改几行代码重新提交一次”这个差距是巨大的。当然这个数据只能算团队内部的经验观察谈不上严谨实验但它至少说明一件事Review 前置不是降低效率而是把效率“花在了刀刃上”。5. 下一步我准备怎么继续演进流程跑顺之后我开始想一些更长远的改进方向。这里也顺便给同行们提供一些思路。5.1 把 Review 结果沉淀成团队的“AI 知识库”每次 Review 中发现的典型问题我现在会顺手整理成一条“错误模式记录”包含三部分错误样例、修正方案、以及如何在提示词里预防。积攒一段时间后这些记录就变成了一份团队专属的“AI 审查错误模式手册”。这份手册的价值在于它可以直接反哺我们的提示词工程。比如我们频繁发现 AI 在生成定时任务时容易漏掉异常捕获那就在写定时任务相关的提示词时统一加上一句“确保定时任务内有完整的异常兜底避免任务中断”。用这种“从 Review 中来到提示词中去”的闭环AI 生成代码的质量会越来越高人类的审查负担会越来越轻。5.2 让 Agent 在 CI 阶段做第一轮值守我最近在尝试配置一个轻量级的 Agent 来做 CI 阶段的“第一轮值守”当 PR 提交时Agent 自动执行一组自定义静态检查脚本比如密钥扫描、硬编码地址扫描、废弃 API 调用扫描、TODO/FIXME 统计。一旦发现异常会以机器人的身份直接在评论区标记相关人。这一轮最核心的价值是过滤掉“最没有争议的问题”。你想想如果每个 PR 都要人工检查一遍有没有硬编码的密钥那纯属浪费生命。把这部分交给 Agent 做掉以后人工 Review 就能把全部精力放在“真正需要人类判断”的地方——业务逻辑、架构一致性、分布式行为。5.3 用指标考核“发现问题的密度”而不是“审查的数量”我最近在团队里推动一个变化不考核“每天审查了几个 PR”而是统计一个半新指标——“每 1000 行 diff 里发现了多少个需要修改的问题密度”。这个指标比“审查个数”更能反映 Review 的真实价值。为什么这么说因为“审查个数”是一个很容易刷的虚荣指标。你一天看十个 PR但每个都只回一句“看起来没问题”这真的有意义吗而“问题密度”直接逼着审查者去深挖 diff挖得越深发现的问题越多这个数字就越高。虽然这个指标还不完美比如它可能诱导大家故意挑小毛病但总比“为了刷数量而浮于表面”强得多。我个人在实际操作中的体会是这套体系最核心的改变其实是心态。以前我用 AI 写代码总有一种“终于可以偷懒了”的错觉踩了几次坑之后才发现AI 的效率红利是有前提的就是你的审查能力必须同步跟上。我现在每天收工前都会看一眼待审查列表宁可少写两段 AI 生成的新代码也要把已经存在的 PR Review 干净。因为对系统来说多一行不可理解的代码比少一行可理解的代码危险得多。如果要我给所有刚开始拥抱 AI 辅助编程的团队一个建议我会说先别急着把 AI 的产出能力拉到最大先把你们的 Review 流程武装到牙齿。写码可以靠 AI但“这行代码为什么存在”这件事最终还是得靠人回答。 用 AI 辅助编程刚满两个月的时候我一度觉得开发这事儿要“飞起来”了原来磨一个下午的接口层现在把需求描述清楚半天就能把代码、测试、注释全部生成完。提交代码的那一刻我甚至有种“以后是不是可以提前下班”的错觉。直到第一次让同事帮我 Review 一个 AI 大比例生成的功能模块我才被现实狠狠拍醒表面上看这个模块逻辑完整、注释齐全但一深挖事务边界缺失、异常被吞掉、一个已经被标记废弃的 API 版本被当成可用版本接进来。更让我后背发凉的是这些问题如果不靠人工 Review我可能完全发现不了——因为 AI 写出来的代码实在是太“像样”了。这让我认真想明白了一件事AI 让开发“飞起来”根本不是终点Review 必须被重新放回第一优先级。而且这个时代的 Review 和以前完全不是一回事。它不止是“挑毛病”而是人类工程师在 AI 大量产出代码之后对系统负起最终责任的唯一关口。这篇文章想跟你聊聊为什么我会有这个判断以及我又是怎么把 Review 重新设计成一套可落地的流程的。无论你是个体开发者、技术负责人还是正在观望 AI 辅助编程的初学者这部分经验都值得认真参考。1. 当 AI 取代“写码”后问题从哪来在聊 Review 为什么重要之前我们得先看清一个问题AI 提效的真实代价到底在哪。1.1 AI 提效的账要这么算开发速度与审查速度的剪刀差以前写一个模块100 行代码你可能要写两小时现在你把需求描述清楚AI 帮你写 500 行只要半小时。看起来速度翻了不止一倍但你有没有想过人类阅读和理解代码的速度并没有同比提升。这就形成了一个典型的“剪刀差”产出端极速膨胀审查端原地踏步。我见过不止一个团队AI 贡献的代码占比已经接近一半但真正被人完整读过的代码可能不到一成。代码库里的“AI 痕迹”越来越多被人类真正理解、认可、兜底的部分却越来越少。这个剪刀差才是质量问题的源头不是 AI 本身。更麻烦的是AI 生成的代码有一种“语法正确但语义存疑”的特性。它很会写“看起来正确的代码”比如一个 for 循环、一个异常捕获、一个异步调用单拎出来每个语法都对但组合在一起可能漏了幂等判断、忘了资源释放、没考虑并发冲突。这些组合层面的大坑藏在流畅的表面之下恰恰是传统 Review 最容易忽略的盲区。1.2 我观察到 AI 生成代码的三大新风险第一类是幻觉 API 和不存在的库。AI 很擅长一本正经地引用一个“现成的工具类”但这个类在你的工程里根本不存在或者说它把某个开源库的私有实现当成了公共 API。我踩过最典型的坑是AI 推荐我用一个“分布式锁工具类”我照着改完编译直接报红一查发现那个类压根不在当前依赖里。第二类是安全与权限边界丢失。AI 生成的代码经常在业务逻辑上做到“自洽”但把权限校验写在了错误的位置或者把敏感信息直接打进了日志。这类问题比缺少某个方法更隐蔽因为它不报错甚至能跑通功能测试只有做安全审查时才能暴露出来。第三类是重复与泛化代码膨胀。AI 对老代码没有全局记忆于是反复生成相似的工具函数、HTTP client 封装、状态枚举定义。结果就是代码库开始“虚胖”可维护性断崖式下降。这个问题不是 bug但比 bug 更折磨人因为每一次重构都要在一堆重复代码里翻找真正的“事实来源”。1.3 为什么传统 Review 节奏不再够用以往的 Review 节奏是线性的写完代码、提交 PR、别人审查、你修改然后再合入。当 AI 把你的提交频率从一天一次提升到一天三四次之后这个线性流程会直接把人逼疯——审查者根本看不过来。更本质的问题是传统 Review 侧重“这段代码对不对”比如逻辑是否正确、是否符合编码规范。但现在我们必须转向“这段代码为什么值得存在、它和系统其他地方如何保持一致性”。AI 能轻松写出局部正确的代码却对团队约定一无所知。比如我们团队约定支付回调统一走事件总线AI 根本不知道这个约定直接在 Controller 里 new 了一个 Service 就开始调用。这种从“对不对”到“为什么存在”的审查视角转变才是整个行业必须面对的新考题。不解决这个问题AI 带来的开发速度越快代码腐烂的速度就会越快。2. Review 第一优先级背后的三个核心理由既然问题的来源清楚了接下来聊聊为什么我认定 Review 一定是第一优先级。2.1 Review 是从“AI 建议”到“工程决策”的唯一转换阀AI 本质上是“给建议”而不是“做决策”。它的输出基于概率分布背后没有你对业务场景的真实理解也没有你对系统未来演进的判断。它给你的每一个代码片段本质上和同事跑过来跟你说“这样写应该可以”一样只是建议不是结论。而 Review就是这个把“AI 建议”转换成“工程决策”的唯一转换阀。只有在审查环节人类工程师才有机会判断这个建议要不要采纳是原样采纳还是调整后采纳或者干脆整个推翻。这个转换阀一旦失灵AI 的“建议”就会直接流进生产环境那才是真正的失控。我越来越觉得Review 不只是质量检查它是人类工程师对系统的最终“署名权”。你审过、改过、想清楚的代码才真正算你“写”的代码。2.2 防止架构腐化AI 不会记得你两周前定义的边界我给 AI 辅助编程的新手打过一个很形象的比方AI 像一个知识面非常广、非常健谈、但记性很差的实习生。给它一个明确的小任务它干得像模像样但如果你问它“统一下单状态的枚举定义在哪个包里”它大概率会建议你“新建一个”。这种“无记忆”特性直接后果就是架构边界在不知不觉中被侵蚀。系统架构最珍贵的东西比如模块间依赖规则、数据流向约束、公共组件使用规范都存在人的脑子和团队文档里。AI 对这些完全没概念它只会根据你当前这段话去猜测你想要的“最标准答案”。所以如果没有人做 Review 来把关AI 生成的每一段代码理论上都有可能把架构向“熵增”方向推进一步。你可能觉得一次两次没关系但每天几十次“没关系”的累积足以在几周内把一套漂亮的架构变成依赖混乱的“大泥球”。Review 在这里起的就是对抗“架构熵增”的作用这是任何自动化工具都替代不了的。2.3 团队心智拉齐Review 正在成为最便宜的知识同步通道当 AI 让每个人的个人产出都变多时团队内部的知识差也在快速拉大。以前一个团队一个星期合并的代码量有限大家互相瞟一眼就能大概跟上进度现在 AI 让每个人的产出翻了好几倍A 写的代码 B 已经跟不上了C 用 AI 生成的一堆新工具函数A 根本不知道它们的存在。这种时候Review 反而是最便宜的“强制同步机制”。你不需要组织专门的培训不需要写冗长的文档只要保证每个 PR 都被认真讨论过一轮团队对系统现状的共同理解就会一点点长回来。我以前经常用“代码是写给人看的”这句话来推动团队做 Review现在我会更直白地说Review 是唯一能抵抗“AI 个体产出爆炸”导致团队割裂的手段。它不只是为了质量问题更是为了整个团队还能作为一个整体往前走。3. 我把 Review 前置到开发流程中的实操方案认知到位之后更重要的是怎么落地。我把这套方案做成了一种固定的工作流分享给有同样困扰的人。3.1 “写码前先写 Review 清单”的工作流改造我现在最关键的改变是把 Review 从“代码写完以后”提前到“写码之前”。具体操作是每个功能开始动工之前先花 5 到 10 分钟写一份 Review 清单。这份清单不是需求文档而是“这个 PR 合入时我必须重点检查什么”。比如这个功能里的事务边界是否和既有的事务注解冲突磁盘缓存有没有过期清理机制外部服务返回的错误码上层是否能正确处理而不是直接吞掉这次改动会不会破坏另一个模块对同一函数的调用假设然后把这份清单直接贴给 AI让它带着这些审查项去写代码。你可能会有疑问让 AI 带着清单写代码它就能避开所有坑吗当然不能。但效果非常明显AI 生成的代码会收敛很多因为它至少知道哪些点是“被关注的雷区”。更重要的收获是我审查的时候有了明确的抓手不再需要从头到尾把几百行代码读完才能判断好坏。我可以直接对照清单逐项核验这一项过了下一项有问题标出来返回修改。Review 从一件“压力很大的无边界任务”变成了“有明确检查项的核对工作”效率提升是肉眼可见的。3.2 用 AI 做“反向审查”一份可以直接抄的审查任务卡既然 AI 能写代码那它能不能帮忙审查我的答案是能但前提是方法要对。我现在会在代码写完后把完整 diff 贴给另一个独立的 AI 会话让它扮演“最挑剔的资深审查者”按一个固定框架找问题。下面是一份我可以直接拿出来分享的提示词模板你现在是一名拥有十年一线经验的资深软件架构师。请审查这份代码 diff严格按以下顺序检查安全和权限问题有没有密钥硬编码、越权访问、敏感数据泄漏到日志资源和连接泄漏有没有未关闭的连接、未释放的锁、未清除的定时器异常处理和边界条件有没有空指针风险、越界访问、被吞掉的异常API 兼容性有没有破坏既有调用方、使用已废弃接口、改变参数语义可读性与维护性有没有重复代码、命名混乱、职责不清的函数 每个问题请给出具体行号、问题原因以及一句修改建议。如果没有问题请回答“当前 diff 未发现明显缺陷但需要人工确认业务逻辑”。这里有一个非常关键的操作细节不要让同一个 AI 会话“边写边审”。比如你用 Cursor 生成了代码然后就问同一个对话“这代码写得怎么样”这时候 AI 大概率会自我辩护因为它会倾向维护自己刚产出的“作品”。你要做的是把 diff 单独复制到一个全新会话里用上面的 prompt 让它“冷酷”地审一遍。AI 审查的结果当然不完美经常会有误报但它能帮你发现那些“人眼已经麻木”的问题。比如一个 for 循环里反复创建对象的小毛病人看五遍可能都注意不到AI 一眼就给你标出来了。我的经验是AI 负责“扫雷”人负责“排雷”两者配合审查的效率和深度都能上一个台阶。3.3 三个真实场景下的 Review 关注点对比不同场景下Review 的关注点差异很大。我把自己经常遇到的三种场景列成了一个对照表方便直接参考。场景核心关注点典型翻车示例重构老模块是否破坏原有行为、是否静默删掉边界兼容逻辑AI 把旧代码里的一个特殊分支当成“冗余”删掉导致历史数据的兼容逻辑失效新接口开发API 语义、错误码设计、字段命名是否与现有规范一致AI 生成了新的错误枚举但语义和旧的重复调用方根本分不清跨服务分布式改动超时设置、重试策略、幂等设计、消息顺序AI 把远程调用从并行改成串行接口响应时间直接翻三倍针对重构场景我在 Review 时一定会做一件事把原有代码的关键路径先写出来然后逐条对照 AI 重构后的代码确保每条路径都还在。这听起来很笨但效果极好因为 AI 重构时最喜欢“优化掉冗余”——但它分不清“看着冗余但实际上是兼容逻辑”的代码。针对分布式场景我会重点盯一个点AI 有没有在“处理失败”的代码里偷偷把重试策略变成了无限重试或者把超时时间设成了完全不合理的数值。这类问题在单测里根本测不出来只有 Review 时靠人工经验和系统现状判断。4. 踩过的坑与排查经验实录理论讲完讲讲实操中最真实的东西。这些坑每一个都是我和团队用线上故障和加班时间换来的。4.1 常见问题速查表我把这段时间最常遇到的问题整理成了一张速查表方便大家在 Review 时对照排查。现象原因应对方法编译通过但运行时报NoSuchMethodErrorAI 用了一个被移除的旧版本 APIReview 时全文搜索关键函数确认当前依赖版本仍支持catch 块空实现或只打一行日志AI 为了“让代码显得完整”自动补了 catch但没补处理逻辑在审查清单中固定要求所有 catch 必须给出处理方式不允许空吞硬编码的 AK/SK、数据库地址AI 把示例配置当成了真实配置Review 时跑一次全文密钥扫描同时在清单里固定加“扫密钥”一项AI 生成的新类与已有类功能重复AI 不了解现有代码库Review 时先搜索“这类东西是不是已经存在”再决定去重方向多线程环境下共享变量被直接修改AI 生成的代码没有考虑并发访问控制重点审查所有被多线程调用的方法要求补上同步或锁机制测试用例全过但覆盖率造假AI 生成的测试只测了 happy pathReview 时看测试里有没有边界值、异常分支、空响应用例这张表里的问题有一个共同特征单看每一行代码都没毛病但放在系统的上下文里就是暗雷。这也是为什么我始终强调Review 不能只看“代码本身”更要看“代码和系统的关系”。4.2 Review 中我坚持的几条铁律吃过亏之后我给自己定了几条铁律每条都对应一次真实的教训。第一条AI 生成的代码不允许直接 Approve。无论 AI 生成了多漂亮的代码至少要完整读一遍核心路径并在评论里写清楚“我读过这段代码确认它符合 xxx 约定”。这条铁律不是不信任 AI而是强制自己不要被“代码看起来很专业”这种表象催眠。第二条一个 PR 里必须写清楚“哪些是 AI 生成的、哪些是手工改的”。这个信息对审查者极其重要因为它决定了审查者需要用多大警惕度去看这个 diff。如果整个 PR 都是手写代码审查者的心态可以放松一些如果 80% 是 AI 生成那必须用最挑剔的眼光逐行审。第三条超过 400 行的 diff必须拆成多个 PR。以前我觉得拆 PR 浪费时间后来我发现超过 400 行的 diff 根本没有人愿意认真看大家只会粗略扫一眼就合入。AI 时代这个问题尤其严重因为 AI 生成大段代码的能力太强了。拆 PR 不是形式主义它是逼着你把一次大改动拆成多个可独立验证的小步骤每个步骤都能被完整审查。4.3 一个四口小组的量化观察Review 前置到底改变了什么理论吹得再好不如看数据。我拿自己所在的四人小组举例我们主要做后端业务同时兼顾一部分前端。过去两周我们把“Review 清单前置 AI 反向审查 强制拆 PR”这套流程完整跑了一遍这里有三组我很想分享的观察数据。指标调整前调整后平均每周 PR 数约 13 个约 9 个但每个粒度更小平均单 PR Review 耗时约 40 分钟约 25 分钟线上问题issue / 缺陷每周 3 到 5 个每周 0 到 1 个需要返工重写的 PR 比例约 15%约 4%这个数据的样本量不算大但趋势非常明显。最让我惊喜的不是线上问题数下降而是“发现问题的时间点变了”——以前很多问题是在测试阶段甚至上线之后才暴露现在绝大多数问题在 Review 阶段就被拦下来了。返工成本从“改线上代码 补数据 向业务方解释”变成了“改几行代码重新提交一次”这个差距是巨大的。当然这个数据只能算团队内部的经验观察谈不上严谨实验但它至少说明一件事Review 前置不是降低效率而是把效率“花在了刀刃上”。5. 下一步我准备怎么继续演进流程跑顺之后我开始想一些更长远的改进方向。这里也顺便给同行们提供一些思路。5.1 把 Review 结果沉淀成团队的“AI 知识库”每次 Review 中发现的典型问题我现在会顺手整理成一条“错误模式记录”包含三部分错误样例、修正方案、以及如何在提示词里预防。积攒一段时间后这些记录就变成了一份团队专属的“AI 审查错误模式手册”。这份手册的价值在于它可以直接反哺我们的提示词工程。比如我们频繁发现 AI 在生成定时任务时容易漏掉异常捕获那就在写定时任务相关的提示词时统一加上一句“确保定时任务内有完整的异常兜底避免任务中断”。用这种“从 Review 中来到提示词中去”的闭环AI 生成代码的质量会越来越高人类的审查负担会越来越轻。5.2 让 Agent 在 CI 阶段做第一轮值守我最近在尝试配置一个轻量级的 Agent 来做 CI 阶段的“第一轮值守”当 PR 提交时Agent 自动执行一组自定义静态检查脚本比如密钥扫描、硬编码地址扫描、废弃 API 调用扫描、TODO/FIXME 统计。一旦发现异常会以机器人的身份直接在评论区标记相关人。这一轮最核心的价值是过滤掉“最没有争议的问题”。你想想如果每个 PR 都要人工检查一遍有没有硬编码的密钥那纯属浪费生命。把这部分交给 Agent 做掉以后人工 Review 就能把全部精力放在“真正需要人类判断”的地方——业务逻辑、架构一致性、分布式行为。5.3 用指标考核“发现问题的密度”而不是“审查的数量”我最近在团队里推动一个变化不考核“每天审查了几个 PR”而是统计一个半新指标——“每 1000 行 diff 里发现了多少个需要修改的问题密度”。这个指标比“审查个数”更能反映 Review 的真实价值。为什么这么说因为“审查个数”是一个很容易刷的虚荣指标。你一天看十个 PR但每个都只回一句“看起来没问题”这真的有意义吗而“问题密度”直接逼着审查者去深挖 diff挖得越深发现的问题越多这个数字就越高。虽然这个指标还不完美比如它可能诱导大家故意挑小毛病但总比“为了刷数量而浮于表面”强得多。我个人在实际操作中的体会是这套体系最核心的改变其实是心态。以前我用 AI 写代码总有一种“终于可以偷懒了”的错觉踩了几次坑之后才发现AI 的效率红利是有前提的就是你的审查能力必须同步跟上。我现在每天收工前都会看一眼待审查列表宁可少写两段 AI 生成的新代码也要把已经存在的 PR Review 干净。因为对系统来说多一行不可理解的代码比少一行可理解的代码危险得多。如果要我给所有刚开始拥抱 AI 辅助编程的团队一个建议我会说先别急着把 AI 的产出能力拉到最大先把你们的 Review 流程武装到牙齿。写码可以靠 AI但“这行代码为什么存在”这件事最终还是得靠人回答。