AI code review 最容易被誤解的地方，是它看起來像多了一個 reviewer。

PR 開了，機器人跑來留 comment。某段邏輯可能有 bug，某個 edge case 沒蓋到，某個函式名稱不夠清楚。這種互動很像 code review，所以很多團隊會直覺把它放在「開發效率工具」那一格。

但當 Copilot code review 的 agentic 能力開始透過 GitHub Actions runners 執行，而且 code review runs 會消耗 Actions minutes，這件事就不只是「AI 幫忙看程式」了。

它變成一段 CI 工作。

會排隊，會吃 quota，會有帳單，會失敗，會 fallback，也會跟你原本的 lint、test、build、preview deploy 搶同一個自動化成本池。

這個轉變比「AI reviewer 準不準」更值得工程團隊先想清楚。

免費第二雙眼睛這個想像快要過期了

AI reviewer 很容易讓人產生一種舒服的錯覺：反正它只是多看一次，不用白不用。

如果它只是在 UI 上產生幾句建議，這個想法還勉強成立。可是 GitHub Copilot code review 的方向不是停在 comment bot。文件裡提到，部分 agentic 能力會透過 GitHub Actions runners 執行，例如收集完整專案上下文，或把建議交給 Copilot coding agent 後續處理。

也就是說，review 開始碰到 runner。

從 2026-06-01 起，相關 Copilot code review runs 會消耗 GitHub Actions minutes。Self-hosted runners 不會消耗 GitHub-hosted minutes，這句話聽起來像解法，但它只是把成本換一個地方擺：runner 要維護，要排程，要保護 secrets，要管網路邊界，也要有人負責它壞掉時怎麼辦。

這時候 AI review 就不該再被放在「多一個好心同事」的位置。

它比較像你在 PR pipeline 裡新增了一個 job。

有 comment，不代表完整 review 有跑完

這裡還有一個更細的坑。

GitHub 文件提到，如果 Actions 不可用，或 Copilot code review workflow 失敗，Copilot 仍可能產生 review，只是少掉額外的 agentic 能力。

這對工程管理很麻煩，因為它不是那種一眼就看懂的硬失敗。

傳統 CI 失敗很直接：紅燈、required check 沒過、不能 merge。可是 AI review 可能看起來「有東西出來了」。PR 上仍然有建議，團隊也可能以為它完成了一次完整審查。

問題是，這次 review 到底有沒有拿到完整專案上下文？有沒有跑到原本設計的 agentic 流程？有沒有因為 Actions 問題退回比較弱的模式？

如果團隊只看最後有沒有 comment，很容易把降級後的結果當成完整 evidence。

這不是 AI 特有的問題。所有自動化只要有 fallback，都會碰到同一件事：你必須讓人知道現在拿到的是完整結果、降級結果，還是只有部分結果。

差別是 code review 牽涉到信任。信任最怕半透明。

Review policy 其實變成 infra policy

很多團隊導入 AI review 時，第一個想法會是「那就每個 PR 都自動跑吧」。

聽起來合理。越早看越好，越多看越安全。

但如果每個 PR、每次 push、每個 bot-generated change 都會觸發一次 agentic review，這就不是單純的 review 規則，而是基礎設施政策。

台灣不少團隊已經把 GitHub Actions 當成日常膠水：跑 ESLint、型別檢查、單元測試、前端 build、Docker image、preview deploy、release checklist。這些東西本來就在吃 minutes、吃 runner queue、吃工程師等待時間。

AI review 加進來後，它不是在一個免費平行宇宙裡運作。它會進到同一個系統。

小團隊最常見的踩法，是先把 automation 開滿。每個 repo 都開，所有 PR 都跑，review comment 看起來也很有幫助。等到某個月底出現 quota 警告、帳單變醜，或 CI 開始排隊，才回頭問：哪些 review 其實不用跑？

這個順序反了。

導入前就該先問：

• 哪些 PR 值得跑 agentic review？
• 是 PR 開啟時跑，還是 ready for review 後跑？
• Draft PR 要不要跑？
• 只改 README、文案、測試 fixture 時要不要跑？
• 依照 label、路徑、風險模組、檔案數量、測試狀態來觸發，可不可以？
• 手動 review、repo 自動 review、org policy review，成本算在誰身上？
• 如果 AI review 降級或失敗，PR 上要不要顯示成 required evidence 不足？

這些問題聽起來不像 code review。它們比較像 DevOps。

也正因為如此，AI review 的成熟度不是「全開」。成熟度是你知道它什麼時候不該跑。

Agentic PR 本來就該被 CI 指標觀察

另一個值得放進腦袋裡的訊號，是研究開始把 agentic PR 當成 CI/CD reliability object 來看，而不是只看 agent 會不會寫程式。

