文章总结： 阿里开源AI代码评审工具OpenCodeReview，通过将选文件、打包、配规则等步骤交给代码执行，模型仅负责分析，实现比ClaudeCode更高的精确率（25.10%对11.57%），但召回率较低（20%对28.9%），token消耗约为ClaudeCode方案的1/9。提供本地CLI、委托模式、GitHubActions三种接入方式，支持rule.json配置团队规范。接入前需注意5条限制：召回率上限约20%、默认不审测试文件、不会自动打码secret、部分文件审失败仍返回0、跨组问题不会被报出。 综合评分： 85 文章分类： AI安全,安全工具,代码审计,安全开发

阿里 AI 代码评审开源：3 种接法，5 条限制清单

原创

AI安全工坊 AI安全工坊

AI安全工坊

2026年9月28日 16:20 江苏

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

阿里 AI 代码评审开源：3 种接法，5 条限制清单

「AI 写的 PR 一天十几个，一行行看不过来，直接合又不放心，有没有工具能先筛一遍？」

阿里今年 5 月开源的 OpenCodeReview 做的就是这件事。它读取 Git 改动，交给你自己配置的大模型，输出定位到具体代码行的评审意见，可以在本地跑，也可以挂到 GitHub、GitLab 的 PR 流程里。截至 9 月 28 日，仓库有 41,972 个星标，最新版本 v1.12.9，Apache-2.0 协议。

项目团队在博客里说，它在阿里内部已经用了两年，开源的起因就是越来越多人抱怨同一件事：代码是 AI 写的，看不过来，不敢合。

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

下面按官方文档 v1.12.9 整理：它和直接让 Claude Code 评审有什么区别，三种接法各适合谁，规则文件怎么写，以及接入前要先知道的 5 条限制。本文没有在本号环境安装运行，基准数字均为官方或第三方公布的结果。

一、它和 Claude Code 直接评审的区别，附官方基准

很多人已经试过让 Claude Code 带一个评审 Skill 去看 PR。OpenCodeReview 的 README 把这种做法的问题归成三条：改动一多，Agent 会挑着看，漏掉部分文件；报出的问题行号对不上；提示词稍微一改，评审质量就明显波动。

它的做法是把不能出错的步骤交给代码执行，模型只负责分析：

• 选文件：由程序决定哪些文件要审、哪些过滤掉，二进制、依赖目录、测试文件按规则排除。
• 打包：把相关文件分成一组，比如中英文两个 message_*.properties 放在一起，每组交给一个独立的子 Agent，大改动可以并发审。
• 配规则：按文件类型和路径匹配评审规则，只把相关规则给模型看。
• 定位和复核：评论的行号定位、评论内容复核由单独模块处理。

模型这一侧只做动态判断：读完整文件、搜代码库里的调用关系、决定要不要继续查。

官方用自建的 AACR-Bench 做了对比，数据集来自 50 个开源仓库的 200 个真实 PR，覆盖 10 种语言，1,505 条问题由 80 多名资深工程师标注。同一个底层模型下，OpenCodeReview 和 Claude Code 的结果如下：

| 底层模型 | 工具 | F1 | 精确率 | 召回率 | 平均耗时 | 平均 token | | — | — | — | — | — | — | — | | Claude-4.6-Opus | OpenCodeReview v1.3.1 | 25.10% | 33.90% | 20.00% | 1m23s | 385K | | Claude-4.6-Opus | Claude Code v2.1.169 | 11.57% | 7.23% | 28.90% | 13m6s | 5,664K | | Claude-4.8-Opus | OpenCodeReview v1.3.1 | 17.90% | 37.80% | 11.70% | 1m6s | 352K | | Claude-4.8-Opus | Claude Code v2.1.169 | 14.13% | 15.93% | 12.70% | 5m38s | 2,062K |

来源：官方 README 基准图，测试版本为 v1.3.1，当前版本已到 v1.12.9。

按这张表，它报出来的问题更可能是真的。以 Claude-4.6-Opus 为例，Claude Code 报了 5,980 条，其中 435 条命中标注；OpenCodeReview 报了 889 条，命中 301 条。开发者要逐条看的误报因此少很多。

代价是找到的问题更少。同一个模型下，Claude Code 的召回率是 28.90%，OpenCodeReview 是 20.00%。README 明确写了这是「精确优先」的有意取舍。

README 称 token 消耗约为 Claude Code 方案的 1/9。按上表两组数据算，实际倍数分别约为 14.7 倍和 5.9 倍，和模型有关。

二、三种接法：本地命令、借用 Agent 额度、挂到 PR

安装前需要 Node.js 18 以上和 Git 2.41 以上：

