别把整个仓库丢给AI审代码:阿里开源内部工具,误报少九成

让 AI 审一遍代码，它报了 5980 条问题，其中只有 435 条是真的。

同一份代码、同一个模型，换一套流程再跑一遍，它只报 889 条，其中 301 条是真的。

这组数字来自阿里开源的一个代码审查工具公开的榜单，模型从头到尾没换，换的是「让 AI 怎么看这份代码」。

工具叫 Open Code Review，仓库在 GitHub 上的 alibaba/open-code-review，Apache-2.0 许可，Go 写的命令行工具。截至 2026 年 10 月 11 日，4.5 万星、3.3 千 fork，仓库今年 5 月建的，最近一次推送在 10 月 10 日。

官方说法是，它前身是阿里集团内部在用的 AI 代码审查助手，内部跑了两年，服务过数万开发者，识别出数百万个代码缺陷。这几个数是阿里自己公布的，外部没法核实，心里有个数就行。

它的工作方式一句话能说完：读你的 git 改动记录（行话叫 diff，就是你这次改了哪几行），把变更文件交给一个能自己调用工具的 agent，最后给出精确到行号的审查意见。这个 agent 可以读完整文件、搜代码库、翻别的变更文件找上下文，不是只盯着改动那几行。

榜单里最有意思的是同一款模型（Claude-4.6-Opus）的两行。左边是让通用编程 agent（Claude Code v2.1.169）自由审，右边是 Open Code Review v1.3.1 审：

先说清这几个词：准确率是「它报的问题里有多少是真的」，召回率是「真问题里它抓到了多少」，F1 综合分是把两个揉在一起的总分，token 就是模型按字数算钱的单位。

榜单叫 AACR-Bench，官方说法是从 50 个热门开源仓库挑了 200 个真实 PR（就是一次提交合并请求）、覆盖 10 种语言，由 80 多位资深工程师交叉标注出 1505 个真实缺陷当标准答案。数据集挂在 Hugging Face 上。榜单是阿里自己的，没有第三方复现过。

先顺着直觉说。大多数人的做法就是：模型越强越好，给它看的代码越多越好，于是把整个 PR 甚至整个仓库塞进去，让它自由发挥。

转折在这儿。它报得越多，你越不敢信。5980 条里 5545 条是误报，你花的时间不是修 bug，是逐条鉴别哪些不用管。审一次花 13 分钟、烧掉 5664K token，最后换回来一堆要你自己筛的噪声，这事儿干两次你就懒得用了。

Open Code Review 反过来做：先把「哪些文件该看、按什么规则看、评论落在第几行」用代码定死，模型只负责在划好的格子里面判断风险。结果是 889 条里 588 条误报，对比通用 agent 的 5545 条，少了 89%。顺带平均 token 从 5664K 掉到 385K，快了 9 倍多。

官方管这套叫「确定性工程 × Agent 混合驱动」，说人话就是：不该出错的环节，不许模型自由发挥。

第一，精准的文件筛选。哪些文件要审、哪些该过滤，先定死，保证重要改动一个不漏。

第二，智能的文件打包。把关联文件捆成一捆，官方举的例子是中英文两个 properties 文件会被捆在一起。每捆分给一个子 agent，上下文互相隔离，改动特别大时也不会乱，而且天然能并发跑。

第三，精细化规则匹配。按文件特征配对应的规则，把模型的注意力锁死，噪声从源头掐掉。官方说法是，模板引擎式的规则匹配比纯靠提示词引导稳定得多、可预期得多。

第四，外挂的定位与反思模块。两个独立模块，一个专门治「行号对不上」，一个专门拦「内容开始瞎编」。

这几条听着抽象，在 Windows + Node 22 的机器上装完跑一遍就清楚了。ocr delegate preview 这个命令不用配任何大模型就能跑，输出长这样：

两个新增文件，它只放行了一个 Go 文件，另一个 txt 以 unsupported_ext（扩展名不支持）直接排除。这是在任何模型介入之前就完成的，模型还没开口，范围已经划好了。

