2026年的自动化代码审查：让它在每个PR上运行，而无需购买席位

自动化代码审查是一个 CI 任务，它将你的 diff 发送给语言模型，在受影响的代码行上发布发现结果，并在发现严重问题时让状态检查失败。若要让它在每次拉取请求上运行而无需按席位订阅，方法是自行托管一个开源工具链：将大约十五行的工作流复制到仓库中，添加一个 API 密钥，并且只为每次审查消耗的 token 付费。无需购买席位数量，因为没有席位这回事。我们维护的参考实现是 Orca-Code-Review 仓库——公开、MIT 许可，自 2026 年 6 月 25 日创建以来，它一直是 OrcaCode Review GitHub Action 背后的代码。其内置的路由配方默认将审查环节设为 DeepSeek V4 Flash，独立验证评判设为 GLM-5.3，两者都可自行更改。本文将介绍每次推送时实际运行的内容、你需要配置的内容、消耗的 token 成本，以及你会在第二周遇到的故障模式。

简短版。每次推送都会获得一次审查。发现的问题会以内联评论的形式发布在被修改的代码行上。P0 和 P1 级别的发现会导致检查失败并阻止合并；干净运行则通过。你可以通过评论 /orcacode-review 来按需重新审查。工作流位于你的仓库中；审查逻辑位于已发布的 action 中；模型选择位于路由配方中，你可以在自己的工作区中编辑它。审查者会读取 diff 和仓库文件，但绝不会执行你 PR 中的代码。还有一句坦诚的事先说明：它确实能发现真正的 bug，但仍然会漏掉那些只有了解代码来龙去脉的人才能发现的问题。

• 一个工作流 + 一个密钥 + 按 token 计费。全程无需按席位许可。

• 该测试工具是开源的。复制、分叉、审计，然后将其固定到commit SHA。

• 模型是一种设置，而非供应商。要更改审查者，请编辑路由配方，而不是重写 YAML 或调整操作。

• 过大的差异不会带来任何成本。 大小守卫先于模型运行。

• 它只读取你的代码，从不运行它。正是这一安全特性，使pull_request_target可以安全使用。

自动化代码审查实际是如何工作的

每个自动化审查系统都是同样的三种成分穿着不同的外衣：一个事件、一个运行器和一个审查器。

该事件是触发器。随附的工作流会在拉取请求事件上触发——opened（打开）、synchronize（新推送）、ready_for_review（草稿变为就绪）——以及拉取请求评论。由于它运行在pull_request_target上，工作流定义从基础分支读取，这就是为什么工作流必须先存在于基础分支上，才能为拉取请求运行。每次推送进行一次审查；concurrency块会取消之前的运行，因此快速连续推送不会排队对过时代码进行五次审查。

该运行器是运行在 ubuntu-latest 上的 GitHub Actions。该作业需要三项权限：对内容的读取权限、对拉取请求的写入权限（用于发布内联评论），以及对议题的写入权限（用于发布摘要和清理过时评论）。

该审查者是一个语言模型。该操作获取PR头部，汇总diff和引擎选择的仓库上下文，并将其发送给审查模型。结果是一组发现，每个发现都带有严重性标记，并锚定到文件和行。该操作将它们作为内联PR评论发布，并在PR描述顶部的标记区域写入一条摘要评论，每次推送时都会被原位替换。

门禁是一个状态检查。GitHub 并不知道“review”是什么意思；它只知道review检查是否通过。要让门禁真正生效，你需要在分支保护中将该检查标记为必需。这就是合并阻断机制的全部——不需要管理员 API 调用，不需要标签，只需要一个未通过的必需检查。

不会发生的情况是：没有任何东西会执行 PR 的代码。引擎只负责读取。正是这一单一不变量，使得特权级的pull_request_target触发器在与付费 API 密钥一起使用时是安全的。

开源框架是制胜关键

上面这一切对许多工具来说都成立。但大多数工具并不具备的是，整个东西都是可检查和可自托管的，这正是 Orca-Code-Review 仓库所能带给你的。它是一个公开的、MIT 许可的 GitHub 仓库（JavaScript，创建于 2026年6月25日），它将审查打包成一个可复用的复合 GitHub Action 以及一个安装程序，而它正是同一套代码，托管的 OrcaCode Review 应用所运行的。

在代码树里花上十分钟，你就能说出每一个与你的 PR 相关的部分。

• action.yml——该复合操作，约有十五个文档化输入。其中没有硬编码任何模型名称。

