2026 年的自動化程式碼審查：讓它在每個 PR 上執行，無需購買席位

自動化程式碼審查是一種 CI 任務，它會將你的 diff 傳送給語言模型，在受影響的程式碼行上發布審查意見，並在發現嚴重問題時讓狀態檢查失敗。要在每次 pull request 上執行此功能而無需按席位訂閱，方法是自行託管一個開源工具組：將大約十五行的 workflow 複製到你的儲存庫中，新增一個 API 金鑰，並且只為每次審查消耗的 token 付費。沒有要購買的席位數量，因為根本沒有席位。我們維護的參考實作是 Orca-Code-Review 儲存庫——公開、採用 MIT 授權，且自 2026 年 6 月 25 日建立以來，一直是 OrcaCode Review GitHub Action 背後的程式碼。它隨附的路由配方預設將審查環節設為 DeepSeek V4 Flash，並將獨立驗證評審設為 GLM-5.3，兩者皆可自行變更。本文將逐步說明每次 push 時實際執行的內容、你需要設定的項目、它消耗的 token 成本，以及你在第二週會遇到的失敗模式。

簡短版：每次推送都會獲得一次審查。審查發現會以行內方式張貼在變更的行上。P0 和 P1 的問題會使檢查失敗並阻止合併；若沒有發現問題則會通過。您可以透過留言 /orcacode-review 來按需重新審查。工作流程位於您的儲存庫中；審查邏輯位於已發布的 action 中；模型選擇位於路由配方中，而您可以在自己的工作區中編輯該配方。審查者會讀取 diff 和儲存庫檔案，但絕不會執行您 PR 的程式碼。而且我們誠實地事先說明：它能抓出真正的錯誤，但仍會漏掉那些需要由懂得程式碼為何如此撰寫的人類來發現的問題。

• 一個工作流程 + 一個機密 + 一份代幣帳單。任何時候都不需要按席位計費的授權。

• 該測試工具是開源的。複製它、fork 它、稽核它，並把它鎖定在特定的 commit SHA 上。

• 模型是設定，而非廠商。 透過編輯路由配方來變更審核者，而不是改寫 YAML 或調整動作。

• 過大的 diff 不會產生任何成本。 大小檢查會在模型運行之前執行。

• 它只讀取你的程式碼，絕不執行。那是一個安全性質，它讓pull_request_target完全可以安全使用。

自動化程式碼審查的實際運作方式

每個自動化審查系統都是同樣的三個要素，只是換了不同的外衣：一個事件、一個執行者，和一個審查者。

該事件就是觸發器。隨附的工作流程會在 pull request 事件上觸發：opened、synchronize（新的推送）、ready_for_review（草稿變成就緒）；也會在 PR 留言時觸發。因為它執行於 pull_request_target，工作流程定義會從基底分支讀取，因此工作流程必須存在於基底分支，才能為 PR 執行。每次推送審查一次；該concurrency 區塊會取消先前的執行，因此快速連續推送不會排隊執行五次過時代碼審查。

該執行器是運行於 ubuntu-latest 的 GitHub Actions。該工作需要三種權限：對內容的讀取權限、對拉取請求的寫入權限（用於張貼行內評論），以及對議題的寫入權限（用於張貼摘要並清理過時的評論）。

該審查者是一個語言模型。該操作會擷取 PR 的 head，彙整引擎所選取的 diff 與儲存庫上下文，並將其傳送給審查模型。結果是一組發現，每個發現都標記了嚴重性，並錨定到檔案和行號。該操作會將這些發現張貼為行內 PR 評論，並在 PR 描述頂部的標記區域寫入一則摘要評論，並在每次推送時原地取代。

該閘門是一個狀態檢查。GitHub 不知道「審查」是什麼意思；它只知道審查檢查是否通過。你可以透過在分支保護中將該檢查標記為必要，讓該閘門真正生效。這就是整個封鎖合併的機制——不需要管理員 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。這就是實際選擇模型的地方。

• rules/ — 嚴重程度評分標準（P0–P3）、強制性的輸出格式，以及一個慣例指令，將專案自身的慣例文件作為不受信任的參考資料饋入審查。

• scripts/ — 精確度過濾器（L1 加上一個 L2 評判）、diff 防護、合併閘門、執行報告，以及 token 計量器。每一個都是小巧、可讀的 .mjs 檔案，並附有測試。

• skills/setup-orca-code-review — 安裝程式放入你的 coding agent 的技能，涵蓋安裝、重新設定、疑難排解與解除安裝。

• .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

/plugin install orca-code-review（安裝 orca-code-review 插件）

