代码提交前的最后一道防线
代码提交前的最后一道防线
不是所有AI代码都能直接提交，先过autoreview这关。
痛点
AI写了1000行代码，看起来能用。
直接commit？
等等。
- 有没有安全漏洞？
- 有没有边界情况没处理？
- 有没有破坏架构原则？
- 有没有引入新的技术债？
人工review太慢，不review又怕出问题。
autoreview 是什么
OpenClaw生态的一个代码审查Skill——
在commit/ship前，自动运行多个AI引擎对代码进行结构化审查。
核心能力
- 🔍 多引擎审查 — Codex（默认）、Claude、Pi、Droid、Copilot、Cursor、OpenCode
- 🎯 多种模式 — 本地未提交代码、分支diff、单个commit
- ⚡ 并行收尾 — 同时跑测试和审查
- 🛡️ 范围控制 — 防止审查触发scope creep
- 📦 面板模式 — 多个reviewer同时审查
多引擎审查
不绑定单一AI，你想用谁就用谁：
# Codex（默认，用gpt-5.5）"
"$AUTOREVIEW" --mode local
# Claude
"$AUTOREVIEW" --engine claude --model claude-fable-5
# 多引擎面板
"$AUTOREVIEW" --reviewers codex,claude,pi,opencode为什么多引擎？
不同AI有不同视角：
- Codex — OpenAI的GPT-5.5，审查质量通常最好
- Claude — Anthropic的claude-fable-5，安全视角强
- Pi — 轻量级选项
- OpenCode — 代码专用模型
多个AI同时看，交叉验证，漏检概率更低。
三种审查模式
本地未提交代码
"$AUTOREVIEW" --mode local审查当前工作区的unstaged/staged/untracked改动。
分支diff
"$AUTOREVIEW" --mode branch --base origin/main审查feature branch相对于main的改动。
如果是PR，自动用PR的真实base：
base=$(gh pr view --json baseRefName --jq .baseRefName)
"$AUTOREVIEW" --mode branch --base "origin/$base"单个commit
"$AUTOREVIEW" --mode commit --commit HEAD审查已经提交的改动（比如main上的某个commit）。
并行收尾
格式化代码 → 同时跑测试和审查：
"$AUTOREVIEW" --parallel-tests "<focused test command>"为什么这样设计？
- 格式化会改变行号，必须先跑
- 测试和审查互不依赖，可以并行
- 节省时间
如果测试或审查发现bug？
修复后重新跑两者，直到都没有actionable findings。
审查面板（Review Panels）
高风险改动？让多个AI同时看：
"$AUTOREVIEW" --reviewers codex,claude,pi,opencode或简化版：
"$AUTOREVIEW" --panel # Codex + Claude每个reviewer可以设置不同的模型和思考级别：
"$AUTOREVIEW" --reviewers codex,claude \
--model codex=gpt-5.5 --thinking codex=high \
--model claude=claude-fable-5 --thinking claude=max注意： 多面板是opt-in，不是默认。因为多reviewer=更多钱，只在风险值得时用。
范围控制器（Scope Governor）
autoreview是收尾关口，不是重构许可证。
冻结基线
第一次审查前，冻结范围：
- 原始请求或issue
- 目标分支
- 预期行为
- 责任边界
- 改动的文件
- 非测试代码行数
分类发现
审查发现的问题，三类：
- In-scope blocker — 当前diff引入的，影响同一责任边界，能在不改任务契约的情况下修复 → 修
- Follow-up — 真实问题，但属于相邻bug类、兄弟表面、清理或更广的硬化track → 不修，开follow-up
- Stop-and-escalate — 需要新协议/配置/存储/公共API契约、不同责任边界、发布流程变更、原请求外的设计决策 → 停手，上报
何时停手
审查触发修复变成架构变更？
停手。
PR变成migration？
停手。
Diff超过原始文件/代码行数的2倍？
停手。
核心原则： 审查是为了把关当前改动，不是启动新项目。
发布分支纪律
release/beta/stable/hotfix/signing/notarization/appcast/package-publish/release-check分支：
- 只修 release blocker、失败的发布基础设施、精确backport、安装/升级breakage、数据丢失、崩溃、具体安全暴露
- 非blocker的autoreview发现 → 作为main的follow-up，不是扩大release分支的理由
- 不引入 新的产品行为、配置表面、协议形状、migration、插件所有权、文档叙述、流程策略——除非直接unblock发布
如果在发布closeout中发现真实但非关键的设计问题？
停手，开follow-up issue/PR计划。
别用release分支当refactor车道。
使用契约
autoreview有严格的使用规则，摘几条关键的：
对审查输出
- 把审查输出当作建议 — 永远不要盲目应用
- 验证每个发现 — 读真实代码路径和相邻文件
- 读依赖文档/源码/类型 — 当发现依赖外部行为时
- 拒绝 不现实的edge case、投机风险、大范围重写、让代码库过度复杂的修复
对修复
- 优先在正确的责任边界做小修复 — 除非明显改进bug类，否则不refactor
- 当发现显示bug类或重复模式时，检查当前PR范围是否有兄弟实例 — 修复前
- 一次修复有范围的bug类 — 停在接触的表面、责任边界、清晰的follow-up territory
什么时候停
- 当结构化审查返回没有accepted/actionable findings时 — 只要在原始任务范围内
- 当审查触发的修复改了代码 — 重新跑focused tests和结构化审查helper
- 一旦rerun干净退出 — 停止；别花另一个长审查周期做冗余确认
对安全
- 安全视角总是包含 — 但不应破坏合法功能
- 只在变更创造具体的、可操作的风险或移除重要安全检查时报告安全发现
一行命令安装
npx skills add https://github.com/openclaw/agent-skills配置路径
# 全局skill
export AGENTS_HOME="${AGENTS_HOME:-$HOME/.agents}"
export AUTOREVIEW="$AGENTS_HOME/skills/autoreview/scripts/autoreview"
# Claude Code用这个
export AGENTS_HOME="$HOME/.claude"
export AUTOREVIEW="$AGENTS_HOME/skills/autoreview/scripts/autoreview"和behavior-validator配对
autoreview是source-aware——审查change bundle。
behavior-validator是source-blind——审查运行的产品或工具是否符合行为契约。
干净的autoreview不是证明UI、CLI、API或生成的artifact从用户视角工作的证据。
两者配对，才是完整的质量把关。
实战案例
场景1：本地改动审查
# 改了几个文件，想先review再commit
"$AUTOREVIEW" --mode local场景2：PR分支审查
# 功能分支快合了，最后审查一下
"$AUTOREVIEW" --mode branch --base origin/main场景3：高风险改动用面板
# 核心支付模块改动，让多个AI看
"$AUTOREVIEW" --panel --parallel-tests "pytest tests/payment/"场景4：发布分支审查
# release分支只审查release blocker
"$AUTOREVIEW" --mode branch --base origin/main --prompt-file release-notes.md核心价值
autoreview解决的不是"要不要review"的问题——
它解决的是"怎么让AI辅助review更高效、更可控"的问题。
多引擎交叉验证，降低漏检概率
结构化输出，避免主观判断
范围控制，防止审查触发重构地狱
并行收尾，节省时间
一行命令，多个AI，最后一道防线。
关注公众号 Fen9Pi，聊聊AI时代的代码质量。