每天一个开源项目#100 OpenCodeReview：2.6万星的低噪声AI审查器OpenCodeReview把代码审

Trending 排名：#2 | 日期：2026-09-15 | Stars：26,621 | Forks：1,918 | 语言：Go | License：Apache-2.0

代码审查这件事，最烦的不是工具不会说话，而是它说得太多、说得太飘。一个通用 Agent 把 PR 从头到尾扫一遍，常见结果是：评论不少，真正能进修复队列的不多；行号偶尔漂移；大改动里某些文件被轻轻带过。开发者最后还是要自己重新审一遍，等于多了一个需要审查的审查者。

OpenCodeReview 处理的是这个具体问题：把代码审查里必须稳定的部分交给确定性工程，把是否构成缺陷的判断留给 LLM。它不是简单把 git diff 塞进模型，而是先做文件选择、规则匹配、分组、上下文工具、行号定位、结果过滤，再把可解释的审查结果输出到 CLI、JSON、SARIF 或 PR 评论里。

我比较喜欢它的一点是克制。项目 README 没有把高 Precision 说成“缺陷全覆盖”，反而承认 Recall 低于通用 Agent。这对代码审查工具很重要：CI 上一个低噪声机器人，比一个每天制造几十条可疑评论的“热心同事”更容易留下来。

📋 项目概览

项目	内容
项目名	OpenCodeReview
GitHub	github.com/alibaba/ope…
一句话	面向 PR 和全仓扫描的 AI 代码审查 CLI，用确定性流水线约束 LLM 审查过程
Stars	26,621（GitHub Trending 快照）；API 复核同为 26,621
Forks	1,918
语言	Go 为主，另有 TypeScript/JavaScript 前端与 GitHub Action 脚本
License	Apache-2.0
版本	npm / GitHub Release：v1.12.1；main 分支 package.json 为发布占位版本 0.0.0
审计源码	`01ae248`，提交时间 2026-09-15T08:02:47Z

🔥 为什么值得关注

AI Code Review 的老问题是边界太软。你让通用 Agent “帮我审一下”，它会自己决定看哪些文件、什么时候停止、哪些上下文值得读、怎么把问题落到行号上。这套流程在小 PR 里可能还能用，一旦变成几十个文件、跨模块改动、配置和代码一起变，就很容易出现审查覆盖不完整的问题。

OpenCodeReview 的设计思路更像一个审查编排器。它先把 Git 范围、文件过滤、规则解析和任务分发做成硬逻辑，再给模型一组有限工具：file_read、file_find、file_read_diff、code_search、code_comment、task_done。模型可以判断缺陷，但不能随意决定输出结构；评论必须通过 code_comment 进入收集器，并带上路径、已有代码片段、分类和严重级别。

这类工具的价值不在于“替代人审查”。更现实的用法是先把高置信度问题筛出来，减少 reviewer 在空指针、并发共享状态、注入风险、遗漏测试这类问题上的重复劳动。它适合放在 PR 前置检查里，也适合在接手陌生仓库时跑一次全文件扫描。边界要说清楚：LLM 审查不能替代 SAST、单元测试和人工设计评审。

🏗️ 核心特性

确定性文件选择，而不是让模型自己“看心情”审查

ocr review 先从 Git 解析工作区、分支范围或单个提交，再按扩展名、路径、大小和规则过滤文件。源码里的 cmd/opencodereview/review_cmd.go 会先校验 --from、--to、--commit 是否是真实 commit ref，并拒绝以 - 开头的 ref，避免把用户输入变成 Git 参数注入。

Git range / workspace
  -> diff parser
  -> file filter
  -> rule resolver
  -> reviewable set
  -> grouped review tasks

我用一个只有 main.py 改动的临时仓库跑过 preview，v1.12.1 的输出是确定性的：

{
  "files": [
    {
      "path": "main.py",
      "status": "modified",
      "insertions": 3,
      "deletions": 0,
      "will_review": true
    }
  ],
  "total_insertions": 3,
  "total_deletions": 0,
  "total_files": 1,
  "reviewable_count": 1,
  "excluded_count": 0
}

规则是按路径解析的提示约束，不是传统静态分析规则

