每日热门skill-AI 写的代码，谁来看第二眼？阿里把内部跑了 370 万次的评审助手开源了：39K Star 的 open-code-review，用 1/9 的 Token 换 4.7 倍准确率

免费基金定投助手全功能拆解：为什么你的基金定投还在亏钱？因为你的工具用错了。动态平衡仓位管理+8种智能定投策略引擎，会自己算买卖点的定投系统-CSDN博客

https://download.csdn.net/download/weitingfu/93448039?spm=1001.2014.3001.5503

摘要 / 导读

2026 年最尴尬的工程现状是：AI 生成代码的速度，已经远远超过人类评审代码的速度。于是「让 AI 审 AI」成了顺理成章的选择——但你真把整个 diff 丢给 Claude Code，大概率会得到一份覆盖不全、行号漂移、误报成堆的报告。

2026 年 5 月，阿里把内部跑了两年、服务数万开发者、累计执行 370 万次评审任务的 AI 代码审查助手整包开源，项目名 alibaba/open-code-review，CLI 叫 ocr。截至 2026-09-22，GitHub Star 约 39.2K，npm 周下载 10.8 万，Apache-2.0。它给出的答案不是「更聪明的 Prompt」，而是一句很工程化的判断：

必须由工程保证 100% 正确的环节，绝不交给概率模型。

本文基于官方文档、架构页、GitHub API 硬数据与第三方实测，完整拆解它的混合架构、接入方式、可直接复制的配置与 CI 流水线，并给出横向对比、成本测算与一份踩坑清单。

目录

• 一、背景：当「写」不再是瓶颈，「审」成了新瓶颈
• 二、热度依据与数据口径说明
• 三、Open Code Review 是什么：定位与来历
• 四、核心概念：确定性工程 × Agent 的混合架构
• 五、架构与原理：一次 ocr review 内部发生了什么
• 六、快速上手：10 分钟跑通第一次评审
• 七、代码实战：从自定义规则到 CI 全链路
• 八、进阶用法：MCP、委托模式与成本控制
• 九、对比评测：AACR-Bench 与同类方案横评
• 十、最佳实践与避坑清单
• 十一、生态与社区活跃度
• 十二、个人评价与展望
• 参考链接
• 关键词 / Tag

一、背景：当「写」不再是瓶颈，「审」成了新瓶颈

先把问题说清楚。过去两年，编码 Agent 把「产出一行代码」的成本压到了接近于零，但代码进入主干之前的那道闸门没有变宽。于是流水线出现了新的拥塞点：PR 排队等人 review，而人 review 的速度又被 AI 的产出速度进一步拉开。

团队的自然反应是「让 AI 先过一遍」。但真实体验过的人都知道，直接用通用 Agent（Claude Code / Codex / Cursor）做 review，有三个非常稳定的失效模式，官方文档把它总结为：

根因诊断：这三个问题不是模型不够聪明，而是架构缺陷。纯语言驱动的方案，对「审哪些文件」「怎么分包」「评论落在哪一行」这些必须 100% 正确的环节，没有任何硬约束——它本质上是在让一个概率模型去承担确定性职责。

我自己在几个中型仓库上做过对照：一个 40 文件的 PR，通用 Agent 报了 60 多条问题，人工筛完剩下 8 条有价值的；剩下 52 条的处理成本，比它节省的时间还高。误报的成本不是「多读几行」，而是消耗掉团队对自动化评审的信任——一旦信任垮了，工具就再也没人打开了。

这正是 Open Code Review 想解决的痛点，而且它的解法相当克制：不追求「更聪明的 Prompt」，而是把流程切开，一半交给工程，一半留给模型。

二、热度依据与数据口径说明

先说明为什么今天写它。按照我每天的选题流程，这一轮从 GitHub Trending、七牛云周榜、GhTrends 以及中文社区（掘金、CSDN、网易号）交叉验证，近 7 天 AI Agent 赛道热度最高的新项目是 alibaba/open-code-review：

口径提示（重要）：不同来源的 Star 数差异极大（20.5K ~ 39.2K），差值主要来自快照时间而非统计口径。该项目近 5 天日均增星约 2,000~3,000，任何超过 3 天的二手数据都会严重失真。引用时请以 GitHub 官方接口为准，本文所有硬数据均为 2026-09-22 实测。

