“人工审查能不能取消，让 AI 自动审批 90% 的 PR？”Antony Marcano 在文章中提到，自己参加的一场圆桌讨论正是从这个问题开始的。听起来像是在比较人和模型谁审得更准，他却把讨论转向两件事：团队凭什么认定人工审查已经没有价值？为什么代码一定要等到 PR 阶段才接受审查？

“自动审批 90%”只是圆桌讨论抛出的问题，并非建议团队追求的指标。Marcano 主张把代码审查放回实现过程，让反馈更早、更频繁地出现；人工把关能否减少，要看团队自己的质量数据和风险边界。本文依据他的原文和学习笔记整理，并会区分作者观点与实践延伸。

先问证据，也先问审查为何等到 PR

PR 是组织评审、讨论变更和留下决策记录的常见方式，但代码审查并不只发生在 PR 里。取消 PR 合并门禁，不代表取消代码审查。团队仍需判断实现是否正确、易于维护、符合架构约束，也没有给系统带来不必要的复杂度。

Marcano 的原则很直接：“只要你们自己的数据还没有证明人工审查不再值得投入，就应该保留人工审查。”因此，与其抽象地争论“AI 能不能替代人”，不如具体检查：当前流程在哪些地方获得质量反馈？哪些风险仍需要人工判断？如果调整门禁，团队用什么证据确认结果没有变差？

把反馈放回实现过程

质量保障不只是在事后执行测试。测试关注行为是否符合预期，代码审查还会看可维护性、架构、复杂度和一致性。功能即使通过验收测试，若职责混杂、抽象过度或难以修改，仍会给后续维护增加成本。

Marcano 用拼写检查作比：过去需要先写完整份文档，再交给 SpellStar 集中检查；后来文字处理软件能在输入时标出拼写问题，有些错误还会被自动修正。变化不只是“最终检查快了一点”，而是检查发生的位置变了。

软件开发也可以从“做完再提 PR、集中审查、发现问题后返工”，转向“小步实现、即时审查、及时修正，再继续推进”。问题刚出现时，相关决策还记得清楚，团队更容易说明实现缘由并调整设计。这与左移测试（Shift-Left Testing）的思路一致：把质量活动放到问题和决策发生的地方，不要都留到交付末端。

规格、验收与代码设计各有职责

规格驱动开发（Spec-Driven Development，SDD）、行为驱动开发（Behavior-Driven Development，BDD）和测试驱动开发（Test-Driven Development，TDD）可以配合使用，各自回答不同问题。项目级工程宪章、架构原则和编码规范告诉智能体“实现时必须遵守什么”；规格、行为场景和验收测试说明“要实现什么”；持续的代码审查则检查“实现是否清楚、合理并且便于长期维护”。

因此，详细规格不是代码质量审查的替代品。业务意图写得再清楚，也不能自动保证代码结构合适。反过来，代码风格统一也不能证明产品行为符合需求。

Marcano 讨论的从外向内 TDD（Outside-in TDD）用两个循环把这些问题连起来：

  • 外层从业务场景开始，把用户或业务行为写成可执行的验收测试；实现通过后，再根据获得的新知识细化下一个场景。
  • 内层遵循“红—绿—重构”（Red–Green–Refactor）：先写一个会失败的测试，再用最少代码让它通过，然后在测试保护下重构，并持续检查实现设计。

外层帮助团队确认“做的是不是需要的事”，内层则让设计反馈伴随实现发生。TDD 在这里不仅是写测试的方法，也是一种小步设计和审查机制；它不是唯一选择，但能说明质量审查无需等到 PR 才开始。

结对协作让审查自然发生

在乒乓结对编程（Ping-Pong Pair Programming）中，一位开发者先写失败测试，另一位实现最小的通过方案；随后两人一起重构，并交换角色。也可以由编码者（Driver）负责输入，观察者（Navigator）检查代码、提出问题并参与设计判断，再轮换工作。

它带来的质量收益不只是多了一双眼睛。审查发生在代码刚产生时，参与者能看到设计选择形成的过程；抽象、职责边界和测试意图可以当场讨论；轮换伙伴也会让知识和判断方法在团队中流动。PR 审查者往往只看到最终差异，未必能还原实现时的约束与取舍。

Marcano 分享过，他所在的高绩效团队曾通过这类协作让 PR 阶段的阻塞式审查变得多余。这是特定团队的经验，并不意味着所有组织都应取消 PR。团队成员分布、监管要求、变更风险、协作习惯和现有反馈质量都会影响是否适合这样做。

