open-code-review — 用确定性工程驾驭 LLM 的代码审查¶

阿里巴巴内部打磨两年、服务数万名开发者的 AI Code Review 工具开源版。核心思路不是训练更强的模型，而是设计更聪明的流程来驾驭模型：确定性管线（Deterministic Pipeline）处理"不容许出错"的环节，LLM Agent 只在划定好的边界内做语义推理，最终用约 1/9 的 token 成本换来更高的精准度（Precision）与更低噪音。

[!info] 基本信息 - 仓库：https://github.com/alibaba/open-code-review（Apache-2.0，Go + npm 分发） - 实测 Stars / Forks：26.9k / 1.9k（2026-09-20 验证） - 前身：阿里内部官方 AI 审查助理，两年服务数万开发者、识别数百万缺陷 - 安装：npm i -g @alibaba-group/open-code-review，命令名 ocr - 前置：Git >= 2.41（依赖 Git 做 diff 生成与代码搜索，视频未提） - 模型兼容：OpenAI / Anthropic / DashScope / DeepSeek / Z.AI 及自定义端点

目录¶

• 背景与痛点
• 核心架构
• 实务应用与工程落地
• 核心取舍：Precision vs Recall
• AACR-Bench 基准数据
• 验证与勘误记录
• 参考资料

背景与痛点¶

用 Claude Code 等通用型 Agent 做 code review，开发者普遍撞上三堵墙（官方 README 原文确认同样表述）：

根本成因：一个纯粹由自然语言驱动的架构，缺乏对审查流程的硬性规定（hard constraints）——行为既难预测也难控制。这与 Claude Code Hooks - 确定性自动化防线 的结论完全同构：用确定性机制替代不可靠的提示词约束，是当前 Agent 工程的共同收敛方向。

通用 Agent 审查的失败链条：

  大 PR ──> 全部塞进上下文 ──> 注意力稀释 ──> 漏审（低覆盖）
                │
                ├──> 行号靠模型记忆 ──────> 位置漂移（误报核对成本）
                │
                └──> 流程靠 prompt 描述 ──> 结果随 prompt 抖动（品质不稳）
                                              +
                                        整包重复发送（token 爆炸）

核心架构¶

「Deterministic Engineering × Agent」混合架构，可以想象成一个分工精密的作战指挥室：

                    ┌─────────────────────────────────────┐
                    │      确定性工程管线（作战参谋）         │
                    │  处理所有「不容许出错」的环节            │
                    └─────────────────────────────────────┘
  Git diff ──> ① 精确档案筛选 ──> ② 智慧分组（Bundle）
       （哪些该审/该滤）      （message_en + message_zh 打包）
                                  │
                                  ▼
                    ③ 规则匹配（Rule Matching）
                    （按档案特性路由：SQLi / XSS / 执行绪安全…）
                                  │
          ┌───────────────────────┼───────────────────────┐
          ▼                       ▼                       ▼
   ┌─────────────┐        ┌─────────────┐          ┌─────────────┐
   │ Sub-agent A │ 并行   │ Sub-agent B │   并行   │ Sub-agent C │
   │（隔离上下文）│ <───>  │（隔离上下文）│  <────>  │（隔离上下文）│
   └─────────────┘        └─────────────┘          └─────────────┘
          │                       │                       │
          └───────────────────────┼───────────────────────┘
                                  ▼
                    ┌─────────────────────────────────────┐
                    │  ④ 定位与反思模块（独立校对员）         │
                    │  三层渐进式行号定位 + 幻觉拦截          │
                    └─────────────────────────────────────┘
                                  │
                                  ▼
                        行级精准的审查评论

三大模块分工¶

设计原则提炼¶

1. 分而治之（Divide & Conquer）：相关档案打包成独立任务 bundle，每个 bundle 由隔离上下文的 sub-agent 并行审查——上下文不膨胀，速度更快
2. 工程管保证确定性，模型只做语义判断：档案选择、分组、规则路由、行号定位、异步调度全部工程化；风险识别、上下文探索、问题分类交给 Agent
3. 注意力聚焦从源头减噪：规则匹配把每个 bundle 的判读范围缩到最小，无效 token 在进入模型前就被消灭

这套思路与 Loop Engineering 全攻略 - 从 Prompt 到 Agent Loop 中「L3 确定性测试做硬门禁、LLM 补语义盲区」的分层完全一致，也与 Markdown 取代程式碼 - Skill 就是新程式語言 里「确定性系统 vs 概率系统」的边界划分互为印证。

实务应用与工程落地¶

三种典型场景 + 完整命令（已对照官方 CLI Reference 验证）：

1. 本机预审（Local Pre-check）¶

发 PR 前先在本地过一遍，提前修掉问题：

# 安装（npm 全局，命令名 ocr）
npm i -g @alibaba-group/open-code-review
ocr version

# 配置模型（交互式 TUI，自动测连通性）
ocr config provider
ocr llm test

# 审查当前工作区所有变更（staged + unstaged + untracked）
ocr review

# 审查分支范围（merge-base 模式）
ocr review --from main --to feature-auth

