杀死代码评审：AI 写代码、AI 审代码之后，人剩下的是对齐

本文整理自 AI Engineer 大会上 Aviator 联合创始人 Ankit Jain 的演讲《How to Kill the Code Review》。他几个月前写过一套「杀死代码评审」的五层信任模型，这次上台主要做自我修正：评审从来不只是抓 bug，它的另一半是知识共享、传帮带和架构对齐——工具能接走前一半，接不走后一半。原视频：https://www.youtube.com/watch?v=YgEv7IQzGdM

评审的死不是预测，是既成事实

演讲开场，Ankit 给了一组数字：代码 churn 高达 861%，事故数和 PR 数的比值在涨，评审等待时间是过去的四倍，超过 30% 的变更根本没经过评审就直接合并了。

这组数字指向同一个结论：「我们什么时候停止逐行读代码」是个伪问题。我们已经停了。编码环节被 AI 加速之后，瓶颈整体搬了家——从写代码搬到审代码，所有东西都堵在这里。

他还补了一个常被忽略的历史事实：代码评审并不古老。Google 2006 年才在内部上线 Mondrian，把正式评审变成工程流程的一部分，满打满算二十年。更早的 Windows 早期版本，压根没有评审这回事。评审不是亘古不变的圣地，它只是 waterfall 和敏捷时代之间长出来的一种协作习惯。

AI 审 AI 写的代码，人类在旁边围观

Ankit 描述了现在很多团队的真实工作流：AI 写代码，提交 PR，两三个 AI agent 在 GitHub 页面里来回提意见、改意见、解决意见，人类打开这个网页，扫一眼对话串，「AI 都审过了，应该没大问题」，点合并。

他的原话是：当 AI 在评审而没人在读，我们配置错了系统。

这句话是整场演讲的支点。问题不在 AI 审得不好，而在人类在这套流程里的位置只剩下了「见证合并」。你自以为在治理，实际上在盖章。

修正自己：评审的另一半叫对齐

接下来是他对自己五层信任模型的检讨。那套模型回答的问题是：怎么一层一层建立信任，让代码不用逐行读就能合并。它默认评审的目的就是保证正确性——抓 bug、查规范、堵安全漏洞。

他现在承认这个默认是错的。评审从来承担两份职责：

语义正确性：抓 bug、规范、安全问题。这部分可以交给工具，值得不断加码自动化。
对齐（alignment）：知识共享、传帮带、架构反馈、新人 onboarding。这部分不是代码质量问题的副产品，它就是评审存在的另一半理由。

他的判断很干脆：语义正确性可以造更好的工具，对齐必须活下来。如果是单人 vibe coding 项目，这套讨论跟你无关；但只要你在团队里协作，评审承载的知识流动就不能断。

Spec 驱动开发，是 1970 年的瀑布换了个马甲

对当下流行的 spec 驱动开发（写好规格，交给 agent 生成代码，然后验证），Ankit 的批评不留情面：把 1970 年的瀑布模型流程图拿出来对一下——需求、规格、实现、验证，一模一样，唯独没有反馈回路。

spec 是在所有问题被识别之前写完的。这就是为什么大家最后还是回到了 Claude Code、Codex、Cursor 这类交互式会话：spec 里没写清楚的东西，得在来回对话里补上；实现过程中冒出来的新问题，也没人回头去改 spec。指望 spec 写完代码就确定性地产出，可 LLM 本来就不是确定性的，它一定会自己做决定。

但 spec 派有一个洞察值得留住：意图（intent）比代码重要。问题是意图不只住在 spec 里。它住在 Jira ticket 里（目标是什么），住在 PRD 里（打算怎么做），更住在每天和 agent 来回的 prompt 里——真正的决策发生在那里。而现在的做法是：变更合并成 PR 之后，把 prompt 全扔了。