完全不需要 agent？相同的生命週期不過就是純粹的子命令——init 寫入工作流程，reconfigure 更改封鎖規則與 diff 限制，doctor 診斷未執行或未張貼的審查，uninstall 將其移除（先移除必需的檢查）。技能是主要入口，不是唯一的入口。或者手動接線：複製工作流程，新增一個名為 ORCAROUTER_API_KEY 的密鑰，並將 review 檢查標記為必需。

底層引擎是 Ali​baba 的 Open Code Review，鎖定確切版本並以 Apache-2.0 授權。OrcaCode 決定審查方式；OrcaRouter 決定由哪個模型來執行。自託管與託管服務之間的得失比較——當你自託管一個開源審查器時，「免費」的真正代價是什麼——在我們探討開放程式碼審查的文章中有詳細說明。

每次推送時，依序執行哪些項目？

了解順序會有所幫助，因為每個步驟都可能獨立失敗或跳過：

• 差異防護檢查會率先執行，在模型有任何運作之前。如果 merge-base 的差異超過 512 KB 或涉及超過 300 個檔案，審查就會被跳過並發布通知。預設值為on-oversized-diff: fail，因此超出限制的差異無法在未經審查的情況下通過必要的關卡。這同時也是成本控管：過大的 PR 不會消耗任何 token。

• 引擎會審查 diff。 一趟執行，每個檔案的並行數預設為 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 上，無論回報設定為何——一個在 diff 上沒有任何說明的失敗檢查，比一個嘈雜的檢查更糟。P0 代表可利用的安全漏洞、資料遺失、正常路徑上的當機，或建置損壞；P1 代表真實但範圍受限的錯誤；P2 代表只有在異常前置條件下才會觸發的真正缺陷；P3 是風格問題。當在兩個等級之間難以取捨時，評分標準規定選擇較低的那一個。

費用是多少

按 token 計費，而非按席次（seat）。您在 OrcaRouter 上選擇模型，帳單依消耗的 token 計算，而計量表讓每次執行的數字一目了然，而非神秘莫測。GitHub 的運作機制、Copilot 自 2026 年 6 月 1 日起的按量計費程式碼審查，以及第三方審查者如何融入該工作流程，都涵蓋在我們的 GitHub 程式碼審查指南中。逐欄位的完整成本比較——按席次計費的產品對比按 token 計費的產品，並附實際範例——收錄於我們的 AI 程式碼審查工具比較文章中；至於當審查者實際探索儲存庫時，單次審查會消耗多少 token（即 bot 與 agent 的區別），則見於我們的程式碼審查 agent 專文。本文要補充的重點是帳單的形態：它隨您審查的程式碼量而變，而非隨審查人數而變。

有兩項支出控制在一開始就很要緊。在公開儲存庫中，pull_request_target會繞過 GitHub 的分支核准閘門，而審查金鑰是依錢包額度計量的——陌生人可以開啟 PR 並觸發付費審查。請在金鑰上設定附警示的錢包預算，並將auto-review-authors設為類似OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR，讓未知貢獻者不會被自動審查。此外，如前所述，差異守衛（diff guard）代表過大的 PR 完全不花費任何成本。

什麼會壞？

自動化審查就是 CI。它會像 CI 一樣出錯，而且失敗模式大多不是模型的錯：

• 工作流程從未執行。對於 pull_request_target，工作流程是從基準分支讀取的——僅在 PR 分支中新增的工作流程，在合併前不會執行。另外，請確認應用程式已啟用、auto_review 已開啟、PR 不是草稿（在 ready_for_review 模式下會略過草稿），且儲存庫已啟用 Actions（fork 出來的儲存庫預設為關閉）。

• /orcacode-review 不會執行任何動作。註解觸發器要求註解必須以下列四種拼寫之一開頭 — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — 且留言者必須是 OWNER、MEMBER 或 COLLABORATOR。前導空白會破壞比對。外部貢獻者的指令會被刻意靜默忽略：該指令會執行持有付費金鑰的特殊權限工作流程。

• 驗證錯誤。密鑰名稱錯誤或缺失、金鑰已撤銷或超出預算，或工作流程已切換至 pull_request（此事件無法從複本讀取密鑰）。

• 檢查為紅色，並帶有“diff 過大”的提示。這就是大小守衛，依設定運作。拆分 PR，或調高限制，或設定 on-oversized-diff: pass——並請理解，若此檢查為必過，pass 表示一個夠大的 PR 會未經審查就直接通過關卡。

• 審查已執行，但沒有出現任何評論。 有三種原因，皆屬無害或設定所致：乾淨執行會張貼摘要，而非行內評論；靜音模式在發布時會將 P2 靜音（閘門和報告仍將其計入）；或精確度篩選器丟棄了發現結果——L1 會丟棄片段與提交不符的發現，L2 會丟棄低置信度的叢集。工作記錄中的嚴重性計數會告訴你是哪一種。

