阿里内部跑了两年的 AI 代码审查工具开源了:终于不用再把Review 全押给 Prompt

点击上方程序员成长指北，关注公众号

回复1，加入AI Coding 群

AI 代码工具把“写出来”这件事变快以后，很多团队很快会撞上另一个问题：PR 的数量和改动量都涨了，Review 却没有同样扩容。

让 Claude Code、Codex 或 Cursor 帮忙看一遍改动，当然有用。但只要 diff 稍微大一点，大家大概率都遇到过几个场景：它漏看了几个文件；它指出的问题很像那么回事，行号却落在注释上；同一套规则今天执行得不错，换一次上下文又像没读过一样。

这不是模型“不够聪明”这么简单。代码评审里有一部分事，本来就不应该依赖模型临场发挥。

最近我仔细看了阿里开源的 OpenCodeReview（https://github.com/alibaba/open-code-review）（命令行是 ocr）。它最值得借鉴的地方，不是“又有一个 AI Review 工具”，而是把评审拆成两层：让程序保证流程，让 Agent 做理解和判断。 这套分工对任何正在做 AI Coding 工作流的团队都有参考价值。

本文适合：已经用 AI 写代码、希望把本地检查或 PR 评审做得更稳定的开发者和团队。它不是让 AI 替你签字合并，而是给人工 reviewer 一份更干净、可复核的第一轮意见。

OpenCodeReview 官方项目概览图

为什么写这篇文章

很多开发者都知道，给 Agent 一段 git diff 再说一句“帮我 review”，通常能找到一些问题。小改动时，这样做的性价比不错。

但当它变成团队里的固定流程，问题就换了：不是这次能不能找到一个 bug，而是每次到底审了什么、没审什么、为什么这样判断、失败了该不该阻塞。前面这些问题如果没有答案，评审结果就很难进入 CI，也很难建立信任。

OpenCodeReview 官方给出的 benchmark 也在说明这一点：同一底层模型下，它用真实 PR 的基准测试比较通用 Agent，在 Precision 和 F1 上更高、Token 消耗更低；代价是 Recall 更低。这个取舍很诚实——它选择少报一点，换取让人工少花时间确认误报。基准覆盖 50 个开源仓库、200 个真实 PR、10 种语言，并由 80 多位工程师交叉标注了 1,505 个缺陷。具体数字仍要用自己的仓库复测，但方向是对的：评审不是只追求“能多找多少”，还要控制“人需要白看多少”。

本文你能学到什么

为什么一份 Review Skill 或 Prompt 很难单独承担团队级评审；
OpenCodeReview 如何把确定性流程和 Agent 判断拆开；
怎样先在本地验证，再接进 PR，而不是一上来就制造更多评论噪声；
在 Claude Code / Codex 直接评审和独立评审引擎之间，怎么选。

OpenCodeReview 的工程化评审流水线

先看结论：Skill 没有过时，但它不该独自背流程

这里很容易走到两个极端。

第一种是觉得有了 OCR，就不需要 Claude Code 的 review skill 了；第二种是觉得“我写一份更长的规则”就能覆盖一切。两种都不太对。

Skill 很适合作为入口：告诉 Agent 团队最在意的风险、检查顺序、输出格式，甚至把它接到日常命令里。它的优点是轻、灵活，适合一个人临时检查一次改动。

但下面几件事，不能只靠自然语言约束：

评审里的问题	只靠 Prompt 的风险	更适合的做法
哪些文件必须审	Agent 可能挑几个文件就结束	从 Git diff 计算范围并输出 preview
哪条规则作用于哪个文件	同一句规则被模型理解成不同重点	用路径匹配和规则文件决定命中项
一次评审何时算结束	模型没调用完成工具，流程却静默结束	由程序设置轮数、有效调用和失败条件
评论落在哪一行	行号漂移，人工要重新找位置	用 diff 片段匹配，失败后再重定位
多文件改动怎么跑	上下文越塞越大，漏项难追踪	拆分任务并明确并发和隔离边界

一句话说，Skill 是给 Agent 的工作说明；评审引擎是给流程的验收标准。 团队需要两者，不是二选一。

OpenCodeReview 是怎么把流程“卡住”的

从 ocr review 开始到评论输出，OCR 的架构并不神秘，但每一步都有明确责任边界。

1. 先算清楚 diff，再让模型开始说话

它支持工作区、单个 commit 和分支区间三种来源：

# 当前工作区：暂存、未暂存、未跟踪的改动 ocr review

# 评审从 main 分叉到 feature 分支的改动 ocr review --from main --to feature-branch

# 只看一个提交 ocr review --commit abc123

真正值得养成习惯的是这条：

ocr review --preview

它不会调用模型，只展示哪些文件会被保留、哪些被过滤。很多评审“没发现问题”，其实不是模型判断错了，而是关键文件压根没进入题面。把 preview 当成评审前的单元测试，尤其适合刚接入项目规则时。

2. 过滤和规则匹配，由代码而不是模型决定

OCR 会过滤二进制文件、用户排除路径、不支持的后缀、默认测试文件路径等；项目还可以用 .opencodereview/rule.json 配置排除项和按路径生效的规则。

比如，下面这类规则比“帮我注意安全”更容易落地：

