把 AI 代码评审接进 CI：四个平台的路子

2026-07-28

数据截至 2026-07，各项目能力以官方文档当前版本为准。

**把 AI 代码评审接进 CI，技术上的难点不在”怎么调模型”，而在三件更琐碎的事：评审范围怎么框、密钥怎么进流水线、评审意见怎么落到具体行上而不是刷一大段废话。**先在本地把命令跑顺，再往流水线里搬，顺序反了会浪费很多次无效的 CI 运行。

常见的误解是：既然是 AI 评审，那就把整个仓库丢给模型让它挑毛病最省事。实际上大多数团队接完第一版之后遇到的问题恰恰相反——意见太多、位置不准、每次 PR 都刷屏，最后没人看。评审工具的价值不在”能说多少”，而在”说的每一条能不能定位到行、值不值得改”。

这篇以阿里开源的 open-code-review（命令行入口是 ocr）为主线，因为它把 CI 集成这件事写得比较明确，也刚好覆盖了四个不同类型的平台。

先弄清楚这类工具在做什么

它的架构有个值得留意的地方：确定性流水线 + LLM Agent 动态决策两段结合。前半段（文件筛选、规则匹配）是写死的逻辑，后半段才交给模型判断。项目仓库对这个设计的说法是，可以减少通用 agent 常见的”位置漂移”和”覆盖不全”问题，另外它有独立的评论定位模块。这套机制值不值得，看你自己的仓库跑一遍就知道——机制是公开可查的，效果各家都没有能交叉验证的公开基准，这点后面单独说。

内置规则集方面，项目仓库称经过微调，覆盖 NPE、线程安全、XSS、SQL 注入这四类问题。规模上，仓库自述在阿里内部经”数万开发者”使用、发现过”数百万个代码缺陷”——这是项目方自己的口径，没有第三方复核，当作背景信息看就好，别当成选型依据。

从公开可见的关注度看，GitHub 页面显示 star 约 15,000、fork 约 1,000（截至 2026-07-28，当日在 GitHub Trending 上涨约 979）。star 数只能说明它最近有热度，跟适不适合你的代码库是两回事。

第一步：本地先跑通，别直接往 CI 里塞

装法是全局安装：

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

然后走一遍交互式配置和最小评审：

ocr config provider          # 选 LLM 供应商
ocr config model             # 选模型
cd your-project
ocr review                   # 评审已暂存/未暂存的改动

交互式配置会引导你选供应商、填 API key，并自动做一次连通性测试。这一步在本地做的价值很高：CI 环境里报”连不上”和报”key 不对”，日志看起来经常差不多，本地先确认链路通了，后面在 CI 里排查能省掉一大截来回。

除了默认的改动评审，还有三种模式，各自对应不同用法：

ocr review --from main --to feature-branch    # 分支对比
ocr scan --path internal/agent                # 整文件审计
ocr delegate preview                          # 由 AI agent 执行评审

接 CI 主要用的是 --from / --to 这种分支对比模式，因为流水线里没有”未暂存的改动”这个概念，只有两个明确的 ref。ocr scan 更适合手动做局部审计，比如接手一块陌生代码时先扫一遍某个目录，不适合每次 PR 都跑——范围太大，噪音也大。

第二步：确认它支持哪些平台

项目仓库列出的 CI / 代码平台集成一共四个：GitHub Actions、GitLab CI、GitFlic CI、Gerrit。这四个不是同一类东西，接法上的差别也主要来自这里：

GitHub Actions 和 GitLab CI 是流水线，评审跑在 job 里，结果回写成 PR/MR 评论。
GitFlic CI 同样是流水线形态，但它是另一套代码托管平台的 CI，国内团队接触得少，如果你们不用这套平台可以直接跳过。
Gerrit 是独立的代码评审系统，本身就是围绕 change / patchset 转的，评审意见有天然的落点，跟前三者的模型不太一样。