规则也是按文件走的。ocr rules check src/db.go 返回 Pattern: **/*.go，拿到的是一整页 Go 专属规则，第一句就是「宁可少报，一次误报就会耗光审查者的信任」，后面还专门交代：别光看函数名或 import 就断言有并发问题、有注入点，先把调用链和输入边界摸清楚。而那个 txt 文件落到的是 Pattern: default 的通用规则。

前置条件只有一条：Git 2.41 以上（我这边是 2.53，够）。它要靠 Git 生成 diff、搜代码、操作仓库。装就一行：

装完得到 ocr 命令。另外还有安装脚本、GitHub Release 二进制、Homebrew 和源码编译几种方式。

我这边这次装到的是 v1.12.13，构建时间 2026 年 10 月 8 日。值得说一句：它在 npm 上看着是个包，实际拉下来的是一个 Go 编译好的单文件可执行程序，Windows 上那个 exe 就有 57.8 MB，整个 node_modules 加起来 27 个文件、60.4 MB。没有 Python 虚拟环境里那种几百个依赖的连环套，也不用配数据库，这一点比大多数 AI 工具省心。

顺带一提，官网上贴的近 30 天 npm 下载量是 113K 以上（官方口径），榜单里标注的版本还是 v1.3.1、v1.8.7，可见迭代挺快，生产环境要用的话记得锁版本。

它的核心思路，其实就藏在下面这张图里：

— AI 生成示意图：筛选、打包、规则路由做成硬约束，模型只管判断风险

用法一：自己配个模型端点。跑 ocr config provider 选内置供应商或加自定义端点，再跑 ocr config model 挑模型。交互式界面会引导你选供应商、填 API Key、测连通性。预设供应商有 Anthropic、OpenAI、DashScope、DeepSeek、Z.AI，协议上支持 Anthropic Messages API、OpenAI Chat Completions 和 Responses 三种。填自己的私有端点也行，对代码不能出内网的团队来说，这条是关键。

不想走交互界面就直接上环境变量：OCR_LLM_URL、OCR_LLM_TOKEN、OCR_LLM_MODEL，配置文件落在 ~/.opencodereview/config.json。CI 里用这个方式最省事。

用法二：委托模式，不用配 Key。如果你已经在用 Claude Code、Codex、Cursor 或 Kimi Code，这条最香：

OCR 只负责选文件和解析规则，真正跑审查的是你手上那个编程 agent，用的是它自己的模型。也就是说你不用再单独申请一个 API Key，也不用为审查单独掏一份钱。装好插件之后，在 Claude Code 里它会变成一条斜杠命令（打个 / 就能喊它出来），在 Codex / Cursor 里则是一份 Skill（可复用的指令文件，agent 自己会去调）。

用法三：接到 CI 上。官方列了 GitHub Actions、GitLab CI、GitFlic CI 和 Gerrit 的集成方式。常用的几条命令：

ocr scan 那条值得单独说一句：它不看 diff，直接审整个文件。拿来审计一份刚接手、完全不熟的代码库挺合适。

第一个，没配模型端点会直接报错。报错原文是：

看到这个别以为装坏了，老老实实配端点，或者改用委托模式。

第二个，工作区模式会把没跟踪的文件也一起审了。README 里写得很清楚：暂存、未暂存和未跟踪的变更全在范围内。也就是说你仓库里那些忘了写进 .gitignore 的日志、构建产物、临时脚本，都会被算进去，白白烧 token。跑之前要么先清一遍，要么直接用 --from main --to beta 这种按分支的方式，范围干净得多。

第三个，召回率低这件事要提前接受。它漏掉的真问题比通用 agent 多。所以别把它当成唯一一道关，尤其是安全相关的改动。它适合帮你从一堆噪声里先捞出几个值得看的点，不适合替你签字。

一个人写代码，提交前想自查——直接上，委托模式最省事，不用配 Key。

小团队，想把审查接到 CI 上——合适，用环境变量配端点，记得锁版本。

代码不能出内网——特别合适，填自己的私有端点就行。

指望它替代人审、替代安全审计——别，召回率摆在那儿。

完全不用编程 agent，也不想配端点——先别折腾，它至少要占一头。

先别管它审得对不对，看它挑了哪几个文件、又排除了哪些、排除的理由是什么。这一步做完你就会明白，AI 辅助编程的下半场，拼的可能不是谁的模型更强，而是谁先把流程管住了。

我是老李，一个爱折腾技术的普通人，只分享真正上手折腾过的东西。你现在的代码审查是怎么做的，评论区聊聊。