第25章：autoreview —— 围绕代码质量构建系统性工具

"autoreview is the most impactful skill I've added to my skill stack after crabbox.sh. It auto-reviews your code before PRs. Found so many edge cases. Sometimes it runs for hours."

autoreview 是我添加到技能组合中最具影响力的技能，仅次于 crabbox.sh。它在 PR 之前自动审查你的代码。发现了很多边界情况。有时它会运行数小时。

—— Peter Steinberger, 2026 年 5 月

第 12 章认识了 Peter Steinberger，OpenClaw 的作者，他那句「You shouldn't be prompting coding agents anymore」48 小时内两百万浏览，把 Loop Engineering 推到台前。第 16 章讲了 Addy Osmani 的 agent-skills，把工程纪律从人的自觉变成了 Agent 的结构化约束——反合理化表、验证门禁、七阶段生命周期。两章合起来回答了三个问题：Agent 该走什么流程（纪律），Agent 怎么自己跑（循环），Agent 怎么沉淀知识（复利）。

但还有一个问题没回答。代码写完之后，提交之前，谁来保证质量？

第 8 章的 goal-workflow 引入了 /review-it 技能，提交前做代码 review 和修复，第 16 章的 /review 也管这件事。但那都是代码写完了、要合并时的门禁。Steinberger 的想法更激进：不等代码写完再审，把审查做成一个自动运行的 skill，代码改了就跑，该修就修，修完再跑，直到整洁。他叫它 autoreview。

本章专讲 autoreview。它是什么、怎么设计的、为什么有时候能跑上好几天、以及它怎么和其它章节的方法论对接。

25.1 一个人和他的工具箱

第 12 章聊过 Steinberger，知道他是 OpenClaw 的作者，知道他提了 Loop Engineering。但如果你以为他只是个做平台工具的，那就漏掉了最重要的东西——他的 Agent 工具不是玩具项目里实验出来的，是从一个真实、复杂、多平台的产品里逼出来的。

第 12 章拆过他的 Loop 方法论：「每次你发现自己为 Agent 做重复的观察、判断、路由或验证，就建一个工具把那个活交给 Agent。把自己从反馈路径中移除。」agent-skills 仓库（openclaw/agent-skills）就是这套方法论的公版——六个 skill：agent-transcript（会话记录）、autoreview（自动审查）、behavior-validator（行为验证）、crabbox（远程沙箱）、handoff（Agent 交接协议）、session-viewer（会话浏览器）。Steinberger 自己说过两遍，最影响他工作的只有两个——crabbox 和 autoreview。

这一章专注讲 autoreview。

25.2 autoreview 解决什么问题

先把问题说清楚。

Agent 写的代码要审查。这事谁都知道。但有三件事让人工审查在 AI 时代越来越不靠谱。

一是量。Agent 几分钟吐几千行，人工审查的速度跟不上，审查员在第 50 个 diff 之后开始跳着读。跳过的刚好是 bug 藏着的地方。

二是盲区。Agent 擅长写代码，不擅长发现自己的 bug。你让它审自己的代码，它大概率说「看起来没问题」。不是偷懒，是概率。训练数据里审代码的场景远比写代码少，审出问题的场景又远比审出没问题的场景少。输出分布天然指向「过」。

三是无聊。代码审查是人最容易偷懒的工程活动——不是不负责任，是大脑在重复读 diff 的时候自然会走神。走神的时候，那个 != 写成 == 的 bug 就从眼下溜过去了。

Steinberger 的解法不是让 Agent 变得更聪明。是建一个 skill，把它变成一个绕不过去的关口——代码改了，autoreview 就跑，发现问题就修，修完再跑，直到整洁。人最后看一眼报告就够了。

这个思路和第 16 章的 agent-skills 是同一个思路。agent-skills 的 /review 是质量的门神，覆盖正确性、安全、性能、可维护性、代码风格五个维度。autoreview 相当于在门神前面再加一道关——用一个独立模型跑审查，多一层保障。

25.3 四个设计原则

autoreview 的 SKILL.md 有三百多行，但核心的设计决策就四个。理解这四个原则，剩下的都是细节。

25.3.1 审查是收尾关卡，不是审批系统

第一条原则直接写在 SKILL.md 最前面：「This is code review, not Guardian auto_review approval routing.」

Guardian 是 OpenClaw 的审批系统，在 CI 里跑，决定一个 PR 能不能合。autoreview 不是那个东西。它不决定能不能合，它只发现问题、报告问题。修不修看人。

但最终决定权在人，不是说 Agent 没有自主权。autoreview 的合约里写得很清楚：找到问题之后，Agent 可以自己修，但要遵守一堆护栏——读实际代码路径验证、拒绝不切实际的边缘情况、小修优先、同类 bug 批量修、修完重测重跑。修到你接受不了的时候，它会停，等你的决定。