• workflows/orca-code-review.yml — 示例消费者工作流（约十五行），您将其复制到 .github/workflows/.

• recipes/—— 路由 DSL。这里就是实际选择模型的地方。

• 规则/严重性分级标准（P0–P3）、强制输出格式，以及一条约定指令，将项目自身的约定文档作为不可信参考数据提供给审查。

• scripts/ — 精度过滤器（L1 加 L2 评判器）、diff 防护、合并门、运行报告和 token 计量器。每个都是一个小型、可读的 .mjs 文件，带有测试。

• skills/setup-orca-code-review——安装程序放入你的编码代理中的技能，涵盖安装、重新配置、故障排除和卸载。

• .claude-plugin/—— 这让 Claude Code 可以将技能作为自动更新的插件进行安装。

安装是一个单行命令，它教会你的AI这个产品是什么，然后停止：

npx @orcarouter/code-review

CLI 会检测你使用的编码代理——目录涵盖 36 个平台，从 Claude Code、Cursor、Codex、OpenCode、Windsurf 到 GitHub Copilot、Gemini CLI、Amazon Q Developer、Cline、RooCode 等——安装技能，然后交由你处理。接着你可以用自然语言向代理提问：“在这个仓库中设置 OrcaCode Review” “仅阻止 P0” “为什么审查没有运行？”该技能承担整个生命周期：它编写工作流，引导你完成 API 密钥设置，配置门禁，并且只询问那些真正需要你来回答的问题。

Claude Code 可以改为将技能作为插件安装，这样当仓库变动时，它能保持更新：

/plugin marketplace add Continuum-AI-Corp/orca-code-review

安装 orca-code-review 插件

完全没有 agent？同样的生命周期就是简单的子命令——init 写入工作流，reconfigure 更改阻塞规则和差异限制，doctor 诊断不运行或不发布的审查，uninstall 将其移除（先删除必需的检查）。技能是入口，但不是唯一的入口。也可以手动配置：复制工作流，添加一个名为 ORCAROUTER_API_KEY 的密钥，并将 review 检查标记为必需。

底层引擎是阿里巴巴的 Open Code Review，以精确版本锁定，并采用 Apache-2.0 许可证。OrcaCode 决定审查方式；OrcaRouter 决定运行审查所用的模型。自托管与托管的成本对比——当您自行托管开源审查工具时，“免费”的真正代价——在我们关于开放代码审查的文章中已作深入探讨。

每次推送时依次运行什么？

知道顺序会很有帮助，因为每一步都可能独立地失败或被跳过：

• diff 守卫会最先运行，先于模型执行。如果 merge-base 差异超过 512 KB 或涉及超过 300 个文件，则跳过审查并发布通知。默认值为 on-oversized-diff: fail，因此超出限制的差异无法未经审查就通过必需的门禁。这也是成本控制手段：超大的 PR 消耗零 token。

• 引擎审查差异。单次执行，每个文件的并发数默认为 24，单次执行的墙上时钟时间上限为 20 分钟。

• 精度过滤器会对原始发现进行后处理。L1 是一种确定性过滤器，它会对照被审查的提交验证每个发现所声称的现有代码片段，并对不匹配项进行重新归属或丢弃。L2 是一个 LLM 评判器，它按根本原因对发现进行聚类，并丢弃低置信度的聚类。这两层均为软失败机制：出错时会保留前一阶段的发现，且绝不会中止审查。

• 该门禁适用。 P0 和 P1 发现项会导致检查失败；PR 摘要会统计所有发现项，包括在 diff 中被静音的发现项。

• 计量器打印其成本。该计量器记录每次调用的 token 核算信息——提示词、补全、缓存 token 以及路由器解析出的模型——并在作业日志中打印汇总表。

• 可选的运行报告将严重性计数和门禁元数据发送到 OrcaRouter 控制平面，以供分析仪表板使用。它不包含任何代码、差异或发现项文本。

您实际配置的内容

有三个表面，它们的爆炸半径差异很大。

1. 工作流文件。消费者工作流刻意保持精简。值得调整的输入都位于 action 中：block-on（决定哪些严重级别会导致检查失败——默认 P0,P1），fix-first（决定哪些严重级别会提前终止详尽审查），auto-review-authors（谁会被自动评审的允许名单），max-diff-kb 和 max-diff-files 和 on-oversized-diff（大小保护机制），timeout-minutes，concurrency，meter，以及report。每个输入都有文档化的默认值，因此一个全新的工作流只需五行 YAML 加一个 secret。

