别把 Code Review 全交给一份 Prompt：阿里 OpenCodeReview 的工程化评审思路开源了！

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

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

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

最近我仔细看了阿里开源的 OpenCodeReview（命令行是 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 直接评审和独立评审引擎之间，怎么选。

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

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

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

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

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

一句话说，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-review
ocr version

# 默认模式下配置模型；委托模式不需要 OCR 自己的 API Key
ocr config provider
ocr config model
ocr llm test

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

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

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

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

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

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

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

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

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

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

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

总结：别让模型承担它不擅长的确定性

OpenCodeReview 不会替代人工 Review，也不可能消灭误报和漏报。它真正提供的是一条更清楚的边界：模型负责理解改动、追上下文、提出怀疑；程序负责确保审查范围、规则匹配、停止条件和评论落点都有迹可循。

如果你现在只是偶尔让 Agent 看一次改动，先把任务说具体就够了；如果同一套检查要在多人、多个 Agent 和 CI 中重复发生，就值得把流程从 Prompt 里拿出来。代码生产越来越快之后，Review 的升级不是让模型说得更多，而是让每一条意见更容易被相信、被定位、被处理。

你可以立刻执行的检查清单

• 选一个有历史 PR 的小仓库，而不是生产主仓库，安装并运行 ocr review --preview。
• 写下团队最贵的 3～5 类错误，放进 .opencodereview/rule.json，并用 ocr rules check 验证匹配顺序。
• 挑 10～20 个历史 PR，比对采纳率、误报类型、漏报类型、耗时和 token，而不只看“找到了几个问题”。
• 明确模型端点、代码出境和 Secret 使用的边界；不要把带 Secret 的 CI job 当作不可信 PR 的执行器。
• 当评审结果稳定后，再考虑用 CI 自动留下第一轮意见，人工 reviewer 保留合并责任。

参考资料

• OpenCodeReview 开源仓库
• 官方中文 README 与基准测试说明
• 官方架构文档
• 官方快速开始
• 评审规则文档
• CI/CD 集成文档