在这四个之外的平台（比如自建的 Jenkins、各家云厂商的流水线），仓库没有列出现成集成，理论上你仍然可以在任何能跑 Node 的环境里执行 ocr 命令，但”把结果回写成评论”这一段就得自己接对应平台的 API，工作量不在工具这边。

第三步：GitHub Actions 的路子

思路最直接：在 pull_request 触发的 workflow 里装好 Node 和 ocr，然后对比目标分支和当前分支。

# 结构示意，各 action 的具体版本号以官方文档当前版本为准
on: pull_request

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<当前版本>
        with:
          fetch-depth: 0          # 关键：默认浅克隆拿不到目标分支
      - uses: actions/setup-node@<当前版本>
      - run: npm install -g @alibaba-group/open-code-review
      - run: ocr review --from origin/${{ github.base_ref }} --to HEAD

这里有两个容易踩的点。

第一是 fetch-depth: 0。GitHub Actions 默认只拉一层提交，--from origin/main 这种引用在浅克隆里根本不存在，报错信息往往是 git 层面的”unknown revision”，跟 AI 评审没关系，但很容易让人误以为是工具坏了。

第二是非交互配置。本地那套 ocr config provider 是交互式的，CI 里不能停下来等你敲回车，必须换成环境变量或配置文件的方式提供供应商、模型和密钥。具体的环境变量名和配置文件字段，以项目仓库当前文档为准，这篇不替它编——名字写错了排查起来特别费劲，值得去仓库里对一眼原文。

密钥本身走 GitHub Secrets 注入，不要写进 workflow 文件。另外注意，来自 fork 的 PR 默认拿不到仓库 secrets，这是 GitHub 的安全设计，不是配置错了；开源项目要在外部贡献上跑 AI 评审，得单独设计触发方式。密钥管理的通用做法可以参考API 密钥怎么安全管理。

第四步：GitLab CI 的路子

GitLab CI 的整体结构类似，差别在几个具体机制上：

分支引用用 $CI_MERGE_REQUEST_TARGET_BRANCH_NAME 这类预定义变量，不是 GitHub 那套 github.base_ref。
克隆深度由 GIT_DEPTH 变量控制，同样要放开，否则拿不到目标分支的历史。
密钥放 CI/CD Variables，记得勾上 masked，避免日志里被打出来；如果是 protected 变量，注意只有 protected 分支/tag 的 job 能读到，特性分支上跑会拿到空值。
job 建议只在 merge request 事件上跑，别每次 push 都触发一遍，否则一个 MR 迭代十次就评审十次，既吵又费 token。

自建 GitLab 还要多确认一件事：runner 能不能出网访问你选的模型端点。很多企业内网的 runner 是隔离的，本地能跑通、CI 跑不通，大多卡在这里。

第五步：GitFlic CI 与 Gerrit

GitFlic CI 的形态跟前两者接近，都是 YAML 定义的流水线，差异主要在变量名和 MR 评论 API 上。这个平台在国内团队里用得不多，如果你们不在用，这条路子知道有就行。

Gerrit 值得单独说，因为它的心智模型不一样。Gerrit 里评审的单位是 change 和 patchset，每次提交本来就要走一遍人工评审，评论天然挂在具体行上。把 AI 评审接进来，通常是在 patchset 上传后触发一次自动评审，把意见作为一条机器人评论写回去。

用 Gerrit 的团队往往本来就有比较严格的评审文化，这时候 AI 评审的定位要想清楚：它是给人工评审做前置过滤的，帮忙先挑掉低级问题，让人把注意力留给设计和边界条件；不是用来替代人工 +2 的。如果团队默认”机器人没提意见就等于没问题”，那接进来反而是负作用。

密钥、供应商和大陆准入

模型供应商这块，项目仓库自述兼容 OpenAI 与 Anthropic 格式。仓库没有列出具体推荐的模型名，所以这篇也不列——模型清单变动很快，以官方文档当前版本为准。