这和第 12 章 Loop Engineering 的 maker-checker 分离是一个逻辑。Loop 里 maker 写代码，checker 验证；autoreview 里 Agent 写代码，另一个模型审查。审查结果驱动修补循环，但最终判断权在人。

25.3.2 Scope Governor：审的是这个 PR，不是整个项目

autoreview 最特别的设计是 Scope Governor——范围控制。这个概念在别的地方找不到。

逻辑很简单：autoreview 是收尾关卡，不是重写一切的许可证。审查之前，先锁定一个范围基线：原始需求、目标分支、预期行为、归属边界（谁拥有这段代码、谁为它负责）、改动文件、非测试代码行数。审查回来后，把每条发现分三类：

• In-scope blocker（范围内阻断）：当前 diff 引入的问题，在同一归属边界内，修它不改变任务的契约。
• Follow-up（跟进）：真实问题，但属于相邻 bug 类、关联模块、或更广的加固工作。
• Stop-and-escalate（停，上报）：需要新协议、新配置、新存储、新公共 API、不同归属边界、发布流程变更、或超出原始需求的设计选择。

第三条最狠。审查模型可能会发现一个设计问题——这个类的职责太重了，应该拆。Agent 看了，觉得有道理，开始拆。拆到一半发现需要改公共 API，又去改 API。改 API 发现需要改配置文件，又去改配置。等回过神来，三个小时过去了，一个原本 50 行的 PR 长成了 800 行。Agent 特别爱干这种事。

Scope Governor 就是堵这个洞。它不是建议你不要扩大范围，它是强制你停。五条停止条件，触发任何一条就停：

• 本来是个小改动，变成了架构变更、协议变更、数据迁移、或者发布流程改动；
• diff 的文件数或非测试行数翻了一倍以上，且没拿到明确的范围扩大许可；
• 两轮修复审查之后还没收敛——停，重新分类每条剩余发现；
• 最佳修复是「先定规范契约」而不是「再加一层本地推断」；
• 修了当前的发现会让 PR 不再描述同一个行为、问题、归属边界。

这和第 16 章 agent-skills 的反合理化表是同一个思路——Agent 会自我说服「顺便重构一下没关系」，Scope Governor 提前写好反驳：有关系，停。

25.3.3 多引擎审查：一个人的审查委员会

autoreview 不只支持一个模型，它支持七个引擎：Codex（默认，gpt-5.5）、Claude（claude-fable-5）、Pi、Droid、Copilot、Cursor、OpenCode。

单引擎：

"$AUTOREVIEW" --engine claude --model claude-fable-5 --thinking max

面板（Codex 加 Claude 双审）：

"$AUTOREVIEW" --panel

自定义评审团：

"$AUTOREVIEW" --reviewers codex,claude,pi

全部七个引擎一起上：

"$AUTOREVIEW" --reviewers all

这里真正的权衡不是引擎越多越好，而是三个现实问题。

一是花费。七个引擎全上，每个跑几分钟到几十分钟，token 成本成倍上涨。Steinberger 在 SKILL.md 里写了：「Multi-reviewer panels are opt-in only. Use them when explicitly requested or when risk justifies the extra spend.」

二是信噪比。不同引擎的长处短处不一样。Codex 默认用 GPT-5.5，结构化审查上表现最好，Claude 在理解上下文和设计意图上更强。多引擎面板不是投票制，引擎各说各的，人来看哪些问题大家共同发现、哪些是某一家独有的，自己判断。

三是可用性。模型有时排不上队。SKILL.md 里特别写了，不要把模型容量爆了当理由去切引擎。重试同一条命令，别换模型。

25.3.4 引擎隔离：被审的仓库不能污染审查者

搞 CI 的人都懂，你要审查一个 PR，不能让那个 PR 里的配置文件影响到你的审查工具本身。autoreview 把这个逻辑用到了模型引擎上——你用 Codex 审查当前仓库的代码，不能让仓库里的 .codex/ 目录、AGENTS.md 文件、CLAUDE.md 指令污染 Codex 的运行环境。

autoreview 对每个引擎都配了一套隔离参数：

这套设计和第 24 章 /modern-go 的「读 go.mod、绝不越级」是同一种思路：Agent 容易被环境带偏，那就把环境隔离掉。审查者必须只看代码，不看被审仓库的 Agent 配置文件。

25.4 工作流：从本地到 PR 到发布分支

25.4.1 日常开发：commit 之前

最常见的场景是本地改完了，提交之前跑一下。三种模式：

本地未提交的改动：

"$AUTOREVIEW" --mode local

指定 commit：

"$AUTOREVIEW" --mode commit --commit HEAD

分支 diff：

"$AUTOREVIEW" --mode branch --base origin/main

最简单的做法是把 autoreview 和测试塞进并行收尾：

