OpenCodeReview 评测：阿里巴巴开源 AI 代码审查工具的亮点，以及我们测试中的发现

OpenCodeReview 是阿里巴巴开源的 AI 代码审查 CLI 工具。我们阅读了其源码、重新核算了它的基准测试数据，并在一个测试仓库上运行了它。它每个 PR 大约发布 3 条评论，而 Claude Code 会发布 15 到 30 条；它发现的真实 bug 更少，而且其 Java 规则中没有安全类规则。

作者：BRANDON FOSTER · FDEINTERVIEWS 编辑部 · 更新于 2026 年 10 月 21 日 · 阅读时长 11 分钟

实践一下：Agentic 软件工厂指南 · 面向 FDE 的 Harness Engineering 课程 · LLM-as-a-judge 概念 · 必知的 FDE 面试问题

OpenCodeReview 是阿里巴巴开源的 AI 代码审查工具，它真正的贡献在于一种架构，而不是某个模型或某项分数。它用普通代码决定哪些文件需要审查、每条规则适用于哪些文件，以及每条评论应落在何处。它只把判断题交给语言模型：这段代码是否有问题？在它自己的基准测试中，这使得它比用相同模型把 Claude Code 当作审查工具运行要安静得多，成本也低约九倍，代价是发现的真实 bug 更少。我们阅读了 Go 源码、重新核算了基准测试数据，并在一个测试仓库上运行了该工具。我们的结论是：采纳其设计，锁定版本和模型，为 Java 自行编写安全规则，并且不要把基准测试解读为“发现更多 bug”。它发现的 bug 更少，但浪费审查者的时间也少得多——对大多数团队而言，这才是正确的取舍。

一分钟了解 OpenCodeReview 是什么

OCR (the CLI is

ocr

) was Alibaba's internal AI review assistant before it was released under Apache-2.0. The README says it served tens of thousands of developers over two years; we have no way to check that, so treat it as the company's claim. As of 21 October 2026 the repository has about 47,800 GitHub stars and the npm package is at version 1.13.2.

它有四项功能：

• Diff 审查（ocr review）：针对工作区变更、分支范围或单个提交进行审查，支持可恢复的会话。
• 全文件扫描（ocr scan）：对没有 diff 的目录进行扫描，用于审计从未被审查过的代码。
• 委派模式（ocr delegate）：由 OCR 负责文件选择和规则解析，而由你自己的编码 Agent（Claude Code、Codex、Cursor、Kimi Code、OpenCode）使用其模型进行审查。无需 OCR API 密钥。
• CI 集成：支持 GitHub Actions、GitLab CI、GitFlic 和 Gerrit，带有 OpenTelemetry 钩子以及用于审查会话的本地查看器。

它需要 Git 2.41 或更高版本，以及任何兼容 OpenAI 或 Anthropic 的端点。

工作原理：代码负责记账，模型负责判断

README 中对将通用 Agent 用作审查工具的诊断，与我们在客户部署中观察到的情况相符：在大型变更集上，它们会跳过文件，行号会偏离目标，而且其质量会随提示词的微小改动而大幅波动。OCR 的应对之道，是把每一个不容出错的步骤都从模型手中拿走。

来源：OpenCodeReview 的实现。该图将确定性代码与模型调用区分开来。

源码中有四个细节值得复制到你构建的任何 Agent 中。

Selection is a pure function.

selectFiles

applies path and extension gates, skips deletions and enforces a per-file token ceiling. It has no LLM and no Git access, so the

--preview

command and the real run compute the same answer. A comment in the code says the two used to drift apart. If your agent's dry run and real run can disagree, you do not have a dry run.

分组以低成本方式使用模型。README 将打包称为“确定性工程”，但 grouping.go 让 LLM 仅使用元数据（状态、路径以及新增和删除的行数，不含 diff 内容）对文件进行分组，并返回整数索引而非路径，以节省输出 token。少于四个文件的变更集会跳过该调用：如果总变更量低于 200 行，则一起评审，否则每个子 Agent 处理一个文件。任何错误都会回退为每组一个文件。这是一个合理的设计。它并非纯确定性，当你调试为什么两个文件被分开评审时，这一区别很重要。

grouping.go