npm install -g @alibaba-group/open-code-review

装好后命令是 ocr。接下来按使用场景选接法：

| 接法 | 谁调用大模型 | 要不要配 API Key | 适合 | | — | — | — | — | | 本地 CLI | OpenCodeReview | 要 | 提交前自己先审一遍 | | 委托模式 | 你的编码 Agent | 不要 | 已经订阅 Claude Code、Codex、Cursor，想用现有额度 | | GitHub Actions / GitLab CI | OpenCodeReview | 要，放进 CI secret | 团队每个 PR 自动出评审评论 |

本地 CLI

先配模型，交互界面会引导你选服务商、填 Key，并自动测试连通性：

ocr config provider ocr config model

然后在项目目录里评审：

ocr review                                  # 工作区里所有未提交的改动 ocr review --from main --to feature-branch  # 分支从 main 分出去之后的改动 ocr review --commit abc123                  # 单个 commit ocr scan --path internal/agent              # 没有 diff 时整目录审计

它兼容 OpenAI 和 Anthropic 两种接口协议，模型可以换成自己能用的。

委托模式：不配 Key，用 Agent 自己的额度

委托模式下，OpenCodeReview 只负责挑文件和给规则，评审由 Claude Code、Codex 等 Agent 用自己的模型完成，OpenCodeReview 这边不调用任何模型。

Claude Code 用户装一个命令文件即可：

mkdir -p .claude/commands curl -o .claude/commands/delegate-review.md \   https://raw.githubusercontent.com/alibaba/open-code-review/main/plugins/open-code-review/claude-code/commands/delegate-review.md

支持 Skill 的其他 Agent：

npx skills add alibaba/open-code-review --skill open-code-review-delegate

它背后是两条命令：ocr delegate preview 列出要审的文件和被排除的原因，ocr delegate rule <文件> 给出每个文件对应的评审规则。

另有一个 Claude Code 插件 /open-code-review:review，由 OpenCodeReview 调用你配置的模型。文档写明这个命令默认会自动修复它判定值得采纳的问题。如果你只想看评论，改用 Agent Skill 版本，它会先问再改。

GitHub Actions：一个文件加两个 secret

官方 workflow 可以直接下载到仓库：

mkdir -p .github/workflows curl -o .github/workflows/ocr-review.yml \   https://raw.githubusercontent.com/alibaba/open-code-review/main/examples/github_actions/ocr-review.yml

然后在 Settings → Secrets and variables → Actions 里配置：

| Secret | 必填 | 说明 | | — | — | — | | OCR_LLM_URL | 是 | 模型 API 地址 | | OCR_LLM_AUTH_TOKEN | 是 | 模型 API 的 Key | | OCR_LLM_MODEL | 否，但没有默认值 | 模型名，实际必须设置 | | OCR_LLM_USE_ANTHROPIC | 否 | 用 Claude 系列模型时设为 true |

回贴评论用的 GITHUB_TOKEN 由 GitHub 自动提供。整条流程如下：

PR 新建时自动触发，评审者在 PR 下评论 /open-code-review 可以手动重跑。GitLab CI、Gerrit、Bitbucket 的示例在仓库 examples/ 目录里。

官方文档提到两个配置细节：

2. --background

   是「效果最显著的单一参数」，建议把 PR 标题传进去，标题符合 feat(auth): add OAuth2 support 这类格式时效果更好。

3. PR 标题要通过 env: 传入脚本。直接把 ${{ github.event.pull_request.title }} 写进 run:，带 shell 特殊字符的标题会在 runner 上被执行。

- name: Run OCR review   env:     PR_TITLE: ${{ github.event.pull_request.title }}     BASE_REF: ${{ github.base_ref }}     HEAD_REF: ${{ github.head_ref }}   run: |     ocr review \       --background "$PR_TITLE" \       --from "origin/$BASE_REF" \       --to "origin/$HEAD_REF" \       --format json --audience agent

控制成本可以用 action 的 effort 参数（low / medium / high，默认 medium 跑 2 轮，low 跑 1 轮，文档称成本约减半）和 max_tokens_budget（token 总量上限）。

三、规则文件：把团队规范写进 rule.json

OpenCodeReview 内置了 Java、Python、Go 等几十种语言和配置文件的评审规则，覆盖空指针、线程安全、XSS、SQL 注入等问题。团队自己的规范写在项目根目录的 .opencodereview/rule.json，随仓库提交：

{   "rules": [     {       "path": "src/api/**/*.go",       "rule": "Every public handler must `defer tx.Rollback()` immediately after starting a transaction."     },     {       "path": "**/*mapper*.xml",       "rule": "Check SQL for injection risks, missing parameter binding, and unclosed XML tags."     }   ] }

