OpenCodeReview（OCR）
一句话
阿里巴巴开源的 AI 代码审查工具——出身阿里内部（服务数万开发者两年、找出数百万缺陷的官方 AI 审查助手），今年 5 月开源，让你用一条命令对代码改动做「精确到行」的 AI 审查。
基本信息（2026-09-17 核实）
- 仓库：alibaba/open-code-review
- 数据：43,109 Star / 3,103 Fork（2026-10-02 实测，此前记 34,062 / 2,420）；2026-05-18 开源，持续高频更新；Go 语言，Apache-2.0
- 最新正式版：v1.12.11（2026-09-29 发布）——本机装的是 v1.12.5，落后 6 个补丁版
- 近几版新增：Jinja 模板白名单、OpenRouter 服务商、
ocr session rm、F# 审查规则、VS Code 扩展、QCA Forward 宿主、GitFlic CI - ⚠️ v1.12.10 移除
OCR_CONFIG_PATH环境变量（本笔记未依赖，无影响） - ✅ 核心理念与基准无需修正：AACR-Bench（50 仓库 / 200 PR / 10 语言 / 1505 问题）、token 约 1/9——与官方 README 逐项一致
- 官网/文档：open-codereview.ai
- 安装：
npm install -g @alibaba-group/open-code-review（命令ocr；需 Git ≥ 2.41；OpenAI/Anthropic 兼容的模型端点都行）
它干什么
- 读 Git 改动 → 带工具的 Agent 审查 → 产出精确到行号的结构化审查意见（不是泛泛而谈的 diff 点评）
ocr scan：不做 diff，直接整仓/整目录扫描——审查陌生代码库用- 支持工作区模式、分支对比、单 commit、会话续跑；结果可导出 JSON
核心设计：确定性工程 × Agent 混合
通用 agent（如 Claude Code）做代码审查的三大痛点：大改动覆盖不全（偷工减料挑着看）、行号漂移（报的位置对不上）、质量不稳（提示词一变结果就飘）。根源：纯语言驱动的架构缺少硬约束。
OCR 的解法是各管各擅长的：
- 确定性工程管「不能错的」：精确选文件（重要改动一个不漏）、智能分组（相关文件打包成一个审查单元、独立子 Agent 隔离上下文——大改动集也稳、天然支持并发）、模板引擎做规则匹配（NPE/线程安全/XSS/SQL 注入等内置规则精准对号）、独立的位置定位与反思模块
- Agent 管「要动脑的」：场景调优的提示词、从大规模生产数据里蒸馏出的专用工具集
成绩单（自建 AACR-Bench：50 仓库 / 200 真实 PR / 10 语言 / 1505 个人工标注问题）：同样底层模型下，比通用 agent 精确率和 F1 显著更高、token 只用约 1/9、速度更快；召回率故意放低——宁少报、不噪音。
生态
- 插件：Claude Code / Codex / Cursor / Kimi Code / OpenCode（审查斜命令或技能）
- 委托模式：不需要给 OCR 配模型——让你自己的 coding agent 执行审查，OCR 只管选文件和规则
- CI/CD：GitHub Actions、GitLab CI、Gerrit；MCP Server 可扩展审查工具；Session Viewer 浏览器里回放审查会话
它是 skill 吗？（形态辨析，9-18）
本体不是 skill，是独立的命令行工具；但它同时提供 skill/插件形态。 用三个已知的东西排个谱：
| 形态 | 例子 | 说明 |
|---|---|---|
| 纯 Skill（最轻） | [[mingli-master | 大师]]、Archify |
| 独立工具 + Skill/插件包装 | **[[OpenCodeReview | OCR]]** |
| 独立平台/运行时（最重） | HomeRail | 一整套要部署的服务 |
给用户的实用结论：①最省事的用法是装 CLI（npm install -g @alibaba-group/open-code-review）+ 配模型端点，然后敲 ocr 命令；②想在自己惯用的 AI 里直接用，就装它对应的插件/skill（Claude Code、Codex、Cursor、Kimi Code 都有官方包）；③还有「委托模式」——OCR 只负责选文件定规则，审查让已有的 coding agent 执行，不用配模型。
能力边界：能审旧程序吗？会帮忙改吗？（9-18）
- 审已有的旧程序：可以——
ocr scan专为这种场景设计：不做 diff、不需要 git 历史，直接对整个仓库或指定目录做全文件审查（官方场景就叫「审查陌生代码库」）。Project One 这类已有项目直接能扫 - 只找问题，不改代码：OCR 是审查者，产出「行号级问题清单」，不负责修复——这是刻意的分工设计（裁判不下场踢球，保证审查独立客观）
- 正确的查改闭环：OCR 出问题清单 → 把清单丢给 coding agent（Claude Code/我）修 → 修完让 OCR 复查 → Session Viewer 里可把意见标记为「已修复/忽略」。查、改、复查三步，每步角色分明
- 提醒：问题清单要人工过目再修——评测里它故意牺牲召回率换精确率，报出来的基本是真问题，但「报什么、修什么」的最终决定权在人
它找的问题都是什么类型？（9-18）
第一层：内置硬规则（模板引擎按文件类型精准匹配，机器保证不漏）：
| 规则 | 大白话 |
|---|---|
| NPE（空指针） | 系统以为数据一定在，结果取到个空值就崩了——最常见的一类崩溃 |
| 线程安全 | 两个任务同时改同一份数据，把账算错、状态搞乱 |
| XSS（跨站脚本） | 网页没过滤用户输入，别人能把恶意代码塞进页面——Web 项目必查 |
| SQL 注入 | 查询语句是拼出来的，有人把恶意命令混进去就能偷库、删库 |
第二层：AI 深度审查（规则覆盖不到的，Agent 读全文件、搜代码库、看上下文后挖出来）：
- 逻辑错误——代码能跑，但业务逻辑不对（比如「应收-已收」算反了）
- 上下文不一致——改了 A 处忘了 B 处（改了函数签名，另一个调用的地方没跟着改）
- 边界条件遗漏——正常数据没问题，空列表、极端值一来就出错
- 资源与隐患——数据库连接没关、异常没兜住、配置写死
对应到我的项目：Project One 是 Python + Web 前端 + 数据库——上面四类硬规则全部命中（SQL 注入和 XSS 直接相关），AI 层还能查出 LLM 分析逻辑里的上下文不一致。
安装记录（2026-09-18 ✅ 全部完成）
| 件 | 状态 | 位置 |
|---|---|---|
| CLI 本体 v1.12.5 | ✅ sha256 校验一致后安装 | /Users/randyz/.npm-global/bin/ocr |
| 主审查 skill | ✅ 官方 SKILL.md（256 行） | ~/.trae-cn/skills/open-code-review/ |
| 委托模式 skill | ✅ 官方 SKILL.md（188 行） | ~/.trae-cn/skills/open-code-review-delegate/ |
- 安装过程中的坑（记给自己）：①本机 git 被苹果 Xcode 许可协议挡住（
git --version都跑不了）——用户需在自己终端跑一次sudo xcodebuild -license accept（要输密码），否则 OCR 的对比审查模式不可用；②Trae 沙盒终端里的 node/npm 证书库不完整（系统 curl 正常但 npm 报证书错）——改用国内镜像下载官方 Release 二进制 + 官方 sha256sum 校验一致后安装，绕开 npm - 下一步（使用前）：模型端点配置
ocr config provider（交互式，选 OpenAI 兼容端点填 key），或用委托模式不配模型 - skill 生效：新会话自动加载（本会话之前已启动，可能需新开会话）
两个 skill 的区别（9-18 已装这两个）
两个 skill 共用同一个 ocr 程序，区别只在**「谁当审查的大脑」**：
open-code-review（主审查） | open-code-review-delegate（委托模式） | |
|---|---|---|
| 审查的大脑 | 你在 OCR 里配置的模型（ocr config provider，可以是便宜的模型） | 当前对话里的 AI 自己（比如 deepseek-flash） |
| OCR 干什么 | 全套：选文件 + 定规则 + 调模型 + 出意见 | 只干粗活：算出该审哪些文件（preview）+ 匹配规则（rule），材料打包递给对话 AI |
| 前提 | 必须先配置模型端点 | 零 LLM 配置（OCR 侧完全不调模型） |
| 适用场景 | 独立客观的审查（与对话解耦）、想省 token 用便宜模型审、CI/CD 自动化 | 对话中顺手查、不想折腾配置、审查结果直接融入对话 |
| 输出规范 | OCR 自己的结构化报告 | 七步工作流（预览→规则→diff→逐文件审→格式化→按严重度分级→可选修复），覆盖率强制（每个文件必须标记 reviewed 或说明跳过原因） |
怎么选：平时对话里让我顺手查代码 → 委托模式；要正式的独立审查报告或接 CI → 主审查模式。两个都装着不冲突，用哪个看场景。
主审查配 Qwen 够用吗？（9-18 评估）
结论：够用，是合理的省钱组合。 两条依据：
- OCR 的架构替模型扛了最难的活——选文件、分组、规则匹配、行号定位全是工程做的，模型只负责「读材料、下判断」。官方评测的核心结论就是：同一个模型，套上 OCR 后精确率远超裸奔状态——这意味着模型档次可以适当让一让，脚手架会把质量托回来
- 选对款式——用 Qwen 的 Coder 系列（写代码向，代码理解是它的主业），别用通用聊天款。审查任务需要的正是代码理解力 + 判断力，这正是 Coder 系列的强项
实操建议：先配上跑三五次真实审查，看两件事——行号准不准、报的是不是真问题。满意就固定；不满意换更高档的模型，OCR 换模型是一分钟的事。也可以「双模型策略」：日常审查用 Qwen（省），重大改动用旗舰模型（稳）。
成本账：OCR 的 token 消耗只有通用 agent 的约 1/9，再叠 Qwen 的低价，日常审查成本几乎可以忽略。
模型配置进展（9-18）：✅ 最终方案 MiniMax M3（不限量包月）
- ✅ 配置成功并验证通过：provider =
minimax-cn（api.minimaxi.com/v1）+ 模型 MiniMax-M3 + 用户 Token Plan Key（sk-cp- 前缀）——ocr llm test连通性测试通过，模型正常应答 - 为什么这是最优解：MiniMax Token Plan 是包月不限量——审查的边际成本 = 零。日常无限次代码审查不产生任何额外 API 费用；重大改动想要更强的大脑时再切别的模型
- 已顺带配置：审查语言 = 中文（
ocr config set language 中文） - Qwen 通道记录（受阻存档）：百炼 Coding Plan 专属 Key 失效（报 token expired）——正确端点应为
coding.dashscope.aliyuncs.com/apps/anthropic（Anthropic 协议），等用户换新 Key 后可再加一路 - 配置踩坑记录：①百炼 Coding Plan 专属 Key 不能用标准兼容端点（401）；②内置预设服务商（minimax-cn 等）要用
providers.<name>.api_key覆盖方式配，不能用custom_providers.<name>（会报名称冲突）
和我的关系
- 某合作银行项目的质量关卡：项目启动后 AI 会写大量代码——OCR 正好当「第二双眼睛」，AI 写完 AI 查，行号精确可定位
- 设计哲学共鸣：确定性工程 × Agent 混合，与 HomeRail 的思路同源——该硬约束的绝不交给模型随机发挥
- 接入 Claude Code/Codex 插件即用，也可用委托模式白嫖现有 coding agent
相关笔记
相关日记
- 2026-09-17 - 首次了解