asks the LLM to group files using metadata only (status, path and lines added and removed, no diff content), returning integer indexes rather than paths to save output tokens. Change sets under four files skip the call: they are reviewed together if their total churn is under 200 lines, otherwise one file per sub-agent. Any error falls back to one file per group. That is a sensible design. It is not purely deterministic, and the distinction matters when you debug why two files were reviewed apart.

位置来自引用，从不来自模型。每条评论都附带它所指的现有代码，OCR 在 diff 中查找该文本以计算行号。只有当文本匹配失败时，才会进行第二次模型调用以提取确切的代码片段，然后再次运行匹配。这是该仓库中最具可迁移性的想法：永远不要让语言模型给出行号。让它给出文字，让代码来计数。

过滤器被告知哪种错误更严重。评审过滤器的提示词指出，保留一条错误的评论只会让评审者多花几秒钟，而删除一条正确的评论则会毁掉一个永远无人能看到的发现。它只能删除 diff 能证明是错误的评论，而“我无法验证这一点”意味着保留。这种用平实语言写出的不对称性，正是过滤器能在不严重损害召回率的情况下提升精确率的原因。

基准测试，正确解读

OCR 的 README 展示了 AACR-Bench 上的排行榜：50 个开源仓库、200 个真实 pull request、10 种语言、1,505 个已验证问题。我们针对阅读这些评论的团队重新计算了每一行的含义。下图按 200 个 pull request 进行了除法计算。

来源：仓库基准测试和 AACR-Bench 论文。该图表基于报告结果使用了我们的每 PR 算术。

一旦你做了这个除法，有五点会脱颖而出。

标题是噪音，而不是发现的 bug。使用 Claude 4.6 Opus 时，Claude Code 发现了 1,505 个问题中的 435 个，OCR 发现了 301 个。在全部五组同模型对比中，Claude Code 的召回率都更高。OCR 赢的是数量：每个 PR 大约 3 条未匹配评论，而 Claude Code 是 28 条。面对一个 PR 里三十条评论的审查者，到周三就不看了。

“大约 1/9 的 token”属实。汇总五组同模型对比，Claude Code 使用的 token 是 OCR 的 9.0 倍（按模型不同，比率在 5.4 到 14.7 之间）。

对所有人来说，绝对质量都很低。表格中最好的 F1 是 25.1%。即使是最“安静”的配置，也大约每三条评论中只有一条对应已验证的问题。2026 年末的 AI 审查是第一道初筛，而不是审查者。

这个基准测试并非独立。AACR-Bench（arXiv 2601.19494）由南京大学和阿里巴巴共同撰写。其候选问题由“一个内部审查系统”和 Claude Code 生成，再由 80 名工程师验证，1,505 个问题中有 1,114 个来自这种模型加专家的增强流程。一条评论是否算正确，取决于一个 LLM 匹配器（Qwen3-235B）是否判定它与某个已验证问题等价且行号重叠。这是合理的方法，也意味着精确率是一个下限：流程中没人发现的真实 bug 会被记为误报。这也意味着风格接近内部系统的审查者拥有主场优势。我们希望看到在阿里巴巴没有参与构建的基准上跑出同样的表格。

更新的模型得分更差。Claude 4.8 Opus 在 OCR 1.3.1 下的 F1 为 17.9，而 4.6 为 25.1，召回率几乎减半。该行还混用了版本：Qwen3.8-Max 运行在 OCR 1.8.7 上，而其他模型运行在 1.3.1 上。审查框架是针对构建它时所用的模型的习惯调优的。把模型升级当作审查系统的一次变更，先在自己的样本上重新跑一遍。

我们运行后的发现

我们下载了 1.13.2 Linux 版本，对照公布的 SHA-256 进行了校验，并构建了一个包含一个真实功能提交的小型仓库：一个 Java 服务变更，添加了库存检查和字符串拼接的 SQL 查询；一条没有对应中文版本的英文消息；一个新的 lodash 依赖；JavaScript 中的一处 innerHTML 赋值；一个切换为 pull_request_target 并检出 PR head 的工作流；一个被删除的文件；一个 3,000 个包的 lockfile 和一个 60,000 行的生成式 JavaScript 文件。然后我们运行了 ocr delegate preview 和 ocr delegate rule，它们可以在不调用模型的情况下，准确展示模型会收到什么。

