阿里两万人用了两年的 AI 代码审查工具，开源了
阿里开源 OpenCodeReview（OCR），一款已在内部服务两万人、经两年生产验证的 AI 代码审查工具。它通过工程化流程约束 LLM 行为，解决通用 Agent 在代码审查中常见的覆盖不全、位置漂移、效果不稳定等问题，在相同底层模型下准确率与 F1 得分优于 Claude Code，token 消耗仅为其约 1/9。
解决真实痛点的生产级工具
阿里内部两万人用了两年的 AI 代码审查工具，5 月份开源了。两个半月，GitHub 17000+ star。
这个数字说明一件事：代码审查这个环节，大家真的受够了。
受够什么？PR 挂三天没人看，reviewer 只回一个"LGTM"，自己审自己的代码永远觉得"没问题"。让 AI 来审？大家都想过。但你真拿 Claude Code 去跑，它告诉你"第 42 行有空指针风险"，翻过去一看，第 42 行是个注释。
OpenCodeReview（命令行里叫 ocr）就是阿里给出的答案。
结构化审查：读 diff，生成带行号的意见
一句话：读你的 Git diff，用 LLM 生成带行号的结构化审查意见。
听起来跟"给 Claude 一段代码让它 review"差不多？差远了。
通用 Agent 做代码审查有三个老大难。覆盖不全：变更文件一多，Agent 开始偷懒，挑几个看看就交差。位置漂移：报的行号跟实际代码对不上。效果不稳定：同一份代码跑两次，出来的意见能差一半。
OpenCodeReview 的 benchmark 下得起本：50 个热门开源仓库、200 个真实 PR、10 种语言，80 多位资深工程师交叉标注出 1505 个真实缺陷当标准答案。在底层模型相同的前提下，它的准确率和综合得分（F1，可以理解为"报得准不准"的总分）都明显高于 Claude Code 直接跑，token 消耗只有约 1/9。
OpenCodeReview 与 Claude Code 在准确率与 F1 得分上的对比代价是召回率低一些。说白了：它宁可少报，也不乱报。报出来的问题大概率是真问题，不用你花大量时间去确认"这到底是不是误报"。
确定性归工程，动态性归 Agent
这个工具最让我觉得聪明的地方，是它的架构哲学。
通用 Agent 做审查，本质上是把整个流程都交给 LLM 自由发挥。该看哪些文件、按什么顺序看、关注什么规则，全靠 prompt 引导。LLM 一"自由发挥"，你就失去了可控性。
OpenCodeReview 把流程劈成两半。
工程逻辑管"不能错"的部分。 哪些文件要审、哪些该跳过，写死的规则说了算。关联文件还会自动打包，比如英文和中文的国际化文件会被归为一组一起审，避免漏掉一边。
每个文件包派一个独立的子 Agent 并发去审，互相之间不串味。审什么、按什么标准审，由预置规则模板定好，不让 LLM 临场发挥。这一步的关键是行为可预期：同一份代码跑十次，结果一致。规则也支持自定义，团队自己的编码约定可以喂进去。
Agent 管"需要判断"的部分。 要不要读完整文件、要不要搜索代码库里的其他引用、要不要看关联的变更文件。这些需要理解力的决策，交给 LLM 动态决定。
确定性的归工程，动态的归 Agent。让 LLM 干判断，让代码干流程。
还有两个外挂组件：一个定位模块，专门把审查意见锚定到精确行号；一个反思模块，在输出前做交叉校验，拦截 LLM 编造不存在 API 或记混上下文的情况。这两个环节如果也让 LLM "顺便"做，就是你前面看到的"位置漂移"问题。单独拆出来用工程手段兜底，效果立竿见影。
开箱即用：五分钟完成本地部署
前置条件就一个：Git >= 2.41。
npm install -g @alibaba-group/open-code-review装完配个模型：
ocr config provider # 选供应商，支持 Anthropic/OpenAI/自定义端点
ocr config model # 选模型然后进你的项目目录：
ocr review # 审查当前工作区所有变更
ocr review --from main --to feature-branch # 审查分支差异
ocr review --commit abc123 # 审查单个提交输出长这样（简化版）：
{
"file": "src/handler.go",
"line": 87,
"severity": "error",
"message": "未检查 conn.Close() 的返回值，连接泄漏时无法感知",
"suggestion": "if err := conn.Close(); err != nil { log.Warn(...) }"
}带文件路径、行号、严重级别、修改建议，可以直接对接 CI 流水线贴到 PR comment 里。
还有个 ocr scan 模式，不依赖 diff，直接审查整个文件。适合你接手一个陌生代码库，想先让 AI 帮你扫一遍有没有明显坑。
如果你已经在用 Claude Code，OpenCodeReview 提供了原生插件，装完后直接在 Claude Code 里用斜杠命令调起审查，不用切终端。Codex 和 Cursor 也有对应集成。
委托模式：提升现有 Agent 的审查质量
除了"OCR 自己调 LLM 做审查"这个默认模式，还有个委托模式（delegate mode）。
你不用给 OCR 配 API Key。它只负责文件筛选、规则匹配、上下文整理这些确定性工作，然后把整理好的"题面"交给你正在用的编程 Agent（比如 Claude Code）去作答。
巧妙在哪？通用 Agent 自己审代码，相当于让一个没受过训练的人凭感觉看。委托模式下，Agent 拿到的是一份整理好的、带规则约束的审查任务，该看哪些文件、关注什么问题、意见怎么定位到行号，这些容易出错的环节 OCR 已经做完了。Agent 还是那个 Agent，但答对的概率高了一截。
适用场景与成本结构
- ✓ 团队 PR 审查积压严重，想让 AI 先过一遍再人工复核
- ✓ 用 Claude Code 做审查但被误报和位置漂移折磨过
- ✓ 代码不能出内网的合规场景（OCR 本身纯本地运行，LLM 推理走你自己配的端点，可以是私有部署的模型）
- ✓ 想在 CI/CD 里加一道自动化审查关卡（支持 GitHub Actions、GitLab CI、Gerrit）
不太需要它的场景：个人小项目改两行代码，或者你享受的是 review 本身带来的思考过程。
Apache-2.0 协议，完全免费开源。代码用 Go 写的。
你唯一的成本是 LLM 的 token 费用。考虑到它只要通用 Agent 约 1/9 的 token 消耗，长期跑下来反而比直接用 Claude Code 审查便宜得多。
工程纪律决定 AI 落地成败
这两年看下来，AI 工具能不能落地，往往不取决于模型多强，而取决于你愿意用多少工程纪律去给它兜底。OpenCodeReview 没发明新模型，它只是把"哪些事不能交给 LLM 自由发挥"想清楚了。
阿里内部两万人跑了两年，识别了数百万个缺陷。这不是 demo 级别的数据，是生产环境里真金白银验证过的。
npm install -g @alibaba-group/open-code-review，五分钟跑起来。你下次提 PR 之前，先让 ocr review 扫一遍，可能会少挨几句骂。
JOTO 企业落地观察
- 企业部署 AI 代码审查工具时，必须面对“模型能力”与“工程可控性”的根本张力。OpenCodeReview 的价值不在更强模型，而在将 LLM 严格限定于语义判断环节，其余流程由确定性代码承载——这对构建可审计、可复现、可合规的审查流水线至关重要。
- 这类系统在智能体工程中提示一种新范式：不追求单个 Agent 全能，而是通过工程化编排，让多个轻量 Agent 各司其职。其“委托模式”实质是将审查任务解耦为上下文构造与语义推理两个阶段，为企业已有 Agent 工具链提供即插即用的能力增强层。
- 对 RAG 知识工程而言，OCR 中“关联文件自动打包”“跨文件上下文注入”等设计，实为一种面向代码域的轻量级 RAG 实践——它不依赖向量库，而是用静态分析+规则匹配实现精准上下文检索，对企业知识治理成本更低、响应更快。
- 在 AI 安全治理层面，OCR 的纯本地执行+用户自控 LLM 端点+无外部依赖的设计，天然满足金融、政企等强监管场景的数据不出域要求；其低 token 消耗特性也降低了模型调用链路中的敏感信息暴露面。
