最近在处理一个老项目的 PR 时，我又遇到了那个经典困境：改动涉及十几个文件，Reviewer 没空细看，自己 review 自己的代码又越看越顺眼。我就想，能不能有一个工具，能像有经验的同事一样逐行看代码，还不用担心漏看。
然后在 GitHub Trending 上看到阿里开源的 open-code-review。介绍里写得很直接：源自阿里巴巴集团内部官方 AI 代码审查助手，服务过数万名开发者，识别过数百万个代码缺陷，现在开源出来。Go 写的，Apache-2.0 协议，周增 4750 Star，18k+ 总星。
我把它看了一遍，试着跑了几条命令。今天说说这个工具到底怎么样。
一、它不是又一个 Claude Code 插件
现在市面上用 Claude Code、Cursor 做代码审查的方案很多，但阿里的这个工具思路不一样。它不是把审查任务丢给一个通用 Agent 就完事，而是做了一个确定性工程 + LLM Agent 的混合架构。
通用 Agent 审查代码时常见的问题：
- 覆盖不全：改动文件多的时候，Agent 会偷懒，只看其中一部分
- 位置漂移：指出的问题行号不准，评论贴不到正确的代码位置
- 质量不稳定：换个提示词，审查质量就忽高忽低
Open Code Review 的解法是：能用工程保证正确的步骤，就不交给模型决定。
二、核心架构：确定性的部分硬控，不确定的交给 Agent
确定性工程负责什么
- 精确文件选择：自动判断哪些文件需要审、哪些该过滤，避免漏审
- 智能文件分束：把相关文件打包成一个审查单元。比如
message_en.properties和message_zh.properties会捆在一起审。大改动自动拆成多个子任务，支持并发 - 规则匹配：根据文件特征匹配审查规则，比如 Java 文件重点看 NPE、线程安全，Web 文件看 XSS、SQL 注入
- 评论定位模块：把模型生成的评论精确对应到代码行
- 评论反思模块：独立校验评论内容的准确性
LLM Agent 负责什么
- 动态决策：根据上下文决定要不要读取更多文件、要不要搜索代码库
- 动态上下文检索：读取完整文件内容、检索相关代码、对比多个改动文件
- 深度审查：给出具体、有上下文的缺陷描述
这套分工很明确：工程保证"不遗漏、位置准、规则对"，Agent 负责"看得懂、说得清"。
三、一条命令跑起来的流程
安装很简单：
npm install -g @alibaba-group/open-code-review
装完后 ocr 命令全局可用。然后配置模型：
ocr config provider # 选内置 provider 或自定义
ocr config model # 选模型，自动测连通性
支持 OpenAI、Anthropic 等兼容接口，也可以自己加自定义 provider。
三种主要用法
# 工作区模式：审所有 staged/unstaged/untracked 改动
ocr review
# 分支对比
ocr review --from main --to feature-branch
# 单个 commit
ocr review --commit abc123
我用分支对比试了一下，整个流程大概是这样的：
Git diff -> 文件选择 -> 文件分束 -> 规则匹配
|
v
每个 bundle 交给 LLM Agent
|
v
生成评论 -> 行级定位 -> 反思校验
|
v
输出结构化评论
实际跑下来，一个中等规模的 PR 大概 1-3 分钟能审完，比普通 Agent 快很多。
四、效果怎么样？看一组benchmark数据
Open Code Review 自己建了一个 benchmark：从 50 个流行开源仓库、200 个真实 PR、10 种编程语言里构造数据集，由 80 多位高级工程师标注了 1505 个真实问题。
和通用 Agent（Claude Code）对比：
| 指标 | Open Code Review | Claude Code |
|---|---|---|
| F1 | 更高 | 基准 |
| Precision | 显著更高 | 基准 |
| Recall | 略低 | 更高 |
| 耗时 | 更快 | 更慢 |
| Token 消耗 | 约 1/9 | 基准 |
这个结果符合它的设计取舍：宁可漏报一点，也不要大量误报。 对于 CI 集成和大型团队来说，Precision 比 Recall 更重要——没人愿意在几十个假阳性里找真问题。
五、不止 diff 审查，还能全量扫描
除了审改动，ocr scan 可以审查整个仓库或指定目录的完整文件，不依赖 git diff：
ocr scan # 扫描整个仓库
ocr scan --path internal/agent # 扫描指定目录
ocr scan --resume <session-id> # 中断后恢复
这个适合两个场景：
- 接手老项目：没有改动也能扫一遍，快速发现历史遗留问题
- 关键目录审计：定期扫核心模块，比如支付、权限相关代码
六、怎么接到工作流里
CI/CD 集成
项目提供了 action.yml，可以直接在 GitHub Actions 里用：
- name: Open Code Review
uses: alibaba/open-code-review@main
with:
provider: openai
model: gpt-4o
api-key: ${
{
secrets.OPENAI_API_KEY }}
也支持 GitLab CI、Gerrit、GitFlic CI。
编码助手集成
- Claude Code：装插件后用
/review类命令 - Codex：插件化技能
- Cursor：可移植 skill
- OpenCode：原生工具和 slash 命令
还有一种委托模式（Delegation Mode）：OCR 负责文件选择和规则匹配，但审查由你自己的编码助手执行。这样不需要给 OCR 配 LLM key。
七、内置规则库很实用
Open Code Review 自带多语言规则集，覆盖常见问题：
- Java：NPE、线程安全、资源泄露
- Web：XSS、SQL 注入、命令注入
- Go：panic 处理、goroutine 泄漏、错误处理
- Python：类型问题、异常处理
规则不是简单关键词匹配，而是结合文件特征和 AST 信息做筛选，再让模型聚焦看。这比"请帮我 review 一下"要靠谱得多。
八、我的判断
适合什么场景：
- 中大型团队，PR 量大、Reviewer 时间有限
- 想让 AI 先筛一遍常见缺陷，再由人确认
- 有 CI/CD 流水线，想把代码审查自动化
- 需要行级精确评论，而不是泛泛而谈
不太适合什么场景：
- 小型项目，改动很少，人工 review 已经很快
- 需要深度架构讨论，不只是找 bug
- 对 Recall 要求极高、不能漏掉任何潜在问题
真实感受：
我最大的感受是它很工程化。不是炫技式的"AI 替代人类 review"，而是把 review 流程拆成可控制的环节：文件别漏、评论别贴歪、规则要对口。这些看起来基础，但正是通用 Agent 最容易翻车的地方。
1/9 的 token 消耗也很关键。团队规模大了，LLM 审代码的费用不是小数目。用更少的 token 达到更高的 precision，这是能落地的方案。
不过它也有代价：Recall 比 Claude Code 低。如果你是需要"地毯式排查"的场景，可能还要配合其他工具。但对我来说，把最明显的缺陷先拦住，已经值回票价。
结语
阿里的 Open Code Review 给 AI 代码审查提供了一个更务实的路线：不是让模型自由发挥，而是用工程约束把流程框住，让模型只在真正需要判断的地方发力。
对于每天处理大量 PR 的团队来说，这种"稳定、可控、省钱"的工具，比听起来很酷的通用 Agent 更有价值。