版本侧的硬数据同样来自官方源：npm 最新稳定版 v1.12.8（发布于 2026-09-21 12:54 UTC），累计发布 121 个版本，License Apache-2.0，主语言 Go，仓库创建于 2026-05-18，最近一次 push 为 2026-09-21。

三、Open Code Review 是什么：定位与来历

3.1 一句话定位

Open Code Review（下称 OCR）是一个 AI 驱动的代码审查 CLI + Agent Skill 套件。它读取 Git diff，通过具备工具调用能力的 Agent 把变更文件交给可配置的 LLM，最终产出具备行级精度的结构化审查意见。

它不是「把代码丢给大模型总结一下」，而是：

• Agent 可以读取完整文件内容（而不只是 diff 片段）；
• 可以搜索整个代码库、查看同 PR 的其他变更文件以补充上下文；
• 除了 diff 审查，ocr scan 支持全文件审查，用于审计陌生代码库或没有有意义 diff 的目录。

3.2 来历：不是 Demo，是内部资产外溢

这一点是它区别于绝大多数「周末项目」的关键。官方 README 明确写道：它的前身是阿里集团内部官方 AI 代码审查助手，过去两年在内部服务了数万开发者，识别出数百万个代码缺陷，经过大规模验证后才孵化开源。

第三方报道补充的内部运行数据（来源见文末参考链接，属于官方口径，非独立审计）：

• 月活开发者：2 万
• 累计评审任务：370 万次
• 问题采纳率：>30%（即 AI 提的意见，超过三成开发者真的改了）
• 位置准确率：97%（报告说第几行就是第几行）

我的看法：这三个数字里，「采纳率 >30%」比任何 F1 分数都更有说服力。基准测试的分数可以被数据集构造方式影响，但「开发者愿不愿意照着改」是骗不了人的产品指标。当然，它是官方自述，独立第三方尚未复现，请自行判断权重。

3.3 它属于哪一类「Agent Skill」

按我一直在跟踪的分类，OCR 属于**「CLI 能力 + 多形态 Skill 封装」**这一类：底层是一个 Go 写的独立 CLI（ocr），上层同时提供：

• Claude Code 插件（marketplace 形式，带 /open-code-review:review 斜杠命令）
• Codex 插件（可调用的 review skills）
• Cursor 插件（.cursor-plugin/plugin.json 便携技能）
• Kimi Code 插件（斜杠命令 + skills）
• OpenCode 原生工具
• QCA Forward 模板（委托模式）
• 通用可移植 Agent Skill（npx skills add 安装，任何兼容 Skill 的 Agent 都能用）
• MCP Client（可挂载外部 MCP Server 扩展审查 Agent 的工具集）

也就是说，它不绑定任何一家 Agent 厂商——这在当下这个各家都在抢入口的阶段，是个相当清醒的选择。

四、核心概念：确定性工程 × Agent 的混合架构

这是全文最值得记住的一节。

4.1 分工原则

OCR 的全部设计，可以浓缩成一句话：

确定性工程负责「不能出错」的环节，Agent 负责「需要理解与判断」的环节。

确定性工程（Hard Constraints） 承担四件事：

Agent（Dynamic Decisions） 只承担两件事：

洞见：这套分工的本质，是把「Agent 不确定性」关进工程笼子里。你会发现它和 Anthropic 那套 “writing effective tools for agents” 的思路有呼应——与其让模型更聪明，不如让模型的选择空间更小、更结构化。

4.2 六道文件过滤闸门

ocr review 对每个 diff 文件依次过闸（源码 internal/agent/selection.go）：

内置密钥路径（永不出网，这点对合规团队极其关键）：

**/.ssh/** **/id_rsa **/id_dsa **/id_ecdsa **/id_ed25519
**/.netrc **/_netrc **/.npmrc **/.pypirc **/.dockercfg
.env 及 .env.*（.env.example / .env.sample / .env.template 除外）

