阿里把内部用了两年的AI代码审查工具开源了:精度反超Claude Code,Token只花1/9

确定性工程 × LLM Agent，给代码审查装上硬约束

用AI写代码的人越来越多，但代码审查这件事，反而越来越难了。

改动涉及十几个文件，Reviewer 没空细看；自己 review 自己的代码，越看越顺眼；等到线上出了空指针，才发现这个问题 review 的时候就应该看出来。

现在市面上用 Claude Code、Cursor 做代码审查的方案不少，但踩过坑的人都知道三个典型痛点：

覆盖不全——改动一大，Agent 倾向于“抄近路”，挑着看几个文件，其他直接略过。一次提交改了 30 个文件，最后报告里可能只出现 5 个。

位置漂移——报出来的问题行号对不上、文件指错位置。审查意见说“第 42 行有空指针风险”，你跳过去一看，第 42 行是个空行。

质量不稳——提示词稍微改一改，审查质量就大幅波动。今天能查出来的问题，明天换个措辞可能就漏了。

阿里集团内部有一支官方 AI 代码审查助手，跑了两年，服务了数万名开发者，识别了数百万个代码缺陷。这套东西经过大规模验证之后，在 2026 年 5 月正式开源，取名 Open Code Review（CLI 命令 ocr）。

项目地址：https://github.com/alibaba/open-code-review

它和通用Agent有什么不一样？

通用 Agent 做代码审查的问题，根源不在模型笨，而在架构缺约束——纯语言驱动的审查流程，没有对审查过程本身的硬控制。

Open Code Review 的解法非常直接：把确定性工程和 Agent 各自擅长的事分开，该用代码保证的绝不让模型猜。

具体怎么分工？

确定性工程负责“绝对不能出错”的环节：

• 精确文件选择：自动判断哪些文件需要审、哪些该过滤，避免漏审

• 智能文件分束：把相关文件打包成一个审查单元。比如 message_en.properties 和 message_zh.properties 会捆在一起审，大改动自动拆成多个子任务，支持并发

• 规则匹配：根据文件特征匹配审查规则。Java 文件重点看 NPE、线程安全，Web 文件看 XSS、SQL 注入

• 评论定位：把模型生成的评论精确对应到代码行

• 评论反思：独立校验评论内容的准确性

LLM Agent 负责“需要理解上下文”的环节：

• 动态决策：根据上下文决定要不要读取更多文件、要不要搜索代码库

• 动态上下文检索：读取完整文件内容、检索相关代码、对比多个改动文件

• 深度审查：给出具体、有上下文的缺陷描述

这套分工的逻辑很清晰：工程保证“不遗漏、位置准、规则对”，Agent 负责“看得懂、说得清”。

打个比方：通用 Agent 像是一个什么都懂但容易走神的资深工程师，你让他审代码，他可能看几个文件就“觉得差不多了”。Open Code Review 则是给这位工程师配了一个严格的流程督导——哪些文件必须看、看到第几行、按什么规则看，全都有硬性规定，工程师只负责在规定的框架内做判断。

效果怎么样？看一组benchmark数据

Open Code Review 团队建了一个真实的代码审查基准测试：从 50 个流行开源仓库、200 个真实 Pull Request、10 种编程语言中构造数据集，由 80 多位高级工程师标注了 1505 个真实问题。

和通用 Agent（Claude Code）对比，结果是这样的：

在相同底层模型下：

• 精度（Precision）和 F1 综合得分显著高于通用 Agent——也就是说，它报出来的问题里，真正是缺陷的比例更高，误报更少

• Token 消耗只有约 1/9——同样的模型，成本降到零头

• 审查速度更快——对 CI 流水线来说，这意味着更低的延迟

需要说明的是，Open Code Review 的召回率（Recall）低于通用 Agent——这是有意为之的设计取舍：宁可少报，不可误报。

换句话说，如果你需要的是“宁可信其有”的深度审计，它可能不是最合适的。但如果你需要的是低噪声、高可信度的日常审查，让开发者真正愿意看审查意见而不是直接忽略，这个取舍方向是对的。

三种用法，一条命令跑起来

安装

bash

npminstall-g @alibaba-group/open-code-review

装完后 ocr 命令全局可用。

