GitHub Copilot Code Review 現在能批准 PR：怎麼開、誰能用，以及為什麼不能盲信

GitHub 在 2026 年 9 月 1 日宣布，Copilot code review 開始支援「approval assessment」，並在管理員開啟後，讓 Copilot 對符合條件的 Pull Request 提交 approval。這個變化很容易被簡化成「AI 可以自己合併程式碼」，但那不是官方說法，也不是這個功能目前保證的事情。比較準確的理解是：Copilot 可以把一次程式碼審查的判斷，轉成 GitHub 工作流程裡可被看見、可被管理、在特定設定下能算進 required approvals 的審核結果。

這篇整理官方公告與文件，說清楚它到底做了什麼、怎麼設定、適合誰，以及在團隊導入前不能忽略的限制。

這次新增的是什麼？

每次 Copilot code review 都會在 overview comment 裡提供 approval assessment。它會告訴你 Copilot 認為這個 PR 是否已經接近可以批准，讓團隊不用只看一長串逐行留言，也能先看到一個總結判斷。GitHub 把這個判斷定位成輔助資訊：單獨的 assessment 不會自動滿足 merge requirement，也不等於人類 reviewer 已經按下核准。

如果管理員進一步允許 Copilot 提交 approval，Copilot 才能在設定範圍內送出一個真正的 approving review。再往前一步，若 repository 也允許 Copilot approval 算進合併所需的 approvals，它才可能成為 branch protection 規則裡的一票。這三個層次要分開看：

Copilot 產生 approval assessment。
Copilot 被允許提交 approval。
這個 approval 被允許算進 required approvals。

其中後兩個預設都不是無條件開啟。GitHub 把這項能力列為 public preview，設定與行為都可能調整。

實際怎麼開？

對個人方案來說，官方文件列出的自動 code review 設定適用於 Copilot Pro、Pro+ 或 Max。你可以從 GitHub 右上角頭像進入 Copilot settings，找到 Automatic Copilot code review，將它設為 Enabled。這主要處理「要不要自動發起審查」；它不等於已經允許 Copilot 替你批准 PR。

Repository 層級則要到 Settings，進入 Code, planning, and automation 裡的 Copilot → Code review。這裡可以調整 review effort level，也能在 Auto-approval 區域設定：

Allow Copilot to approve pull requests：允許 Copilot 提交 approving review。
Allow Copilot approvals to count toward merge requirements：允許這些 approvals 滿足分支保護所要求的核准數。
File paths：限制哪些變更路徑可以讓 Copilot approval 算入 merge requirements。

File paths 是很重要的安全閥。官方文件說明可以用 glob 逐行指定，最多支援 15 個 glob，而且只有當 PR 裡每個變更檔案都符合規則時，approval 才會算入要求。你可以把它限制在測試、文件或低風險的特定目錄，而不是讓它對整個 repository 一視同仁。

Organization 層級可以選擇全部啟用、交由 repository 決定、只對選定 repositories 啟用，或全部停用。Enterprise 還能決定 organization 是否有權自行開啟。官方文件同時指出，Enterprise 預設是 Disabled everywhere。這代表真正的控制權不是藏在某個使用者的個人選項，而是可以由企業、組織、repository 三層逐級收斂。

為什麼它對團隊有用？

它最實際的價值不在於「少請一個 reviewer」，而在於把重複性的第一輪檢查變成一致的流程。對每天有大量小型 PR 的團隊，Copilot 可以先檢查明顯的邏輯問題、測試缺口與一般性的風險，再把 approval assessment 放在 overview comment。人類 reviewer 便能先處理架構、產品意圖、資料邊界與例外情境，而不用每次都從相同的低階檢查開始。

它也適合維護者較少、但變更頻率高的開源專案。自動 review 可以在 contributor 發出 PR 後先提供回饋；設定 review new pushes 後，新的 commit 也能觸發後續審查。對 draft PR 開啟 review，則能在正式請人看之前提早抓錯。這些用途都比較像「自動化的前置檢查」，而不是把最終責任交給模型。

不能忽略的五個限制

第一，這仍然是 public preview。功能名稱、權限介面、可用方案與行為都可能變，不能把它當成長期穩定的合規承諾。

第二，approval assessment 不等於 approval。Copilot 覺得 PR ready，只有在管理員額外打開權限後，才可能真正提交 approving review。若你的團隊只想先得到判斷、不想讓 AI 的票數進入保護規則，可以只使用 review 與 assessment，不開 auto-approval。

第三，Copilot 不會因為自己按了 approval 就自動取代所有治理流程。GitHub 的設定仍然由 enterprise、organization、repository 管理員控制；而且 approval 是否算入 merge requirements，也有獨立的開關。真正的風險不是某一個按鈕，而是團隊有沒有把「可批准」與「可合併」混為一談。

第四，新的 commit 會讓原本的 Copilot approval 像人類 reviewer 的 approval 一樣被 dismiss。也就是說，PR 在獲得 approval 後如果又推了程式碼，不能把舊的核准視為仍然有效；需要重新要求 Copilot review，取得針對新內容的判斷。

第五，模型能看懂程式碼，不代表它理解完整產品風險。權限設計、資料外洩、商業規則、災難復原、效能預算與使用者體驗，往往不是單靠 diff 就能判斷。即使把 file paths 限制在低風險目錄，也仍應保留人類對高風險變更的最後責任。

與傳統人工審查怎麼比較？

人工 reviewer 的優勢是能理解上下文、問反問題，並對不在程式碼裡的風險做判斷；代價是等待時間與審查品質可能因人而異。Copilot code review 的優勢是反應快、可重複，對格式、常見錯誤與局部邏輯有一致的檢查節奏；弱點是容易把「看起來合理」誤當成「符合產品意圖」，也可能漏掉跨服務、資料生命週期或實際營運上的問題。

因此比較好的分工是：Copilot 負責先讀 diff、列出問題、形成 assessment；人類 reviewer 負責決定變更是否真的符合設計、風險是否可接受，以及這次 approval 是否應該進入 merge gate。若把它直接設定成所有 PR 的自動通行證，得到的可能不是更快的交付，而是更快地把錯誤推進主分支。

我會怎麼開始導入？

先挑一個有完整測試、低風險、變更邊界清楚的 repository。第一階段只開自動 review 與 assessment，不讓 Copilot approval 算入 required approvals；觀察兩週它抓到的問題類型、誤報率、AI credits 與 reviewer 是否真的省下時間。第二階段再把 auto-approval 限制在文件、測試或明確 glob 的路徑，並保留新 commit 重新 review 的規則。最後才評估某些低風險 PR 是否適合讓 approval 進入 merge requirements。

這個功能真正值得注意的地方，不是 AI 突然變成了團隊主管，而是 code review 正在被拆成更細的權限與判斷層。你可以採用它的速度，不必一次把最終責任也交出去。

官方資料：