阿里开源 OpenCodeReview：把 AI 代码审查做成一条可控流水线

代码审查是 AI 编程里一个很自然的场景：把 Git diff 交给大模型，让它找 Bug、风险和不合理的改动。

真正放进开发流程后，问题却不只是“模型够不够聪明”。变更一多，通用 Agent 可能漏看文件；评论内容是对的，行号却偏了；换一个提示词，输出质量又不稳定。团队需要的不是偶尔给出惊喜的回答，而是一套覆盖范围明确、结果位置准确、规则能够复用的审查流程。

阿里开源的 OpenCodeReview，正是从这个方向切入。

一句话定位

OpenCodeReview 是一款 AI 驱动的代码审查 CLI：用确定性工程控制审查范围、规则和评论定位，再让 LLM Agent 负责理解上下文与判断问题。

它的重点不是再做一个通用 AI 编程助手，而是专注代码审查这一件事，把一次模型调用变成可重复、可配置、可接入 CI/CD 的工程流程。

基础信息卡片

项目 README 介绍，OpenCodeReview 的前身是阿里内部的 AI 代码审查助手，经过两年内部使用后开源。它读取 Git diff，把变更文件交给具备工具调用能力的 Agent，并输出可落到具体代码行的结构化审查意见。

解决什么问题

通用编码 Agent 当然也能做代码审查。给 Claude Code、Codex 或 Cursor 一段指令，它们都可以读取 diff、分析代码并给建议。

但专用审查工具面对的是另一组工程问题。

1. 不能漏掉该看的变更

大规模改动经常包含很多文件。完全依赖 Agent 自己决定“先看什么、看多少”，容易出现选择性审查。OpenCodeReview 把文件筛选和分组交给确定性逻辑，先明确审查范围，再把关联文件打包成独立任务。

这样做的关键不是让模型一次读进更多代码，而是确保每一组重要变更都进入审查流程。

2. 评论必须落到正确位置

代码审查意见如果无法对应到具体文件和行，开发者还要重新定位，使用价值会明显下降。OpenCodeReview 增加了独立的评论定位与反思组件，对模型结果进行校正，而不是直接把原始回答当成最终输出。

3. 团队规则需要稳定执行

不同项目、目录和文件类型，关注点并不相同。支付模块更关注边界与一致性，Web 接口需要检查注入和权限，Java 代码可能重点关注空指针与线程安全。

OpenCodeReview 使用规则引擎按文件特征匹配审查规则。规则选择由工程逻辑控制，模型负责在明确范围内判断，结果比单纯依赖一段自然语言提示词更容易复用和调试。

核心功能

确定性工程与 Agent 分工

这是 OpenCodeReview 最值得关注的设计。

确定性部分负责文件筛选、关联文件打包、规则匹配、评论定位和结果反思。这些环节强调覆盖、边界和可预测性，适合用程序逻辑保证。

Agent 则负责动态决策：读取完整文件、搜索代码库、检查其他变更文件，并根据上下文判断某段改动是否真的存在问题。它不只盯着一小段 diff，而是可以主动补充理解所需的信息。

简单说，程序负责“审查流程不能乱”，模型负责“具体问题需要理解”。

多种审查范围

本地开发时，可以直接检查工作区中的暂存、未暂存和未跟踪变更；也可以比较两个分支、审查单个提交，或者恢复中断的审查会话。

除了 diff 审查，ocr scan 还能扫描整个仓库、目录或文件。这适合接手陌生代码库、做阶段性检查，或者处理没有明确 Git diff 的代码目录。

规则与团队流程集成

项目支持按路径和文件匹配自定义规则，也提供 GitHub Actions、GitLab CI、Gerrit 等集成路径。团队可以把 AI 审查放到 Pull Request 流程里，生成行级评论和汇总，而不必要求每位开发者手动执行同一套步骤。

它还提供 Claude Code、Codex、Cursor 等编程 Agent 的插件或 Skill。委托模式下，OpenCodeReview 负责整理审查范围、规则和上下文，由宿主编程 Agent 使用自身模型完成评审。

模型供应商可配置

OpenCodeReview 并不绑定单一模型。官方说明中列出的范围包括 OpenAI 兼容接口、Anthropic、Google Gemini、Amazon Bedrock 和 Azure OpenAI 等。

这让团队可以根据现有账号、成本和合规要求选择模型端点。不过也要注意：默认模式会把代码 diff 发送给你配置的 LLM 服务。涉及私有代码时，应先确认模型供应商的数据处理政策和团队内部规范。

适合谁

• 个人开发者：在提交前完成一轮机器审查，再进入人工检查。
• 维护开源项目的团队：通过 GitHub Actions 在 Pull Request 中自动生成行级评论和审查摘要。
• 有统一工程规范的研发团队：按目录、文件类型和业务场景配置规则，让常见风险检查稳定执行。
• 正在使用 AI 编程 Agent 的开发者：让编码 Agent 负责实现，OpenCodeReview 负责组织和约束审查过程。

快速上手

前置条件是 Git 2.41 或更高版本。最直接的安装方式是 npm：

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

安装完成后，先配置模型供应商和模型：

ocr config provider
ocr config model

交互界面会引导你填写 API Key、选择模型并测试连接。

进入一个 Git 项目，审查当前工作区改动：

cd your-project
ocr review

比较分支或审查单个提交：

ocr review --from main --to feature-branch
ocr review --commit abc123

扫描整个仓库或指定目录：

ocr scan
ocr scan --path internal/agent

建议第一次先在非敏感项目上运行，观察误报、漏报和 Token 消耗，再根据项目特点增加规则。确认效果和数据边界后，再接入 Pull Request 或 CI/CD 流程。

结论

OpenCodeReview 的价值，不是证明“大模型也会看代码”，而是把 AI 代码审查做成一条更可控的流水线。

它用确定性工程保证审查范围、规则匹配和评论定位，让 Agent 集中处理真正需要上下文理解的部分。这种分工，比单纯把 diff 丢给一个通用 Agent，更接近团队可以长期使用的工程工具。

同时，它仍然是一名辅助审查者，而不是自动修复和最终审批系统。项目 Roadmap 明确表示，建议可以由工具生成，但应用修改仍需要人工确认。

如果你正在寻找一个可本地运行、可选模型、能接入现有研发流程的 AI 代码审查工具，OpenCodeReview 值得先用一个真实 Pull Request 试跑。