需要提前面对的是准入问题：这几家厂商官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外。其中 Anthropic 官方受支持地区列表明确不含中国大陆（anthropic.com/supported-countries）。市面上确实存在第三方中转、聚合类服务，但其合规性、计费透明度和数据处理方式需要使用者自己核实并承担风险，这篇不提供也不背书任何具体渠道。

对代码评审这个场景，还有一层比接入难度更重要的考虑：你送出去的是源码 diff。哪怕接的是能连通的端点，也要先确认公司对源码外发的规定、对方的数据保留策略是什么。这件事应该在选型会上讨论，而不是等某个工程师自己在 CI 里配好 key 之后才被发现。相关的取舍可以参考AI 工具的数据安全风险。

关于”厂商自述数字”的一点提醒

项目仓库里有一条比较醒目的说法：在更高精度的同时，token 消耗约为 Claude Code 的 1/9。这是项目方自己的基准口径，没有第三方复现，看到的时候心里要打个折——不是说它一定不实，而是各家 AI 评审工具目前都没有可交叉验证的公开基准，这类数字只能作为”厂商声称”来读。

同理，前面提到的”数万开发者""数百万缺陷”也是仓库自述的规模数据。这三条都不构成”比别家强”的结论。

如果你要在几个工具之间选，比较靠谱的做法是：只比公开可查的机制差异（是不是有确定性预筛、评论怎么定位、支持哪些平台、协议是什么、能不能自托管模型），效果部分自己拿仓库里最近几个真实 PR 跑一遍对比。GitHub Copilot 的代码评审功能有自己的计费口径，成本上的考量可以看Copilot 代码评审的成本怎么算，Cursor 侧的对应能力可以看 Cursor Bugbot 怎么用。

接进去之后：噪音和成本怎么控

第一版接通之后，大多数团队会经历一段”意见太多”的阶段。几个可操作的收敛办法：

缩小评审范围：把生成代码、锁文件、迁移脚本、第三方 vendor 目录排除掉。这些文件 diff 大、信息量低，占掉大量 token 还提不出有用意见。
只在 MR/PR 事件跑，不在每次 push 跑：这是省成本最直接的一刀。
大 PR 单独处理：几千行的重构 PR，AI 评审的定位准确度和可读性都会下降，与其硬跑不如拆分。
意见分级对待：把 NPE、注入类这种规则明确的问题当作要处理的，把风格类建议当作参考。全部同等严肃对待，团队很快就会开始无视整个机器人。
定期回看命中率：跑一段时间后翻一下，机器人提的意见里最后真正被改的占多少。这个比例低到某个程度，说明配置该调了，而不是”AI 不行”。

诚实说局限

有几件事得说清楚。

一是它看不到运行时。AI 评审读的是 diff，业务语义、上下游依赖、线上数据分布这些它都不知道，所以它擅长的是模式化的缺陷，不擅长”这个改动会不会打穿下游服务”这类判断。

二是不能替代测试和人工评审。评审工具挑出的问题和测试覆盖的问题是两个集合，交集没有想象中大。把 CI 里的测试环节换成 AI 评审，是明确的倒退。

三是效果高度依赖你选的模型和仓库特征。同一个工具，接不同模型、跑不同语言的仓库，产出质量差别很大。别人跑得好不代表你跑得好，也不代表你跑不好，只能自己试。

四是这类项目迭代快。命令参数、配置字段、支持的平台清单都可能变，这篇写的是 2026-07 的形态，真正动手时以项目仓库当前文档为准。

小结

先在本地用 ocr review 跑通、确认链路和意见质量，再往 CI 里搬，这个顺序能省掉大量无效的流水线运行。四个受支持的平台里，GitHub Actions 和 GitLab CI 的接法结构类似，卡点集中在克隆深度、分支变量名和非交互配置这三处；Gerrit 更适合作为人工评审的前置过滤。密钥一律走平台的 secret 机制，源码外发的合规问题要在选型阶段就讨论掉。项目仓库自述的性能与规模数字（包括 token 消耗对比）只能当厂商口径读，选型时比机制、比自家仓库的实测，不比宣传数字。