阿里开源的 AI 代码审查工具open-code-review,居然故意「少报」?我本机跑通后理解了

我自己平时就用 coding agent 写代码，最怕的就是审查这一步翻车。不是怕它不审，是怕它「审了跟没审一样」。我见过太多次这三种翻车：

• 漏文件：一个 PR 改了 20 个文件，它只扫了其中 3 个，剩下 17 个它觉得「应该不用看」；

• 定位漂移：它告诉你「第 142 行有问题」，你打开一看 142 行啥也没有，真正的问题在 387 行；

• 输出随机：同一个 PR，第一次说 Looks good、第二次说存在 SQL 注入、第三次说线程安全风险，代码一行没动，只有 AI 在变。

这三种翻车根子往往都指向同一件事：把太多事压给 LLM。至少在我见过的翻车里，文件筛选、流程控制、精确定位、规则执行、一致性输出这些，LLM 并不是最稳的那一环（当然也受上下文预算、diff 生成、工具实现、模型参数和提示模板等影响，不能全怪模型）。所以翻这周周榜，看到 alibaba/open-code-review 冲上来，我没光看标语，下载下来跑，至于「阿里内部用了两年、审了数百万个缺陷」这种规模，本地实测验不了，只能当作项目方自述，下面我会标清楚。

下面是这次真实跑过的经过，关键终端输出我都贴了出来（完整命令和源码见文末说明）。

说起来，读者比趋势榜更早把它递到我眼前。这得从上周一的实测说起：那篇我跑了 tirth8205/code-review-graph，思路是先把代码建成本地 SQLite 图谱，让 Agent 少读无关文件。评论区有读者问，能不能把它和「阿里OCR」结合做 AI code review；我一开始按字面理解，回了一通「把图片文字提取出来再喂给 code-review-graph」，结果被另一位读者纠正：他说的「OCR」其实是「阿里的 open code review」。我这才反应过来，主角早被点出来了，就是 alibaba/open-code-review。所以这周它冲上趋势榜，正好给了我由头，把那篇评论区里读者点名、我却照字面意思带偏的项目真正跑一遍，补上那个乌龙。

按项目方介绍，OpenCodeReview 是个 AI 驱动的代码审查 CLI，前身是阿里集团内部的官方 AI 代码审查助手，过去两年在内部服务了数万开发者、识别了数百万个代码缺陷，充分验证后才孵化为开源项目，配置一个模型端点就能用。

按项目方说法，它做的事：读取 Git diff → 通过带工具调用能力的 Agent 把变更文件发给可配置的 LLM → 生成行级精度的结构化审查意见。Agent 能读完整文件、搜代码库、看其他变更拿上下文，所以是深度审，不是只扫一眼 diff。另外据项目方文档，除了 diff 审查，还有 ocr scan 能直接扫整个文件，适合审计不熟悉的代码库、或者没有有意义 diff 的目录。

阿里的思路其实就一句话：让工程做工程，让 AI 做 AI。它没把宝全押在提示词上，但也确实做了「场景化提示词调优」，官方把这块列为核心能力之一；更关键的是它把流程重写了：哪些文件要审、哪些规则该查，由工程逻辑先钉死，只有「理解代码、定位问题」这种 LLM 真正擅长的动态判断，才交给模型。具体拆成四块能力（按项目方说法）：

• 精准文件选择：改了 20 个文件，重要改动也不容易漏掉，该审哪些由程序判定，不靠 LLM 自己猜。

• 智能文件打包：message_en.properties / message_zh.properties 这类成对的国际化文件，OCR 会自动打包给同一个 Agent，避免把同一份逻辑拆成两份看。

• 规则按路径匹配：java 文件命中 java.md、go 文件命中 go.md（首个匹配路径即生效），不靠用户在提示词里硬写规则，我贴的 delegate rule 输出就是它匹配到的安全规则。

• 定位与反思独立成模块：行号不准时有一层独立的「定位 + 反思」组件去校正（官方说它提升 AI 反馈的位置与内容准确度，背后仍会调用模型），不是纯靠 LLM 临场发挥，也不是纯确定性保证。