"$AUTOREVIEW" --parallel-tests "go test ./..."

测试和审查同时跑，哪个先结束都不耽误另一个。唯一要注意的是，如果审查触发了修改，测试要重新跑一遍——代码变了，上一次的测试结果不可信。

25.4.2 发布分支的特别规矩

autoreview 在发布分支上有自己的一套规矩，比普通分支严得多。

发布、beta、stable、hotfix、签名、notarization、appcast——只要沾发布的边，autoreview 就切到冻结模式。不是检查更严了，是允许修的更窄了：

• 只修发布阻断项：崩溃、数据丢失、安装/升级失败、确认的安全漏洞。
• 不引入新行为、新配置、新协议、新迁移、新文档内容。
• 非阻断的审查发现一律归为 follow-up，留给 main 分支。
• 审查发现了一个真实但不是阻断的设计问题？不是修，是开 issue/PR 留给 main。

发布分支的原则不是零问题，是零不该有的改动——发布时间窗里碰什么都可能连锁反应，一处改动就能引发跨模块故障。

这和第 10 章 Harness Engineering 的安全门禁同一个思路：关键路径上的自动步骤不是辅助，是护栏。

25.4.3「有时会运行数小时」

Steinberger 那条推文里最引人注意的一句是「Sometimes it runs for hours.」有人觉得是 bug，他觉得是 feature。

到底为什么？不是审查慢。是审查发现 bug → 修复 → 修复引入新的上下文 → 重新审查。这个循环可能转好几轮。每一轮都是真实的模型调用，大量上下文，结构化输出验证。SKILL.md 里写了，一次结构化审查最多可以跑 30 分钟。

而且 autoreview 不允许你因为「等太久了」就杀掉进程。它专门写了一条：不要因为跑了两到五分钟没动静就杀掉审查。心跳行 review still running: ... elapsed=... pid=... 就是健康的。只有心跳停了好几个周期、过了 30 分钟、或者子进程明确挂了，才该检查。

这个设计和第 16 章 agent-skills 的 doubt-driven development 类似：好的审查需要时间，不能催。Agent 偏向速战速决，这种机制逼它慢下来，让深度推理发生。

25.5 上下文效率：别让审查吃两次 token

autoreview 有一个容易忽略但实用的细节：上下文效率。

它的设计原则是「跑一次，拿结果，汇总」。不是「先跑 Codex，Codex 说这块有问题，再拿这块去问 Claude，Claude 说……」，一层一层套。那套做法的 token 成本是指数级的。autoreview 是：一个 helper 脚本，选择 target、选择 engine、构建一个大 bundle、跑一次结构化审查、出结构化结果。输出吵的话就汇总，不要重跑。

审查模型可以自己用工具——读文件、查上游文档、web search——但这些工具在审查者手里是读的，不是写的。SKILL.md 明确禁止嵌套审查：「Do not invoke built-in codex review, nested reviewers, or reviewer panels from inside the review.」审查者不能自己再调审查者，不然就无穷递归了。

这条和第 14 章 improve 的 STOP 条件同宗——不让 Agent 做链式自我审查。链式自我审查的熵跑得比人发现得早，三圈下来就算没引入 bug，上下文已经被审查本身的噪声填满了。

25.6 最终报告：证明整洁（clean），不是声称整洁

autoreview 跑完之后的最终报告有自己的规矩：

• 列出跑过的审查命令
• 列出跑过的测试和证明
• 每条接受的发现和拒绝的发现，用一句话写为什么接受或拒绝
• 最后一次 helper 跑的整洁结果——autoreview clean: no accepted/actionable findings reported

最后一条最硬。autoreview 不准你在报告里造假——你不能为了报告好看再跑一次审查。最后一次 helper 跑完，退出码是零，没有可操作的发现，才算整洁。退出码不是零，别写整洁两个字。

25.7 本章小结

autoreview 把资深工程师最机械、最疲劳的工作——代码审查——做成了一条不可绕过的收尾关卡。四个设计原则——收尾关卡而非审批系统、Scope Governor 控制范围、多引擎冗余审查、引擎隔离防污染——定义了 AI 时代的代码评审应该怎么做。

Scope Governor 是本章最值得带走的概念。它回答的问题不是「这段代码有什么问题」，而是「这个 PR 的边界在哪里」。它把 AI 最容易犯的「看了问题就顺手重构一大片」制度化地堵住。它和第 16 章反合理化表的哲学一致：不是让 Agent 更聪明，是让 Agent 无法绕过最该守住的线。

「有时运行数小时」不是 bug。好审查需要时间，修复→审查→修复的循环是质量保障的成本，不是浪费。

上一章用 Go 专属技能把代码写地道、写安全、写快。这一章用 autoreview 在 submit 之前兜住最后一层质量。