OpenCodeReview AI Code Review 实测：自动检查 Git Diff、Bug、安全漏洞和代码质量，真实项目能发现多少问题？

先对齐：OpenCodeReview 到底审什么

中文圈常把它和 OpenCode（opencode serve 那种编码 Agent）混成一个词。不是同一件事。OpenCodeReview 是阿里内部用了两年的 AI 代码审查助手开源出来的 CLI：读 Git 变更，输出结构化行级评论，内置多语言规则（空指针、线程安全、XSS、SQL 注入等），模型端点兼容 OpenAI 与 Anthropic。官方仓库见 alibaba/open-code-review，文档入口在 open-codereview.ai。

它解决的不是「再找一个会夸你好代码的机器人」。普通聊天模型只看见你贴进去的那一小段 diff，既不读调用方，也不知道隔壁文件有没有同一把锁。OpenCodeReview 的设计是确定性工程做分诊，Agent 做深度：先决定哪些文件该审、哪些该丢掉，再按文件类型注入规则清单，最后让 Agent 自己 file_read、搜仓库、对照其它变更文件。

站内已有一篇讲 OpenCode 自托管时 4GB / 8GB / 16GB 怎么选——那是编码 Agent 的内存账单。这篇只谈 ocr review：自动检查 Git Diff、Bug、安全漏洞和代码质量时，真实项目能发现多少问题。

官方口径是：内部服务过数万开发者、识别过数百万缺陷。那是阿里规模下的累计数字，不是你下一个 PR 的承诺。你要的如果是「合并前多一双眼睛」，它合适；你要的如果是「机器签字就能上生产」，README 和这篇实测都不会帮你签字。

它怎么读 Git Diff：三种审查模式

读者搜「自动检查 Git Diff」，通常只关心「我改了什么」。CLI 把这件事拆成三种互斥模式，混用会直接报错。完整旗标见 CLI Reference。

范围模式算 merge-base，这一点比「把两个分支硬 diff」更接近人审 PR 的方式：main 上后来合进来的无关提交不会灌进审查。GitHub Action 官方实现也是先算 merge-base，再跑 ocr review --from MERGE_BASE --to HEAD_SHA --format json，把行级评论贴回 PR。

还有第四条路：ocr scan。没有有意义的 Git 历史、或你要审计一整棵不熟悉的目录时，它审完整文件而不是 diff。代价是 token 和噪声都会上去。日常合并审查，先用 diff；接手遗产仓库，再考虑 scan。

审查前一定要先跑 ocr review --preview。它只走过滤管道、不花模型钱，会告诉你每个文件 will_review 还是因为扩展名、删除、测试路径被丢掉。我们实测时，一个带图片和 lockfile 的 PR 会先丢掉一半「看起来改了很多」的文件——那些本来就不该送给 LLM。

五分钟跑起来：安装、配模型、preview

推荐安装是 npm 全局包。也可以用官方 install.sh 或 GitHub Release 静态二进制。Git 要 ≥ 2.41，因为 diff、搜代码、仓库操作都走 Git。配好模型之前，ocr review 不会凭空工作（除非走 Delegation Mode，把审查交给你已经在用的编码 Agent）。

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider          # 选内置或自定义端点，填 Key
ocr config model
ocr llm test                 # 不通就别往下烧 token

cd /path/to/your-repo
ocr review --preview         # 不花模型钱，看哪些文件会进审查
ocr review --from main --to HEAD --format json --audience agent

配置落在 ~/.opencodereview/config.json。CI 里用 ocr config set 写 provider / model / api_key，或直接复用已有的 ANTHROPIC_* / OCR_LLM_* 环境变量。评论语言用 ocr config set language 中文，不设则默认英文。项目规则可以提交 .opencodereview/rule.json；全局规则在家目录，别把 Key 写进仓库。

npm 安装默认会后台自更新（大约 18 分钟冷却）。CI 镜像里请 export OCR_NO_UPDATE=1，并钉死版本号，避免周一和周五审出来的规则不是同一套。会话记录在 ~/.opencodereview/sessions/，ocr viewer 默认开在 localhost:5483，用来回放某一次审查，而不是对外提供服务。

本机内存怎么估，不要照搬那篇 OpenCode 自托管文。OpenCodeReview 的重活在 LLM API 和并发 Git 子进程，CLI 本身不常驻一套 LSP。--concurrency 默认 8，--timeout 默认每文件 10（单位见当期 CLI）。笔记本合盖、key 跟日常聊天抢同一把额度时，审查会半路断；需要常开、可复现的 runner，比在出差电脑上赌一次 ocr review 更诚实。

真实项目实测：三个变更包发现了什么

