AI 代码评审的 token 成本：全量审和增量审差很多
数据截至 2026-07，各项目能力以官方文档当前版本为准。
AI 代码评审的账单，绝大部分是被”你往模型里塞了多少代码”决定的，跟你选哪个模型、跟它回你几条意见关系都不大。同一个仓库、同一套配置，只审这次改动的几十行，和把一个目录整个扫一遍，输入 token 差出一到两个数量级——这不是省钱技巧的差别，是两种完全不同的用法，值得在接进流水线之前就想清楚各自用在什么时候。
一个挺常见的误解是：评审贵是因为”AI 要想很久”。实际情况相反。评审这类任务的输出通常很短，几条问题描述加行号定位，撑死几百上千 token；而输入侧要把变更文件（很多工具还会连带相关上下文）整个送进去，动辄几万 token。真正在烧钱的是读进去的那一侧。想清楚这一点，优化方向就从”换个便宜模型”变成了”控制送进去的范围”，后者的效果通常大得多。
下面用阿里开源的 open-code-review（命令行工具名 ocr）当例子。它是一个分析 git diff、把变更送给 LLM agent、产出带行级定位的结构化评审意见的 CLI 工具，采用 Apache-2.0 协议开源。选它当样本不是因为它一定最合适，而是因为它把几种评审动作分成了不同命令，正好能把”输入范围”这件事摊开讲。截至 2026-07-28，GitHub 页面显示该项目约 15,000 star、约 1,000 fork。
一、先把”一次评审”拆成输入和输出两块
任何按 token 计费的调用，账都分两笔：输入（prompt）和输出（completion）。代码评审这个场景的特点是两边严重不对称。
输入里通常包含：系统提示词和评审规则、被评审的代码内容、以及可能附带的上下文（相邻代码、依赖文件、项目约定）。其中代码内容是大头，而且它随仓库规模线性增长。
输出就是评审意见本身。哪怕一次审出十几个问题，每个问题两三句话加个行号，总量也远小于输入。
所以当你发现某次评审费用异常，第一反应不该是”模型是不是话太多”，而应该去查这次到底送进去了多少文件、多少行。绝大多数异常账单都能在这里找到原因。
二、三种评审动作，输入范围差一个数量级
open-code-review 的常用命令大致对应几种不同的输入范围，装完之后（npm install -g @alibaba-group/open-code-review）先走一遍交互式配置：
ocr config provider # 选 LLM 供应商
ocr config model # 选模型
配置过程会引导选供应商、填 API key，并自动做连通性测试。项目仓库说明它兼容 OpenAI 与 Anthropic 两种接口格式，具体支持哪些模型以官方文档当前版本为准。
配好之后，几种动作的输入范围是这样拉开的：
ocr review # 评审已暂存/未暂存的改动
ocr review --from main --to feature-branch # 分支对比
ocr scan --path internal/agent # 整文件审计
ocr delegate preview # 由 AI agent 执行评审
ocr review 只看当前工作区的改动，你刚写完一个函数就跑，输入可能就是几十行 diff 加少量上下文，这是最省的用法。
ocr review --from main --to feature-branch 看的是两个分支之间的全部差异。一个开了两周的特性分支，累计改动几十个文件很正常，输入量比前者高一到两个数量级。
ocr scan --path xxx 是整文件审计，它不看 diff，直接把指定路径下的文件内容送进去。这时候输入量跟你改了多少完全无关，只跟那个目录有多大有关。指定一个几百个文件的模块，输入 token 能轻松冲到很高的量级。
还有一个 ocr delegate preview，是交给 AI agent 来执行评审流程，输入范围取决于 agent 自己决定看哪些文件，属于最难提前估算成本的一种，第一次用建议在小仓库上试。
上面前三个命令在日常使用中经常被混着用，但它们的成本画像完全不同。把 scan 当日常习惯用，和把 review 当日常习惯用，月底的账单不是一个量级。
三、全量审的 token 是被三个乘数放大的
同样一句”扫一遍”，为什么有的人跑一次没感觉、有的人跑一次心疼，差别在于三个乘数叠在了一起：
第一个乘数是参与评审的文件数。 增量评审的文件数由你这次改了什么决定，通常是个位数到几十；全量扫描由目录大小决定，可能是几百上千。这一项本身就能带来一到两个数量级的差距。
第二个乘数是每个文件送进去的长度。 diff 模式送进去的是变更块加少量上下文行，整文件模式送进去的是完整文件。一个三千行的老文件，你改了五行，两种模式的输入量能差出两个数量级以上。历史包袱越重的项目，这个乘数越夸张。
第三个乘数是每个文件是否附带额外上下文。 有的工具为了判断准确，会把被改动函数的调用方、相关的类型定义、项目里的编码规范一并送进去。这对准确率有帮助，但每个文件的输入基数会被抬高一截。是否开启、开到什么程度，值得当成一个成本开关来对待，而不是默认全开。
三个乘数是相乘关系而不是相加。这就是为什么”顺手扫一下整个模块”这个动作，感觉上只是多敲了几个字符，实际消耗却可能比日常增量评审高出一到两个数量级。
四、CI 里最容易漏算的一笔：触发次数
前面三个乘数说的是”一次调用有多贵”，真正让月度账单失控的往往是第四个变量：一天触发多少次。
open-code-review 支持接入 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 这四种平台。接进 CI 之后，评审就从”我想跑的时候跑”变成了”系统按规则自动跑”，触发频率不再由人控制。
几个容易踩的地方：
- 每次 push 都触发。 开发过程中一个分支 push 十几次很常见，如果每次 push 都跑一遍分支对比评审，前面十几次审的内容高度重复。更合理的做法是只在 PR 创建和 PR 更新时触发，或者干脆只在 PR 打上特定标签时触发。
- 同一个 PR 反复全量重审。 评审第五次提交时，前四次已经审过的部分又被完整送了一遍。如果工具支持只审增量提交，优先用增量模式；不支持的话，考虑降低自动触发频率、改成人工按需触发。
- 在 fork PR、依赖升级机器人 PR 上也跑。 自动化机器人提交的依赖版本号变更，AI 评审能给出的价值有限，但一样按量计费。这类 PR 建议直接在 CI 条件里排除。
- 合并到主干后又跑一遍。 主干上的 push 事件如果也绑定了评审，等于每个 PR 都被审两次。检查一下你的触发条件里有没有把 push 到主分支也包进去。
把这四条捋一遍，很多团队的调用次数能降下来一大截，而且几乎不损失评审价值——因为砍掉的都是重复审和无效审。
五、确定性筛选那一层为什么省钱
open-code-review 的架构是确定性流水线（文件筛选、规则匹配）+ LLM Agent 动态决策两段结合。这个设计跟成本的关系很直接：能用确定性规则处理掉的事，就不要花 token 让模型去做。
具体一点说，文件筛选这一步可以在完全不调用模型的前提下，把锁文件、自动生成的代码、资源文件、格式化产生的纯空白变更等等排除掉。这些内容在很多仓库的 diff 里占比不低，而它们进模型基本产不出有用意见。规则匹配同理，一部分能用静态规则判定的问题，没必要交给模型。
项目仓库还提到它内置了一套经过微调的规则集，覆盖 NPE、线程安全、XSS、SQL 注入等方向；并称这种混合架构可以消除通用 agent 常见的”位置漂移”与”覆盖不全”问题，同时它有独立的评论定位模块负责把意见准确落到行上。这些是项目仓库自己的说法，能不能在你的代码库上兑现，需要你自己试。
不过从成本角度看，“先用不花钱的规则收窄范围，再让模型处理剩下的部分”这个思路本身是通用的，不依赖某个具体工具。哪怕你用的是别的评审方案，在调用前加一层文件过滤（比如按扩展名、按路径、按 diff 行数阈值排除）通常都能立竿见影。
六、厂商自述的省 token 数字该怎么看
这里要专门说一句，因为很容易被带偏。
open-code-review 的项目仓库自述称，它在保持更高精度的同时，token 消耗约为 Claude Code 的 1/9；仓库还称该工具在阿里内部经数万开发者使用、发现过数百万个代码缺陷。这些都是项目方自己给出的口径，没有第三方复现，也没有公开可验证的测试集和评测方法。
我的建议是：把这类数字当成”项目方认为自己在这个维度上有优势”的信号，而不是当成可以直接写进选型报告的结论。原因很实在——AI 代码评审这个方向，目前各家（不管是 Copilot code review、CodeRabbit 还是开源方案）都没有可交叉验证的公开基准。token 消耗和评审质量的比值高度依赖于测试用什么仓库、什么语言、什么复杂度的改动，换一组样本结论可能就翻过来。
要比，比机制差异更靠谱：是走 diff 还是走全文件、有没有确定性预筛选、是否支持增量重审、上下文附带策略是否可配。这些是公开可查、你自己也能验证的东西。效果谁强谁弱，还是拿你自己的仓库跑一轮更实在。
七、自己动手算一笔账
与其猜，不如实测。一个不用写代码的土办法：
- 挑三个有代表性的场景：一次日常小改动（几十行）、一个中等规模的特性分支（十几个文件）、一个你平时会顺手扫的目录。
- 各跑一次，记下模型侧的用量。 大多数供应商的控制台都能看到按时间的 token 消耗，跑之前先记下时间点，跑完看增量。如果你的调用走的是自己的网关，直接在网关侧记账更准。
- 算出三个场景的单次成本比值。 三者之间可能拉开一到两个数量级，具体数字取决于你的仓库形态。
- 乘上你预计的月度触发次数。 这一步最容易吓一跳——单次很便宜的动作，乘上一天两百次就不便宜了。
- 据此定规则。 比如：日常改动本地随手
review；PR 走分支对比但只在创建和标签触发时跑；整目录scan定为季度性动作或者接手陌生模块时的一次性动作，不进自动流水线。
这套流程跑一次大概花不了半小时，但比任何通用建议都贴合你自己的项目。关于用量统计的更细做法，可以参考自己统计 token 用量：别等厂商账单出来才知道花了多少。
八、这套办法的局限
诚实说几条：
增量评审会漏掉跨文件的问题。 只看 diff 的模式，天然看不到”你改的这个函数还有三个地方在调用”。有些工具会自动补上下文，有些不会。省 token 和查得全，在这里是真实的取舍，不存在两头都占的方案。
全量扫描并非总是浪费。 接手一个陌生模块、准备重构一块历史代码、安全合规检查前，整文件审计的价值是增量审给不了的。它该被当成低频高价值的动作，而不是被彻底禁用。
token 省下来的钱，未必是你最该省的。 如果一次评审能拦住一个上线事故，那点调用费不值一提。这篇讲的是别让钱花在重复审和无效审上，不是鼓励把评审范围压到失去意义。
工具在快速变化。 命令、配置项、支持的集成方式都可能调整，上面提到的命令以项目仓库和官方文档当前版本为准，别照着几个月前的文章硬套。
小结
AI 代码评审的成本重心在输入侧，也就是你送进去多少代码，而不是模型回你多少字。增量 diff 评审、分支对比、整文件审计三种动作的输入范围可以差一到两个数量级，混着用而不区分场景，是账单失控最常见的原因。接进 CI 之后还要额外盯住触发次数，重复审和无效审砍掉之后，通常不损失评审价值。厂商自述的省 token 比例可以作为参考信号，但目前这个方向没有可交叉验证的公开基准，选型时比机制差异比比效果宣称更靠谱。最实在的做法还是拿自己的仓库跑三个场景，把比值和月度次数乘出来，然后据此定规则。