Open Code Review：阿里开源的 AI 代码审查利器

图1：Open Code Review 项目 Logo

想象这样一个场景：你是一个拥有十年经验的老架构师，每天要审阅十几二十个 Pull Request。代码风格、安全漏洞、并发问题、SQL 注入风险……每一项都不能漏掉。但人的精力是有限的——当你审到第十个 PR 的时候，注意力早已不在最佳状态，漏掉一个关键 Bug 是常有的事。

阿里巴巴的工程团队也面临同样的挑战。过去两年，他们内部用一套 AI 代码审查系统服务了数万名开发者，累计发现超过百万个代码缺陷。这套系统最近正式开源，就是我们今天要介绍的主角——Open Code Review（简称 OCR）。

从阿里内部走向开源：两年打磨的代码审查 AI

Open Code Review 诞生于阿里巴巴集团内部的工程实践。不同于那些从论文出发、实验室里造出来的项目，OCR 从一开始就是在真实生产环境里跑着的工具：服务内部数十个大型代码仓库、覆盖 Java/Go/Python/TypeScript/C++ 等十余种语言、日均处理数万次代码变更请求。

2026 年 5 月，阿里将这套系统开源到 GitHub，迅速获得社区关注，目前已达 4800+ Stars。开源版本保留了内部版本的全部核心能力，同时增加了 Claude Code 插件、Codex 插件、GitHub Actions / GitLab CI 集成等社区友好的接入方式。

图2：Open Code Review 功能亮点（来源：项目 README）

通用 Agent 的软肋与 OCR 的解决思路

如果你用过 Claude Code、Codex 这类通用 AI 编程 Agent 的代码审查能力，你可能已经注意到几个让人头疼的问题：

第一，覆盖不全。 当你提交了一个包含十几个文件变更的分支，通用 Agent 往往会"抄近路"——只审其中几个文件，其他的就跳过了。

第二，位置漂移。 Agent 生成的评论里提到的代码行号和实际位置经常对不上，审阅者得自己去猜它说的是哪一行。

第三，质量不稳定。 同样的代码变更，今天审查和明天审查可能给出完全不同的反馈，prompt 里微调一句话结果就天差地别。

这些问题的根源在于：纯粹靠自然语言驱动的 Agent 架构，缺乏对审查过程的硬约束。OCR 的核心设计哲学正是针对这一点——用确定性工程 + Agent 的混合架构，让两者各司其职。

确定性工程：硬约束保证下限

"硬约束"意味着无论模型怎么变、AI 能力如何波动，审查的基本流程和质量底线都是固定的。具体体现在：

精确文件筛选：系统会明确判断哪些文件需要审查、哪些应该过滤掉，确保没有重要变更被漏审。

智能文件打包：将相关联的文件打包成一个审查单元（比如 message_en.properties 和 message_zh.properties 一起审），每个单元运行一个独立的子 Agent。这是分而治之策略——即使面对上百个文件的大型变更集，依然能保持稳定，同时天然支持并发审查。

细粒度规则匹配：根据每个文件的特征匹配相应的审查规则（如 Java 文件用空指针检查规则、SQL 文件用注入检测规则），让模型注意力高度聚焦，从源头减少噪声。这比纯语言驱动的规则引导更稳定、可预测。

外部定位与反思模块：独立的评论定位模块和评论反思模块，分别负责提升反馈位置的准确性和内容的正确性。

Agent：动态决策补足上限

当确定性工程封住了质量下限，Agent 的强项就集中在真正需要智能判断的地方：

场景化 Prompt 模板：深度优化过的代码审查专用 Prompt，减少 token 消耗的同时提升审查效果。

场景化工具集：从海量生产数据（工具调用频率、重复率、对整体调用链的影响）中提炼出来的专用工具集，专为代码审查场景设计，比通用 Agent 工具包更稳定可预测。

核心功能与使用方式

OCR 提供两种使用模式：本地 CLI 和 CI/CD 自动化集成。

本地 CLI 快速上手

安装方式非常简洁，推荐通过 npm 全局安装：

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

安装后即可使用 ocr 命令。首次使用需要配置一个 LLM 端点（支持 OpenAI 和 Anthropic 兼容接口）：

export OCR_LLM_URL=https://api.anthropic.com/v1/messages
export OCR_LLM_TOKEN=your-api-key
export OCR_LLM_MODEL=claude-opus-4-6
export OCR_USE_ANTHROPIC=true

# 测试连接
ocr llm test

# 审阅当前工作区变更
ocr review

# 审阅两个分支之间的差异
ocr review --from main --to feature-branch

# 审阅单个提交
ocr review --commit abc123

OCR 还内置了会话查看器（Web UI），运行 ocr viewer 即可在本地启动一个浏览器界面，查看历史审查会话的详细内容（端口 5483）。