这套描述听着漂亮，但漂亮话我见多了。我更想知道的是：它到底能不能落地。所以我没急着配 key，而是先看它不依赖 LLM key 也能跑的那部分（规则提示、文件选择）：这部分才是它和「套个提示词让通用 Agent 审」真正的区别；要出审查评论，仍然得接自己的 LLM。（这里的「规则提示」指 ocr delegate rule 按路径匹配吐出的审查规则文件，它本身不做缺陷检测，只是把该查什么钉死。）

安装它很简单。官方给了 npm 包，我用本机 Node 22 直接 npm install -g @alibaba-group/open-code-review安装，装下来是 v1.8.4 的预编译二进制（darwin/arm64），不需要 Go 工具链，和我的 M 芯片 Mac 对得上。装完先看版本：

版本是当天构建的，说明项目还在高频迭代。接着 ocr --help 暴露出一整套命令：review / scan / delegate / rules / session / viewer，分工很清楚。

重点在 delegate 这一类—：它的 preview / rule 子命令完全不需要 LLM key。但要说清：delegate 把审查交给你的宿主 coding agent 去跑，所以 OCR 这边不用单独配 key，真正的审查仍靠宿主 agent 自己的模型，不是「完全不需要模型」。我拿来跑了一遍。

先写了个故意留缺陷的 Go 文件，把平时最容易出的几个坑都放进去：

然后跑 ocr delegate rule buggy.go。这一步不调 LLM，吐出来的是一整套 Go 审查规则，而且是模板引擎匹配出来的，不是 LLM 现编的。我贴两段真实的：

你品一下这两段。第一段讲的是「精确率优先于召回率，误报会消耗 reviewer 的信任」，这不是泛泛的「请审查这段代码」，而是带着明确取舍的审查策略。第二段直接点名 SQL 注入、命令注入、路径穿越这些具体边界。能确认的是，这些规则是写死在仓库里的静态文件，不是模型临场生成；至于规则最初由谁编写、是否直接来自内部真实案例，项目方没公开细节，我只能说读起来像工程经验沉淀，不能当成已证实的事实。

我又在 workspace 模式下跑了 ocr delegate preview，它准确选出了我新增的 handler.go（一个忘了关 response body 的文件），输出是：

— 本机实测跑通（含接 LLM 后的 AI 审查）

接上我自己的 LLM，把最值钱的那步也跑通

前面那几步免 key，但真正让 LLM 出审查评论的 ocr review / ocr scan，必须你自己的 LLM 端点（OpenAI 兼容或 Anthropic 都行）。OCR 用 ocr config 就能接任意 OpenAI 兼容网关，不用改一行业务代码：

这里补一句实在话：OCR 把 diff 和文件发给你的 LLM 去审，端点指向哪儿，代码就流向哪儿。配本地或公司私有网关自然没问题；但要是为了顺手配了个公共云端模型，源码改动就出了公司内网。团队用的话，先把模型端点的数据合规确认清楚，别把敏感仓库的改动直接丢到外部。

配好之后，ocr scan 直接扫整个文件。我另写了一个专门埋缺陷的文件，下文叫它 defects-demo.go（扫描输出里显示的原名还是 buggy.go），里面故意放了 SQL 注入、nil 解引用、硬编码密钥等几类缺陷，模型吐出来的审查意见（节选）：

注：这个埋缺陷的文件我另命名为 defects-demo.go，和前面 ocr delegate rule 举例的 buggy.go 不是同一个，免得重名搞混；它扫出来一共报了 6 条意见（节选见下），为省篇幅只贴输出、没全文贴源码。

一条 critical（SQL 注入）、一条 high（nil panic）、一条 high（硬编码密钥），加上几个 medium/low。注意它给的不是「这段代码可能有问题」这种废话：SQL 注入那条直接给了参数化查询的修法，连 db.QueryRow(...) 都写好了。（注：上面示例用的是 ? 占位符，这是 MySQL / SQLite 风格；PostgreSQL 要用 $1。我不能证明这段示例能直接套到某个具体驱动上，只能说它把「参数化」这个正确方向给出来了。）

