dev.to 那篇讲 AI 代码审查的文章，中文圈子转了好几轮。Robert Adamson 的核心论点就一句：AI 生成代码的速度已经超过了人类审查代码的速度，瓶颈从“写”挪到了“审”。这个判断没错，但它只瞧见了表皮。或者说，它指出了一个现象，却把病根给诊断浅了。
真正的问题从来不是审查速度跟不上生成速度。审查慢，是结果，不是原因。原因是我们用“能跑”替代了“理解”，用“堆量”替代了“工程判断”，然后突然发现：代码多到没人看得过来。这不是 AI 的错，是我们自己把防线拆了。AI 只是那个拆完以后站旁边问“还需要我再快点吗”的人。
我天天用这类工具，几十分钟出 27 个文件、1800 行代码，把 RBAC 的中间件、API、UI、测试全铺好，我没说它没用。我要说的是：你把 1800 行代码交给一个工程师，他一边看一边说这个变量命名有问题、那个迁移顺序可能会炸、这个边界情况没处理——这一小时不是浪费，这一小时是工程活动。你把它从流程里拿掉，剩下的不是工程，是流水线。
GitHub 最近给 Copilot Code Review 做了升级，能调额外工具去构建、跑测试、搞针对性检查，还试了多代理 ensemble 方案，说高严重度审查意见处理比例提升了 47%。技术上我信，确实是可用的东西。可这个 47% 细想一下很滑。它提升的是“处理比例”，不是“发现问题数量”，更不是“保证过了这套审查的代码真符合需求”。一个 agent 找出一堆“看起来可疑”的地方，另一个 agent 负责确认——要是两个 agent 共享同一套训练数据、同一套对需求的理解偏差，它俩一致同意的“正确”代码，可能每一行都是错的。
Adamson 文章里那个例子就是讲这个，很多人没听进去。需求是“只有账户所有人可以永久删除工作区”，AI 写了实现，写了测试，测试全绿。可实际业务里还有管理员、成员、暂停账户、删除账户这些角色——实现和测试一致地无视了它们，测试跑通的结果是每一层验证都“通过”，但你交付的是一个逻辑错误的功能。不是测试写得烂，是验证体系里根本没有人类判断这一环。AI 能证明代码符合它自己的理解，它证明不了那个理解跟现实需求是一回事。这两件事中间的沟，不是靠升级模型填的，是靠人填的。
现在圈子里有种说法：让 AI 生成代码，再让另一个 AI 审查代码，人类最后点批准就完事。我对这个方案只有一个评价：它会把人类变成整个流程里信息最少的一方。你想想，需求是你用自然语言说的，实现是 agent 写的，测试是 agent 生成的，审查是另一个 agent 做的，修复是 agent 自己改的——到最后你审批的是个啥？是“这堆东西看起来能跑，而且几个 agent 都说没问题”。你不理解这个系统的行为边界，不理解哪些输入会把它搞崩，不理解哪条数据路径是要命的关键路径。你签了字，但你不负责。不是不想负责，是没有足够的信息去负责。工程上有个现成的词，叫信息不对称决策。说难听点，叫背锅。
Sonar 给过 AI 技术债一个定义：AI 生成代码的产出速度快于团队验证、理解、维护能力的时候，返工和风险就来了。这个定义我认。传统技术债是开发者知道自己在走捷径，欠了债记在账上，管理层也认。AI 技术债更麻烦：代码当下能跑，团队里没人真正理解它。账本上没有这一项，因为它不体现成“我们欠了重构时间”，而是体现为“系统出了一个谁都解释不了的行为，谁都不敢动”。这种债比砍几个迭代还不清。
有人会说，那就加大审查力度，把人招回来做深度 review，把 agent 权限收紧。陈腔滥调。审查不是瓶颈，审查是那根最后的保险丝——你把保险丝加粗，电路该短路的照样短路，烧的不过是变压器。真正要解决的是前面那半步：你对要处理的问题，到底有没有一个正确且足够具体的理解。
Adamson 把审查分成五层：需求、架构、影响范围、失败模式、可维护性。分层没问题，但顺序比分层重要。大部分人一上来就盯着“影响范围”——认证、授权、支付、数据库迁移、生产数据、缓存、并发、基础设施——因为这些是高危区，出了事就是生产事故。没错。但如果你第一层“需求”没搞清，后面四层的审查全是在替一个可能错误的需求找实现细节。你审查出来的“授权逻辑缺失”，真的是这功能要的授权吗？还是说这功能从一开始就不该这么干？第一层不到位，后面四层审得越细，投入越大，产出越废。这不是在审代码，这是在给错误的需求攒正确性。
AI 擅长的是正常路径，写正常路径又快又好。可生产上最难查、最贵的 bug 从来不在正常路径上。API 超时了怎么办，数据库挂了怎么办，并发请求打进来怎么办，用户刷新页面重入 POST 怎么办，支付成功但 webhook 失败怎么办，第三方接口返回垃圾数据怎么办，未授权用户直接调端点怎么办——这些异常路径，AI 通常写得要么没有，要么一个 catch-all 日志。审查的人如果只是开着 diff 一行行看，也不见得能在 1800 行正常路径里一眼揪出缺失的失败分支。这就是为什么有经验的工程师审代码跟没经验的工程师审代码，差距能大到天上地下——不是手快，是知道该往哪儿看。
原文底下 infracore 那条评论我注意到，他说得在点子上：大型 AI PR 先审 API 契约，从基线分支和 PR 头部分别生成 openapi.json 做 diff。如果 DELETE /workspace/:id 这个改动跟需求对不上，那 1800 行代码一个都不用看。这是值钱的经验。不是“怎么快速审”，是“先认准问题的定义级正确性再下钻”。Pushpendra 提的另一个盲区也真实：团队可能认真审了 1800 行逻辑，结果死在新增环境变量和迁移顺序上——审查抓得出逻辑缺陷，抓不出部署步骤上的坑。为什么迁移顺序没人审？因为审代码的人和部署代码的人通常不是同一条责任链。链断了，速度和理解就都成了口头上的要求。
说点难听的。AI 进入开发流程以后，很多团队在庆祝周 PR 数量从 10 涨到 35，缺陷从 2 涨到 11 这件事没人拿出来说。缺陷率从 20% 升到 31%，绝对数字乘以 3，而理解覆盖率从“开发者理解变更”掉到“没人理解一半的变更”。你明明在做更多的东西，却没有交付更多“经过验证且可维护的价值”。你把“提交量”当进步，那是仓库变胖，不是系统变好。
指标得换。从“合并 PR 数”换成“多少变更通过了人确认的需求验证”；从“feature 数”换成“存活超过一个版本且不需要返工的 feature 数”。光这个转换就能让一大半“AI 提效”的幻象消失。因为真实数字很难看。很难看不是 AI 的错，是流程把“理解”这个环节给优化掉了。
Adamson 说真正的瓶颈是信任，我同意。但这个“信任”不是“信不信任 AI 写的代码”，而是“我们还能不能信任自己理解自己负责的系统”。前者可以靠工具、测试、静态分析、agent ensemble 缓解，后者只能靠人补基本功恢复。基本功是什么？不是回去背分布式八股文，是恢复那几个在这个岗位上一回都没过时过的能力：能不能把一个复杂需求拆成什么时候做什么、什么角色有什么权限、什么异常触发什么处理、什么数据不可以落到什么条件之外。拆得清，AI 就是你的批量机器；拆不清，AI 就是一台高效生产烂摊子的流水线。
审查应该变成一种验证“AI 写的东西是否跟人脑里的正确模型一致”的活动，而不是一种“从 1800 行里挑刺”的活动。这要求人先有模型，然后才谈得上验证。没模型的人审代码，只能看风格、看格式、看 lint——那跟让 AI 自己做自己的检查有什么区别？
所以最后把态度亮清楚：真正的瓶颈，从来不是代码审得不够快，是你对自己要交付什么、它每一步为什么这么做，说不清楚。解决方式也不是让多个 agent 加速审查，而是把审查之前那步“需求验证”重新变成工程流程里的硬性前置门——先证明理解了需求，再谈生成和审查的速度。
我的态度很明确：你先把需求拆到能让另一个人复述出来的程度，再让 AI 去生成 1800 行。如果你自己都说不清“我把这个角色加上以后，暂停账户删除时会发生什么”，那 AI 写出来的东西，你签不签字都改不了它底下是个沙子的事实。AI 能帮你快，帮不了你想清楚。把“想清楚”当奢侈优化掉的人，生成了多快的代码，就生产了多快的风险。欠的债早晚要还，只是这次不是你自己动手还，是生产环境动手收。