踩坑提示：**/vendor/** 在 diff 层按仓库根路径前缀匹配，在文件层按 glob 匹配。所以根目录下的 vendor/pkg/x.go 被报为 provider_directory，include 规则救不回来；而 api/vendor/pkg/x.go 被报为 default_path，include 可以救回来。遇到「我的规则怎么不生效」，先用 ocr review –preview 看它到底卡在哪道闸。

4.3 四层规则解析链

规则（即「这个文件该按什么标准审」）按优先级从四层中取第一个命中的：

系统内置规则覆盖了相当细的粒度，举几个有意思的：**/*{mapper,dao}*.xml → MyBatis mapper SQL 注入检查；**/pom.xml / **/package.json / **/Cargo.toml → 依赖与脚本检查；.github/workflows/**/*.{yaml,yml} → GitHub Actions 工作流检查；**/*.{ftl,ftlh,ftlx} → FreeMarker 模板的 SSTI/XSS；**/*.sol / **/*.vy → 智能合约；**/*.{v,sv,vh} / **/*.{vhd,vhdl} → Verilog/VHDL RTL。

甚至还有一个细节：.m 文件同时属于 MATLAB 和 Objective-C，OCR 会嗅探首个非空行（是否 #import / @implementation）来二选一，读不到时回退 matlab.md。

五、架构与原理：一次 ocr review 内部发生了什么

官方架构页给出了完整流水线，我按其描述重绘如下：

flowchart TD
A["ocr review<br/>命令入口"] –> B["bootstrap<br/>解析 LLM 端点 / 加载模板·工具·系统规则"]
B –> C["diff provider<br/>git diff / ls-files / show<br/>Workspace · Commit · Range"]
C –> D["filter & rules<br/>六道闸门 selection.go<br/>四层规则链解析"]
D –> D2["semantic grouping<br/>单次 LLM 调用<br/>仅传文件元数据, 不传 diff"]
D2 –> E["subtask dispatch<br/>并发 N=8, 每组独立 goroutine<br/>Plan 阶段 → Main 循环 × rounds"]
E –> F["comment worker pool<br/>行号解析 → 重定位 → 反思过滤"]
F –> G["output writer<br/>text / json / sarif"]

E -.->|每个 sub-agent| T["工具集<br/>code_search · file_read · file_read_diff<br/>file_find · code_comment · task_done"]
T -.->|外部扩展| M["MCP Servers<br/>Jira / 内部文档 / 自定义 linter"]

5.1 语义分组（Semantic Grouping）

过滤后的文件不是一个个单独审，而是先做一次 GROUPING_TASK LLM 调用。注意这里的关键设计：

• 只传文件元数据（路径、状态 ADDED/MODIFIED/DELETED/RENAMED、增删行数），绝不传 diff 内容 —— 省 token，也避免过早消耗上下文。
• 模型返回 {label, files} 数组，每个组在同一个会话里审查，因此 Agent 能跨文件推理（handler + service + mapper 的联动问题藏不住）。

三道保护确保分组不会失控：

设计要点：分组是尽力而为的优化，不是正确性闸门。分组调用失败/返回空/解析不了，只会打一条 warning，然后回退到「一文件一组」的老行为。这个取舍我很欣赏——优化路径永远不能成为单点故障。

5.2 每个子任务的 Plan / Main 两阶段

Plan 阶段（可选），由两个阈值触发：

// PLAN_MODE_LINE_THRESHOLD = 50, PLAN_MODE_GROUP_LINE_THRESHOLD = 100
if maxFileChanged >= 50 { plan } // 单个大改写
if fileCount >= 2 && total >= 100 { plan } // 多个中等文件合计够大

小改动直接跳过 Plan（否则纯增延迟）。Plan 阶段不发送 Tools 字段，模型调不了工具，只返回一份 checklist 作为 {{plan_guidance}} 注入主提示词。

Main 循环跑工具调用会话，六个内置工具：

循环退出条件有五：task_done 被调用 / 达到 MAX_TOOL_REQUEST_TIMES（默认 100）/ 连续 3 轮无有效工具结果 / 上下文取消 / 压缩后仍超阈值。

5.3 评论处理流水线

每条 code_comment 都要过一遍 CommentWorkerPool（固定大小协程池，不阻塞主循环）：

5.4 三层 Token 预算护栏

tokenLimit := MaxTokens * 4 / 5 // 80%
if countMessagesTokens(messages) > tokenLimit {
record warning "token_threshold_exceeded"
return nil // 跳过该组
}

三层分别是：调度前的 fail-fast 检查、selectFiles 阶段的 too_large 过滤、分组内的 enforceGroupTokenBudget。任何一层都会产生非致命 warning 而不是失败——超预算的组被跳过并在 JSON warnings 里报告，其余组照常出结果。

5.5 六个提示词模板

internal/config/template/task_template.json 定义六个任务：GROUPING_TASK、PLAN_TASK、MAIN_TASK、MEMORY_COMPRESSION_TASK、REVIEW_FILTER_TASK、RE_LOCATION_TASK。

注意：模板不是 CLI 可覆盖项。想改提示词必须编辑 task_template.json 并重新编译。而 –tools 参数覆盖的是工具注册表，不是提示词模板——这两个经常被混淆。

六、快速上手：10 分钟跑通第一次评审

6.1 前置条件

• Git >= 2.41（硬要求，低于此版本直接失败）
• Node.js >= 14（npm 安装方式）

6.2 安装

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

包体积通过平台特定的 optional dependencies 分发（ocr-linux-x64 / ocr-win32-x64 / ocr-darwin-arm64 等六种），安装后 ocr 命令全局可用。也支持安装脚本、GitHub Release 二进制和源码构建。

# 验证安装
ocr version

6.3 配置模型

ocr config provider # 交互式选择供应商、填 API Key、选模型
ocr config model # 切换模型
ocr llm test # 验证连通性

内置供应商覆盖面相当广，国内外主流都在：

完整表格见官方配置页，上表为节选。对国内团队最实用的一点：整个链路可以完全走国内模型 + 私有部署，代码不出内网。

6.4 三种审查模式

cd your-project

# 工作区模式 —— 审查所有 staged / unstaged / untracked 变更
ocr review

# 分支范围 —— merge-base 模式，审 feature 与 main 分叉后的全部变更
ocr review –from main –to feature-branch

# 单个提交
ocr review –commit abc123

# 全文件扫描 —— 无 diff 也能审（代码审计场景）
ocr scan
ocr scan –path internal/agent

# 【强烈推荐】先预览，不花一个 Token
ocr review –preview

–preview 会打印「哪些文件会审 / 哪些被排除 / 为什么被排除」，大仓库在正式烧 Token 前务必先跑一次。

七、代码实战：从自定义规则到 CI 全链路

7.1 自定义项目规则（团队落地第一步）

在项目根目录建 .opencodereview/rule.json，提交进仓库，全团队共享：

{
"include": ["src/**/*.{ts,tsx,js,jsx}", "internal/**/*.go"],
"exclude": ["**/*.gen.ts", "**/generated/**", "**/mocks/**"],
"rules": [
{
"path": "internal/api/**/*.go",
"rule": "所有对外暴露的 handler 必须：1) 校验请求体必填字段；2) 事务开启后立即 defer tx.Rollback()；3) 禁止在循环中查询数据库（N+1）。",
"merge_system_rule": true
},
{
"path": "**/*mapper*.xml",
"rule": "检查 SQL 注入风险（禁止 ${} 拼接）、参数绑定是否完整、XML 标签是否闭合、是否存在全表扫描。"
},
{
"path": "src/api/**/*.ts",
"rule": "检查未处理的 Promise rejection、缺失的错误边界、以及对用户输入直接 dangerouslySetInnerHTML 的情况。"
}
]
}