CI/CD 集成：PR 自动审查

OCR 支持与 GitHub Actions 和 GitLab CI 无缝集成，可以对每个 Pull Request 自动发起代码审查，并将评论直接发布到 PR 上。GitHub Actions 示例：触发条件可以是 PR 创建时，也可以是评论中包含 /open-code-review 或 @open-code-review 时。只需配置 OCR_LLM_URL 和 OCR_LLM_AUTH_TOKEN 两个 Secret，即可开启自动化审查流程。

AI 编程 Agent 集成

OCR 提供了丰富的 AI 编程 Agent 集成方式：

• Claude Code 插件：在 Claude Code 中安装 /open-code-review 斜杠命令，一键调用 OCR 审查当前变更并自动过滤/修复高置信度问题。

• Codex 插件：在本地 Codex 中安装 Open Code Review 插件，支持 @Open Code Review review my changes 风格的对话调用。

• 通用 Skill：通过 npx skills add 将 OCR 作为 Skill 安装到项目中，让任意支持 Skill 的 AI 编程工具调用。

内置规则集：开箱即用的安全审查

OCR 内置了一套阿里巴巴在生产环境中打磨出来的审查规则，覆盖以下高频问题：

• NPE（空指针异常）：Java/Go 等语言的空指针风险检测
• 线程安全：并发场景下的数据竞争和锁问题
• XSS（跨站脚本）：前端代码的脚本注入风险
• SQL 注入：数据库查询中的参数化问题

规则体系采用四层优先级链：CLI --rule 参数 > 项目级配置 > 全局用户配置 > 系统默认规则。支持 Glob 路径匹配和通配符（**、{a,b}），也支持 include/exclude 控制审查范围。

架构解析

从项目目录结构可以清晰看到 OCR 的模块化设计：

internal/
├── agent/       # 核心 Agent 逻辑（文件选择、打包、规则匹配）
├── llm/         # LLM 客户端（支持 OpenAI + Anthropic）
├── config/      # 配置管理（rules/toolsconfig/template）
├── diff/        # Git diff 解析
├── gitcmd/      # Git 命令封装
├── model/       # 数据模型
├── session/     # 会话管理（历史记录、查看器）
├── telemetry/   # OpenTelemetry 可观测性
└── tool/        # Agent 工具集（代码搜索、文件读取等）

核心依赖方面，OCR 用 Go 1.25 编写，通过 Anthropic SDK（v1.47）和 OpenAI SDK（v3.39）对接大模型，用 go.mod 管理依赖。OpenTelemetry 全链路追踪开箱即用，支持 OTLP 导出到 Jaeger、Prometheus 等主流可观测性平台。

代码质量方面，项目结构清晰、模块边界明确，内置完整测试套件（go test -v -race），README 文档覆盖多语言（英文、中文、日文、韩文），代码规范检查通过 go vet 和 gofmt。

局限与注意事项

OCR 并不是银弹，有几个场景需要特别关注：

第一，依赖外部 LLM API。 OCR 本身只是一个 Agent 框架，实际审查能力完全取决于所调用的模型质量。不配置 API Key 根本无法运行，审查效果的上限取决于你用的模型能力。

第二，无本地模型支持。 当前不支持 Ollama、vLLM 等本地推理引擎，所有请求都走云端 API，对网络和隐私有要求的团队需要注意。

第三，无 Dockerfile 容器化。 作为纯 CLI 工具，安装和使用都需要在有 Node.js 或 Go 环境的机器上。没有 Docker 一键部署能力，CI/CD 集成需要自行配置 Runner 环境。

第四，中文文档社区贡献有限。 虽然 README 提供了多语言版本，但中文社区的 Issues 和 PR 反馈相对较少，遇到问题主要靠英文社区。

行业意义与未来展望

Open Code Review 的开源，是 2026 年 AI 编程工具生态中值得关注的一个信号。

它代表了一种务实的技术路线——不是用更大的模型去"覆盖一切"，而是用工程约束去"保证下限"，再让 AI 的智能去"突破上限"。这种混合架构在工业界有广泛的应用前景，未来很可能看到更多类似的"AI Agent + 确定性工程"组合出现在代码生成、测试、运维等领域。

从社区活跃度来看，OCR 赶上了 AI 编程工具的大爆发期。GitHub 上代码审查类项目的 Stars 增速明显，越来越多的团队开始重视 PR 质量而非仅仅关注代码覆盖率。OCR 作为阿里巴巴内部两年生产验证的工具，在可靠性和实用性上有一定背书。

如果你正在寻找一个能融入现有 CI/CD 流程、支持多语言、开箱即用且有大型企业背书的 AI 代码审查工具，Open Code Review 值得一试。