ocr review 走的是 diff 视角，默认审你本次改动或新增、且通过了文件过滤的文件（二进制、不支持扩展名、测试文件、vendor / node_modules 等会被自动排除，不是所有改动都会进审查）。我加了个 pay.go（含命令注入和除零），它审出来两条都是 critical，而且直接给出了带「-」「+」标记的修复 diff：

顺带说一句：上面 Calc 的修复是 OCR 直接给的 diff——b == 0 时 return 0。这能避免 panic，但 return 0 可能悄悄掩盖了错误的业务结果；更稳妥的接口通常是返回 (int, error)，或按你的业务约定显式处理。所以「直接给修复 diff」不等于修复一定正确，这点得说清楚。

它擅长抓什么、不擅长什么

看了上面这些真实输出，可以给它画一张能力地图：哪些问题它大概率能帮你兜住，哪些别指望它：

项目方做了一套很硬核的基准（项目方披露，非本人复现；该基准基于 v1.3.1，本文实测为 v1.8.4）：50 个开源仓库、200 个真实 PR、10 种语言、1505 个真实缺陷、80+ 高级工程师人工标注。拿 OCR 去对比 Claude Code，结论是：精确率（Precision）约 25%–38%，远高于 Claude Code 的约 7%–16%（但绝对值仍不到一半）；F1 更高、token 只花约 1/9、审查还更快；但召回率更低。

这最后一点不是翻车，是有意设计：在多数常规业务代码里，我平时做 code review 时最烦的往往不是 AI 少发现几个问题，而是每行都给你一个黄标、最后只能全点 Ignore。

当然，安全、支付、基础设施这类场景，漏掉一个严重问题往往比多处理几条误报更糟，所以召回率高低本来就取决于你的业务取舍。OCR 正是选了 precision over recall，宁可少报，也不拿误报消耗你的信任。

项目方把这套思路概括为「确定性工程 × Agent 混合驱动」：文件筛选、智能打包、规则匹配这些能钉死的，由工程逻辑强约束；定位与反思是独立的模块（仍会调模型），Agent 负责它真正擅长的动态决策和上下文召回。

我自己的判断是：对团队来说，它最值钱的地方不是「比通用 Agent 多审出几个 bug」，而是相对可预期。我前面说怕 review 翻车，怕的其实就是「不可预期」：今天审得严、明天可能就飘了，你都不敢信它，最后还是要自己重看一遍。OpenCodeReview 把规则钉死、把噪声压得比通用 Agent 低（这是相对结论，不是绝对无噪声），等于给这一步加了一道相对可预期的门禁（这是设计愿景；我这次两个小文件既没重复运行、也没接 CI，稳定性和「更少误报」都证不了，得靠真实 PR 验证）。但它召回率偏低，意味着它不替代人审，是「第一道过滤」。要不要上，取决于你更怕漏报还是更怕误报，这是只有你自己的业务能回答的问题，我没法替你拍板。

落到工程上，OCR 支持把审查结果输出成结构化 JSON（ocr review --format json），这意味着能直接挂进 GitHub Actions、GitLab CI 这类流水线，在 PR 合并前做一道自动初审，比人工手动跑一遍更稳。这偏部署层面，本文没演示，CI 模板以官方文档为准。

回到开头说的「翻车」：open-code-review 干的事，就是给 Agent 写代码最容易翻车的那一步，加一道相对可预期、相对低噪声的门禁（设计愿景：稳定性未测）。它不替代人审，是「第一道过滤」：低召回意味着它可能漏，精确率相对更高意味着它报出来的相对更值得看，误报比通用 Agent 少得多，这是相对结论（基于基准 Precision 25%–38% vs 7%–16%）；但 OCR 自己的绝对 Precision 仍不到一半，所以「认真看」不等于「每条都对」。我这次连需要 LLM 的那一半也用自己机器上的端点跑通了，流程是通的、该报的明显缺陷也报出来了；但「它比通用 Agent 更稳、更少误报」这种结论，得靠那套官方基准和你的真实 PR 去验证。

我是开源仓库猎人，专注于发现 GitHub 上的热门开源项目，不只是罗列，更想说清楚它们在往哪个方向走。每周一三五深度解读，周日盘点十大热点。

如果觉得今天这篇有收获，我们周三见。