比人工评审靠谱百倍，阿里开源AI代码审查工具完整指南

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

代码审查这件事，比相亲还让人社死

你知道程序员最怕什么吗？

不是产品经理凌晨两点改需求，也不是服务器周五晚上宕机。

是提交完代码，在群里@了同事，结果对方甩过来二十条评论，第一条就是：“你这段代码，我奶奶用Excel都能写得比它优雅。”

更可怕的是，你打开一看，发现"奶奶"说得对。

这时候你多希望有个工具能替你挨这顿骂，最好是那种骂完之后还能告诉你怎么改的。阿里最近开源的 Open Code Review，简称 OCR，就是这么一个"电子替罪羊"。

注意啊，这个 OCR 不是你把图片扔进去识别文字的那个 OCR，虽然它们缩写一样，但功能完全不同。一个是"这图里有啥字"，一个是"你这代码里有啥病"。

安装它，比安装前任的良心还简单

安装这个工具只需要一行命令：

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

装完之后，你的命令行里就多了一个叫 ocr 的指令。以后你在项目里敲 ocr review，它就像个刚入职的实习生一样，乖乖地帮你把代码从头到尾看一遍。

只不过这个实习生不会问你"中午吃什么"，也不会在茶水间说你坏话。它只会冷冷地指出：“第 42 行，你这个变量命名，人类看了会沉默，机器看了会流泪。”

而且人家是真干活。你审当前没提交的改动，可以；你审两个分支之间的差异，也可以；你甚至可以让它只审某一个提交，就像点外卖时备注"只要辣椒不要香菜"一样精准。

规则配置：给 AI 写一本"家规"

最妙的是，你可以给它定规矩。

在项目里建一个 .opencodereview/rule.json，就像给新来的家教写一份《学生注意事项》。比如：

{
  "rules": [
    {
      "path": "src/pay/**/*.go",
      "rule": "重点检查金额计算、错误处理和并发安全"
    },
    {
      "path": "**/*mapper*.xml",
      "rule": "检查 SQL 注入风险、参数错误和缺少闭合标签"
    }
  ],
  "exclude": ["**/generated/**", "vendor/**"]
}

这段配置的意思翻译成人话就是：凡是支付相关的 Go 文件，你给我盯着点，别让人把一分钱算成一块；凡是 XML 文件，你给我看看有没有 SQL 注入，别让用户输入个分号就把数据库给删了。

至于 generated 和 vendor 目录？那是自动生成的代码和第三方库，审它们就像给外卖包装纸挑错别字，纯属浪费时间。

规则优先级也很人性化：命令行指定的最牛逼，项目里的次之，用户全局配置再次，最后才是内置规则。就像你在家听老婆的，在公司听老板的，在老婆公司听老婆的——优先级清晰，不会打架。

它到底怎么干活的？

好，现在进入技术环节，但我会尽量说得像人话。

整个流程可以分成七步，我给它起了个名字叫"七步成诗"——只不过诗是写给你的，骂也是写给你的。

第一步：npm 只是个皮条客

你以为 npm 包装里全是 JavaScript？太天真了。npm 只是个中介，真正的审查逻辑是用 Go 写的。就像某些 APP，前端是 React，后端是 Java，但用户只关心能不能用。

npm 负责把命令传给 Go 程序，Go 程序负责真的去干活。这种"表里不一"的设计，在程序员圈子里叫"务实"。

第二步：整理配置，像出门前列清单

你出门旅游前是不是会列个清单？衣服、充电器、身份证、脑子。OCR 在真正干活之前也会列清单：审哪些文件、用什么规则、输出什么格式、并发多少、要不要带需求背景。

这时候它还没看代码，就像你还没出门，但已经把行李箱摊在地上了。

第三步：读 diff，像批改作业

接下来它去读 Git diff。不管你是工作区未提交的改动，还是两个分支的差异，还是某个提交的历史遗留问题，它都能读。

读完之后，它会做一件很关键的事：筛选。二进制文件不要，生成代码不要，你明确排除的不要，纯删除的文件也不要。就像老师批改作业，空白页直接跳过，不浪费红墨水。

最后剩下的，就是真正需要审查的"幸运儿"。

第四步：给每个文件发"准考证"

每个进入审查队列的文件，都会拿到一份完整的运行上下文。这份上下文包括：文件路径、diff 内容、其他变更文件列表、需求背景、可用工具、审查规则。

你可以把它理解为高考的准考证——没有这张证，AI 连考场都进不去。有了这张证，它才知道自己该审什么、按什么标准审。

第五步：并发审查，像同时开多个窗口

如果一次改动涉及十几个文件，挨个审太慢了。OCR 支持并发审查，就像你同时开了十几个浏览器窗口摸鱼——哦不，工作。

不过它有个底线：单个文件的 diff 不能超过阈值，否则直接跳过。这就像作文纸只有两页，你写了二十页，老师直接拒收，让你回去重写。

第六步：单文件审查，AI 的独角戏

每个文件都会启动一个 Review Agent。这个 Agent 会读取 diff，必要时调用工具补全上下文，发现问题就通过 code_comment 提交结构化评论。

如果它发现需要更多上下文，它会主动调用工具去查。这就像你写代码时遇到不懂的 API，会去查文档一样。唯一的区别是，AI 查文档不会打开浏览器然后刷半小时短视频。

第七步：汇总输出，交卷

所有文件审完之后，结果会被汇总。你可以让它输出文本格式，适合人类阅读；也可以输出 JSON 格式，适合 CI 或其他程序消费。

JSON 输出意味着你可以把它接入流水线，代码提交后自动审查，发现问题自动拦截。以后老板问你为什么提交被拒了，你可以理直气壮地说：“AI 说的，不关我事。”

它到底解决了什么问题？

很多人以为 AI 代码审查就是"让模型看一眼代码"。这就像你以为医生看病就是"让医生看你一眼"——太草率了。

OCR 真正解决的是工程化问题：审查范围明确、规则可配置、输出格式固定、不同 Agent 接入时表现一致。它不是给你找个会写代码的 ChatGPT，而是给你搭了一套可复用、可集成的审查流水线。

换句话说，以前你的代码审查靠运气——今天同事心情好，夸你两句；明天同事失恋了，把你骂得狗血淋头。现在好了，AI 没有感情，它只会冷静地、一致地、无情地指出你的问题。

虽然被骂的感觉差不多，但至少现在你可以说是"算法的问题"，而不是"人的问题"。

总结一下

阿里开源的 Open Code Review 是一套工程化的 AI 代码审查方案。它通过 npm 分发、Go 执行，支持灵活的规则配置和并发审查，输出结构化结果，可接入 CI 流水线。

如果你厌倦了人工 code review 的社交压力，不妨试试这个工具。毕竟，被 AI 骂，总比被同事骂要体面一点。

最后友情提示：OCR 虽然好用，但别指望它能替代你的技术积累。它只能告诉你"哪里错了"，但"为什么错"和"怎么改更好"，最终还是要靠你自己的脑子。当然，如果你连 AI 的修改建议都看不懂，那可能问题就不在代码上了。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01