最近用 ChatGPT、Codex 做稍微大一点的开发任务很容易碰到一个以前不明显的问题Agent写代码越来越快但人已经Review不过来了。比如让Codex完成一次支付模块重构。十几分钟以后它可能直接给你38个文件发生变化新增和删除合计5000多行API、Service、测试一起修改CI全部通过还顺手调整了一部分公共代码。从“任务完成速度”来看非常爽。可真正打开PR以后问题来了5000行Diff我到底应该从第一行开始看还是直接相信测试如果继续沿用以前人工开发时代的习惯从第一个文件开始一行一行往下读。很可能看了半小时还停留在格式调整、变量重命名和generated code上。真正高风险的一处事务逻辑却藏在第27个文件。所以Agent时代的Code Review第一个要改变的不是看得更快。而是先决定什么最值得看。一、5000行PR真正危险的不是“行数多”很多团队看到AI生成的大PR第一反应是Diff太大没法Review。但5000行并不一定都危险。其中可能有2000行generated code。1000行测试数据。800行格式变化。真正影响生产行为的核心代码也许只有几百行。反过来一个只有20行的PR也可能修改权限判断。资金计算。事务边界。数据库Migration。所以我更倾向于把AI PR理解成Change Volume不等于Change Risk。人工Reviewer真正应该先找的是风险集中在哪里。而不是平均分配注意力。二、第一步不要看代码先看任务目标有没有发生漂移拿到一个大PR以后我不会马上打开第一个Diff。我更建议先回答三个问题原始任务是什么Agent最终声称完成了什么实际改动范围是否仍然服务于原始任务例如原始任务只是修复订单取消后库存没有恢复的问题。结果最终Diff里出现支付工具类重构。库存表结构调整。公共异常体系修改。日志框架升级。这时候即使代码每一行都写得不错也值得先警惕。因为它可能已经出现Scope Drift——修改范围漂移。Agent特别容易在执行过程中发现“这里顺便整理一下更合理。”“这个公共方法一起重构更干净。”对它来说是优化。但对Review来说每增加一个无关修改就增加一块新的验证面积。所以Review第一关不是代码写得漂亮吗而是它到底有没有只做这次应该做的事三、第二步先看Change Surface而不是Diff顺序传统Git Diff通常按文件排列。但风险不会按文件名排序。所以对于ChatGPT、Codex生成的大PR我更推荐先自己画一个非常简单的Change Surface这次到底动了哪些区域例如API ↓ OrderService ↓ InventoryService ↓ Database ↓ Event ↓ Tests如果一个任务原本只是Service层Bug现在却一路改到了数据库。Event Schema。API Contract。那Review优先级应该立刻改变。因为真正需要人工判断的已经不是某个if写得对不对。而是这次修改是不是改变了系统边界。这一步特别适合让Codex先帮你总结Modified Files → Logical Modules → External Contracts → Data Changes人再基于这个结果决定从哪里开始看。四、第三步优先找“不可逆”或者“爆炸半径大”的修改不是所有代码错误代价都一样。一个内部变量名写错可能测试马上发现。但下面这些变化我会优先Review数据库Migration。数据删除。权限判断。支付金额。缓存一致性。消息Schema。公共API。并发与锁。重试逻辑。外部系统调用。因为它们共同特点是一旦错了影响可能跨出当前模块。例如Agent把if (user.isAdmin())改成了一套新的Permission判断。Diff可能只有十几行。但它的风险可能比几百行DTO重构高得多。所以人工Review应该从高Blast Radius区域开始。而不是从README.md一路看到核心业务代码。五、第四步先看Contract再看实现细节AI特别擅长快速重构实现。但很多线上事故并不是“实现代码写错了。”而是边界协议悄悄变了。比如Agent修改了一个API以前{ userId: 123 }后来{ userId: 123 }单服务测试可能全部通过。但旧客户端可能直接出问题。所以大型AI PR里我会特别优先检查API Request / Response。Event Schema。数据库字段。配置格式。公共方法签名。序列化行为。错误码。这些本质上都是Contract。内部实现可以重构。Contract一旦变化下游可能根本不知道。所以Review顺序应该是先确认系统边界有没有变再看内部是怎么实现的。六、第五步看数据和状态变化如果PR涉及订单状态。支付状态。库存。账户余额。任务状态机。数据库Migration。这类代码我不会先看“写法是否优雅”。我会先问Before是什么状态After是什么状态中间失败会留下什么比如Agent增加一个流程创建订单 → 扣库存 → 调用支付 → 写数据库正常路径全部正确。但真正危险的是支付成功以后数据库写入失败怎么办库存已经扣了后面超时怎么办请求重试会不会重复执行所以AI PR里涉及状态变化的地方人工Review应该优先看Failure Path。因为Agent很容易把Happy Path写得很完整。生产事故往往发生在第3步成功、第4步失败这种中间状态。七、第六步才看测试但不要只看“绿没绿”AI生成PR以后最容易出现一句话All tests passed.这句话不能直接等于这个PR安全。真正需要Review的是测试覆盖了什么风险例如这次修改涉及API兼容。事务。并发。重试。结果测试新增的只是输入正确 → 返回200。那即使测试全部通过也不能证明核心风险已经被验证。所以看测试时我通常会反过来问这次最可能出错的三个地方是什么然后看测试里有没有对应Evidence。例如重复请求是否幂等旧API是否仍兼容事务中途失败是否回滚并发下是否重复扣款如果这些都没有测试那100个绿色Case也可能只是覆盖了大量低风险路径。八、Generated Code和机械修改最后再看一个5000行PR里最容易浪费Reviewer时间的是generated code。格式化。Import调整。自动生成类型。锁文件变化。机械重命名。不是说这些完全不用看。而是它们不应该占据第一轮人工注意力。更合理的方法是先确认Source of Truth改得对不对。Generator是否正确执行。生成Diff是否符合预期。如果来源和生成链已经可信人工就没有必要从generated文件第一行读到最后一行。Agent时代Review效率很大一部分提升就来自把人的注意力留给机器最难判断的地方。九、我更推荐一套“风险优先”的Review顺序如果Codex一次给我一个几千行PR我现在会按照下面顺序看1. Intent原任务到底是什么最终实现有没有偏题2. Change Surface改了哪些模块有没有扩散到任务之外3. High-Risk Boundary权限、支付、事务、数据、并发、外部调用有没有变化4. ContractAPI、Schema、Event、配置是否变化5. State Failure Path异常路径、中间状态、重试是否安全6. Validation测试是不是覆盖了真正的风险7. Low-Risk Diff最后才看generated code、格式和机械修改。也就是Intent → Surface → Risk → Contract → State → Validation → Detail这比“从上往下读Diff”更适合Agent生成的大型PR。十、Agent反而可以先帮你做第一轮Review压缩这里有一个很实际的用法。不要直接问ChatGPT、Codex帮我Review这个PR。这种要求太宽。可以让它先生成一份Risk Map。比如要求它回答这次PR修改了哪些业务模块哪些修改改变了外部Contract哪些涉及数据持久化哪些地方可能产生不可逆副作用哪些文件只是generated或机械变化哪些测试真正覆盖了高风险区域这样几千行Diff可以先压缩成十几个真正值得人工确认的风险点。人再逐个Review。这比让Agent给每一行代码写点评更有价值。十一、不要让“测试全绿”替代人工判断Agent写代码以后自己跑测试是好事。但测试的本质是验证已经想到的条件。人工Review还有一个任务找没有被想到的条件。例如旧客户端怎么办灰度期间新旧版本同时存在怎么办任务执行到一半Pod重启怎么办重试会不会产生重复数据Migration回滚不了怎么办这些问题很多时候并不会自动出现在测试里。所以AI开发以后人类Reviewer的价值并没有消失。反而更集中到边界判断、风险识别和异常场景。十二、一个指标High-Risk Review Coverage如果这篇只留一个指标我建议用High-Risk Review Coverage——高风险变更审查覆盖率可以简单理解为已经人工确认的高风险变更点 ÷ 本次PR识别出的全部高风险变更点比如一个PR识别出API Contract。数据库Migration。支付状态变化。重试逻辑。权限判断。共5个高风险区域。人工真正Review并验证了4个。那么高风险审查覆盖率就是80%。它比“5000行代码我已经看了4000行”更有价值。因为看了80%的代码不代表看到了80%的风险。十三、什么时候应该直接拆PR而不是硬Review如果一个Agent PR已经同时包含功能开发。架构重构。数据库Migration。依赖升级。大量格式化。测试重写。那最好的Review方法可能根本不是研究如何更快看完。而是先拆。例如拆成功能行为修改。数据库变化。公共接口变化。机械重构。这样每个PR都有更明确的Intent和验证范围。Agent生成代码很快不代表PR越大越好。真正适合工程协作的是Large Task可以很大但Review Unit应该尽量可控。十四、Plus和Pro怎么判断如果你平时主要让ChatGPT、Codex处理几个文件的小任务。单模块Bug。局部重构。一次Diff几百行。这种情况下Plus通常已经够用。让Agent先总结改动再人工Review关键文件工作量不会特别大。如果你已经经常让Codex处理大型仓库。一次任务跨几十个文件。需要反复读取Diff、日志、测试结果和CI。一次PR数千行。还要连续让它做Risk Map、修改、重新验证和二次Review这种长上下文、多轮工程协作越来越频繁时Pro会更适合。真正的判断标准不是PR有5000行就必须Pro。而是这种大型Agent任务是不是已经变成你的日常工作方式。最后Agent一次生成5000行PR人工Review到底应该先看哪里答案不是从第一行开始。AI写代码越来越快以后人工Review真正稀缺的已经不是阅读代码的速度。而是对风险进行排序的能力。拿到一个大型ChatGPT、Codex PR以后更值得先看的应该是任务有没有漂移。改动范围有没有扩大。高风险边界有没有变化。Contract有没有被改。状态和失败路径是否安全。测试有没有真正覆盖这些风险。最后才是大量低风险机械Diff。所以Agent时代的Review顺序更应该变成Intent → Change Surface → High Risk → Contract → State → Validation → Detail当代码生成速度越来越快以后人类真正需要守住的也不再是“每一行都是不是自己看过。”而是真正可能让系统出问题的地方有没有被认真看过。持续分享 Codex、大模型开发与 AI 编程实战内容也整理了稳定的 Plus/Pro 订阅渠道有需要下方可自取。