智能体审查的粒度仍是开放问题

现在可以让审查智能体在实现任务结束后检查规格和代码质量，也可以尝试对抗式审查，让不同智能体分别找问题、质疑对方的结论。例如，Superpowers 的子智能体驱动开发流程，就把规格符合性检查和代码质量检查安排为不同的审查步骤。至于每次应该审查多大一段改动，目前还没有通用答案。

审查时机可能的好处需要留意的代价
每个“红—绿”循环反馈最及时，问题范围小调用频繁，单次上下文可能不足
每个业务场景容易把审查结论关联到用户行为场景内部的设计问题可能被漏掉
每个实现任务较容易接入现有智能体工作流任务过大时，反馈仍会来得太晚
每次提交（Commit）便于回溯代码变化和审查记录提交大小和内容不一定稳定
每个 PR与现有协作流程兼容，方便整体讨论反馈较晚，修改成本可能更高

这张表是本文对原文问题的实践整理，不代表已有比较试验证明哪种方式更好。团队可以从影响面小、风险可控的改动开始，观察反馈速度、审查质量和投入，再决定是否调整。

审查智能体数量增加，不代表判断就更独立。若编码者和审查者共享同一错误假设、资料缺口或模型盲点，它们可能一起漏掉同一个问题。评估时可以检查：审查是否有独立依据？结论是否指向具体代码、测试或规则？发现能否复现？意见冲突时由谁裁决？共同遗漏又如何被发现？

自动化审查不新鲜，难点在上下文判断

静态分析早已承担部分自动化代码审查工作：复杂度、重复代码、无用代码和编码规则都能交给工具检查，也可以设为合并门槛。更难验证的是，AI 能否结合项目背景，稳定判断抽象是否必要、职责边界是否清楚，以及测试通过后是否仍存在长期维护成本。

因此，不能用审查评论的数量代表质量。更有意义的是看发现是否真实、重要、可操作，也要看它漏掉了什么。大量无关提醒会消耗开发者注意力；一句流畅的解释也不自动构成有效证据。

已发布，不等于已完成（Shipped ≠ Done）

Marcano 还把两个经常被 PR 合并门禁混在一起的判断拆开了：

判断要回答的问题常见依据
可以安全发布（Safe to Ship）当前变更是否满足发布条件？自动化测试、静态检查、安全控制和部署保障
真正完成（Done）代码是否达到团队认可的长期维护标准？持续审查、设计反思、重构和团队共识

Marcano 描述的团队采用主干开发（Trunk-Based Development，原文描述为不使用分支）和持续集成、持续部署（CI/CD）；约定的自动化检查通过后，代码可以在几分钟内进入生产环境，团队再继续改进设计。作者用一句话概括这种节奏：“Ship, ship, ship, done.”发布可以早于长期维护工作的全部结束，但质量责任不会随发布消失。

有些团队会用反向拉取请求（Reverse Pull-Requests）保留 PR 的讨论、知识共享和反馈价值，同时不再让它阻塞发布。改变的是审查与发布的先后顺序，不是放弃代码审查。

这里有清楚的边界：安全、合规、数据完整性或不可逆操作不能简单地留到发布后处理。Marcano 也指出，在监管严格或运行风险高的环境里，人工批准可能仍是必要控制。任何“先发布、后审查”的做法，都必须与业务风险、恢复能力和组织义务相匹配。

研究数字说明了限制，不是通用审批率

Marcano 引用的 SWR-Bench 研究基于 1,000 个真实 GitHub PR。在一项使用 Gemini 2.5 Pro 的 PR-Review 评估中，对于只需一项修改的 PR，模型检出相关修改的比例为 38.35%；对于需要五项或更多修改的 PR，这一比例为 8.88%，但该组只有 22 个 PR。

Marcano 还提到一项 2026 年的短程序编写基准研究：在简单提示下，部分模型会错误拒绝约 25% 至 75% 的正确实现。这个范围只描述该研究所测的模型和任务，不是所有代码审查工具的普遍错误率。

这组结果能说明的范围有限。发现问题不等于可以安全批准，小样本不能代表所有代码库和风险，误报与漏报都会影响效率和交付安全。不同研究所用的任务、指标和样本也不相同。Faros AI、GitClear、CodeRabbit、SlopCodeBench v2、对抗式审查（Adversarial Review）和 CodeAgent 提供了不同角度的资料，不能把它们的结论混成一句“AI 代码都更差”。

用团队自己的数据决定人工审查是否退出