2. 仪表板。当settings: true（默认值）时，每次运行都会从 OrcaRouter → Apps → OrcaCode Review 获取每个仓库的设置：模型、审查模式、合并策略、报告严重级别、安静模式、详尽审查、自定义评估标准和护栏。设置settings: "false"后，工作流文件即具有最终决定权——仪表板中的任何值都无法覆盖它。如果你从未打开控制台，也不会失去任何功能；只需在 YAML 中进行配置即可。

3. 路由配方——人们常常忽略的那个。该操作从不指名道姓地指定模型。相反，它将原始事实作为请求头注入——运行被记录为哪个层级、上一次通过是否发现 P0/P1，以及当请求是 L2 裁判时的一个视角标记——然后工作区路由器的 DSL 配方将这些请求头映射到一个具体的模型。随附的配方默认将审查交给 DeepSeek V4 Flash，将裁判交给 GLM-5.3，故意将两者路由到不同的模型。更改审查你代码的模型，就是对你自己工作区中该配方的编辑：无需操作版本升级，无需重写 YAML，无需重新部署。

严重性约定包含两个独立的设置，而非一个。合并策略决定什么会阻止合并；报告严重性决定什么会发布到 diff 上。默认配置是 P0/P1 阻止，P2/P3 通过。任何会阻止合并的严重级别总是会被发布，无论报告设置如何——一个失败的检查如果在 diff 上没有任何说明，比一个嘈杂的检查更糟糕。P0 表示可利用的安全漏洞、数据丢失、正常路径上的崩溃或构建损坏；P1 表示真实但受控的 bug；P2 表示只在异常前置条件下触发的真实缺陷；P3 属于风格问题。在两个级别之间犹豫时，规则要求选择较低的那个。

费用是多少

按 token 计费，而非按席位计费。您在 OrcaRouter 上选择模型，计费按消耗的 token 计算，而计量器让每次运行的计费数字一目了然，不再神秘。GitHub 的运作机制、自 2026 年 6 月 1 日起 Copilot 的按量计费代码审查，以及第三方审查者如何融入该工作流程，在我们的 GitHub 代码审查指南中均有介绍。完整的逐项成本对比——按席位计费的产品与按 token 计费的产品，并附有实例——见我们的 AI 代码审查工具对比；至于单次审查在审查者实际探索代码库时消耗多少 token（即 bot 与 agent 的区别），见我们的代码审查 agent 专题文章。本文要补充的重点是账单的形态：它与您审查的代码量成正比，而非与参与审查的人数成正比。

有两个支出控制从一开始就很重要。在公共仓库中， pull_request_target 会绕过 GitHub 的 fork 审批门禁，并且审查密钥是按钱包计量的——陌生人可以打开 PR 并触发付费审查。为密钥设置带提醒的钱包预算，并将 auto-review-authors 设置为类似 OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR 的值，这样未知贡献者就不会被自动审查。而且如前所述，diff 守卫意味着过大的 PR 根本不会花费任何成本。

什么会坏？

自动化评审就是 CI。它像 CI 一样会出故障，而且故障模式大多不是模型的错：

• 工作流永远不会运行。对于 pull_request_target，工作流是从基础分支读取的——仅在 PR 分支中添加的工作流在合并前不会运行。还要检查：应用已启用、auto_review 已开启、PR 不是草稿（在 ready_for_review 模式下会跳过草稿）、仓库已启用 Actions（复刻仓库默认会关闭它们）。

• /orcacode-review 不执行任何操作。 评论触发器要求评论必须以以下四种拼写之一开头 — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — 且评论者必须是 OWNER、MEMBER 或 COLLABORATOR。前导空格会导致匹配失败。外部贡献者的命令会被静默忽略，这是有意为之：该命令会运行一个持有付费密钥的特权工作流。

• 身份验证错误。机密名称不正确或缺失、密钥已吊销或超出预算，或者工作流已切换到 pull_request（这无法从复刻中读取机密）。

• 该检查呈红色，并带有“diff too large”的提示。这就是大小保护机制，按配置运行。拆分 PR，或提高限制，或设置 on-oversized-diff: pass——同时要明白，当这是一项必需检查时，pass 意味着一个足够大的 PR 会径直穿过门禁而未经审查。

• 评审运行了，但没有评论出现。有三种原因，均为良性或配置所致：干净运行会发布摘要而非行内评论；安静模式会在发布时使 P2 静默（闸门和报告仍会将其计入）；或精度过滤器丢弃了发现项——L1 会丢弃片段与提交不匹配的发现项，L2 会丢弃低置信度簇。作业日志中的严重级别计数会告诉你具体是哪种。