验证规则是否命中：

ocr rules check src/main/java/com/example/UserService.java
# 输出：File / Source: System built-in / Pattern: **/*.java / Rule: （规则全文）

ocr rules check –rule custom.json src/main/resources/mapper/UserMapper.xml

merge_system_rule: true 是个容易被忽略的好设计：默认情况下，用户规则命中后会替换系统内置规则；加上这个开关，两者会合并，你既能拿到团队规约，又不丢失内置的 NPE / 线程安全 / XSS 检查。

7.2 本地审查完整示例

# 带上业务背景（对质量提升最明显的杠杆），输出机器可读 JSON
ocr review \\
–from main –to feature/payment-refund \\
–background "本次重构退款流程，将同步退款改为消息队列异步处理，需要重点关注幂等性与事务边界" \\
–format json –audience agent \\
–output /tmp/ocr_result.json

关键参数说明：

用 Python 消费 JSON 输出：

import json, collections

with open("/tmp/ocr_result.json", encoding="utf-8") as f:
data = json.load(f)

comments = data.get("comments", [])
buckets = collections.defaultdict(list)
for c in comments:
buckets[c["severity"]].append(c)

for sev in ("critical", "high", "medium"):
for c in buckets.get(sev, []):
pos = f"{c['path']}:{c['start_line']}" if c["start_line"] else f"{c['path']}(行号未锚定)"
print(f"[{sev.upper()}][{c['category']}] {pos}")
print(f" {c['content']}")
if c.get("suggestion_code"):
print(f" 建议: {c['suggestion_code'][:200]}")
print()