Marcano 的判断标准不是“AI 评论写得像不像资深工程师”，而是它能否可靠地发现团队真正关心的问题。只要人工审查仍能找到智能体遗漏的重要问题，就应该保留这部分人工投入，并把发现反馈给编码规则、自动化检查或智能体工作流。

反过来，连续出现“人工没有评论就通过”的记录，也不足以证明人工审查没有价值。审查者可能走过场；样本可能风险较低；问题也可能尚未在生产环境暴露。需要把审查记录和后续结果放在一起看。

实践延伸：团队可以先观察以下指标。

指标用途
人工独有发现率（Human Unique Finding Rate）统计人工发现且确认重要的问题
AI 审查召回率（AI Review Recall）评估 AI 对已知重要问题的检出能力
AI 审查精确率（AI Review Precision）观察 AI 提出的意见中有多少有效
逃逸缺陷率（Escaped Defect Rate）追踪发布后的缺陷变化
审查返工成本（Review Rework Cost）估算审查与修改带来的投入
可维护性趋势（Maintainability Trend）观察复杂度、重复代码和技术债的变化
审查反馈延迟（Review Feedback Latency）衡量从问题引入到收到反馈的时间

例如，人工独有发现率可以定义为“人工独有且确认重要的问题数 ÷ 人工审查的变更数”。解读时还要考虑风险、抽样方式和审查质量，不能只凭这个数值撤掉人工把关。

可以按风险逐步试行：先让 AI 和人工同时审查，记录漏检、误报及人工独有发现；再把重复出现的问题转成明确规则或测试。之后选择可回滚、监控完善的低风险改动试点自动放行，对比发布后的缺陷、安全、运维、返工和维护情况，最后再按风险调整人工审查的位置和力度。若把“自动审批 90%”当成不分风险的单一指标，团队可能只优化了数字，却看不清实际质量。

把评审纳入 AI 原生质量工程的持续循环

以下是基于原文观点的工程实践延伸，不是 Marcano 在原文中提出的框架。 如果 PR 不再是唯一的质量判断点，团队需要让证据贯穿需求、实现、发布和运行后的复盘。例如：需求与验收标准先被检查，智能体按小步实现；另一个审查角色检查代码并运行测试；发现问题后修复、重构、留下可核对的证据；通过自动化门禁后发布，再观察线上表现并回顾结果。

这会让质量工程师的工作不再只是在最后检查变更，还包括实现前检查需求和验收标准、确认测试是否覆盖真实业务行为、审查小步实现、核验结论的依据、评估发布准备度，以及追踪发布后的缺陷和维护问题。

其中尤其需要重视证据核验。智能体说“质量看起来不错”，与它明确说明检查了哪些文件、发现位于何处、执行了哪些测试、哪些风险没有验证，是完全不同的结果。评审者需要看到依据，而不只是结论。

如果智能体反复漏掉同一类问题，处理方式也不应只是要求它“下次仔细一点”。更有效的闭环是：发现问题、提供证据、修正实现、再次验证、记录结果，再据此改进规则、测试或审查触发时机。

还有几个问题没有标准答案

  • 最合适的审查粒度是每个 TDD 循环、业务场景、实现任务、Commit，还是 PR？
  • 如何证明审查智能体确实找到了问题，而不是生成了看似合理的说明？
  • 如何识别编码智能体和审查智能体共同依赖的错误假设？
  • 什么样的团队证据、风险边界和恢复机制，足以支持移除人工 PR 合并门禁？
  • 如果 PR 不再是质量决策的中心，测试、审查和设计决定应沉淀在哪里，才能继续追溯？

这些问题没有适用于所有团队的统一答案。它们指向的也不只是一个审批按钮：团队还得决定何时触发反馈、怎样记录证据，以及由谁承担剩余风险。

结语：让质量反馈早一点发生

Marcano 既没有说 PR 已经过时，也没有断言 AI 永远不能审代码。他质疑的是把 PR 当成唯一审查时机、把自动审批比例当成目标的做法。团队可以把评审前移，按小增量持续检查，用自己的数据比较 AI 和人工分别发现了什么，并分开判断“能否发布”与“维护工作是否完成”。

落到实践上，就是把评审前移、按小增量持续审查、用证据支撑结论，并把“可以发布”和“已经完成”分开判断。

与其追求 AI 自动审批 90% 的 PR，不如让质量审查贯穿每个实现增量，再用可验证的团队证据决定哪些人工审查可以安全退出。

参考资料

代码审查员安全测试白盒测试背靠背测试本地化测试
分享