安全態勢值得明確闡述，因為它正是整個設計之所以安全的原因。引擎只會讀取 diff 和倉庫檔案，絕不執行 PR 程式碼。審查者沒有合併權限——審查發現可以阻止合併或新增評論，但沒有任何程式碼路徑能讓模型輸出批准或修改倉庫。未標記的審查發現會安全失敗，被視為阻擋性而非建議性。此外，執行報告不包含任何程式碼或審查發現的文字。這種雙層設置能捕捉單遍審查遺漏的問題，是我們 AI 程式碼審查安全文章的主題；上述威脅模型已記載於倉庫的 SECURITY.md 中。

當自動化審查是錯誤的工具時

它出錯的頻率比工具供應商所承認的還高。遇到以下情況時，請先略過：

• 問題在於脈絡，而非數量。如果審查緩慢是因為審查者必須理解程式碼為何以這種方式撰寫，那麼讓 LLM 閱讀 diff 的幫助不大。它不記得前一個月的討論串，也對系統的歷史一無所知。

• 這個 diff 大部分是生成或第三方引入的程式碼。自動格式化的輸出、樣板生成的檔案、相依套件的快照。審查這些內容會耗費大量 token 並製造噪音，而這正是 conventions 指令最派不上用場的地方——這些程式碼並非刻意遵循專案的風格。

• 團隊已經以結對方式審查所有內容。自動化審查是擴大規模的槓桿。如果每一項變更都已經由一位在場的人審查過，機器增加的第二意見通常比第一意見更不了解全貌。

• 沒人閱讀調查結果。一份無人據以行動的審查，就是永遠無法變綠的工作流程。這是最常見的靜默失敗，沒有任何精確度過濾器能修正它。

• 審查必須執行程式碼。 如果你需要的是針對 PR 的測試套件，LLM 審查是錯誤的工具。它只會閱讀；不會執行。需要建置並執行工件的安全掃描，應屬於獨立且謹慎界定範圍的工作——請記住，審查工作流程絕不可擴展為執行 PR 控制的程式碼。

• 儲存庫很小，或是拋棄式的。 低於某個變更頻率時，審查的負擔大過於它能抓到的錯誤。

誤報，以及精確度過濾能修復與不能修復的問題

對每個 AI 審查者的指控都是它會「喊狼來了」。測試框架透過兩層來應對這個問題，而精確釐清哪一層修復哪一種失敗會很有幫助。

該確定性層（L1）會消除幽靈發現：引擎有時會聲稱程式碼存在，但其實並不存在——例如片段漂移，或發現被複製到同級檔案。L1 會根據實際審查的提交，驗證每個發現的現有程式碼片段，並將不符者重新歸位或捨棄。這就解決了「這行根本不存在」這類的誤判，而這類誤判是機械性且可驗證的。

該判斷層（L2）會消除重複及未經證實的主張：LLM 評判者會根據根本原因將發現分群，並捨棄信賴度低於評判門檻（預設 0.5）的群集。這能修正“同一錯誤以三種方式回報”及臆測性發現。

這兩層都無法解決的問題，值得明說。一個錯誤但自信的發現結果能通過法官的審查——法官也是 LLM，而一個聽起來很篤定的 LLM，並不等於一個正確的發現結果。如果法官跑在審查者自己的模型上，它等於替自己背書，整個 pass 雖然仍回報成功，但實際上已經失效；這就是為什麼出貨的 recipe 會把法官導向與審查者不同的模型。而且嚴重程度的評分標準刻意保守——「當在兩個等級之間難以取捨時，選擇較低的那個」——這意味著一個真實存在但有條件的 bug，更可能被歸類為 P2 建議，而非阻斷性的 P1。對於一個不能把一切都擋下的工具來說，這是正確的校準；但這終究只是一種校準：它用漏掉的阻斷性問題，換來更少的誤報。PR 摘要永遠會列出所有發現，所以那些被壓低為 P2 的項目仍然都在那裡，可以讀到。如果這個取捨不適合你的團隊，評分標準和法官門檻都是配置，而不是需要開一張支援單的事。

底線

對於已經在使用 GitHub Actions 的團隊來說，開源的 harness 是在每個 PR 上獲得自動化程式碼審查最便宜的方式：一個 workflow 檔案、一個 secret、一份隨著被審查程式碼量成長的 token 帳單，以及一個由你自己掌控的模型選擇。當你想要零維運和一個可以聯絡的廠商時，才購買按席位計費的產品——不是因為審查品質更好，而是因為你在買別人承擔的問題，而不是自己扛下來。而在你設定任何這一切之前，先問問審查結果會不會有人看。Harness 可以讓審查自動發生，但它無法讓任何人去讀它。

想要同一個審查者，卻不想自己執行嗎？OrcaCode Review 以託管式 GitHub App 的形式執行這套完全相同的 harness——同樣的開放配方、同樣的按 token 計費、無需席位。