# 审 Review 本身：贯穿双 Loop，方式归团队共识

瓶颈搬家

AI 让写代码变快了。Google Cloud Office of the CTO 的观察很直白：生产侧瓶颈被消掉之后，约束转移到了 Review 与集成——巨大的 PR、互相卡住的依赖链、以及越点越麻木的 approval fatigue。

更快的模型解决不了这件事。约束已经不在「能不能生成」，而在「谁来证明可以合入，以及用什么方式证明」。

对团队来说，这不是多加人肉 Reviewer 能填上的坑。人读 diff 有天花板；AI 产出的体积很容易把天花板打穿。继续用「人审每一行产物」的旧假设，只会同时损失速度与质量。

主旨：人审的是 Review，不是每一份产物

站内已经讨论过 HITL / HOTL / HOOL：监督应按风险路由，而不是全程挡在每一步前面。Addy Osmani 把同一条线推得更远——Inner Loop（调查、实现、部分验证）可以托管给脚本与 Agent；人应守 Outer Loop：约束、抽样、审计、问责。

这里容易误会：Review 并不等于 Outer Loop。 Review 是端到端的——Inner Loop 里同样可以、也应该有自动化 Review。例如一次 Apply / 一次文件写入 / 一轮自测之后，立刻跑 lint、测试、独立 AI Evaluator，把关在环内完成，不必把每一次检查都升成人类门禁。

更准确的分工是：

层级	Review 做什么	谁来做
Inner Loop	动作完成后的自动验证：脚本门禁、AI 对照 Spec/风险扫描、失败即重试	脚本 + AI（可托管）
Outer Loop	约定「怎么审」：路由、阈值、抽样、审计、问责；审 Review 方式是否失真并纠偏	团队共识（岗位可模糊，团队要清楚）

AI4SE 里岗位边界会继续模糊，但团队是清楚的。Outer Loop 不是某个头衔的私有职责，而是团队对「用什么方式证明可以合入」的共同约定——不是说所有 Review 动作都只能发生在 Outer。

落到 Review，结论是：

可重复、可判定的 Review，优先沉到 Inner Loop，交给脚本与 AI；团队在 Outer Loop 主要审的是「这些 Review 方式本身对不对」。不对，就一起改门禁、改规则、改 Evaluator——而不是靠某个人把大 diff 再读一遍。

这和 问责永远在人 不矛盾：最终签字与事故责任仍在人；变的是人把注意力花在哪一层。Osmani 提醒过：同族模型互相点赞，常常只是 borrowed confidence——闭环很自信，并不等于有人真正理解了风险。

对象变宽：从 Code 到 Artifacts

古法编程里，团队说 Review，第一反应多半是 Code Review。AI4SE / SDD 下，Review 面明显变宽。

以 OpenSpec 一类流程为例：一次 Change 对应 proposal、specs、design、tasks 等产物——多数由 AI 起草。精益做法是：Spec Ready 之前就审，而不是等几千行代码落盘后再猜意图。代码合入主干前仍要审；同时，端到端里的 User Harness（规则、技能、目录约定、权限边界）本身也是可漂移的产物，同样需要 Review。

这与站内 规格成为真相源 一致：当代码大量由 Agent 生成时，人类可读、可对照的锚点上移到 Spec。Bryan Finster 的表述更锋利——若 Review 才是第一次发现「实现是否正确」，说明质量过程从未真正前移；AI 只是把崩溃提前放大了。

Review 对象	团队更该一起关心的问题
Proposal / Spec / Design / Tasks	意图、范围、非目标是否清楚？能否当验收锚点？
代码 Diff / PR	是否对照 Spec？体积是否还可审？证据（测试/风险）是否齐全？
User Harness	Guides/Sensors 是否过时、互相冲突、或被 Agent 绕过？

详见 Harness Engineering。

时机变多：Review 贯穿端到端

Review 不是某一个阶段、某一个岗位的工作，而是端到端上的一组门禁：

1. Spec Ready 之后 — 同意「建什么」，再让 Agent Apply
2. Apply 之后、合入之前 — 对照 Spec 做规格验收 + 质量扫描 + 人类判断（见 Review Pipeline）
3. 过程中的熵管理 — context 漂移、规则膨胀、技能失效、目录腐化时，同样要 Review 并回写 Harness

时机变多，并不等于人要出现更多次。恰恰相反：时机越多，越要把确定性检查沉进 Inner Loop 的自动化，把人在 Outer Loop 的出场留给高 blast-radius 决策与方式纠偏。

方式分层：脚本 → AI → 人