规则按四层依次查找，先匹配到的那条生效：

| 优先级 | 来源 | 路径 | | — | — | — | | 1 | 命令行参数 | ocr review --rule xxx.json | | 2 | 项目配置 | <仓库>/.opencodereview/rule.json | | 3 | 个人全局配置 | ~/.opencodereview/rule.json | | 4 | 内置规则 | 随程序发布 |

这里有一个容易踩的坑：如果你写了一条匹配所有文件的 **/* 规则，它会替换掉内置的各语言规则。想在内置规则之上再加一层，需要加上 "merge_system_rule": true：

{   "rules": [     {       "path": "**/*",       "rule": "Security review: flag hardcoded secrets, unvalidated redirects, and missing authz checks.",       "merge_system_rule": true     }   ] }

规则没按预期生效时，用 ocr rules check <文件路径> 查看这个文件最终用的是哪一层、哪条规则。

四、接入前先看的 5 条限制

以下几条都写在官方文档或第三方评测里，决定要不要接之前值得先看一遍。

1. 召回率上限约 20%，独立复测结果有争议。 官方基准里最好的配置召回率是 20.00%，意味着标注出来的问题有八成它没找到。HCLTech 的 Daniel Vaughan 在分析文章里也指出，保证精确率的分组机制，同时限制了它发现跨文件、架构层面问题的能力。Shopify 工程师 Tom Rochette 的评测提到，目前唯一一次独立基准测试在 10 个 PR 上的精确率约 12%，维护者认为是工具调用异常，已经修复，但修复后还没有独立复测。

2. 默认不审测试文件。*_test.go、*.test.ts、__tests__/ 等测试文件会被内置规则排除。AI 同时改了业务代码和测试时，测试部分不会出现在评审里。需要审测试的话，在 rule.json 里用 include 重新纳入。

3. 不会自动把 secret 打码。 diff 和工具读取的代码片段会发到你配置的模型端点。它会跳过 .ssh/、id_rsa、.npmrc、.env 等已知敏感路径，但写在普通代码文件里的 Key 会原样发出去。文档建议的做法是：不把 secret 提交进仓库，把敏感文件加进 exclude，或用 pre-commit 在提交前脱敏。脱敏功能在路线图上，目前没有。

4. 部分文件审失败，命令仍然返回 0。 一个文件出错不会拖垮整次评审，这是有意设计，但 CI 里看到绿色不代表每个文件都审了。需要检查 JSON 输出里的 warnings 字段。设置了 max_tokens_budget 时，超预算跳过的文件会记为 failed(budget)，同样返回 0。

5. 跨组的问题不会被报出来。 同一组文件共享一个对话，模型可以在组内交叉推理。其他组的文件它只能通过工具读取作为参考，文档写明这些地方发现的问题「禁止作为评论目标」。一个改动牵连多个模块时，模块之间的问题要靠人看。

五、怎么开始

先挑一个改动频繁的仓库，在本地跑：

ocr review --preview

这条命令不消耗 token，只列出会审哪些文件、哪些被排除以及原因。确认范围符合预期后，再挂上 GitHub Actions 跑一段时间，记录评论里有多少被开发者采纳、多少是误报，再决定要不要推到其他仓库。

试跑期间，合并前的人工评审照常保留。

相关链接

• 仓库：https://github.com/alibaba/open-code-review
• 官方文档：https://open-codereview.ai/docs
• 中文 README：https://github.com/alibaba/open-code-review/blob/main/docs/i18n/README.zh-CN.md
• GitHub Actions workflow：https://github.com/alibaba/open-code-review/blob/main/examples/github_actions/ocr-review.yml
• action 参数说明：https://github.com/alibaba/open-code-review/blob/main/action.yml
• 基准数据集 AACR-Bench：https://huggingface.co/datasets/Alibaba-Aone/aacr-bench
• 团队开源两个月复盘（中文）：https://github.com/alibaba/open-code-review/blob/main/pages/src/content/blog/zh/oss-two-month-retrospective.md
• InfoQ 中文报道：https://www.infoq.cn/article/jJIXCaLHUvPgswTOZ1uQ
• Tom Rochette 评测：https://tomrochette.com/agents/open-code-review/
• Daniel Vaughan 分析：https://codex.danielvaughan.com/2026/08/11/opencodereview-deterministic-code-review-agent-codex-cli-rule-dispatch-grounded-review-independent-reflection/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI安全工坊 AI安全工坊 AI安全工坊《阿里 AI 代码评审开源：3 种接法，5 条限制清单》