项目内置 system_rules.json，当前源码里有 52 条路径规则，例如 Java、Go、Kotlin、Python、GitHub Actions、pom.xml、package.json、Cargo.toml 等。它的规则本质是“给模型看的审查说明”，不是 AST 级别的可执行检查。这一点要分清。规则解析是确定性的，缺陷判断仍然由模型完成。

{
  "schema_version": "1",
  "groups": [
    {
      "source": "system",
      "pattern": "**/*.{py,pyi,ipynb}",
      "files": ["main.py"],
      "rule": "...Python review guidance..."
    }
  ]
}

分组策略把“全 PR 一口吞”和“逐文件碎片化”折中起来

internal/agent/grouping.go 里有一个清楚的策略：少量文件或小变更可以直接本地分组，较大变更才调用 LLM 做语义分组。每组最多 10 个文件，还会受 token 预算约束。分组失败时回退到逐文件审查，而不是中断整个任务。

这个取舍很实际。逐文件审查成本可控，但跨文件一致性差；全 PR 一次性审查上下文完整，但容易超长、漏看、输出发散。OpenCodeReview 在中间加了一层 file group，尽量把相关文件放在一个审查单元里。

行级评论有二次定位和过滤

code_comment 工具要求模型提供 existing_code，再用差异文本里的连续代码片段做匹配。匹配失败时，internal/diff/relocation.go 还能调用重定位任务，让模型重新给出更准确的代码片段，然后再解析一次。评论进入最终结果前，还有 review filter 任务。它的过滤策略不是“觉得没用就删”，而是只删除 diff 已经证明错误的评论；证据不足时保留。

LLM finding
  -> code_comment(path, existing_code, category, severity)
  -> snippet match against diff / full file
  -> optional re-location
  -> optional fact-check filter
  -> JSON / SARIF / PR comment

同一套核心能力覆盖本地、CI 和 Agent 委托模式

CLI 有三条主路径：

模式	命令	适合场景	是否需要 LLM 配置
Diff review	`ocr review`	本地改动、PR 范围、单个 commit	需要
Full scan	`ocr scan`	审查没有 diff 语义的目录或陌生仓库	需要
Delegation	`ocr delegate`	让 Claude Code、Codex、Cursor、OpenCode 等宿主 Agent 执行审查	不由 OCR 直接调用 LLM

ocr delegate preview --format json 会输出文件清单、增删行和模式信息；ocr delegate rule --format json <path...> 会输出路径对应的审查规则。也就是说，宿主 Agent 可以复用 OpenCodeReview 的文件选择和规则解析，而模型调用走自己的订阅或上下文系统。

🔬 技术架构深度解析

执行边界

OpenCodeReview 的核心边界可以这样拆：

┌─────────────────────────────────────────────────────────┐
│                    Git / working tree                   │
└───────────────┬─────────────────────────────────────────┘
                │
                ▼
┌─────────────────────────────────────────────────────────┐
│ Deterministic layer                                     │
│ - resolve refs / merge-base / commit identity           │
│ - parse diff or enumerate scan files                    │
│ - apply include/exclude and allowed extensions          │
│ - resolve path rules                                    │
│ - group files, enforce size and token budget            │
│ - persist session, manifest, resume identity            │
└───────────────┬─────────────────────────────────────────┘
                │ review unit + rule + bounded tools
                ▼
┌─────────────────────────────────────────────────────────┐
│ LLM layer                                                │
│ - optional plan task                                     │
│ - inspect current diff / file                            │
│ - call file_read / file_find / file_read_diff / search   │
│ - emit code_comment or task_done                         │
│ - memory compression for long conversations              │
└───────────────┬─────────────────────────────────────────┘
                │ structured comments
                ▼
┌─────────────────────────────────────────────────────────┐
│ Post-processing layer                                    │
│ - parse and repair tool-call JSON                        │
│ - line/snippet resolution                                │
│ - cross-file relocation when needed                      │
│ - review filter                                          │
│ - JSON / SARIF / PR review / local viewer                │
└─────────────────────────────────────────────────────────┘

这里最关键的不是“用了 Agent”，而是哪些事情不交给 Agent。Git ref 校验、文件集合、路径规则、并发、预算、输出 schema、行号定位都在 Go 代码里。模型负责判断和解释，但它的输出被收束到工具调用和结果结构里。

