阿里开源的 AI 代码评审 CLI：把评审拆成工程层与模型层

上周末 clone 了 alibaba/open-code-review。它本质上是阿里内部用了两年、服务过上万名开发者的 AI 代码评审 CLI，今年 5 月开源，现在 3.7 万 star、2.7k fork。我本来以为是又一个"套个 LLM 就敢叫代码评审"的项目，但读核心源码、本地装了二进制真跑一遍之后，发现它在架构上确实下了功夫——它把"哪些事必须做对"和"哪些事可以交给模型发挥"拆成了两层。

它解决的是哪三个具体痛点

README 直接点名了通用 Agent（比如拿 Claude Code 配个 review skill）做代码评审时的三个毛病：大改动集上会"抄近路"只审部分文件；报的位置经常对不上实际代码（行号、文件漂移）；质量随提示词微小变化大幅波动。根因一句话：纯语言驱动缺乏硬约束。OpenCodeReview 的解法是——能让工程逻辑保证正确的步骤，绝不让模型来定。

架构：两层分开管

OpenCodeReview 混合架构图：左侧输入 git diff，中间上方为确定性工程层（文件选择、文件捆绑、规则匹配、定位与反思模块），中间下方为 Agent 层（多轮 LLM tool-use loop 加场景化工具集），右侧输出行级评论与可恢复的 Session/Manifest — 图：按 internal/agent/agent.go 实际管线梳理的两层结构

核心跑在 Go 写的 ocr 二进制里（module 为 github.com/alibaba/open-code-review，go 1.25.5）。一个容易踩的认知误区：npm i -g @alibaba-group/open-code-review 装的 bin/ocr.js 只是个启动器，它根据平台从 GitHub Releases 拉对应预编译二进制，并不现场编译 Go。所以你装的是"壳 + 下载器"。

确定性那层做了什么（不靠模型）

文件精准选择（selectFiles）：确定性地决定哪些文件进评审、哪些被过滤。我本地用 delegate preview 实测过——data.pb.go、*.generated.go 这类生成文件被 default_path 规则直接排除，绝不会占模型上下文。
智能文件捆绑（groupDiffs）：把相关文件捆成一个评审单元（比如 message_en.properties 和 message_zh.properties 绑一起），每个单元跑一个子 agent、带独立上下文。大改动集上靠分治保持稳定，也天然支持并发。
细粒度规则匹配（SystemRule.Resolve）：按文件路径把对应语言的评审规则喂给模型，比自然语言描述规则稳定得多。我用 ocr rules check 看过，Java / Go / JS·TS 各有独立规则集，来源全是 "System built-in"。
定位 + 反思两个外挂模块：评论落点不准时，internal/diff/relocation.go 的 ReLocateComment 让模型重新生成精确代码片段再重试定位；模型偶尔把评论 JSON 写坏时，internal/tool/comment_args_repair.go 在确定性层做修复兜底。

Agent 那层做了什么

模型只在"该动态决策的地方"出场：场景化调优的提示词，加上从生产数据里蒸馏出来的工具集（file_read / file_find / code_search / code_comment）。每个文件组跑 Plan（小改动可跳过）→ Main 多轮 loop → Review filter 三段。并发靠一个信号量池（默认 8），大改动集天然并行。

最值得说的是那个 Review filter（executeGroupReviewFilter）——它是 README 说的"反思模块"：强制模型在 report_incorrect_comments / approve_all_comments 两个工具里二选一，只有"这条评论的某行代码能证明它是错的"才删，否则一律保留。这直接压低误报，对应它反复强调的"precision 优先"。

我本地真跑了一遍

环境：macOS 14 / Apple Silicon / Node 22（npm 装的壳），实际跑的是 darwin/arm64 预编译二进制 v1.12.7（build 85cecfe，2026-09-19 打的包）。不需要 API key 就能验证的部分，我全跑了。

# 装 + 看版本（npm 壳会顺带从 Releases 拉 Go 二进制）
$ npm install -g @alibaba-group/open-code-review@1.12.7
$ ocr --version
open-code-review v1.12.7 (85cecfe) darwin/arm64
built at: 2026-09-19T08:48:54Z
https://github.com/alibaba/open-code-review

先是规则匹配——同样一条命令换不同后缀，命中的规则集完全不同（节选）：

$ ocr rules check internal/agent/agent.go
File: internal/agent/agent.go
Source: System built-in
Pattern: **/*.go
Rule: #### Go Review Principles
> Favor precision over recall ...

$ ocr rules check web/handler.js
Source: System built-in
Pattern: **/*.{ts,js,tsx,jsx,mjs,cjs}
Rule: #### XSS Protection / Code Injection Protection ...

$ ocr rules check templates/index.html
Source: System built-in
Pattern: default
Rule: #### Correctness / Security / Performance ...

再看文件选择。我造了个临时 git 仓，故意塞了 .pb.go 和 .generated.go：

$ ocr delegate preview   # workspace 模式，无需 LLM
# Files (2 reviewable / 4 total)
~~- `data.pb.go` [added] +1/-0 (excluded: default_path)~~
~~- `generated.generated.go` [added] +1/-0 (excluded: default_path)~~
  - `main.go` [modified] +3/-1
  - `newlib.js` [added] +1/-0

两条生成文件被干净排除，剩下的 Go / JS 才进评审队列。这就是 README 说的"精准文件选择"落到了代码里，不是口号。

哪些地方是真工程，不是 PPT

可恢复 + 可审计：每次 run 都会算一个确定性 SHA-256 manifest（sourceArtifactSHA256 / ruleConfigSHA256 / runtimeConfigSHA256），把"本次输入、规则、运行时配置"全冻住。中断后能 --resume 接着跑，且换 ref 后输入变了 manifest 也会变——它是真把"评审可复现"当一等公民。
评论落库走异步 worker 池（CommentWorkerPool），主 loop 不用等后处理，模型可以继续发请求，不与 IO 挤在同一条关键路径上。
它大方承认 Recall 比通用 Agent 低——这是主动取舍，不是缺陷。benchmark 是它自己的 AACR-Bench（50 个仓库 / 200 个真实 PR / 80+ 资深工程师标注），声称同样模型下 F1 和 precision 更高、token 只要约 1/9。这是项目自己的声明，我没法独立核实 token 数，按来源标注。

值不值得用

场景	结论
适合	已经用 Claude Code / Codex / Cursor 之类做 review、被"漏文件 / 位置漂移"烦到的团队；想接 CI（GitHub Actions / GitLab / Gerrit 都有现成示例）；有多语言栈、想要稳定可复现评审结论的。
不适合	需要"尽量别漏"的高召回场景——它明确 precision 优先、recall 偏低，安全敏感改动可以等 H2 的 Ultra Mode（高召回模式）。不想再付一份 LLM 调用成本（delegate 模式虽免 key，但是把活甩给你自己的 coding agent）。想要它顺手帮你改代码——Roadmap 明确"不自动修代码、不做通用编码助手"。

一个诚实的说明：我这次没能跑完整评审，因为手头没有可联网的 LLM key，只验证了不需要 key 的确定性部分（规则匹配、文件选择、架构）。真要结论好不好用，得等你配一个 OpenAI / Anthropic / Gemini / Bedrock 兼容端点实际审一两个 PR 才知道。

一句话总结：它不是一个"套壳 LLM 评审"，而是把评审拆成"工程保证正确"和"模型负责判断"两层，并用 manifest + 反思模块把误报和漂移压下去。如果你已经被通用 Agent 审代码时的漏审和飘位置搞烦了，值得试；但别指望它替代人工，也别指望它免费。