print("warnings:", data.get("warnings", []))

每条评论的字段：path / content / start_line / end_line / category（bug, security, performance, maintainability, test, style, documentation, other）/ severity（critical, high, medium, low）/ suggestion_code / existing_code / thinking。

注意 start_line == end_line == 0：这不是 bug，是行号解析失败的显式信号。消费方必须自己兜底（读内容、看文件、手动定位），不要直接当成第 0 行渲染。

7.3 接入 Claude Code / Codex / Cursor

Claude Code（在 Claude Code 内执行）：

/plugin marketplace add alibaba/open-code-review
/plugin install open-code-review@open-code-review

装完得到 /open-code-review:review 与 /open-code-review:delegate-review 两条斜杠命令。

Codex：

codex plugin marketplace add alibaba/open-code-review
codex

打开 /plugins 安装并启用 Open Code Review，然后：

@Open Code Review review this branch against main
@Open Code Review review and fix high-confidence issues

Cursor：把 plugins/open-code-review/ 整个目录拷到 ~/.cursor/plugins/local/open-code-review/，确认 manifest 位于 ~/.cursor/plugins/local/open-code-review/.cursor-plugin/plugin.json，重启或执行 Developer: Reload Window。

通用可移植 Skill（任何兼容 Skill 的 Agent）：

npx skills add alibaba/open-code-review
# 或只装委托模式
npx skills add alibaba/open-code-review –skill open-code-review-delegate

7.4 接入 GitHub Actions（团队最该做的一步）

官方提供复合 Action，直接用：

name: AI Code Review
on:
pull_request:
types: [opened, synchronize, reopened]

permissions:
contents: read
pull-requests: write

jobs:
ocr-review:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
with:
fetch-depth: 0 # 必须！否则找不到 merge-base

– uses: actions/setup-node@v4
with:
node-version: '20'

– name: Install OCR
run: npm install -g @alibaba-group/open-code-review@1.12.8

– uses: alibaba/open-code-review@main
with:
llm_url: ${{ secrets.OCR_LLM_URL }}
llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
llm_model: ${{ vars.OCR_LLM_MODEL }}
effort: high
max_tokens_budget: '10000000'
llm_reasoning_effort: low
stream_progress: 'true'

需要的 Secrets / Variables：

走 SARIF 上传 GitHub Code Scanning（推荐，安全团队会喜欢）：

– name: Run OCR review (SARIF)
env:
BASE_REF: ${{ github.base_ref }}
HEAD_REF: ${{ github.head_ref }}
run: |
ocr review \\
–from "origin/$BASE_REF" \\
–to "origin/$HEAD_REF" \\
–format sarif –audience agent > results.sarif

– uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: results.sarif

GitLab CI 同理，注意设 GIT_DEPTH: 0，评论通过 MR Discussions API 内联发布：

script:
– |
ocr review \\
–background "$CI_MERGE_REQUEST_TITLE" \\
–from "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" \\
–to "${CI_COMMIT_SHA}" \\
–format json –audience agent

安全提示：PR 标题、分支名这类攻击者可控的值，务必通过 env: 传入再引用，不要直接把 ${{ github.event.pull_request.title }} 插值进 shell——这是经典的 Actions 注入面。

八、进阶用法：MCP、委托模式与成本控制

8.1 委托模式（Delegation Mode）：零 API Key 的玩法

如果你已经在用 Claude Code / Codex / Cursor / Qoder 的订阅，完全不需要为 OCR 单独配一个模型端点。委托模式下：OCR 只做确定性的文件筛选与规则解析，真正的审查推理由宿主 Agent 自己的模型完成。