安全态势值得直截了当地说明，因为它正是整个设计安全性的基础。引擎只读取 diff 和仓库文件，绝不执行 PR 代码。审查者没有合并权限——发现的问题可以阻止合并或添加评论，但没有任何代码路径能让模型输出批准或变更仓库。未标记的发现会安全失败，按阻断而非建议处理。运行报告也不包含代码或发现文本。两层设置能捕获单次审查遗漏的问题，这正是我们 AI 代码审查安全文章的主题；上述威胁模型记录在仓库的 SECURITY.md 中。

当自动化审查是错误的工具时

它出错的频率比工具供应商承认的还要高。请在以下情况下跳过此步骤：

• 问题在于上下文，而非数量。如果评审缓慢是因为评审者需要理解代码为何这样编写，那么阅读 diff 的 LLM 帮助甚微。它不记得上个月的讨论串，也不了解系统的历史。

• 这个 diff 大部分是生成的或第三方引入的代码。自动格式化的输出、脚手架文件、依赖快照。审查它会消耗 token 并产生噪音，而这正是 conventions 指令最没有帮助的地方——这些代码并不是项目有意采用的风格。

• 团队已经对所有内容进行结对审查。 自动审查是提高审查量的杠杆。如果每项变更都已有在场的人工审查过，机器给出的第二意见通常不如第一意见了解得全面。

• 没有人阅读这些发现。无人跟进的审查就是一种永远无法通过的工作流。这是最常见的静默故障，任何精准过滤器都无法修复它。

• 审查必须运行代码。如果你需要的是针对 PR 的测试套件，那么 LLM 审查就是用错了工具。它只能阅读，不能执行。需要构建并运行产物的安全扫描，应该放在单独且仔细划定范围的任务中——请记住，审查工作流绝不能被扩展来运行 PR 控制的代码。

• 仓库规模很小或是临时性的。 在变更频率低于一定程度时，审查的开销超过了它能发现的缺陷。

误报，以及精确过滤能解决和无法解决的问题

对每一位AI审查者的指控都是它在喊“狼来了”。测试框架通过两层来应对这一指控，而明确哪一层修复哪种故障是有帮助的。

该确定性层（L1）能消除“幽灵发现”：引擎有时会声称某段代码存在，但该代码其实并不存在——比如一段发生漂移的片段，或一条被复制到兄弟文件中的发现。L1 会对照实际审查的提交，逐条验证发现所对应的现有代码片段，并对不匹配项重新归位或删除。这样就修复了“这行代码根本不存在”这类误报，这类误报是机械性的，且可验证。

该判断层 (L2) 会消除重复项和无依据的发现：LLM 判断器按根本原因对发现进行聚类，并剔除置信度低于判断阈值（默认 0.5）的聚类。这样就解决了“同一个 bug 被以三种方式报告”以及推测性发现的问题。

这两层都无法修复的问题，值得明说。一个错误但自信的发现能通过评判者——评判者就是一个LLM，而一个听起来笃定的LLM并不代表发现就是真实的。运行在审查者自身模型上的评判者会与自己意见一致，检查就会在仍然报告成功的同时失去作用，这正是随附配方将评判者路由到与审查者不同的模型的原因。严重性规则也刻意保守——“在两个级别间犹豫时，选较低的”——这意味着一个真实但有条件的缺陷更可能被定为P2建议而非阻塞性P1。对于一款不能阻塞一切的工具来说，这是正确的校准，但它终究是校准：它用漏掉阻塞项来换取更少的误报。PR摘要总是计入每一条发现，所以被压低的P2仍然可以读到。如果这种权衡对你的团队不适用，规则和评判者阈值属于配置，而不是支持工单。

底线

对于一个已经深度使用 GitHub Actions 的团队而言，开源工具链是让每个 PR 都获得自动化代码审查的成本最低方式：一个工作流文件、一个密钥、一份随审查代码量增长的 token 账单，以及一个由你掌控的模型选择。当你想要零运维、有供应商可求助时，再去买按席位计费的产品——不是因为它的审查更好，而是因为你买的是别人替你承担的问题，而不是自己运营。在把这一切搭起来之前，先问问：审查会被读吗？工具链可以让审查自动发生，却无法让任何人去读它。

想要同一个审查器，又不想自己运行？OrcaCode Review以托管式 GitHub App 的形式运行这一完全相同的测试框架——同样的开放配方、同样的按 Token 计费、无席位限制。