与过去相同的是「自动化 + 人工」；不同的是自动化里多了一层 AI Review，并且顺序应刻意设计为：

确定性规则 / 脚本  →  独立 AI Evaluator  →  人的高杠杆判断
         ↑ Inner Loop 可托管 ↑                    ↑ Outer 抽样 / 签字 ↑

• 脚本优先（常在 Inner）：命名、格式、依赖策略、禁止调用、测试必须绿、PR 必须挂 Spec 链接——这些是人类沉淀的经验逻辑，应尽量脚本化。写脚本本身也可以交给 coding agent，但 规则与阈值仍由团队在 Outer 定义。
• AI 次之（也常在 Inner）：架构气味、Spec 对照摘要、风险面扫描、缺失测试提示。它适合处理「可推理但难写死」的检查，可在动作完成后自动跑，不必等人来点开。
• 人最后（偏 Outer）：这是不是该做的变更？取舍是否可接受？有没有「谁都没写进 Spec」的缺口？合入问责能否签字？以及对 Inner 自动化 Review 的抽样审计。

独立 Evaluator 不是可选项。同一 Generator 换一句 prompt 自评，等于没有第二视角——见 Planner / Generator / Evaluator。

站内 Review Pipeline 讲的是 PR 上的三步做法；本文强调的是团队视角：要一起审的是这三层有没有配错、有没有失效——尤其是 Inner 自动 Review 是否还可信。

Outer Loop 要守的：审什么，不对怎么办

审什么（Review 方式本身）

信号	可能失真
AI Review 长期「全绿」或与线上事故无关	漏报；提示词/规则过宽或未覆盖真实失败模式
人仍在刷风格注释、重复同一类意见	本该脚本化的经验还堵在人工队列
门禁很多，但高风险项也被秒批	approval fatigue；路由未按风险分层
Generator 与 Evaluator 同源、同会话	自评偏差；borrowed confidence
Spec 门禁形同虚设，大 diff 直接进 PR	对象/时机设计失败，人被迫回到逐行读码
Harness 只增不减，Agent 行为越来越飘	熵未管理；Sensors 未反馈到 Guides

不对怎么办（纠偏动作）

1. 改路由 — 低风险 → HOOL/HOTL；不可逆与合规 → HITL；减少无意义的微批准。
2. 补 Spec / 场景 — 把反复漏掉的边界写进规格或验收场景，让后续脚本与 AI 有锚点。
3. 拆体积与证据 — 强制小批量；PR 附带 Spec 链接、风险说明、测试证据，而不是裸 diff。
4. 换独立 Evaluator — 不同角色、不同模型族或至少不同系统约束；禁止「自己给自己 LGTM」。
5. 失败即提炼 — 每次人工抓住的确定性模式，沉淀为脚本、CI 规则或技能；让人少审一次同类问题。
6. 抽样审计 — 团队不审每一个产物，但共有一套抽样约定：高风险路径全检，低风险路径抽检 Inner 自动 Review 的结论，并回溯「自动化本该拦住却没拦住」的案例。

一句话：Inner 可以自动 Review；Outer 审的是这些自动 Review 的方式对不对。方法不对，就修系统，而不是加人肉。

反模式与最小行动

反模式

• 同一个 Agent 既生成又评审，还叫「自动化过关」
• 把 Review 理解成「只能发生在 Outer」——Inner 不做自动验证，所有检查都堆给人类
• 人仍以逐行读大 diff 为荣，把本该 Outer 的方式治理丢回 Inner 的人肉扫码
• 只挂一个 AI review bot，不改门禁、不改 PR 契约、不改 Evaluator 独立性
• User Harness 从不 Review，规则与技能只增不治理
• 用「测试绿了」替代「这是不是该建的东西」
• 把 Outer Loop 默认甩给某一个头衔，团队其余人只点 Approve

本周可做的三件事

1. 盘点团队真正生效的 Review 门禁：哪些在 Inner 自动跑，哪些在 Outer 需要人签；标出哪一层在扛不该扛的重量
2. 指定独立于 Generator 的 Evaluator（人、Agent 或二者组合），并写清它对照什么验收——作为团队共识，而不是个人偏好
3. 建一条短反馈环：线上或评审漏网 → 归类 → 改脚本/规则/Spec（回写 Inner）→ 下周抽检是否复发

生成还会更快。团队的杠杆不在读完每一份 AI 产物，而在让端到端的 Review 系统本身越审越准——Inner 负责跑得勤，Outer 负责定得对；并且这要成为共识，而不是某个角色的独角戏。