Diff review 和 full scan 是两条不同流水线

ocr review 以 Git diff 为中心。它先解析变更，再构造只针对新增或修改代码的审查任务。ocr scan 不依赖 Git diff，而是把整文件内容作为扫描对象，所以 scan 模式会隐藏 file_read_diff 工具，避免模型浪费调用次数去找不存在的 diff。

ocr review:
  git diff -> changed files -> grouped diffs -> review comments

ocr scan:
  path selection -> full file content -> per-file/batch scan -> project summary

这两个模式的模板也是分开的：diff review 使用 task_template.json，scan 使用 scan_template.json。源码里 scan 的注释写得很直白：全文件扫描没有“其他变更文件”的概念，所以模板里会替换成固定哨兵值，避免模型误以为自己在审一个 PR。

Session、resume 和 manifest 是可维护性的底座

OpenCodeReview 不是一次性把文本打到 stdout。它会为审查会话写 JSONL 历史，记录请求、响应、完成项、失败项和最终 manifest。--resume 也不是简单接着跑，它会校验输入范围、规则、provider、model 等身份信息，发现不一致就拒绝恢复。

这让它更适合 CI：审查任务可能被超时、预算、网络和模型错误打断。没有 session 层，恢复很容易变成“看起来继续了，其实换了输入”。源码里 validateResumeIdentity 明确把这些差异当成恢复前置条件处理。

基准数据该怎么读

README 的 benchmark 来自项目方构建的 AACR-Bench：50 个开源仓库、200 个真实 PR、10 种语言、80 多名高级工程师交叉标注，共 1,505 个 ground-truth issues。这个数据集有价值，但仍然是项目方发布的基准，不等于第三方独立结论。

图中几组可读数据如下：

模型	工具 / 版本	Precision	Recall	F1	Avg Time	Avg Token
Claude-4.6-Opus	Open Code Review v1.3.1	33.90%	20.00%	25.10%	1m23s	385K
Qwen3.8-Max	Open Code Review v1.8.7	33.90%	17.40%	23.00%	5m14s	334K
GLM-5.2	Open Code Review v1.3.1	32.30%	15.90%	21.30%	7m58s	682K
Claude-4.8-Opus	Claude Code v2.1.169	15.93%	12.70%	14.13%	5m38s	2,062K
Qwen3.7-Max	Claude Code v2.1.169	8.23%	23.37%	12.17%	8m6s	5,153K
GPT-5.5	Codex v0.140.0	27.82%	4.92%	8.36%	2m58s	525K

这张表反而说明了一个不太营销的事实：OpenCodeReview 的方向是低噪声，不是“找出全部问题”。以 Claude-4.6-Opus 行为例，OCR 的 Precision 是 33.90%，Recall 是 20.00%；Claude Code 的 Claude-4.6-Opus 行 Precision 只有 7.23%，但 Recall 是 28.90%。前者更适合减少误报，后者更像宽网搜索。两者不是同一种优化目标。

源码规模和模块分布

我对浅克隆源码做了 NUL 分隔的 git ls-files 统计，避免终端截断影响计数。当前审计快照包含 821 个跟踪文件，其中 Go 文件 333 个、Markdown 191 个、TypeScript/TSX 115 个、JavaScript 20 个。源码类文件约 10.2 万行 Go、7,760 行 TypeScript、6,307 行 TSX、13,512 行 JavaScript；测试文件 227 个。

模块	文件数	行数	说明
`internal/`	317	76,844	Git、LLM、规则、session、工具、viewer 等核心实现
`cmd/`	93	30,807	Cobra CLI、命令参数、输出和动作入口
`pages/`	156	33,460	本地 viewer / 文档页面相关前端
`scripts/`	19	13,657	npm 安装器、GitHub Action 评论发布等脚本
`plugins/`	18	6,637	Claude Code、Codex、Cursor、OpenCode 等集成
`extensions/`	72	11,211	编辑器或宿主环境扩展层

Go 是主体，占 GitHub API 语言统计的 70.2%；JS 和 TS 分别约 12.8%、12.2%。这不是一个只靠 README 和脚本拼起来的壳，核心实现确实在 Go 里。

CI 安全边界