{  "exclude": ["**/generated/**", "**/*.lock"],  "rules": [    {      "path": "**/*Controller.java",      "rule": "检查鉴权、参数校验、租户隔离和错误码兼容性；新增查询必须给出租户条件证据",      "merge_system_rule": true    },    {      "path": "**/*.java",      "rule": "新增查询必须确认租户隔离；缺少租户条件时给出调用链证据",      "merge_system_rule": true    }  ]}

这里有个很实用的细节：同一层规则只取第一个匹配项。因此更具体的 Controller 规则应该放在通用 Java 规则前面。写完别靠猜，直接用 ocr rules check <文件路径> 看它到底匹配了哪条。

规则也不要变成第二份 ESLint。格式、import 顺序和可自动修复的 lint 项交给静态检查；OCR 的规则应该优先写“这个项目最贵的错误”，例如权限越权、租户隔离、金额精度、幂等性、兼容性。

3. Agent 只负责它擅长的动态部分

文件进入队列后，每个文件会在独立的子任务里评审。小 diff 直接进入主循环；变更行数达到阈值时，先让模型做一份检查计划，然后再读取完整文件、搜索代码库、查看其他变更文件。

这正是 Agent 该发挥的地方。它可以判断“只看 diff 不够，我还要找谁调用了这个函数”“这个改动要不要读配置和测试”；但它不该自行决定“我今天只看这三个文件就算完成”。

OCR 对主循环还设了工具调用上限、连续无有效结果的停止条件，以及上下文压缩和 token 预算守卫。你不必记住这些内部参数，记住一个工程原则就够了：模型可以探索，流程不能失控。

4. 评论先定位，再过滤，最后输出

很多 AI Review 工具最影响体验的，往往不是有没有找到问题，而是评论贴不到正确的行。

OCR 的做法是让模型在评论中给出 existing_code，再用程序把这段代码和 diff 做匹配，解析到实际的起止行。如果匹配失败，才触发一次重定位；评审结束后还会让过滤阶段对照当前 diff，删除能够证明为误报的评论。

这不代表它不会误报，也不代表行号永远正确。它只是把“定位”从模型顺带完成的一步，升级成单独可验证、可回退的组件。对 PR 评论来说，这个区别很大：少一次人工找代码，意见才更有机会被真正处理。

用起来之前，先做一次最小验证

官方前置条件是 Git 2.41+、Node.js 18+。本地先固定一个版本跑通，不要在第一次尝试时就把它挂到所有 PR 上。

# 安装并确认版本npm install -g @alibaba-group/open-code-reviewocr version# 默认模式下配置模型；委托模式不需要 OCR 自己的 API Keyocr config providerocr config modelocr llm test

进入一个有真实改动的仓库，我建议按下面顺序走：

ocr review --preview
：范围是否正确？有没有把 generated、lock 文件和无关测试混进来？
先只写 3～5 条和正确性直接相关的项目规则，再执行 ocr rules check 验证命中。
给一次业务背景。比如：ocr review --background "本次改动修复支付回调幂等性，不能改变旧接口返回码"。
人工读一轮输出，记录“真正有用”“无效”“漏掉”的问题类型。

第四步看起来最朴素，却决定了它能不能进入团队流程。别用“模型看起来很聪明”作为验收标准；挑 10～20 个历史 PR，统计哪些评论真被采纳、哪些问题总是漏掉、每次等待和 token 大致是多少。这样再调规则、模型和并发，才有依据。

Claude Code、Codex 和 OCR，到底怎么配合

如果你已经在用 Coding Agent，不需要切换阵营。OCR 有 Claude Code、Codex、Cursor 等集成，也提供委托模式：OCR 做文件选择和规则解析，宿主 Agent 用自己的模型来完成评审。

可以按下面这个简单规则选：

场景	推荐默认动作	原因
个人改了几十行，想快速找明显问题	直接让 Claude Code / Codex review	上下文少，交互更快
改动跨多个目录，担心漏文件	先跑 `ocr review --preview`，再评审	先校验范围，减少“看起来审了”的错觉
团队有固定的业务风险	用 `rule.json` 把规则沉淀下来	不靠每个人反复复述同一段要求
每个 PR 都要跑第一轮检查	把 OCR 放进 CI，人工负责最终判断	输出、失败和审查范围可追踪
不能把代码发到公共服务	配置可控端点，先核对组织合规要求	OCR 在本地运行，但模型端点仍决定数据去向

最后一行尤其要注意。“OCR 本地运行”不等于“代码天然不出内网”：它会把内容发送给你配置的模型端点。私有部署、企业网关和审计策略是否满足要求，仍要由你们自己确认。

接入 CI 前，有一个安全边界不能跳过

把评审意见自动贴到 PR 很诱人，但 CI 里同时存在两个高风险输入：来自 PR 的代码，以及拥有模型凭据、评论权限的环境。

因此建议按官方 CI 文档的原则做两件事：模型 Token 只放 Secret；使用带 Secret 的 job 时，不执行 PR 提交进来的脚本或测试。先把 workflow 和规则合进默认分支，再新建一个测试 PR，检查 Actions 日志、汇总评论、行内评论和失败 Artifact 是否符合预期。

这一步不是“部署细节”。如果评审机器人为了看一段不可信代码而把 Secret 暴露出去，工具越自动化，事故半径反而越大。