AI 代码评审工具怎么选：先想清楚你要它管什么
数据截至 2026-07，价格与限额以各官网为准。
选 AI 代码评审工具，别一上来就比”哪个模型更聪明”——这个维度目前没有任何一家能拿出可以交叉验证的公开基准，比了也是各说各话。真正该先定下来的是三件事：评审在哪个环节触发、产出的意见给谁看、你希望它优先管哪一类问题。这三条定清楚，工具清单会自己收窄到两三个候选，剩下的差异才值得逐条比。
一个常见误解是把 AI 评审当成”多一双眼睛”，装上就是净收益。实际落地时更常见的情况是相反的：意见太多、位置对不上、复述一遍代码在干什么却没指出风险，几轮之后团队开始习惯性折叠它的评论，工具就废了。评审工具的价值不取决于它能说多少，而取决于它说的每一条你都愿意看。
一、先回答三个定位问题
这三个问题的答案决定了工具形态，顺序不要颠倒。
评审在哪个环节触发？ 大致有三个位置：提交前在本地跑（改完 diff 自己先看一遍）、推到 PR 时在 CI 里跑（团队所有人可见）、以及对存量代码做整体审计（不看 diff，直接扫文件）。这三个位置对工具的要求完全不同——本地跑的最看重速度和不打断心流，PR 上跑的最看重噪声率，存量审计最看重覆盖面。想同时要三个，通常意味着三种模式都得单独配。
意见给谁看？ 只给作者自己看，可以宽松一点，宁多勿漏；发到 PR 上给全组看，标准要严得多，因为每一条误报都在消耗其他人的注意力，而注意力一旦透支就收不回来。
优先管哪类问题？ 空指针、并发、注入类漏洞这种”错了就是错了”的确定性问题，和代码风格、命名、架构合理性这种见仁见智的问题，应该分开托管。前者适合交给带规则集的自动评审，后者继续留给人。把两类混在一起输出，是评审噪声的主要来源。
二、机制差异比”谁更聪明”更值得看
既然效果没法横向验证，那就看机制——机制是公开可查的，也直接决定了你会遇到什么问题。
以阿里开源的 open-code-review 为例，它是一个 AI 代码评审的命令行工具，做法是分析 git diff，把变更文件交给 LLM agent，产出带行级定位的结构化评审意见。项目仓库描述的架构特点是确定性流水线加 LLM Agent 两段结合：文件筛选、规则匹配这些能写死的环节走确定性流程，动态判断的部分才交给 agent。
按仓库的自述，这样拆的目的是压住通用 agent 常见的两个毛病：一是”位置漂移”（意见本身有道理，但挂错了行），二是”覆盖不全”（该看的文件没看到）。它另外有一个独立的评论定位模块专门处理挂载位置，内置规则集则称经过微调，覆盖 NPE、线程安全、XSS、SQL 注入这几类。
这些都是仓库自述的设计目标，不是第三方实测结论。但它至少告诉你一件可判断的事：如果你被”评论挂错行”折磨过，那定位模块是不是独立的，就是一条实打实的选型依据；反过来如果你的痛点是”提的都是废话”，那该看的是规则集覆盖范围，不是定位精度。把自己的痛点和机制对上，比看谁的宣传语更响有用。
许可证方面它是 Apache-2.0（Copyright 2026 Alibaba）。截至 2026-07-28，GitHub 仓库页面显示约 15,000 star、约 1,000 fork，同日 GitHub Trending 榜上新增 979 star。star 数只说明关注度，跟适不适合你的仓库没有因果关系，但对开源工具来说，它间接影响你遇到问题时能不能搜到别人踩过的坑——这一点在选型时值得算进去，具体判断方法可以参考开源项目怎么选？看 star 之外还要看什么。
三、本地先跑一遍，再谈接 CI
强烈建议先在本地手动跑几轮，不要一上来就往 CI 里接。原因很简单：CI 里跑出来的噪声是全组一起承担的，而本地跑坏了只有你自己知道。
open-code-review 仓库给出的安装命令是：
npm install -g @alibaba-group/open-code-review
首次使用走交互式配置，仓库描述的流程是引导选择供应商、填 API key，并自动做连通性测试：
ocr config provider # 选 LLM 供应商
ocr config model # 选模型
cd your-project
ocr review # 评审已暂存/未暂存的改动
除了默认的 diff 评审，它还提供几种模式，正好对应上面说的三个触发位置：
ocr review --from main --to feature-branch # 分支对比
ocr scan --path internal/agent # 整文件审计
ocr delegate preview # 由 AI agent 执行评审
实际试跑时，建议挑三类 diff 分别过一遍：一个纯重构（改了很多行但语义没变）、一个真有并发或空指针隐患的改动、一个只改了配置文件的改动。第一类看它会不会因为 diff 大就疯狂输出，第二类看它能不能命中，第三类看它会不会对着 YAML 大发议论。三轮跑完，这个工具适不适合你的仓库基本就有数了。
模型供应商这块，仓库自述兼容 OpenAI 与 Anthropic 两种格式。具体支持哪些模型名、哪个版本，以项目官方文档当前版本为准，不建议照抄任何教程里的模型名。
四、接 CI 的时候，先想清楚触发条件
open-code-review 仓库列出的集成对象是 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 四个。如果你的代码平台不在其中，那这条路先放下，别指望”应该也能接”。
接进去之后有几个开关比工具本身更影响体验：
- 触发时机：每次 push 都跑，还是只在 PR 打开和标记 ready 时跑？前者在活跃分支上会重复刷屏。
- 评论方式：逐行 inline 评论，还是汇总成一条总结？团队刚开始用的时候，汇总成一条更容易接受，等信任建立了再放开逐行。
- 是否阻断合并：初期一律不阻断。让一个还没被验证过的评审器拥有否决权，是最快把它变成公敌的方式。
- 跳过规则：生成代码、依赖锁文件、大批量格式化提交，都应该在文件筛选阶段排除掉，别让它们烧 token 也烧耐心。
五、厂商自述的数字，该怎么读
open-code-review 的仓库里有几个数字容易被直接引用：仓库称该工具在阿里内部经”数万开发者”使用、发现过”数百万个代码缺陷”，还称在更高精度的同时 token 消耗约为 Claude Code 的 1/9。
这几条都是项目仓库自己的口径，没有第三方复现，读的时候要保持它原本的性质：
- “数万开发者""数百万缺陷”说明的是这套东西在一个大规模内部环境里真实跑过，不是纯实验室产物。这个信息有价值，但它跟你的仓库能得到什么结果没有推导关系。
- “1/9 token”是仓库自己设定的基准场景下的对比结果。基准怎么构造、评审任务是否等价、上下文注入策略是否相同，外部都无从验证。它不能用来得出”比某某工具强”的结论——这不是针对哪一家，而是目前所有 AI 评审工具的共同处境：没有公开、可复现、各家都认的基准。
- 真要比 token，唯一可信的办法是自己比：同一批 PR、同一个模型、同样的提交口径，各跑一轮，记账对比。这个成本不低，但结论是你自己的。
同理，市面上其他 AI 评审工具（比如 GitHub 的 Copilot code review、Cursor 的 Bugbot 等）的效果宣称也是一样的性质。可以比的是公开机制：跑在哪、怎么定位、覆盖哪些平台、怎么计费；不能比的是”谁找得更准”。
六、成本别只看订阅价
评审类功能的计费往往不在主套餐的显眼位置，容易漏算。
以 GitHub Copilot 为例，按官方计费说明的口径：对年付用户，2026-06-01 起模型倍率有过上调，Copilot code review 的模型倍率是 13——也就是每触发一次 PR 或 IDE 里的代码评审，扣掉 13 个 premium request。另外一个更容易漏的：code review 自 2026-06-01 起还会同时消耗 GitHub Actions 分钟数。两笔账分别记在不同的额度池里，只盯着其中一个看，月底容易对不上。详细拆解见Copilot code review 到底怎么计费。
自建路线（比如 open-code-review 这种自带 key 的 CLI）没有订阅费，但成本转成了 token 账单和 CI 机时。哪种更划算取决于你的 PR 频次和 diff 体积，没有普适答案，唯一靠谱的做法是先跑一个月小范围试点，把真实账单拉出来看。
七、接海外模型之前，先确认准入前提
如果你打算给评审工具接的是海外厂商的模型，这一步要在写配置之前想清楚，不然会走到一半发现路不通。
Anthropic 官方的受支持国家/地区列表不含中国大陆（anthropic.com/supported-countries）。OpenAI、Google 这几家官方同样没有面向中国大陆开放，注册、控制台与 API 端点都在境外，具体以各自官网的地区政策页为准。这里不提供也不背书任何第三方中转渠道——市面上确实存在这类服务，但其合规性与稳定性风险由使用者自行承担，把生产环境的代码评审链路押在这上面并不是一个稳妥的选择。
如果团队在大陆，更现实的做法是接国内厂商的兼容端点，或者走公司已有的合规接入通道。工具本身兼容 OpenAI 格式，换端点通常不涉及改代码。
八、诚实说局限
有几件事 AI 代码评审目前做不好，提前知道能省掉不少失望：
- 跨文件、跨模块的设计问题基本看不出来。它看的是 diff，一个改动为什么不该这么设计，往往要放在整个系统的上下文里才成立。
- 业务语义正确性它判断不了。代码没有语法和并发问题，但算错了折扣金额，这类问题只能靠测试和熟悉业务的人。
- 误报无法归零。规则命中的部分相对可靠，靠模型推断的部分一定会有误判，接受这一点，然后用”不阻断合并”来限制误判的破坏力。
- 不能替代测试。评审意见是概率性的，测试是确定性的，两者不互相取代。这个话题可以延伸看AI 写的代码能直接上生产吗。
小结
选 AI 代码评审工具，先定”在哪触发、给谁看、管哪类问题”这三条，再去比机制而不是比效果。open-code-review 是一个可以本地先跑起来的开源选项，Apache-2.0 协议，仓库自述采用确定性流水线加 LLM Agent 的混合架构、有独立的评论定位模块、内置规则集覆盖 NPE 与注入类问题，集成对象是 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 四个平台。仓库里”1/9 token""数万开发者""数百万缺陷”这几个数字是厂商自述口径，可以作为背景参考，但不适合当作选型结论。真正的决策依据只有一个：拿你自己仓库里的三五个真实 PR 跑一轮，看它提的意见你愿不愿意逐条读完。