11 月 14 日刷 GitHub Trending，榜首附近有个熟悉的 logo——alibaba/open-code-review，51,000+ star，官方介绍写着”源自阿里内部官方 AI 代码审查助手，服务数万名开发者两年，发现过数百万个代码缺陷”。这类自我介绍我一般打个对折再读，但它是 11 月 13 日刚发 v1.13.9、连续两天 Trending 的活跃项目，而且提出了一个我感兴趣的主张：纯 prompt 驱动的代码审查不可靠，审查流程里”不能错”的环节要用确定性工程锁死，Agent 只负责需要动态决策的部分。
这个主张直接打脸了包括我在内很多人的用法——拿 Claude Code 或 Codex 装个审查 skill 就当 CR 用。恰好我 11 月 6 日测过 Cloudflare 的 security-audit 技能（纯 prompt 六阶段流水线，免费模型跑到一半额度见底），两相对照正好能看出”工程锁流程”和”prompt 锁流程”的差别。于是花一晚上把它拆开测了一遍：装、配、跑、对答案，以下全部来自我 M4 / 16GB Mac 上的真实操作。
它的底子：确定性工程 × Agent 混合架构
先把官方逻辑翻译成人话。README 列了纯语言驱动 CR 的三个老毛病：大改动集时模型偷懒只审部分文件、报告的行号漂移、prompt 微调导致质量波动。open-code-review 的解法是把三件事从模型手里拿走：
- 文件选择：哪些文件要审、哪些该过滤，由工程逻辑决定，不靠模型自觉；
- 文件打包：相关的文件捆成一个审查单元，每个单元跑一个隔离上下文的子 Agent，大改动集天然可并发；
- 规则匹配：按文件特征挂规则模板，把模型注意力收窄。
模型只留下动态决策：读 diff、搜代码、定位问题、写结论。官方还放了一个 AACR-Bench 基准——50 个开源仓库、200 个真实 PR、10 种语言、80 多位高级工程师交叉标注的 1,505 个真值问题，结论是同等模型下 Precision 和 F1 明显高于通用 Agent，代价是 Recall 主动放低（少报，不误报），token 消耗约为通用 Agent 的 1/9。基准数据集在 Hugging Face 上以 Apache-2.0 开放，我查了仓库元信息：2026 年 2 月创建，主数据文件 dataset.json 约 2.1MB，525 次下载。数字是否注水我无法完整复跑 200 个 PR，但至少基准本身是可查证的，比”内部服务数万开发者”这种无法证伪的话术实在。
5 分钟跑起来（含免费模型配置）
安装很简单，npm 全局装完就有 ocr 命令：
npm install -g @alibaba-group/open-code-review
ocr --version
# open-code-review v1.13.9 (0e9060d) darwin/arm64运行环境：macOS 26.5.2 / M4 / 16GB，Node v22.22.2，open-code-review v1.13.9，Git 2.50。
配置模型是第一道门槛——ocr review 必须自己配 LLM，不吃你 Claude Code 订阅。好消息是内置了 30 家 provider（DeepSeek、Kimi、Gemini、OpenRouter、SiliconFlow 都在列），也支持自定义 OpenAI 兼容网关。我不想为测试花钱，直接把 OpenRouter 的 key 配上免费模型：
ocr config set provider openrouter
ocr config set providers.openrouter.api_key "$OPENROUTER_API_KEY"
ocr config set model nvidia/nemotron-3.5-lightning:free
ocr llm test
# ✓ Connection test successful
# ✓ Tool-call round trip verifiedllm test 不只是测连通，还做了一次工具调用往返验证——这个细节值得点赞，很多工具只测补全连通，等真跑起来才发现模型不会调工具。
实测一：种 5 个 bug 的靶场 diff，全中
光看它审别人的代码不够，我按老办法造了个靶子：一个 90 行的标准库多用户待办 API，main 分支干净，feature 分支上种了 5 个真实缺陷——eval() 直接执行用户输入、subprocess.run 拼用户文件名还开 shell=True、INSERT 用 % 格式化拼 SQL、SELECT 用字符串拼接 SQL、以及一个硬编码的 debug-master-key 后门。另外在 diff 里混了 3 个”该被过滤”的文件：自动生成的 generated/schema_gen.py、testdata/fixtures.json、README。
跑一次正式审查：
ocr review --from main --to feature/reorder --format json结果：5 个缺陷全部命中，0 误报，5 条评论行号全部精确。耗时 3 分 30 秒，总 token 100,332（输入 65,684 / 输出 34,648），工具调用 6 次零失败。
| 种入缺陷 | 报告严重度 | 行号 | 是否命中 |
|---|---|---|---|
eval() 执行用户输入 |
critical/security | 73-76 | ✅ |
shell=True 命令注入 |
critical/security | 79-82 | ✅ |
INSERT 用 % 格式化拼 SQL |
high/security | 68-70 | ✅ |
| SELECT 字符串拼接 SQL | high/security | 51-54 | ✅ |
| 硬编码 debug 后门 | medium/bug | 26-30 | ✅ |
最有意思的是后门那一条。它不但报了”硬编码调试密钥是后门”，还顺手指出了一个我自己都没注意到的二阶缺陷：auth_user 对后门 token 返回 0，而调用方用的是 if not user:——0 在 Python 里是 falsy，这个后门实际上根本登不进去。一个 bug 里藏着另一个 bug，免费模型把它挖出来了，这比我预期的多给了一层。
实测二：干净 diff 对照，0 误报
Precision 优先的代价是 Recall，那反过来测：干净代码会不会被硬挑出毛病？我又写了一个 31 行、写得规规矩矩的请求日志模块（无 bug，含正常的可变属性和显式 flush），单独跑一轮：
ocr review --from main --to feature/clean --format json0 条评论，29 秒，9,143 token。规规矩矩的代码它一句废话没说。两轮对照下来，”Favor precision over recall”不是 README 里的一句话，规则模板里第一条就写着”上下文不清时保持沉默，误报比漏报次要问题更伤审查者信任”——这是拿真金白银的信任换来的产品哲学。
三个没人告诉你的坑
坑一：generated/ 目录默认不会被排除。 我原以为”自动生成的文件不审”是默认行为，实测发现默认路径规则只排除 testdata/ 这类目录，我自己建的 generated/schema_gen.py 照样进了审查队列。要排除得显式传参：
ocr delegate preview --from main --to feature/reorder --exclude '**/generated/*'--exclude 生效后预览里会标 (excluded: user_exclude)，与默认规则标 (excluded: default_path) 区分。想先看哪些文件会被审、不必烧 token，ocr delegate preview 是零成本入口——这个子命令直接把文件选择、过滤原因、规则匹配全部打印出来，确认完再跑 review 才是正确姿势。
坑二：macOS 上 /tmp 路径会让 ocr session list 返回空。 review 跑完后我列 session，报”No sessions found”，但按 session ID 一查，文件好好地躺在 ~/.opencodereview/sessions/private-tmp-ocr-lab-target/ 里。原因很简单：macOS 的 /tmp 是 /private/tmp 的符号链接，session 存储按真实路径建目录（前缀 private-tmp-），而 session list 按你 cd 进去的路径找——从 /tmp/... 进去找 /private/tmp/... 的目录，找不到就报空。从 /private/tmp/... 进去就正常。在 macOS 上用临时目录跑 review 的人大概率会撞上，记住从 session show <id> 直接拿结果就行。
坑三：免费模型也有一轮”没接住”。 日志里出现了 No tool calls parsed for app.py,generated/schema_gen.py, retrying...——第一轮打包审查时模型的工具调用没被解析出来，ocr 自动重试了一轮才拿到结果，日志显示 Round 2/2 added no new findings ... stopping early。这是免费模型的纪律问题，不是工具的锅，但要提醒：给 open-code-review 配太弱的模型，可能出现整组文件审不出任何东西且不报错的情况。配模型后先跑 ocr llm test 确认工具调用往返通过，再上真活。
Token 账单与适用边界
22 行 diff 花了 10 万 token（缓存读另有 4.2 万），31 行干净 diff 花了 9 千——注意干净那次快，是因为日志里明确写着 Skipping plan phase for group (1 file(s), max 31 lines)，小 diff 跳过了规划阶段。官方”1/9 token”是对通用 Agent 的基准相对值，单看绝对值并不便宜。如果你的仓库每天大量 PR，这笔账要拿真实改动集先试算一轮。
不建议使用的场景：一，需要穷尽式找 bug 的安全审计——官方明说 Recall 低于通用 Agent，漏报换低噪音，追求召回率的活请用专门的审计流程；二，模型没配好就想上线——工具调用失败的那组文件会静默产出 0 发现，CI 里无声无息地漏审；三，单文件全量扫描（ocr scan）和 Claude Code 插件（delegate-review 模式）我这次没测，不做推荐也不做否定，需要的人自己跑一遍 ocr scan --help 看说明。
顺带说一句工程完成度：ocr session show/export 能把每次审查落成 JSONL 档案，ocr viewer 起一个本地 WebUI（默认 5483 端口）看历史审查记录，ocr session compare 还能对比两次审查的差异——这些是纯 prompt skill 给不了的东西。
写在最后
这轮测试让我把 11 月 6 日那篇 security-audit 的结论又往前推了一步：纯 prompt 技能的流程约束天花板很低，免费模型连六阶段都跑不完；而 open-code-review 把”不能错”的环节全部工程化之后，同一个免费模型反而把 5 个缺陷全数报对、行号精确、干净代码零噪音。确定性流水线 + 小模型，可能比通用 Agent + 大模型更适合嵌进日常 CR 流程——至少在”少打扰人”这个维度上。
相关阅读：11 月初我在 Cloudflare security-audit 技能实测里同样用种缺陷靶场量化过审计工具；graphify 是另一个”把代码理解交给确定性工程”的思路；如果你关心 Agent 的 token 开销怎么省，caveman 实测有完整的压缩器量化数据；task-view 则覆盖了编码 Agent 改动后的 Git 审查流程。
参考链接：