# Step 1: 预览将要审什么
ocr delegate preview –from main –to feature

# Step 2: 拿规则（按规则内容分组，避免重复）
ocr delegate rule src/handler.go src/service.go

# Step 3: 宿主 Agent 用 git diff 取内容，照着规则分组逐文件审
git diff <merge_base>..feature — src/handler.go

flowchart LR
subgraph A["默认模式"]
A1["Agent"] –> A2["调用 ocr review"]
A2 –> A3["OCR 自带 LLM<br/>独立完成审查"]
A3 –> A4["结构化评论"]
end
subgraph B["委托模式 Delegation"]
B1["宿主 Agent"] –> B2["ocr delegate preview<br/>ocr delegate rule"]
B2 –> B3["确定性结果<br/>文件清单 + 规则"]
B3 –> B4["宿主 Agent 用自己的<br/>订阅额度做推理"]
B4 –> B5["结构化评论"]
end

这个模式对企业非常友好：不需要新建 API Key、不需要走采购流程、代码不需要再出一份给第三方端点，而且订阅额度本来就是沉没成本。

三种模式的对比：

8.2 挂载 MCP Server 扩展审查能力

OCR 本身是 MCP Client，可以挂载外部 MCP Server，让审查 Agent 拿到 diff 之外的上下文：

# 本地 stdio 服务
ocr config set mcp_servers.docs.command npx
ocr config set mcp_servers.docs.args '["-y", "@acme/docs-mcp-server"]'
ocr config set mcp_servers.docs.tools '["search_docs", "get_page"]'
ocr config set mcp_servers.docs.setup "npm install -g @acme/docs-mcp-server"
ocr config set mcp_servers.docs.env '["DOCS_TOKEN=secret"]'

# 远程 Streamable HTTP 服务（注意：只设 url 不够，必须设 type）
ocr config set mcp_servers.search.type remote
ocr config set mcp_servers.search.url https://mcp.example.com/mcp
ocr config set mcp_servers.search.tools '["search", "fetch"]'

配置字段：type（stdio/remote）、command、args、url、headers、tools（白名单）、setup（启动前命令，5 分钟超时）、env。

踩坑清单（MCP）：

• 只设 url 不设 type: remote → 被当作 stdio，连不上。
• 工具名与内置工具（file_read、code_search、task_done 等）冲突 → 静默跳过并打 warning，先注册者胜。
• headers 里的 $VAR 展开为空 → 连接直接失败，不是当作缺省处理。
• 所有诊断走 stderr 且带 [ocr] 前缀，不会污染 –format json 的 stdout。

8.3 成本控制的四个旋钮

8.4 会话回放与增量对比

所有评审以 JSONL 落盘在 ~/.opencodereview/sessions/<encoded-repo-path>/<session-id>.jsonl，每行一个事件（提示词、响应、工具调用、评论）。无数据库，纯追加日志。

ocr viewer # 默认 http://localhost:5483
ocr session list
ocr session show <id>
ocr session comments <id> –severity critical,high
ocr session compare <before> <after> # 四桶：new / persisting / resolved / not_reviewed
ocr session export <id> -o report.html
ocr review –from main –to feature –resume <session-id>

compare 的四桶输出特别适合做**「这轮改完问题少了多少」**的量化汇报。

九、对比评测：AACR-Bench 与同类方案横评

9.1 AACR-Bench：官方基准（务必带着方法论读）

数据集构成：50 个热门开源仓库 / 200 个真实 PR / 10 种编程语言 / 80+ 位资深工程师交叉标注 / 1,505 个 ground-truth 缺陷，已发布在 HuggingFace（Alibaba-Aone/aacr-bench）。配套论文见 arXiv:2608.09290。

核心结果（同模型对比，最能说明架构差异）：

怎么读这张表（很重要）：

