阿里巴巴开源的 AI 代码审查 CLI 工具，用 Go 编写，将确定性工程流水线与 LLM Agent 结合，输出精确到行的评论，兼容 OpenAI 与 Anthropic。
项目定位与要解决的问题
这个项目的定位是嵌入研发生命周期的工程化审查工具，而不是通用对话助手。它源自阿里巴巴集团内部官方的 AI 代码审查助手，README 称两年间已服务数万名开发者、识别出数百万代码缺陷，经大规模验证后孵化为 Apache-2.0 开源项目。它以 ocr 命令分发，可通过 npm 包全局安装，官方称还提供安装脚本、GitHub Release 二进制与源码构建等途径，支持 Windows、macOS、Linux。除独立命令行使用外，它还以插件或技能形式接入 Claude Code、Codex、Cursor、OpenCode、QCA Forward 以及兼容 skill 的宿主，并提供 MCP Server、GitHub Actions、GitLab CI、GitFlic CI 与 Gerrit 的集成、可在浏览器浏览并重放会话的 Session Viewer，以及基于 OpenTelemetry 的可观测性；仓库徽章显示其获得 OpenSSF Best Practices 金级。配置一个模型端点即可开始使用。
核心能力
核心设计哲学是把确定性工程与 Agent 混合，各做各自擅长的事。对绝不能出错的环节用工程逻辑而非语言模型来保证：精确判定哪些文件需要审查、哪些应当过滤，避免重要改动被漏掉；智能文件打包把相关文件合成一个审查单元，例如英文与中文的 properties 资源文件被打包在一起，每个文件包作为上下文隔离的子 agent 运行，这种分治策略让流程在超大改动集上仍然稳定，并天然支持并发审查；基于模板引擎的细粒度规则匹配把审查规则对应到文件特征，从源头削减信息噪音，官方认为这比纯语言驱动的规则引导更稳定可预测；评论定位与评论反思两个独立模块分别改进 AI 反馈的位置准确度与内容准确度。模型只被用于动态决策与动态上下文检索：场景化调优的提示词模板在提升效果的同时降低 token 消耗，工具集则是分析大规模生产数据中的调用轨迹、工具重复率以及新工具对调用链的影响后定制而成。内置多语言规则集覆盖空指针、线程安全、跨站脚本与 SQL 注入等问题。
技术结构与实现思路
从仓库与文档可以看到的组件分为若干层。最外层是 ocr 命令入口，涵盖 review、scan、delegate 三类审查任务以及 session 会话管理与 config 配置。配置层支持内置 provider、自定义 provider、模型选择、环境变量与交互式连通性测试。规则层按路径过滤与目标匹配解析审查规则，并内置多语言规则集。执行层包含文件选择、文件打包、子 agent 调度，以及相互独立的评论定位模块与评论反思模块，后者在模型输出之外校正行号与意见内容。能力扩展层提供 MCP Server，可为审查 agent 挂载外部工具，并以插件或技能形态适配 Claude Code、Codex、Cursor、OpenCode、QCA Forward 以及通用的兼容 skill 宿主。执行模式上区分默认模式与委托模式：默认由 OCR 用自己配置的模型完成审查，委托模式下 OCR 只负责文件选择与规则解析，由宿主编码 agent 用自己的模型执行审查，因此不必配置 OCR 的 API Key。输出层支持文本与 JSON 并可写入文件，会话数据可由 Session Viewer 浏览、重放、标记为已修复或已忽略。整体以 Go 实现，依赖 Git 完成 diff 生成、代码搜索与仓库操作。
实际工作流程
典型使用路径是：先确认 Git 版本不低于 2.41，通过 npm 全局安装后获得 ocr 命令；接着执行 ocr config provider 与 ocr config model 选择或新增 provider、填写 API Key 并选定模型，交互界面会引导整个过程并自动测试连通性，若采用委托模式则无需配置 OCR 侧模型。审查时在项目目录执行 ocr review，处理工作区中已暂存、未暂存与未跟踪的变更；或用 ocr review –from main –to feature-branch 以 merge-base 方式审查特性分支相对主干的改动；或用 –commit 审查单个提交。ocr scan 跳过 diff 直接扫描整个仓库、指定目录或文件，适合审计没有有意义 diff 的陌生代码库。被中断的区间审查或全文件扫描可用 ocr session list 找到会话并以 –resume 继续。内部运行流程是读取 Git diff，先做文件选择与打包，为每个文件包匹配审查规则，再由具备工具使用能力的 Agent 读取完整文件、搜索代码库、查看其他变更文件补充上下文，最后经定位与反思模块产出精确到行的结构化评论；结果可用 –format json –output 落盘，便于宿主 agent 消费。
与同类方案的取舍
差异点集中在对抗通用 agent 的不可控性。README 指出，用 Claude Code 这类通用 agent 配合 Skills 做代码审查时存在三个痛点：较大的改动集上 agent 会挑活，只选择性地审部分文件而漏掉其他文件；报出的问题位置经常与真实代码不匹配，行号或文件引用发生漂移；自然语言驱动的技能难以调试，提示词的微小变化就会引起质量明显波动。其归因是纯语言驱动架构缺少对审查流程的硬约束。Open Code Review 的回应是把文件选择、文件打包、规则匹配、评论定位与反思交给确定性工程逻辑，只把动态决策与动态上下文检索留给模型。项目方在 README 中给出 AACR-Bench 基准：由 50 个热门开源仓库、200 个真实 Pull Request、10 种编程语言构成，80 多名资深工程师交叉验证出 1505 条标注问题，数据集发布于 Hugging Face。据其自述，在同一底层模型下与通用 agent 相比，Precision 与 F1 显著更高、token 消耗约为九分之一、审查耗时更短，但 Recall 低于通用 agent，项目方称这是为压低噪音而有意做出的取舍。这些对比数字均为项目方自述，本解读无法独立验证。
值得关注的设计
核心设计创新在于把评审流程拆成确定性与 Agent 两层。文件筛选、文件捆绑（例如中英文资源文件合并成一个评审单元）、基于模板引擎的细粒度规则匹配，以及独立的评论定位与反思模块，全部由工程逻辑保证，不交给模型自由发挥，从而避免规则引导随提示词波动。每个捆绑包以上下文隔离的子 Agent 运行，形成分而治之的结构，在超大变更集上更稳定并天然支持并发。Agent 侧只保留面向代码评审调优的提示词与工具集，工具集据称由大规模生产环境的工具调用轨迹（调用频次分布、单工具重复率、新工具对调用链的影响）裁剪而来。以上优势均属项目方自述。
适用领域和具体场景
使用方式以命令行 ocr 为中心。默认工作区模式评审所有已暂存、未暂存与未跟踪改动；也可用 –from 与 –to 按 merge-base 评审分支区间，或针对单个 commit。ocr scan 在没有有意义 diff 时整文件扫描，适合审计陌生仓库或目录，并支持 –resume 续跑被中断的会话，会话可用 session list 查看。结果可用 –format json –output 落盘，便于被 AI 宿主代理消费。delegate preview 与 delegate rule 只做文件选择与规则解析，把实际评审交给宿主编码代理，无需配置 OCR 侧模型。此外还有 MCP 服务器扩展外部工具、GitHub Actions 与 GitLab CI 等流水线集成，以及浏览器会话查看器。
哪些人会受益
目标用户大致分几类。一是希望把代码评审纳入 CI/CD 的团队，可用 JSON 输出与流水线对接，并关注时延与成本指标。二是个体开发者与中小团队，通过 npm 全局安装后只需配置一个模型端点即可开始使用。三是已经在用 Claude Code、Codex、Cursor、OpenCode 等编码代理的工程师，可安装插件或走委托模式复用宿主模型，不必额外配置密钥。四是需要审计缺乏 diff 的历史代码库的工程师，可用整文件扫描。五是受合规约束、需要接入自有 OpenAI 或 Anthropic 兼容端点的企业用户。文档提供中、英、日、韩、俄多语言版本，对非英语团队相对友好。
上手、部署与集成
接入门槛是 Git 2.41 及以上，以及一条 npm 全局安装命令，安装后获得全局 ocr 命令。首次使用通过交互式界面选择内置或自定义 provider、录入 API Key、挑选模型并自动测试连通性，也支持用环境变量与配置文件完成高级配置。项目以 Apache-2.0 许可发布，带有 OpenSSF Best Practices Gold 徽章，并覆盖 Windows、macOS、Linux 与多种宿主代理。README 称其源自阿里巴巴内部官方 AI 代码评审助手，两年间服务数万名开发者、发现数百万代码缺陷，但这类规模数字属于项目方自述，仓库未提供可独立核验的采用统计。基准数据集已在 Hugging Face 公开，可供外部复核。
限制与风险
README 明确承认召回率低于通用代理，这是项目方为压低噪声而刻意做的取舍，意味着部分真实缺陷仍可能漏过，评审结果不能替代人工把关。基准结论由项目方在自建数据集上测出，对比对象为通用代理，尚无第三方独立复现，精确率、F1 提升以及约九分之一 token 的说法都应视为项目方自述。使用前必须配置 LLM 或改用委托模式，并依赖 Git 2.41 以上版本。公开材料未给出评审时延与单次成本的具体数字，也未说明完全离线或气隙环境下的部署方式；内置规则集覆盖空指针、线程安全、跨站脚本与 SQL 注入等类别，但规则完备性与误报漏报分布无法从仓库验证。
综合观察
整体看，这个项目最值得关注的是设计取向：把容易出错的流程环节，包括文件选择、规则匹配与评论定位，交给确定性工程，只把动态判断与上下文检索留给模型，并据此组织隔离上下文的子代理与并发执行。README 把通用代理的典型问题归纳为覆盖不全、位置漂移、质量不稳，并用混合架构正面回应，思路清晰且可解释。以 Apache-2.0 开源、获得 OpenSSF Gold、覆盖主流编码代理与多套 CI 系统，客观上降低了试用与集成摩擦。需要提醒的是，性能与质量结论目前全部来自项目方自述及其自建基准，尚无第三方验证；若评审场景对漏报敏感，建议先在自己的代码库上实测召回表现，再决定是否纳入正式流程。
解读依据仓库 README 与简介，周期榜名次和数据按已采集的日期动态计算；项目文档和实际能力可能变化。