lodash

dependency, an

innerHTML

assignment in JavaScript, a workflow switched to

pull_request_target

that checks out the PR head, a deleted file, a 3,000-package lockfile and a 60,000-line generated JavaScript file. Then we ran

ocr delegate preview

and

ocr delegate rule

, which show exactly what the model would be given without calling one.

这个 Java 发现具有普遍性。Python、PHP 和 Rust 的规则文件都要求模型标记由字符串拼接的 SQL，MyBatis mapper XML 和默认规则也直接点名 SQL 注入。Java 文件使用 java.md，其中完全没有安全章节，Kotlin 和 C++ 文件也没有（C 文件至少覆盖了缓冲区溢出）。默认规则虽然会询问 SQL 注入和 XSS，但只适用于没有专属规则文件的文件类型，因此永远不会作用于 Java 文件。模型仍可能凭自身判断标记出注入问题；但规则表所保证的是，它不会被提示去查看。仓库描述承诺的规则集包含“NPE、线程安全、XSS、SQL 注入”，这在整个规则集层面属实，但对单个 Java 文件而言并不属实。

java.md

, which has no security section at all, and neither do the Kotlin and C++ files (the C file at least covers buffer overflows). The default rules, which do ask about SQL injection and XSS, apply only to file types with no rule file of their own, so they never reach a Java file. The model may still flag the injection on its own judgment; what the rule table guarantees is that it will not be prompted to look. The repository description promises a ruleset with "NPE, thread-safety, XSS, SQL injection", which is true across the rule set and not true for a Java file.

这是 OCR 设计的代价，在此公允地说明。聚焦模型注意力的规则，同时也决定了它不去看什么。精确率和覆盖率来自同一份预算，你应该知道你的工具把它花在了哪里。

优缺点

适用场景与不适用场景

合适的场景。拥有大量 Pull Request 但资深评审者较少的团队，瓶颈在于注意力。希望用一套评审策略覆盖多种语言、并按路径设置规则的平台团队。Agentic 编码环境中 Agent 会打开大量 PR、需要人工分流的场景；我们在 agentic 软件工厂指南中论证过，评审会成为约束，而一个安静的初筛评审者在这里很有帮助。对于前沿部署工程师来说，ocr scan 是快速熟悉陌生客户代码库的方法：对你即将改动的模块运行它，把发现的问题当作风险分布地图来阅读。

ocr scan

is a fast way into an unfamiliar customer codebase: run it over the modules you are about to touch and read the findings as a map of where the risk sits.

不合适的场景。安全评审。受监管的变更——漏掉一个缺陷代价高昂。每周只有少量 PR 的小团队，通用 Agent 额外的召回几乎不占用注意力。以及任何没人维护规则文件的场景，因为规则本身就是产品。

我们的推广方式

• 先影子运行两周。对每个 PR 运行 OCR，但结果发布到日志而非 PR。让评审者对一部分评论标注为有用、错误或琐碎。这样你就得到了自己的精确率，这是唯一重要的数字。
• 补写你缺失的规则。对于 Java，在自定义规则文件中加入注入、反序列化、路径遍历和密钥检查。为生成代码、第三方引入代码和快照添加忽略规则。
• 固定版本和模型。在更改任一项之前，重新运行你标注过的样本。已发布的表格显示，模型升级可能使召回率减半。
• 在 CI 中保留安全扫描器和依赖扫描器。OCR 会排除 lockfile，且不是 SAST 工具。
• 衡量被实际处理的内容。跟踪评论中促成代码修改的比例。如果降到大约四分之一以下，说明人们已经不再阅读，这个机器人就成了成本。
• 按计划在高风险目录上搭配一个通用 Agent，以提交 issue 而非评论的方式。

成本很容易估算。基准测试中的 OCR 运行每次评审使用 334K 到 743K tokens。按每百万输入 token 3 美元的示意价格计算，40 万 token 在缓存前约为每个 Pull Request 1.20 美元，一个每月合并 500 个 PR 的团队大约花费 600 美元。而不用在每个 PR 中阅读 25 条额外评论所节省的评审时间，其价值比这高出一个数量级。

即使你从不安装它，也能从中得到什么