配置模型

bash

ocr config provider   # 选内置 provider 或自定义ocr config model      # 选模型，自动测连通性

支持 OpenAI、Anthropic 等兼容接口，也可以自己加自定义 provider。配置文件在 ~/.opencodereview/config.json，也支持命令行直接设置，方便脚本和 CI 使用。

三种审查模式

bash

# 工作区模式：审所有 staged/unstaged/untracked 改动ocr review# 分支对比ocr review --from main --to feature-branch# 单个 commitocr review --commit abc123

整个流程大致是：Git diff → 文件选择 → 文件分束 → 规则匹配 → 每个 bundle 交给 LLM Agent → 生成评论 → 行级定位 → 反思校验 → 输出结构化评论。

实际跑下来，一个中等规模的 PR 大概 1-3 分钟能审完。

除此之外，ocr scan 可以审查整个文件，适合审计不熟悉的代码库或没有有意义 diff 的目录。

接进CI流水线，PR自动审查

Open Code Review 支持集成到 CI/CD 流水线中，自动化审查 Merge Request 和 Pull Request。

项目提供了现成的集成示例：

• GitHub Actions：仓库里提供了即用的 workflow 示例，触发条件是 pull_request_target (opened) 或评论以 /open-code-review 或 @open-code-review 开头——后者允许 Reviewer 在 PR 上评论以按需重新运行 OCR

• GitLab CI：examples/gitlab_ci/ 目录下提供了完整的 GitLab CI 集成示例

• GitFlic CI：也提供了对应的集成示例

此外，OCR 还提供了 Claude Code 插件和 Skill 支持。你可以直接复制命令文件，在 Claude Code 里使用 /open-code-review 斜杠命令，让 Agent 自主决定是否应用修复建议。

几个你需要注意的点

大 MR 场景下的 Token 成本：有社区 Issue 反馈，在某个较大的私有 MR 中，流程在超时前进行了大量搜索、读取文件和模型请求，产生了较高的 Token 消耗。如果你的 MR 规模很大，建议关注一下成本控制。

召回率偏低：如前所述，这是设计取舍。如果你的场景需要“尽可能发现所有潜在问题”，它可能不如通用 Agent 全面。

跨模块问题的局限：实际体验反馈显示，它对单文件的逻辑漏洞、空指针、资源泄漏这些“局部问题”反应很快；但涉及跨模块调用链、历史 commit 引入的回归、团队内部的隐式规范时，表现会下降。

Apache-2.0 协议，完全开源：项目采用 Apache-2.0 协议，可以自由商用、修改和分发。主语言是 Go，通过 npm 分发（@alibaba-group/open-code-review），也提供安装脚本和 release binaries。

社区活跃度：项目创建于 2026 年 5 月 18 日，截至 9 月中旬已收获 约 2.5 万 Star、1800+ Fork、160 位贡献者，多次登上 GitHub Trending 榜首。公开活跃期约 4 个月，社区仍在持续贡献 PR 和修复。

适合谁用？

• 技术团队：想统一团队的 AI 代码审查标准，降低 Review 噪声

• 独立开发者：一个人写代码，需要一个靠谱的“虚拟 Reviewer”帮你把关

• DevOps 工程师：想把代码审查接进 CI 流水线，实现 PR 自动审查

• 任何对“AI 工程化”感兴趣的人：想理解确定性工程和 Agent 如何各司其职

结语

Open Code Review 最值得关注的地方，不是它背后有阿里的品牌背书，而是它解决问题的方式。

通用 Agent 做代码审查，靠的是“让 AI 更聪明”。Open Code Review 走的是另一条路——把不能出错的环节从 LLM 手里拿走，交给确定性工程。文件选择、规则匹配、行号定位这些“绝对不能让模型猜”的事，用代码保证；动态决策、上下文理解、深度分析这些“模型真正擅长”的事，交给 Agent。

这个思路，其实适用于所有 AI 落地的场景：不是让 AI 做所有事，而是让 AI 做它最擅长的那部分，剩下的交给工程。

GitHub 地址：https://github.com/alibaba/open-code-review

官网：https://open-codereview.ai

Benchmark 数据集：https://huggingface.co/datasets/Alibaba-Aone/aacr-bench