• 同模型下，OCR 的 Precision 是 Claude Code 的 4.7 倍（33.90% vs 7.23%），Token 约为 1/15（385K vs 5,664K），速度快 9.4 倍。
• 但 Recall 输了：20.00% vs 28.90%。Claude Code 生成了 5,980 条评论命中 435 个真问题；OCR 只生成 889 条命中 301 个。这是刻意的设计取舍——宁可少报，不要误报。
• 绝对数值（F1 25%）看着不高，说明自动代码评审整体仍处于早期，不是 OCR 一家的问题。
• 口径冲突提示：有中文报道称「OCR 每次评审约 37.5K token」，与官方图表的 385K 差一个数量级，疑为笔误或不同统计口径。本文采用官方图表值 385K，并标注此冲突。

这是项目方自己发布的基准，不等于第三方独立结论。 但对工程决策来说，同模型对比的相对关系仍有参考价值：它证明的是「把确定性职责从模型手里收回来」这个方向有效，而不是「OCR 天下第一」。

9.2 与同类方案横向对比

上表价格均为第三方榜单的公开报价，各厂商调价频繁，采购前请以官网为准（标「待验证」）。

选型建议：

• 代码合规要求严 / 已有国产模型 / 想自己掌控流程 → OCR 几乎是唯一选择。
• 追求最高召回（安全审计） → Greptile 那类全仓库多跳方案更合适，或者 OCR 的 ocr scan 全文件模式 + effort high 组合，再叠加专业 SAST。
• 只想开箱即用、不想运维 → CodeRabbit / Copilot 更省事。
• 已经订阅了 Claude Code / Codex → 用 OCR 的 Delegation Mode，零额外成本拿到工程化评审。

9.3 一个粗略的成本测算

假设团队每天 40 个 PR，用 OCR（medium effort，约 385K token/次）+ 国产模型（按 ¥4/百万 input token 估算，价格为示意，实际以厂商报价为准）：

40 PR × 385K token ≈ 15.4M token/天
按 ¥4/M input + ¥16/M output（假设 output 占 5%）估算：
input: 15.4M × 0.95 × ¥4/M ≈ ¥58.5/天
output: 15.4M × 0.05 × ¥16/M ≈ ¥12.3/天
合计 ≈ ¥71/天 ≈ ¥1,550/月（22 工作日）

对比 20 人的 CodeRabbit Pro（约 $24/人/月）≈ $480/月 ≈ ¥3,400/月。OCR 在 20 人团队规模下大约能省一半，且规模越大优势越明显——因为 SaaS 是线性按席位收费，而 OCR 是按 PR 计费。

这只是量级估算。真实成本取决于你的 PR 粒度、模型选型和 effort 设置，务必先用 –max-tokens-budget 灰度跑两周再下结论。

十、最佳实践与避坑清单

10.1 落地路径（我的建议）

flowchart LR
S1["Step 1<br/>个人本地用<br/>ocr review –preview<br/>熟悉排除逻辑"] –> S2["Step 2<br/>写团队 rule.json<br/>ocr rules check 验证"]
S2 –> S3["Step 3<br/>非核心仓库灰度 2 周<br/>统计采纳率与行号准确率"]
S3 –> S4["Step 4<br/>接 CI，只做评论<br/>不阻断合并"]
S4 –> S5["Step 5<br/>稳定后接 SARIF<br/>critical 阻断合并"]

关键原则：Step 4 阶段绝对不要让 AI 评审阻断合并。先用评论建立信任，等误报率降到团队可接受，再谈卡点。

10.2 踩坑清单（按踩中概率排序）

⚠️ 坑 1：Git 版本不够。 硬要求 Git >= 2.41。CentOS 7 自带 Git 1.8，必须先升级，否则直接失败。

⚠️ 坑 2：CI 里 Cannot find merge-base。 GitHub Actions 必须 fetch-depth: 0，GitLab 必须 GIT_DEPTH: 0。默认浅克隆拿不到 merge-base。

⚠️ 坑 3：召回率是短板，别当安全审计用。 OCR 明确选择了「精度优先」。做安全审计必须配合 ocr scan 全文件模式 + effort high + 专业 SAST，不能单靠它兜底。

⚠️ 坑 4：大文件被静默跳过。 单文件 diff 超过 max_tokens（默认 200000）的 80% 会被丢弃，且不失败——只在 warning 里报 too_large / token_threshold_exceeded。务必检查 JSON 的 warnings 数组。

⚠️ 坑 5：ocr delegate 的文档不一致。 官方 CLI Reference 页当前未列出 delegate 子命令（只有 review/scan/rules/config/llm/viewer/session），但 README、委托模式文档页和 SKILL.md 都在用它。以 README 为准，delegate 可用，但这属于文档滞后。