项目提供 composite GitHub Action，会安装 npm 包，再执行 ocr review --format json，之后用 actions/github-script 把 JSON 结果发布到 PR。action.yml 默认使用 ${{ github.token }}，并支持 sticky summary、incremental、checkpoint range、路由低严重级别评论等能力。

这里有两个使用建议。第一，给 Action 的 token 只配发布评论需要的权限，不要把高权限 PAT 塞进去。第二，OCR 自身读取 diff 和文件，不执行被审仓库里的任意代码；但 CI workflow 仍然要小心 pull_request_target、fork PR 和 secret 暴露问题。工具降低的是审查噪声，不是 CI 沙箱。

📖 README 核心内容摘要

README 把 OpenCodeReview 定义为 AI-powered code review CLI。官方说它源自阿里内部 AI code review assistant，过去两年服务过数万开发者并识别出数百万代码缺陷。这个说法属于项目方经验陈述，公开仓库里能核对的是当前源码、CLI、基准图和 release/package 状态。

它的使用入口很集中：

npm install -g @alibaba-group/open-code-review
ocr config provider
ocr config model
ocr review

配置层支持 OpenAI 与 Anthropic 兼容协议，也支持自定义 provider。ocr config set 可做非交互配置，例如 provider、model、custom provider URL 和协议。GitHub Action 里则把 llm_url、llm_auth_token、llm_model、llm_use_anthropic 等输入映射为环境变量。

README 里还有几类集成值得看：

集成	作用
Claude Code plugin	在 Claude Code 里添加 review slash commands
Codex skill	给 Codex 提供可调用的审查 skill
Cursor / OpenCode	把 review、delegate 等能力接进编辑器或 Agent 运行时
MCP Server	让外部工具进入审查 Agent 的工具面
Session Viewer	本地浏览和回放审查会话，处理 fixed / ignored 状态
CI/CD	GitHub Actions、GitLab CI、GitFlic CI、Gerrit

我会把它理解成“审查控制面”，不是单个模型提示词。它把 Agent 能力嵌在一个可恢复、可配置、能输出机器可读结果的工程壳里。

🚀 快速上手

下面这些命令已按 v1.12.1 的 CLI help 和 smoke test 核对过。需要真正调用模型的命令必须先配置 provider 和 model；preview / delegate 的部分能力不需要发起 LLM 请求。

安装与版本确认

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

当前 npm 最新版本是 v1.12.1，发布时间为 2026-09-14T11:27:32Z。仓库 main 分支的 package.json 仍是 0.0.0，这是发布占位，不要把它当成用户安装版本。

配置模型

交互式配置：

ocr config provider
ocr config model

非交互配置示例：

ocr config set provider anthropic
ocr config set model claude-opus-4-6
ocr config set providers.anthropic.api_key "$ANTHROPIC_API_KEY"

自定义 OpenAI 兼容网关：

ocr config set provider my-gateway
ocr config set custom_providers.my-gateway.url https://gateway.example.com/v1
ocr config set custom_providers.my-gateway.protocol openai

审查当前工作区改动

cd your-project
ocr review

先看将要审哪些文件，不调用 LLM：

ocr review --preview --format json

审查分支范围：

ocr review --from main --to feature-branch

审查单个提交：

ocr review --commit abc123

把结果写成 JSON，适合 CI 或 Agent 后续处理：

ocr review --format json --output result.json

全文件扫描

ocr scan --path internal/agent --preview --format json
ocr scan --path internal/agent

scan 适合没有明确 diff 的场景，比如接手一段遗留代码，想先看目录级问题。它不是 SAST，不应该拿它给安全合规盖章。

委托给宿主 Agent

ocr delegate preview --from main --to feature-branch --format json
ocr delegate rule internal/agent/agent.go internal/llm/client.go --format json

这种模式下，OpenCodeReview 输出文件选择和规则，真正的审查由宿主 Agent 完成。它适合已经有 Claude Code、Codex、Cursor 或 OpenCode 工作流的团队。

📊 增长速度与社区热度

OpenCodeReview 在 2026-09-15 的 GitHub Trending 快照中排第 2，页面记录 1,571 stars today。API 复核时 Stars 为 26,621，Forks 为 1,918，open_issues_count 为 157。由于 GitHub 的 open_issues_count 会把 issue 和 PR 合并，我又用 Search API 拆了一次：open issues 76，open PRs 81。

