专栏 · Agent 工程手艺 › 第 188 期 · AGENT 工程 · 收录于 2026 年 8 月 21 日
如何干掉代码审查——Ankit Jain(Aviator)
AJ
Ankit Jain · AI Engineer
7,225观看
138赞
1.9%点赞率
9评论
62.7万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一瓶颈已经从「写代码」挪到「评审代码」，而这道闸门其实早就塌了——code churn（代码返工量，写完没多久又被改掉或删掉的那部分代码）涨了 861%，事故数与 PR 数的比值在上升，等 review 的时间是过去的四倍，超过 30% 的改动完全没经过评审就直接合入主干。Ankit 的判断很直白：「我们其实早就已经不 review 了。」→ 详细
- 二他当场修正自己几个月前那个「五层信任模型」——漏掉的那一块叫「对齐」：code review（代码评审，即代码合进主干前由另一个人逐行看一遍）真正的产品从来不是抓 bug，而是知识共享、带人、架构反馈、新人上手。一句话收口：「语义正确性我们可以靠更好的工具来解决，但对齐这件事必须保住。」→ 详细
- 三替代方案是把评审的落点从 diff 挪到证据：从 agent 交互 session 里捞出真实决策当验收标准，叠上从历史评审意见沉淀出的 AI slop registry，合成一份大白话测试计划，让验证系统起一套预览环境端到端跑一遍、留下截图和数据库快照——「现在 reviewer review 的是意图，不是 diff。」→ 详细
01
开场就自我修正：五层信任模型里，有些说对了有些说错了
- 讲者 Ankit Jain 是 Aviator 的联合创始人，公司做的是 AI code verification（AI 代码验证）平台，这场演讲把他们产品里的思路直接搬上台。→ 详细
- 几个月前他在 LinkedIn 发过一篇帖子讲「怎么干掉 code review」，提出一个框架叫五层信任模型——核心是一层一层给代码建立信任，让它最终不用逐行 review 就能合入主干。上台第一件事是承认：「里面有些我说对了，也有些说错了。」所以这场不讲某一层具体是什么，只讲从那次讨论里冒出来的几个概念。→ 详细
- 他把问题定义得很尖锐：代码产出量每天在涨，我们跟不上。所以「还要多久我们才会不再逐行读代码」这个问题本身就问错了——「现实是，我们其实早就已经不 review 了。」→ 详细
02
四个数字：评审这道闸门已经名存实亡
- code churn 涨了 861%——意思是产出的代码里，写完没多久就被改掉或删掉的那部分暴涨。这是「AI 在疯狂产出，但产出的东西不稳」的直接读数。→ 详细
- 事故数与 PR 数的比值在上升——一次 PR（pull request，合并请求，一次改动打包等着合入主干）平均带来的线上事故变多了。他的解读很狠：「就算你今天还在做 review，它也已经不管用了。」→ 详细
- review 的中位时长在变长，等 review 的时间是过去的四倍。瓶颈只是被挪了个位置——「写代码这一环现在算是解决了，结果所有东西全卡在 review 这儿。」→ 详细
- 超过 30% 的改动，是完全没经过 review 就直接 merge 的。这条是全场最硬的一击：闸门不是变慢了，是有三分之一的东西根本没走闸门。→ 详细
03
AI 写、AI 评，人只负责扫一眼点合并——「我们配置错了东西」
- 他先问了个很少有人问的问题：当代码是 AI 写的、review 也是 AI 做的，我们为什么还要在一个 UI 界面里做这件事？ 你打开 GitHub，可能有两三个 AI coding agent 在那儿做 review，意见回传给用户或者 agent，被解决掉，你就在旁边看着 agent 跟 agent 来回拉扯。→ 详细
- 「人在这个环里的位置到底在哪儿？」他给出真实答案：你最后无非是想「AI 都 review 过了，该找的问题大概都找出来了，那我扫一眼就 merge 吧」。→ 详细
- 结论是一句可以直接贴墙上的话：「当 AI 在 review、而没有人真的去读的时候，说明我们配置错了东西。」 问题不在于人不认真，而在于这个流程的形态本身已经不对了。→ 详细
04
code review 只有十五到二十年历史，别把它当天条
- 2006 年 Google 内部上线 Mondrian（Google 的内部代码评审工具），才把正式 code review 变成一件标配的事；在那之前，早期几个版本的 Windows 其实是没有 review 就做出来的。言下之意：这是一套有具体起点、也可以有终点的工程习惯，不是软件工程的物理定律。→ 详细
05
五层模型漏掉的那块：code review 真正的产品是「对齐」
- 我们当然会盯着评审抓 bug、统一规范、找安全问题，但 Ankit 说 code review 同时也在做 alignment（对齐）——「这恰恰是我几个月前那个五层模型里漏掉的一块。」他把对齐拆开点名：知识共享、带人（mentorship）、架构层面的反馈、新人上手（onboarding）、协作。→ 详细
- 他划了适用边界，很诚实：「如果你是在 vibe coding、一个人干单人项目，那这场演讲不是给你听的。」这套东西是给团队协作场景的，不是给那种完全无人值守、没人看代码的黑灯工厂式编排器（orchestrator）。→ 详细
- 全场的枢纽句在这里：「语义正确性（semantic accuracy，即代码逻辑上到底对不对、有没有 bug）我们可以靠更好的工具来解决，但对齐这件事必须保住。」 一半可以外包给机器，另一半外包了就等于把团队的共同心智外包了。而对齐「恰恰是发布环节里最重要的一面」。→ 详细
06
spec-driven development 就是 1970 年的瀑布模型换了张皮
- spec-driven development（先把需求规格写死、再让 AI 照着实现的做法）现在很火，逻辑是：写一份覆盖所有细节的 spec → 丢给 agent → 生成代码 → 验证。Ankit 直接把它拆穿：「回头看 1970 年，这不就是瀑布模型吗——先有需求，再有规格说明，然后实现，最后验证。」而它没有反馈回路。→ 详细
- 第一个漏洞：spec 是在你还没搞清楚其他所有事情之前就写好的。证据就是大家的实际行为——不管你用的是 Claude Code、Codex、Cursor 还是别的什么，你都还是想跟 agent 一来一回地聊。「你之所以要跟 agent 交互，就是因为 spec 里有些东西没讲清楚，那些东西还是得被捕捉下来。」→ 详细
- 第二个漏洞：实现过程中你会发现更多问题，但你从来不会回头去更新 spec——因为按 spec-driven 的玩法，spec 已经定稿了。「spec 一写完，你就默认代码会确定性地长出来。可问题是，LLM 不是确定性的，它会自己做决策。」→ 详细
- 他的结论不是全盘否定，而是分拆继承：「spec-driven development 是个很好的方法论，但放到日常软件开发里就不够用。」该继承下来的最重要的东西是意图（intent）。→ 详细
07
意图活在你的 prompt 里，而我们开完 PR 就把 prompt 扔了
- 意图有三个栖身处：Jira ticket 里装的是目标（我们想做什么）、PRD 里装的是细节和计划、而「最重要的是，今天它活在你的 prompt 里。真正的决策就是在那儿发生的。」你确实是从「我要处理这个 ticket」开始，但接下来跟 agent 的一来一回，才是所有用户侧决策的发生地。→ 详细
- 然后是全场最扎心的一句诊断：「我们今天的做法是：做完改动、开一个 pull request，然后把 prompt 全扔了。这是必须要改的一件事。」 我们精心保存了代码（结果），却把决策（原因）当垃圾丢掉——而 review 真正想看的恰恰是后者。→ 详细
- 他在后面把这条抬得更高：这些跟 agent 之间做出的决策「是让你的 review、你的协作变得有价值的东西，是你带初级工程师、让他们持续成长的方式」，并且——「这些决策才是今天一个软件工程师真正值钱的地方。」→ 详细
08
AI slop registry：把重复出现的评审意见编码成护栏
- 他预判了台下的反问：「Ankit，对齐这块我懂了，可代码里还是有 bug 啊，谁来看？」他的回答很坦白——LLM 在这方面也不算强，AI agent 当 reviewer 未必总是靠谱。所以要引入 AI slop registry（AI 垃圾模式登记册，把 AI 反复犯的同类毛病编成一份可复用的规则库）。→ 详细
- 机制很朴素：如果你今天还在人工 review 代码，你其实是在一遍又一遍地发现同样的问题。那就把这些模式捕捉下来、编码成规则，让它们被自动识别，而不是每次都一条条手写评审意见。→ 详细
- 妙处在于复利：「你这么做几次之后，就建起了一个会随时间学习的系统。」他打的比方是——在你手上那个标准 LLM 之上，又叠了一层训练、一层提炼和沉淀，它是在从人类提供的 review 经验里学习。收口金句：「每一条反复出现的评论，现在都变成了一道护栏，你不用再 review 第二遍。」→ 详细
09
闭环怎么接：session → 验收标准 →（加不变量）→ 测试计划 → 验证
- 他把对齐和语义正确性合起来看，称之为「同一个问题的两半」，要收进同一个闭环。第一步：拿你的 agent session，把里面用户的回复抓出来，这些本质上就构成了验收标准（acceptance criteria）。 哪怕是个很简单的任务，你也常常要来回好几轮，agent 会停下来问你问题——那些回答就是原料。→ 详细
- 第二步：验收标准 + 你持续维护的 AI slop registry → 生成一份测试计划（test plan）。 他给的公式更精确一点：「验收标准加上不变量（invariant，无论怎么改都必须一直成立的约束，比如金额不能为负），就构成了测试计划。」 这两步都明确推荐交给 LLM 做——「我知道写测试计划一向很痛苦，所以这块我特别推荐大家交给 LLM。」→ 详细
- 第三步：验证系统接住测试计划，起一套 preview（预览环境，为这次改动临时拉起的一套可运行环境），端到端跑一遍。 一句话说清了为什么要这么折腾：「代码看起来对是一回事，它到底能不能用是另一回事。」→ 详细
- 副产品很值钱：哪怕你在做一个全新的功能，你根本不需要维护测试——测试是实时生成的。而人留在环里的价值，变成了「治理和 review」，并且 review 的对象是测试计划，不是代码。→ 详细
10
新的 review 界面：你评的是意图和证据，不是 diff
- 「而关键在于——到这一步，它就成了你新的 review 界面。」你不再逐行 review 代码，而是去看三件事的证据：意图是什么？开发者有没有真的实现意图里定义的那个能力？行为有没有真的满足验收标准里写的要求？ 架构层面的决策你照样在做、照样在争论，「但 review 的落点变了」。→ 详细
- 更完整的一句是：「现在 reviewer review 的是意图，不是 diff。」 而且要连「我们试过又放弃了什么」一起从 session 里捞出来——被否决的方案跟被采纳的方案一样是决策的一部分。→ 详细
- 这套东西的谱系他也交代了：测试驱动开发（TDD，先写测试再写实现）提出来已经二十多年，而这套做法某种意义上更接近行为驱动开发（BDD，用大白话描述"系统应该表现成什么样"再据此验证）。差别在于测试计划现在是可以拿给产品经理、拿给设计师看的东西——「所有人都能参与，因为这些内容现在是用大白话写的」；同时又配了确定性的验证，能真正判断某一条标准到底满足没满足。→ 详细
- 抬高一层的好处：不再逐行读，而是「讨论数据模型怎么设计、这些服务之间怎么交互」——架构讨论对任何形式的协作都至关重要，而这正是逐行 review 挤掉的东西。→ 详细
11
能确定就用确定的，非得 LLM 才用 LLM：支付表单的例子
- 他给系统定了个不追求完美的调子：「能确定性的地方就用确定性，非得用 LLM 不可的地方才用 LLM。」 不是所有东西都能确定性，也不是每个系统都能 100% 建在确定性机制之上——LLM 在这里是兜底方案，不是首选方案。→ 详细
- 完整例子：你在 web 应用里新加了一个支付表单，系统针对行为变化生成测试计划，验证的问题是「支付流程有没有按预期变化」。一个 AI agent 去应用里点一遍、把表单填掉、截图留证，然后把截图连同数据库快照一起拿来判断验收标准满足没满足。→ 详细
- 价值不只是「测过了」，而是积累了更扎实的证据——reviewer 看到这些证据，对「这玩意儿是真的能跑」这件事才有信心。→ 详细
12
必须从 session 提取，不能从代码反推——同源的 agent 抓不出自己的问题
- 「记住，从 session 里捞是关键。」他点名引用了同场另一位讲者 Dex 前一天讲过的那个坑：如果生成测试计划的，就是那个写代码的同一个 agent，那它生成的测试计划根本抓不出问题——它只会把自己已经做了什么翻译成"应该做什么"，自证清白。→ 详细
- 所以真正的信息源必须是代码之前的东西：session 里人做的那些决策。这条是整套方法的地基，抽掉它，前面所有的验证都退化成一次昂贵的自动化橡皮图章。→ 详细
13
闪电问答 / 收尾
- 留给全场的作业（唯一一条行动指令）：「回去把你们最近的 1000 条 review 评论挖一遍，把那些会重复出现的东西做成一个 AI slop registry。」理由是你在 code review 里给出的绝大多数意见，其实都在重复、重复、再重复；而这东西会随着每一个 merge 的 PR 复利累积——每沉淀一条进 registry，你就永远不用再写那条评论了。→ 详细
- 先说痛后说甜的预期管理：「它确实会走一条 J 曲线（先下降后上扬的收益曲线），前期的痛是真的，你得先花点时间它才开始回本，因为一开始建 registry 是要下工夫的。」→ 详细
- 只带走一句话：「code review 不只是 code review，它是为了拿到对齐。」 能用更好的工具去解决的那部分是语义正确性，以及把你的 AI slop registry 定义出来；不能外包的那部分是对齐。→ 详细
- 产品线索：Aviator 正在试点一款新产品，叫 Verify，招募早期设计合作伙伴（early design partners），已在和几家公司试跑这套验证系统——它把对齐这一侧，和用 AI slop registry 检测语义正确性的工具能力，合到了一起。→ 详细