⚠️ 坑 6：.m 文件的规则路由不确定。 MATLAB / Objective-C 靠内容嗅探，启发式可能随版本变化。需要确定性路由就显式写项目级规则。

⚠️ 坑 7：api_key_cmd 的后台守护进程。 用 op / gpg 取密钥时，若守护进程持有 stdout 管道，每次 ocr 都会多等 5 秒。加 >/dev/null 2>&1 解决。Windows 上走 cmd.exe 而不是 sh，%VAR% 和 ^ 是元字符，$VAR 不生效。

⚠️ 坑 8：本地模型（Ollama）必须支持原生 tool calling。 否则 Agent 循环直接退化。另外自定义 provider 必须填非空 api_key（随便填个占位符），没有环境变量回退。

⚠️ 坑 9：改提示词要重新编译。 模板不是 CLI 可覆盖项。–tools 覆盖的是工具注册表，别搞混。

⚠️ 坑 10：–no-filter 慎用。 关掉反思过滤会显著拉高误报率，只在你想看原始召回能力时开。

10.3 团队约定建议

十一、生态与社区活跃度

近期 commit 的质量也值得一说——fix(config): exclude dependency and build-output directories by default、fix(diff): parse git's quoted pathnames instead of dropping the file、feat(rules): add F# review support、perf(viewer): paginate large review result lists。都是实打实的工程细节修复，不是刷存在感的文档改动。

唯一需要观察的是贡献者集中度：首位贡献者 283 次提交，第二名 37 次，呈明显的「公司主导开源」形态。这对迭代速度是好事，对长期治理（万一团队转向）是个风险点。Apache-2.0 + 单二进制 + 本地优先，意味着即便项目停更，你的 fork 成本也不高。

十二、个人评价与展望

12.1 我的判断

这是近半年我见过架构思路最清醒的 AI 工程化项目之一。 它没去卷「谁的模型更强」，而是问了一个更本质的问题：在一个业务流程里，哪些环节必须 100% 正确？

答案一旦明确，工程手段就能接管：文件筛选用代码判定，规则匹配用模板引擎，评论定位用滑动窗口算法 + 重定位兜底，反思过滤用独立 LLM 调用。剩下的——理解意图、检索上下文、判断风险——才交给模型。

这套思路的价值远超代码评审本身。任何「Agent 做专业任务」的场景——日志分析、告警归因、合规检查、数据血缘梳理——都可以套用同样的切分法：先问哪些环节不能出错，再决定哪些交给模型。

12.2 需要警惕的地方

12.3 展望

我判断接下来会看到三件事：

• 更多「确定性工程 × Agent」的垂直复刻。OCR 验证了这个范式的有效性，日志分析、测试用例生成、依赖升级评估都会出现同类产品。
• 评审与生成的角色分离成为标准实践。现在「同一个模型又写又审」的做法，两年后会被视为工程事故——就像今天没人会让同一个开发既写代码又合并自己的 PR。
• 推理成本成为核心竞争维度。当效果趋同，1/9 的 token 消耗就是 9 倍的成本优势。这会倒逼所有 Agent 工具重新审视「哪些 token 是非必要消耗的」。

给不同角色的行动建议：

• 个人开发者：今天就可以装，ocr review 直接可用，零成本试错。
• 小团队：先用 Delegation Mode，不花额外的钱，把 .opencodereview/rule.json 建起来。
• 中大型团队：非核心仓库灰度两周，重点观察三个指标——采纳率、行号准确率、Token 花费。这三个数字决定它值不值得进 CI。

参考链接

官方一手来源

基准与论文

第三方报道与实测（交叉验证用）

关键词 / Tag

AI Agent · Agent Skills · Code Review · OpenCodeReview · MCP · 工程效能 · Claude Code · DevOps

免责声明：本文所有硬数据（Star / Fork / 版本 / 下载量）均于 2026-09-22 通过 GitHub REST API 与 npm registry 官方接口实测；价格类数据来自第三方榜单，已标注「待验证」，采购前请以各厂商官网为准。AACR-Bench 为项目方发布的基准，非第三方独立审计结论。