这里有个值得记下的张力。Karpathy 在今年的 AISN 发言里把 AI 编程切成 spec、harness、verification 三层，主张 spec 应该成为 source of truth。Ankit 的立场几乎相反：spec 驱动是瀑布复辟，意图真正住在会话里。两个人不冲突的地方在于——意图要被当成一等公民保存下来。分歧只在存哪儿：一份写全的文档，还是一段可回放的协作历史。

新的评审面：审意图、审证据，不审 diff

演讲后半段是 Aviator 的产品化方案（叫 Verify，正在找早期设计伙伴，这部分自带广告滤镜）。剥掉产品外壳，流程设计本身值得看：

捕获会话。人和 agent 来回对话里的每一次纠偏、每一个被拒绝的方案，都是决策。这些决策被沉淀成验收标准（acceptance criteria）。
生成测试计划。验收标准加上维护中的规则库，用 LLM 生成实时测试计划。测试计划的维护成本是人最不想付的，交给 LLM 合理。
确定性验证。系统拉起 preview 环境，按测试计划端到端跑一遍。能确定性的地方确定性，做不到的用 LLM 兜底——他的原则是「deterministic where it can be, LLM where you must」。比如新增一个支付表单，agent 会真的去浏览器里把表单填一遍，截屏、抓数据库快照，作为证据。
换评审面。人不再逐行看 diff，而是看三样东西：意图是什么（会话里说了要做什么）、验收标准达没达标、验证证据支不支持。架构争论照旧发生，只是从代码行上移到了数据模型和服务交互这一层。

两个设计细节比整体流程更有含金量。

一是测试计划必须从会话生成，不能让写代码的 agent 自己出考卷。同一个 agent 既写代码又写测试，它不会给自己埋雷。出题人和答题人得分开，这条原则在纯人类时代就是对的，AI 时代只是更隐蔽了。

二是这套东西接近 BDD 的自然延伸：测试计划是英文写的，产品经理和设计师都能读、都能参与。二十年前 TDD 把测试往前推，现在「测试计划」正在变成整个团队共享的契约层，人在这套系统里的价值就落在治理和评审测试计划上——审考卷，不审答卷。

AI slop registry：把重复的 review 评论固化成护栏

对语义正确性那半，Ankit 给的方案是「AI slop registry」：把人工评审里反复出现的意见——命名规范、错误处理姿势、日志格式——沉淀成一条条可执行的规则。每条被固化的问题，下次就不用再人肉说一遍。

他给观众布置了个作业：回家挖出最近一千条评审评论，把重复的部分做成规则库。绝大多数评审意见都是重复的，这个资产每次合并都在复利。代价是条 J 曲线，前期建库的成本实打实，回报要攒一段时间才显出来。

这思路不新，lint 规则、review checklist 都是它的前身。新在两点：规则可以从历史评审评论里用 LLM 批量萃取；萃取出来的规则跑在验证回环里而不是靠人记得。

放进更大的图里看

把我自己知识库里的几条旧判断拿来对一下，这场演讲的位置更清楚。

Karpathy 的三层框架里，「生成易、验证难，把验证回路做快才能起飞」是核心主张，我当时的延伸判断是 spec 和 harness 都在补模型当下的短板、会随模型升级贬值，只有 verification 不贬值。Ankit 的整场演讲基本是这句话的产品化：把验证回路做成系统，把人从逐行阅读里解放出来。

但他补上了一个 Karpathy 框架里没有的维度：验证解决的是「代码对不对」，对齐解决的是「团队有没有一起变懂」。前者是技术问题，后者是组织问题。纯 verification 框架会把你带进一个高效但知识孤岛化的团队——代码全绿，没人知道为什么。他对自己五层模型的修正，本质是承认了这一点。

还有一条旁证：编码环节被加速之后，瓶颈必然转移到 review、安全和设计质量这些难以验证的环节。Ankit 给的数据（评审等待四倍、30% 裸奔合并）就是这条判断的现场证据。瓶颈在哪，工具和流程的重构就该在哪，这场演讲算是一次现场施工。