项目名OpenCodeReviewalibaba/open-code-reviewGitHubhttps://github.com/alibaba/open-code-review 官网https://open-codereview.ai 版本持续更新中 协议Apache-2.0 Star21000截至 2026-08-24 语言Go 适用Windows / macOS / Linux CLI 命令ocr开篇让 Claude Code 给你做 Code Review它老是「挑肥拣瘦」现在的 AI 编程工具都能做代码审查但真用起来三个槽点几乎人人踩过覆盖不全变更一多AI 就「选择性审查」只看几个文件剩下直接跳过位置漂移报的 issue 和实际代码位置对不上行号、文件引用老是漂质量不稳纯靠 prompt 驱动微调一下措辞审查质量就天差地别。本质原因官方一句话点透纯语言驱动的架构对审查过程没有硬约束。阿里把这套问题在内部磨了两年——它原本是阿里集团内部的官方 AI 代码审查助手服务了数万名开发者、识别了数百万个代码缺陷2026 年 5 月验证充分后开源了取名叫OpenCodeReview命令是ocr。它最狠的一个数字和通用 agentClaude Code用同一个底层模型做审查Precision 和 F1 更高token 却只花约 1/9。这篇我从原理、安装、用法、规则、CI 集成、踩坑讲透Java/Go 程序员看完就能上。目录它和「让 Claude Code 审查」有什么区别核心设计确定性工程 × Agent 混合Benchmark50 仓库 200 PR 的实测数据Windows 安装配置 LLM Provider 和模型四种审查模式review / commit / scan / delegate内置多语言规则NPE / 线程安全 / XSS / SQL 注入接进 CI/CD 和 AI 编码工具常见坑和解决方案适合谁 / 不适合谁一、它和「让 Claude Code 审查」有什么区别先明确定位OpenCodeReview 是专门的代码审查 CLI 工具不是通用 agent。维度通用 AgentClaude Code SkillOpenCodeReview架构纯 prompt 驱动确定性工程 LLM Agent 混合文件选择靠模型「自觉」工程逻辑精确定位该审哪些文件大变更处理容易跳文件智能打包 子 agent 分治稳定规则匹配全塞进 prompt模板引擎按文件特征精确匹配规则定位精度位置漂移独立定位模块 反思模块纠偏token 消耗高约 1/9交付形态对话里的一段话结构化、行级评论说人话OpenCodeReview 是「审查这件事」的专用流水线而不是让你拿通用 AI「顺带审一下」。二、核心设计确定性工程 × Agent 混合这是它区别于一切「prompt 审查」的根本。官方把审查拆成两块各干各擅长的2.1 确定性工程——硬约束必须不犯错的部分用代码保证模块干什么精确文件选择确定哪些文件要审、哪些该过滤不放过重要改动智能文件打包把相关文件捆成一个审查单元比如message_en.properties和message_zh.properties一起审每个 bundle 跑一个子 agent隔离上下文细粒度规则匹配按文件特征匹配审查规则让模型注意力聚焦源头消除噪音定位 反思模块独立模块系统性纠正评论的位置准确性和内容准确性2.2 Agent——动态决策该灵活的部分交给模型场景化 prompt为代码审查深度优化的模板提效降 token场景化工具集从大规模生产数据的 tool-call 轨迹里「蒸馏」出来的专用工具集比通用 agent 的工具更稳、更可预测。这套「工程管流程、模型管判断」的混合架构是它能在同样模型下做到「更准 更省」的原因。三、Benchmark50 仓库 200 PR 的实测数据官方做了一个真实世界的代码审查基准50个热门开源仓库200个真实 Pull Request10种编程语言80位资深工程师交叉标注共1505个 ground-truth 缺陷。指标含义为什么重要F1Precision 和 Recall 的调和均值综合看审查质量的单值Precision报的 issue 里真实缺陷占比越高越少误报Recall真实缺陷被找到的比例越高越少漏报Avg Time单次审查耗时影响 CI 延迟Avg Token单次审查 token直接影响成本结论和通用 agent 比OpenCodeReview 用同一模型拿到了更高的 Precision 和 F1token 只有约 1/9审查更快。官方也坦白它的 Recall 略低于通用 agent——这是「宁精勿滥」的刻意取舍。数据集的标注数据开源在 HuggingFace 上叫AACR-Bench想较真的可以自己去翻。四、Windows 安装前置要求Git 2.41它靠 Git 生成 diff、搜代码、操作仓库。4.1 npm 安装最省事npm install -g alibaba-group/open-code-review装完ocr命令全局可用ocr --version4.2 其他安装方式安装脚本官方提供一键脚本GitHub Release 二进制去 Releases 页下 Windows 的.exe解压到D:\tools\ocr\这类无空格路径加进 PATH源码编译Go 环境go install。Windows 用户注意ocr是靠git子进程工作的确保git在 PATH 里、且版本 ≥ 2.41git --version查一下。五、配置 LLM Provider 和模型审查前必须先配 LLM除非用委托模式ocr config provider # 选内置 provider 或加自定义的 ocr config model # 给当前 provider 选模型交互式 UI 会引导你选 provider、填 API Key、选模型最后自动测试连通性。几点说明OpenAI Anthropic 兼容既支持官方 Claude / GPT也支持任何兼容网关比如 DeepSeek、通义、或你自己搭的中转站环境变量 / 自定义 provider支持 CLI 配置适合 CI 场景详细配置看官网 https://open-codereview.ai/docs/configuration。六、四种审查模式review / commit / scan / delegate进入你的项目目录后6.1ocr review—— 工作区 / 分支范围审查cd your-project ​ # 工作区模式审所有 staged / unstaged / untracked 改动 ocr review ​ # 分支范围审 feature-branch 相对 main 分叉后的改动merge-base 模式 ocr review --from main --to feature-branch ​ # 单提交 ocr review --commit abc123 ​ # 断点续审 ocr session list ocr review --from main --to feature-branch --resume session-id6.2ocr scan—— 全文件扫描无 git 历史也能审ocr scan # 扫整个仓库 ocr scan --path internal/agent # 只扫某个目录/文件 ocr scan --resume session-id # 续扫适合审计陌生代码库、或者没有 diff 可看的目录。6.3ocr delegate—— 委托模式让 AI 编码工具自己审ocr delegate preview ocr delegate rule src/main.go src/handler.go这个模式很聪明OpenCodeReview 只负责文件选择和规则解析真正的审查交给你的 AI 编码工具而且不用配 LLM。适合已经有 Claude Code / Cursor 在跑、想让审查更可控的人。七、内置多语言规则NPE / 线程安全 / XSS / SQL 注入OpenCodeReview 内置了一套多语言规则集覆盖 Java/Go 等语言的高频缺陷类型规则类型典型问题NPE空指针Java 里null未判、Optional 误用、getter 返回 null线程安全共享可变状态未同步、SimpleDateFormat静态共享、双重检查锁XSS用户输入未转义直接输出、模板注入SQL 注入字符串拼接 SQL、like % param %这类其他资源未关闭、异常吞掉、魔法值等这套规则正是它「比通用 agent 稳」的底气——规则是模板引擎按文件特征精确匹配的不是让模型「凭感觉」想起哪条算哪条。对 Java 程序员来说NPE 和线程安全这两类通用 agent 经常漏它专门盯着。八、接进 CI/CD 和 AI 编码工具8.1 CI/CDGitHub Actions / GitLab CIOpenCodeReview 支持 CI/CD 集成把审查变成 PR 检查的一环。核心思路CI 里ocr review --from main --to $PR_BRANCH把结构化评论回贴到 PR 上。具体模板看官网文档。8.2 和 Claude Code / Codex / Cursor 配合直接审查ocr review跑完出结构化报告委托模式ocr delegate让 AI 编码工具在它的上下文里完成审查OpenCodeReview 保证「审哪些文件、用哪些规则」不出错AI 编码工具写OpenCodeReview 审一个负责生成、一个负责把关正好互补。九、常见坑和解决方案Q1ocr命令找不到npm 全局 bin 目录没进 PATH。where ocr看路径Windows 上通常是%APPDATA%\npm手动加进系统 PATH。Q2审查报 git 版本过低git --version确认 ≥ 2.41。Windows 上 Git for Windows 老版本要升级。Q3配置 provider 后连接测试失败检查 API Key、base_url尤其走中转/网关时、以及网络能不能通。走 Anthropic 官方要注意网络。Q4审查慢 / 卡在大仓库大变更会自动打包并发审但超大仓库第一次扫会慢。可以先用ocr scan --path缩小范围或断点续审。Q5想接 DeepSeek 等国产模型选「自定义 provider」填 OpenAI 兼容的 base_url 和 key 即可模型选对应的 chat 模型。Q6ocr review和ocr scan傻傻分不清有 git 历史、要审「这次改了什么」→review没 git 历史、要审「整个文件/目录」→scan。十、适合谁 / 不适合谁✅ 适合Java / Go 后端尤其在意 NPE、线程安全、SQL 注入这类「通用 agent 容易漏」的缺陷想在 CI/CD 里加一道自动化代码审查关卡又不想花大价钱 token团队想要结构化、行级、可回贴到 PR的审查结果而不是一段对话已经用 Claude Code / Cursor想让审查更「可控」用委托模式。❌ 不适合只想让 AI 泛泛聊「这段代码怎么样」不需要工程化流水线——通用 agent 就够了追求极致 Recall宁多勿漏的场景——它官方也说了 Recall 是刻意压低换 Precision代码量极小、纯个人项目配一套 CLI 反而麻烦。最后总结OpenCodeReview 是 2026 年「AI 代码审查」这个细分方向里最扎实的开源项目——阿里内部两年级别验证、21k Star、确定性工程 × Agent 混合架构、同模型下 token 只要 1/9。它解决的不是「AI 能不能审代码」而是「AI 审查怎么做到稳、准、省、可进 CI」。对 Java 程序员来说npm i -g alibaba-group/open-code-review一条命令就能在提交前多一道「专门盯着 NPE / 线程安全 / SQL 注入」的审查性价比极高。项目地址https://github.com/alibaba/open-code-review 官网https://open-codereview.ai