一篇 2026 年 4 月的研究分析了 GitHub Actions 中由 agentic PR 觸發的 workflow runs。它的有趣之處不是告訴你哪個 agent 最強，而是提醒我們：當 agent-driven activity 進入 repo，影響會出現在 CI 指標裡。

換句話說，你不該只看「AI 幫我開了幾個 PR」。

你要看：

• failed runs 有沒有增加
• retry 次數有沒有增加
• queue time 有沒有變長
• flaky test 是否被放大
• 人工修補時間有沒有下降，還是只是轉移到 reviewer 身上
• agent 產出越頻繁時，workflow success rate 有沒有變差

這才是工程系統該看的東西。

AI review 也是同樣邏輯。它不是一個漂浮在流程外的聰明建議器。它開始有 runner、有 trigger、有 quota、有 fallback、有 downstream action。既然它進了 CI 經濟，就該接受 CI 的量測方式。

不要只問它抓到幾個問題。

也要問它讓 pipeline 多花了多少時間、多少錢、多少等待、多少人力判讀。

一開始不要 every push，先設觸發條件

如果我是從零幫團隊設 AI code review policy，我不會一開始就 every push。

我會先把它當成一個比較貴、比較重、需要上下文的 review job。先讓它跑在真正值得跑的地方。

例如：

• PR 標上 needs-ai-review 才跑
• Draft PR 不跑，ready for review 才跑
• 基本 lint、typecheck、unit test 過了才跑
• 只針對高風險路徑跑，例如 auth、billing、permission、migration、deployment config
• 大型 refactor 跑，但純文件或小文案不跑
• bot-created PR 先用比較保守的觸發條件，不要讓 agent 互相推高 automation volume

這些規則沒有哪一個放諸四海皆準。重點是團隊要承認 AI review 有成本，所以觸發條件需要被設計。

還有一件事要寫清楚：誰是成本 owner。

個人手動要求 Copilot review、repo 自動設定、organization policy、agent-created PR 的後續 review，這幾種情境在帳務和責任上不一定應該混在一起。尤其是外包、接案、多 repo、多 team 共用 organization 的環境，如果只靠默契，最後一定會有人覺得莫名其妙。

「誰按的」和「誰付錢」不一定是同一件事。

Self-hosted runner 不是免費，只是成本換形狀

看到 Actions minutes 這件事後，有些團隊會直覺說：那我們用 self-hosted runner。

可以，但不要把它講成免費。

Self-hosted runner 的確能避開 GitHub-hosted minutes，但它把問題換成另一組工程成本：

• runner 機器誰維護？
• queue 滿了誰處理？
• runner 可以碰哪些內網資源？
• secrets 要怎麼隔離？
• AI review job 能不能跑在和 deploy job 同一批 runner 上？
• 如果 review job 被濫用，會不會拖慢 release pipeline？
• runner log、審計、失敗重跑，要不要進平台團隊的觀測系統？

如果你的團隊本來就有成熟的 self-hosted runner 管理，這可能是合理選項。可是如果只是為了省 minutes，臨時架一台機器讓所有 AI review 都往上丟，那只是把帳單問題換成安全和維運問題。

很多所謂省成本，最後都只是把成本藏到另一個人的待辦清單。

把 AI review 放進可降級的工程系統裡

我不是在反對 AI code review。

剛好相反。它很有用，尤其是在大型 PR 的上下文提醒、常見錯誤掃描、測試缺口提示、陌生模組的初步整理上。對很多團隊來說，它會減少 reviewer 的第一輪負擔。

但有用的工具，最怕被當成魔法。

AI review 一旦開始消耗 Actions minutes，就表示它進入了工程系統的現實世界。現實世界裡沒有免費第二雙眼睛，只有不同形式的 compute、queue、quota、fallback、責任歸屬和維運成本。

所以比較成熟的問題不是：

「要不要讓所有 PR 都給 AI 看一次？」

比較成熟的問題是：

「哪些 PR 值得花這段 compute？它失敗時 PR 狀態要怎麼呈現？它的結果能不能當 required review evidence？誰負責帳單？誰負責 runner？誰負責判斷降級後的 review 夠不夠？」

AI reviewer 是 CI 的一部分，不是 CI 之外的魔法。

把它當成 pipeline job 來設計，你會少很多幻想，也少很多月底才出現的驚喜。

Source notes

• GitHub Docs: Copilot code review 的 agentic capabilities 會使用 GitHub Actions runners，且 code review runs 會消耗 GitHub Actions minutes；self-hosted runners 不消耗 GitHub-hosted minutes。
• GitHub Docs: Actions 不可用或 workflow 失敗時，Copilot 仍可能產生 review，但沒有額外 agentic capabilities。
• arXiv 2604.18334: 研究分析 agentic PR 觸發的 GitHub Actions workflow runs，並把 agent 活動與 CI reliability 指標連在一起觀察。