5 分钟跑通 AI 代码评审：open-code-review 安装、配置与第一次评审指南-开发者社区

5 分钟跑通 AI 代码评审：open-code-review 安装、配置与第一次评审指南

【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review

周四下午等 CI 绿灯的时候，你是不是也卡在同一个动作上：手动翻 PR diff，逐行 check 有没有埋雷。而另一个更让人烦躁的极端是——用通用 Agent 跑评审，评论刷了一屏，十条里七条是"建议补充注释"这种噪音。open-code-review（下称 OCR）是阿里巴巴开源的 AI 代码评审 CLI 工具，它读 Git diff，输出行级精准的评审意见，内置 NPE、线程安全、XSS、SQL 注入等多语言规则集，同时兼容 OpenAI 和 Anthropic 协议。这篇带你从安装到出第一份评审意见，全程约 5 分钟，只需要一个 LLM API Key。

一条命令装好，三步拿到第一份评审意见

别把文档从头读到尾再动手，先跑起来。

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

装完终端里多一个ocr命令。顺手确认它装好了：

ocr version

会输出版本号、git commit 和构建日期——看到这三样，工具就到位了。

模型配置用交互式向导最省事：

ocr config provider

向导是个小 TUI：在 Official / Custom / Manual 三个页签里挑一个内置提供商（Anthropic、OpenAI、DeepSeek、Kimi、DashScope、Gemini 等 20 多家的 Base URL 和协议都预置好了），填入 API Key，选一个模型，保存。Key 没填它会自动回退读环境变量（比如ANTHROPIC_API_KEY、OPENAI_API_KEY），省一步。配置落在~/.opencodereview/config.json，保存后向导自动跑一次连通验证，端点通不通当场就有答案。

进你自己的项目，先探一下范围再动手：

cd your-project ocr review --preview

屏幕会列出本次将要评审的文件清单，不花一个 token，适合先看大改动量再决定跑不跑。确认没问题，正式开跑：

ocr review

跑完你会在终端看到按文件归组、定位到具体行号的评审意见——这就是 OCR 的默认工作区模式：已暂存、未暂存、未跟踪的变更一次性审完。

看到第一份意见，剩下的都算加餐。

版本要求和其余安装方式

跑通之前有两件事值得一提：

Git ≥ 2.41（git --version看一眼）
Node.js ≥ 18（npm 装的ocr只是个启动器，真正干活的是下载下来的二进制）
一个 LLM API Key（委托模式下由宿主 Agent 提供模型，可免）

npm 之外，官方还有 Homebrew、MacPorts、安装脚本、Release 静态二进制这些路子，想本地魔改就从源码构建：

git clone https://gitcode.com/GitHub_Trending/op/open-code-review cd open-code-review make build

构建入口在 Makefile，产物落在dist/opencodereview。各平台的完整安装方式见安装文档。另外 npm 装的ocr默认在后台静默检查新版本并自动升级（18 分钟冷却一次），不想要的话设环境变量OCR_NO_UPDATE=1关掉。

CI 和脚本里怎么无交互配置

没有 TUI 的环境（CI runner、脚本），用ocr config set直接写同一份配置：

ocr config set provider anthropic ocr config set model claude-opus-4-6 ocr config set providers.anthropic.api_key sk-ant-xxxxxxxxxx

三条命令执行完没有任何回显，配置同样落在~/.opencodereview/config.json。之后再跑ocr llm test，看到Connection test successful说明端点可用。所有配置键与环境变量的完整清单在配置文档里。

三种评审姿势，加上预览和全量扫描

ocr review默认审整个工作区，另外两种姿势按场景选：

# 分支区间：feature-branch 相对 main 分叉点之后的全部变更 ocr review --from main --to feature-branch # 单提交：只审这一个 commit 引入的 diff ocr review --commit abc123

两种模式都能配--preview先看范围。--from/--to走的是 merge-base 区间，审的就是"这条分支到底改了什么"，不掺主线后续提交。

没有有意义的 diff，或者想审计一段不熟悉的代码库呢？用ocr scan直接审文件本身而非变更：

ocr scan ocr scan --path internal/agent

第一条扫整个仓库，第二条只扫指定目录或文件。扫描子命令的实现就在 internal/scan 目录。

评审跑一半被中断、网络抖了、机器要下班？大的分支区间评审支持断点续审：

ocr session list ocr review --from main --to feature-branch --resume <session-id>

第一条列出历史会话及其 id，第二条从那个点接着跑，已经评审完的文件不会重跑。会话持久化逻辑在 internal/session 目录。

回放会话，以及让 CI 直接消费评审结果

每次评审都会以 JSONL 形式流式写入~/.opencodereview/sessions/，想看过程用内置查看器：

ocr viewer

浏览器里能完整回放一次会话，实现见 internal/viewer 目录。

给系统消费的输出长这样：

ocr review --format json --audience agent > review.json

--audience agent会隐藏人类友好的进度界面，stdout 只剩 JSON 和最终摘要，CI 脚本或上游 Agent 拿来就能解析。再往前一步，examples 目录里有一套现成的评审回写脚本，覆盖 GitHub Actions、GitLab CI、Bitbucket Pipelines、GitFlic、Gerrit（Jenkins），把评审意见直接贴回平台评论，各平台配法见 examples/README.md。

凭什么比通用 Agent 稳

在 AACR-Bench 上：50 个流行开源仓库、200 个真实 PR、10 种语言，80 多位资深工程师交叉验证出 1505 个标注问题。同一个底层模型下，OCR 的精确率（Precision）和 F1 都明显更高，Token 消耗只有通用 Agent 的约 1/9，评审速度还更快。Recall 比通用 Agent 低一些——这是刻意取舍：宁可漏报，不做噪音。

架构上的解释一句话：该用工程保证正确的，绝不交给语言模型。精确的文件筛选、智能文件捆绑、基于模板引擎的规则匹配，全由确定性流水线完成；提示词与工具集的动态决策才交给 LLM Agent。内置规则集覆盖 NPE、线程安全、XSS、SQL 注入等多语言常见问题，源码在 internal/config/rules，完整架构拆解看架构文档。这套混合架构在阿里内部服务了 2 万+ 活跃用户，累计跑了超过 100 万次评审任务。

卡住了看这里：一条命令解决问题

现象	处理命令
401 / 403，Key 错了或过期	重新`ocr config set providers.<name>.api_key <key>`
`no valid LLM endpoint configured`	`ocr config provider`重走一遍向导
大区间评审中断了	`ocr session list`找到 id，加`--resume <session-id>`续审
想换个模型	`ocr config model`