我们用同一套配置（OpenAI 兼容协议、中等体量对话模型、系统规则 + 项目规则合并）对照了三类真实会进 PR 的变更，不是玩具仓库里的十行示例。每包先 --preview，再 ocr review --from --to --format json，人工把评论标成：必须改、应该改、风格/建议、误报。数字是一次快照，换模型或换规则会漂，但类别比例比「总共几条」更有用。

必须改（7 条）里，安全 3、缺陷 4。安全侧是：字符串拼接查询、未转义输出进 HTML、以及一处把内部错误文本直接回给客户端。缺陷侧是：空值当对象用、并发写 map 没锁、错误没有 %w 包一层导致上层丢原因。这三类正好落在官方宣传的规则集里——NPE、线程安全、XSS、SQL 注入——不是模型「灵光一现」写出来的散文。

应该改（6 条）多数是：超时没设、重试会把非幂等请求打两遍、日志里带了邮箱或请求体。人审也该提，但周五下午容易被「先合再说」压掉。AI 的价值在这里：它不累，也不看你脸色。

风格/建议（10 条）是最大的桶。命名、提前返回、某段可以抽函数。有用，但会稀释信号。不治理的话，团队会在第三周开始把整段审查折叠掉——这和业界对 CodeRabbit 一类工具的抱怨同一病理：召回高、信噪比掉。

误报（4 条）很典型：把测试夹具里的拼接 SQL 当成生产注入；把已经参数化的查询再骂一遍；把 Go 1.22 之后已修复的循环变量问题又提一次。四条里有三条，用 ocr review --preview 加一条排除测试目录的项目规则就能消掉。别先怪模型，先看规则有没有把测试文件送进去。

和官方文档里的示例规模对得上：一次范围审查常见是「9 个文件、十几条评论、一两分钟、两万 token 量级」。我们这三包合计大约这个量级的三倍，因为是三个独立范围，不是一个巨型 PR。单文件 diff 超过模型窗口约 80% 会被直接丢掉——超大生成文件、锁文件、打包产物，preview 阶段就该消失，不该出现在账单上。

Bug、安全、质量：哪些抓得住、哪些抓不住

把 27 条按题目里的四个词切开，比只报「发现了多少问题」更接近你怎么用它。

Agent 能读完整文件，所以比「只看绿色行」的审查强一档。官方示例里那条「map 写入没加锁」就是典型：diff 只改了一行赋值，真正的问题在文件上头已经存在的共享状态。纯 diff 机器人经常放过；带 file_read 的审查会把上下文拉进来。这也是它和「只看 PR 补丁的 Copilot Review」在宣传上的差别——后者快、噪声低，跨文件是弱项。

它抓不住的，我们刻意放进变更包里对照过：错误的折扣计算公式、把人民币当美元的字段、以及「这个接口不该在未审核状态可调」。这三处零评论。模型没有你们的领域词典，--background 把 PR 说明和验收标准喂进去会好一点，但替代不了人审需求。

安全类评论要当线索，不当判决书。它指出「这里在拼 SQL」，你还是要自己确认驱动、权限和数据分级。文章不会示范怎么利用这些漏洞，只记录审查器有没有把风险行标出来。需要把 Agent 改文件的边界也收紧时，对照站内 AI Agent 如何安全修改文件——审查是只读的，编码 Agent 才写盘。

接到 CI：GitHub Actions、规则与误报

本地跑通之后，团队要的是 PR 上自动出现行级评论。官方 composite Action 会：检出可信的 base（不是把 fork 的工作树直接铺开）、拉 head 的 git 对象、算 merge-base、跑 ocr review --format json、再通过 Pull Request Review API 贴行评和一条 sticky 摘要。触发词可以是 PR 打开/同步，也可以是评论里的 /open-code-review。

权限给最小集：contents: read，真要写评论再开 pull-requests: write。模型 Key 进 Secrets，模型名进 Variables。Fork 默认拿不到仓库 Secrets——这是保护，不是故障。不要为了「让外部贡献也能自动审」就把不信任的代码检出来和 pull_request_target 拼在一起；那是泄密组合，不是集成技巧。GitHub 自己的加固说明见 Security hardening for GitHub Actions。

规则是四层：自定义 --rule、项目 .opencodereview/rule.json、全局家目录、内置系统规则。用 ocr rules check path/to/File.java 看某一文件到底吃了哪一层。项目规则设 merge_system_rule: true，避免你写了两条「关注日志」就把 Java 空指针清单整个盖掉。排除测试、生成代码、vendor，比事后抱怨误报便宜。

macOS 上要给 iOS / Xcode 变更做同一套审查，runner 本身比 ocr 更难养。自托管怎么搭、怎么验收，走 GitHub Actions macOS 自托管 Runner；机器不睡、密钥不跟笔记本抢额度，审查才稳定。