OpenCodeReview 是我们应用于面向客户的每个 Agent 的一条规则最清晰的公开示例：把判断交给模型，把簿记交给代码。文件覆盖、位置、规则选择和可恢复性都是簿记。它们应该是你可以测试、预览和 diff 的代码。这与 harness 工程是同一课，也是为什么编码 Agent 如何找到代码与你选择哪个模型同样重要的原因。

如果你面试应用 AI 工程师或 FDE 职位，请准备好在系统设计题中遇到类似这样的问题：“设计一个人们不会屏蔽的 AI 代码审查工具。”优秀的回答会将确定性步骤与模型步骤区分开来，在团队自己的 PR 上衡量精确率，并把审查者的注意力当作稀缺资源来讨论。请在我们的系统设计题以及 RAG 和 Agent 题中练习这类回答，并阅读 SWE-bench，培养本文所依赖的基准测试解读习惯。

把它转化为 offer。练习它所对应的真实面试题和概念：

FAQ

OpenCodeReview（OCR）是阿里巴巴推出的一款采用 Apache-2.0 许可证的命令行 AI 代码审查工具，在内部使用后于 2026 年开源。它读取 Git diff，用代码决定要审查哪些文件以及适用哪些规则，为每组相关文件运行一个可调用工具的 LLM Agent，并发布行级评论。它兼容 OpenAI 和 Anthropic 的端点，并提供 Claude Code、Codex、Cursor、Kimi Code 和 OpenCode 的插件。

在其自行发布的基准测试中，它更精确，也安静得多：每个 pull request 大约 3 到 5 条评论，而使用相同模型的 Claude Code 是 6 到 30 条，token 用量约少 9 倍。在每一组同模型对比中，Claude Code 发现的真实问题都更多。当审查者注意力是瓶颈时，使用 OCR；当漏掉一个缺陷的代价高于阅读噪音的代价时，使用通用 Agent，或两者并用。

就绝对数值而言，并不算高。在 AACR-Bench（200 个 pull request，1,505 个已验证问题）上，OpenCodeReview 表格中最佳配置的 F1 为 25.1%：它找到了 20% 的已知问题，其评论中约三分之一命中了某个问题。精确率只是一个下限，因为基准测试只知道有人发现过的问题，但与细心的资深人类审查者相比，差距仍然很大。

部分覆盖。它针对 JavaScript 和 TypeScript、Python、Go、PHP、Rust、GitHub Actions 工作流以及 MyBatis mapper XML 的规则文件包含安全检查。在 1.13.2 版本中，Java、Kotlin 和 C++ 的规则文件没有任何安全检查，而提到 SQL 注入的默认规则只适用于没有专属规则文件的文件类型。请为这些语言添加你自己的安全规则，并在 CI 中保留一个专门的安全扫描器。

工具本身免费；你为模型 token 付费。其基准测试报告显示，使用 OCR 每次审查消耗 334K 到 743K token（跨模型），而 Claude Code 为 200 万到 570 万。按每百万输入 token 3 美元的示例价格计算，约 400K token 大致相当于每个 pull request 1.20 美元（未计缓存）。请核对你自己供应商的价格和缓存费率。

讨论（5）

行号这一点值得成为一条普适规则，而不仅仅适用于审查机器人。任何时候 Agent 编辑或引用文件，都应让它引用原文，并让代码来定位位置。我们把一个文档批注 Agent 迁移到了同样的模式，错位的编辑就消失了。

读者提问：你会让 OCR 和 Claude Code 并行运行，还是二选一？

并排运行一个月，做不同的工作。OCR 在每个 PR 上发内联评论，因为其数量尚可容忍。通用 Agent 则按计划在风险较高的目录（认证、支付、迁移）上运行，提交 issue 而不是评论。衡量哪些评论被真正处理，然后砍掉人们学会忽略的那一个。

Opus 4.8 那一行是表格中无声的警告。同样的工具，更新的模型，F1 从 25.1 降到 17.9，召回率几乎减半。评审框架是针对某个模型的习惯调校的。在 CI 中固定模型版本，升级前用自己的样本重新跑一遍。

只删除 diff 能证明有误的评论的事实核查提示词是好的设计。大多数团队把过滤器写成相反的逻辑，然后纳闷为什么机器人从来不说有用的东西。非对称代价应该用平实的语言写进提示词里。