# 审查单个 commit
ocr review --commit abc123

# 带业务背景上下文（官方称最高杠杆的 flag）
ocr review --background "Focus on auth refactoring"

2. CI/CD 自动化闸门¶

GitHub Actions / GitLab CI / Gerrit 均有官方集成（仓库根目录自带 action.yml），提交时自动扫描 SQL Injection、XSS 等安全风险：

# CI 中机器可读输出（stdout 保持纯 JSON）
ocr review --format json --audience agent

# SARIF 2.1.0 报告，直接对接 GitHub Code Scanning
ocr review --format sarif -o results.sarif

# 控制 CI 延迟与成本
ocr review --concurrency 8 --timeout 15 --effort medium

3. 全项目审计（Codebase Audit）¶

接手陌生 codebase 时做全域健康检查：

# 扫整个仓库（无需 git 历史）
ocr scan

# 扫特定目录或档案
ocr scan ./internal/auth

场景决策树¶

需要审查？
├── 有 git diff（开发中 / PR / commit）
│   ├── 本地还没推 ──────────> ocr review（workspace 模式）
│   ├── 已推分支 ────────────> ocr review --from main --to <branch>
│   └── 要挂 CI 闸门 ────────> ocr review --format sarif + Actions
├── 无 diff（接手陌生项目）
│   └── 全局健康检查 ─────────> ocr scan ./target-dir
└── 不想配 API key（已有编码 Agent）
    └── Delegation Mode ─────> ocr 只管档案筛选+规则路由，
                               审查由宿主 Agent（Claude Code/
                               Codex/Cursor）用自己的模型执行

Delegation Mode 是视频漏掉的重点：OCR 负责确定性的档案选择与规则解析，LLM 推理交给宿主编码 Agent——「确定性骨架 + 借用别人的模型」，对已在用 Claude Code 的团队几乎零迁移成本。另有 VSCode 扩展、MCP Server、Session Viewer（浏览器回放审查会话）等生态件。

核心取舍：Precision vs Recall¶

设计上刻意牺牲召回率换极高精准度——这是本项目最值得玩味的决策：

潜在风险清单：

• ❌ 过度依赖 → 它刻意放过的少见缺陷会被系统性忽略（低 Recall 是设计而非缺陷）
• ❌ 资安疑虑 → 原始码仍会送往外部 LLM 服务；企业落地需搭配去敏遮蔽或私有化部署（官方预设 provider 含 DashScope/自定义端点，支持私有模型）
• ⚠️ 稳定性待验证 → 有开发者小规模测试发现无法完成所有案例审查；作者承认样本太小仅供参考。第三方实测（samuellawrentz.com）也指出其「Rules First, Model Second」的设计在真实 commit 上有效，但案例数有限
• ⚠️ Recall 可调但更贵 → 官方 CLI 提供 --effort low|medium|high（1/2/3 轮审查），high 提升召回但成本按比例上升

总结：它的价值不在于发明更聪明的 AI，而在于设计更聪明的流程来驾驭 AI——用严谨的工程化手段，把 LLM 的不确定性限制在可控范围内，把 AI 从天马行空的创意伙伴变成专注、高效、成本可控的生产力工具。

AACR-Bench 基准数据¶

官方开源基准：50 个热门开源仓库 / 200 个真实 PR / 10 种语言，80+ 位资深工程师交叉标注出 1,505 个 ground-truth 问题（数据集在 HuggingFace：Alibaba-Aone/aacr-bench）。

同模型（Claude-4.6-Opus）下 OCR vs Claude Code 直接对比：

榜首为 Claude-4.6-Opus + OCR；第二名 Qwen3.8-Max + OCR（F1 23.00%）。官方口径「~1/9 token」来自 1,000 PRs 规模统计，同模型单点对比实际可达 1/15——方向一致，量级甚至更夸张。

验证与勘误记录¶

视频声称 vs 一手来源交叉验证（2026-09-20）：

视频未提但值得知道的：Git >= 2.41 前置要求；Delegation Mode（免配 API key，借宿主 Agent 的模型）；--effort 三档审查深度；AACR-Bench 开源数据集；VSCode 扩展 / MCP Server / Session Viewer / OpenTelemetry 遥测。

参考资料¶

• alibaba/open-code-review - GitHub
• Open Code Review 官网（benchmark 榜单、指标口径）
• CLI Reference - open-codereview.ai
• AACR-Bench 数据集 - HuggingFace
• Rules First, Model Second - samuellawrentz.com（第三方实测）
• 原视频：open-code-review 對決通用 Agent - GitCovery

相关笔记¶

• Claude Code Hooks - 确定性自动化防线 — 同一哲学：用确定性机制替代提示词约束
• Loop Engineering 全攻略 - 从 Prompt 到 Agent Loop — L3 确定性测试做硬门禁的分层思路
• Markdown 取代程式碼 - Skill 就是新程式語言 — 确定性系统 vs 概率系统的边界划分
• Codex goal 底层逻辑 - Ralph Loop 与长时间自主编码 — 非确定性模型的循环验证与自我修复