仓库创建于 2026-05-18。按快照日粗略折算，120 天积累 26,621 Stars，生命周期均值约 221.8 Stars/天。这个数字只能当长期基线，不能替代 GitHub Trending 当天的增长采样。

社区活跃度很高。最近 10 个 release 从 v1.11.2 到 v1.12.1，时间集中在 2026-09-01 到 2026-09-14；最新 10 个提交里，9 月 14 日和 9 月 15 日都有 CLI、viewer、template、规则路由、OpenCode 集成相关改动。贡献者集中度也明显：API 返回的前 10 名贡献者里，lizhengfeng101 有 271 次提交，第二名是 35 次。这说明维护核心比较集中，CI 使用时最好固定版本，不要盲目追 latest。

今日 GitHub Trending 完整榜单

Rank	Repository	Language	Stars	Today
1	JustVugg/colibri	C	32,694	2,173
2	alibaba/open-code-review	Go	26,621	1,571
3	multimodal-art-projection/YuE	Python	8,686	559
4	debpalash/VoiceStudio	Python	29,912	2,776
5	666ghj/MiroFish	Python	73,455	560
6	Panniantong/Agent-Reach	Python	81,672	651
7	asgeirtj/system_prompts_leaks	JavaScript	67,012	764
8	rlaope/oh-my-hermes	Python	2,266	77
9	localsend/localsend	Dart	91,521	251
10	dani-garcia/vaultwarden	Rust	67,600	115
11	TauricResearch/TradingAgents	Python	106,400	745
12	ruvnet/RuView	Rust	94,006	383
13	tech-leads-club/agent-skills	TypeScript	6,189	512
14	OpenBMB/VoxCPM	Python	37,496	216
15	huggingface/transformers	Python	166,119	536
16	ever-co/ever-gauzy	TypeScript	6,177	1,130
17	Crosstalk-Solutions/project-nomad	TypeScript	37,049	40
18	reconurge/flowsint	TypeScript	8,483	280
19	peetzweg/opendisplay	Swift	3,756	229
20	SnailSploit/Claude-Red	Python	5,021	579

🎯 适用场景

场景	是否适合	原因
本地提交前自查	适合	`ocr review --preview` 可先确认范围，再运行审查；适合减少低级缺陷进入 PR
PR/MR CI 审查	适合	JSON 输出、GitHub Action、sticky summary、增量评论和 checkpoint 设计比较完整
大型重构审查	谨慎适合	分组和预算能降低失控概率，但跨模块设计问题仍需要人审
接手陌生仓库	适合	`ocr scan --path` 可按目录做全文件扫描，不依赖 Git 历史
安全合规审计	不适合作为唯一手段	规则是提示约束，缺陷判断由 LLM 完成，不能替代 SAST、DAST、依赖扫描和人工审计
高 Recall 缺陷挖掘	不一定适合	官方基准显示它偏 Precision，低噪声优先，不是尽可能多报问题
已有 Claude Code / Codex 流程	适合	`delegate` 模式能复用 OCR 的文件选择和规则解析，让宿主 Agent 执行审查
严格离线环境	不适合默认配置	审查需要外部或自建 LLM endpoint；除非你已有内网模型服务

💡 总结

OpenCodeReview 的价值不在于“AI 帮你审代码”这个概念本身。这个概念已经不新了。它更像把代码审查拆成了两层：底层用 Go 代码保证输入、范围、规则、并发、预算和输出结构；上层让 LLM 做缺陷判断和解释。这个边界划得比较清楚。

它的短板也清楚。规则不是可执行静态分析；benchmark 是项目方发布的；高 Precision 往往意味着 Recall 不会太高；维护节奏很快，版本更新密集，CI 接入时需要固定版本并观察输出稳定性。

如果你的团队已经在 PR 里试过通用 Agent 审查，但被误报、漏看文件和行号漂移折腾过，OpenCodeReview 值得单独拉出来试。别把它当安全网的最后一道门。把它当一个低噪声 reviewer，放在测试、静态分析和人工 review 之前，价值会更稳定。