AI 程式碼審查：為 Copilot 審批制定團隊規則

本週，AI 程式碼審查不再只是便利功能。10月28日，GitHub 宣佈 Copilot 現在可以批准拉取請求，而且這項批准會像人工批准一樣，計入所需的批准數目。從技術上説，這只是在設定中切換一個選項；但對團隊而言，這帶出一個根本問題：誰要為實際進入主分支的內容負責？

這個議題一直令我很投入，因為我瞭解兩方面。作為開發人員，我歡迎每一個能幫我避免程式錯誤的提示；作為團隊主管，我也明白審查除了找出錯誤，還能傳播知識、分擔責任，以及維持一致標準。因此，本文不會介紹功能概覽，而會提供指引，協助團隊制定 AI 參與審查的規則，內容包括紅綠燈模型、範例檔案，以及首次團隊會議的七個步驟。

簡而言之

Copilot 現在可以批准並放行拉取請求，而且批准會計入所需數目；不過，這項功能預設為關閉。採用紅綠燈模型是合理的做法：AI 可以自行批准低風險路徑上的變更；其他情況則由 AI 先行審查，再由人員作決定。最大的陷阱不在技術，而在於團隊不加思索地接受 AI 的意見。

本文會介紹

自2026年10月下旬起，Copilot 批准功能和「Max」努力程度代表甚麼
紅綠燈模型如何界定 AI 可以自行批准的範圍
團隊如何透過七個步驟制定 AI 審查協議
如何評估 AI 的意見，而不是盲目接受或置之不理

Copilot AI 程式碼審查有甚麼新變化？

Copilot 程式碼審查功能推出已有一段時間。此前，Agent 會發表評論、建議修改，並在最後的概覽中評估是否認為拉取請求已準備就緒。但這並不屬於分支規則所指的批准。如果儲存庫要求兩項批准，你仍然需要兩位人員批准。

2026年10月28日的變更記錄帶來兩項改變。首先，根據 GitHub 的説法，Copilot 批准功能現已正式開放使用：啟用功能後，Copilot 可以批准拉取請求，而且該批准會計入所需的批准數目。如果有人之後推送新提交，該批准便會失效，並需要重新審查。其次，除了「Lite」和「Balanced」之外，現在還有第三個努力程度選項「Max」（根據變更記錄，目前為公開預覽）。它會使用不同供應商提供的模型，執行多個互相獨立的審查 Agent，再由一個匯總 Agent 整合各方結果。這會花更長時間，亦會消耗更多 AI 點數。

有哪些設定開關

對團隊規則而言，重要的是：批准功能預設為關閉。在企業層級，預設設定是「全面停用」；其下的組織和儲存庫則可以自行決定。儲存庫有兩個獨立開關：一個決定是否允許 Copilot 提交批准審查，另一個則決定這些批准是否計入合併要求。

此外，你可以選擇設定最多 15 個檔案比對模式（glob）。只有當拉取請求中每個變更檔案都符合其中一個模式時，Copilot 的批准才會計入。如果欄位留空，批准便適用於所有檔案。對於希望有節制地使用 AI 的團隊而言，這個欄位是最重要的工具。補充一點背景：我查閲資料時，文件中的設定頁面仍將批准功能列為預覽，並把「Max」標示為「即將推出」。變更記錄的更新時間較新。因此，請快速查看你的組織目前實際提供哪些選項。

為何 AI 程式碼審查是團隊共同決定的事

你可以這樣主張：AI 找出錯誤，就讓它批准，大家都能節省時間。但這種説法並不全面，因為審查同時有多個目的。找出錯誤只是其中之一。

人工審查的作用

審查拉取請求的人會因此瞭解相關程式碼。如果提交者正在放假，其他人仍能在晚上理解事故的來龍去脈。例如，同事也會知道付款邏輯為何現在會再試一次。此外，團隊也會在審查中不斷協商標準：我們如何命名？抽象化到甚麼程度才足夠？要測試甚麼？Google 在其 Engineering Practices 中大致如此描述標準：只要一項變更能改善程式碼的整體健康狀況，即使並不完美，也可以獲批准。這需要結合背景作出判斷。我們究竟想要甚麼功能？它是否符合產品的發展方向？

AI 批准帶來的變化

GitHub 在其負責任使用文件中説得很清楚。Copilot 可能會漏掉問題，尤其是面對大型變更時。它也可能報告不存在的問題。建議的程式碼看起來有效，仍可能有錯或不安全。文件明確建議以 Copilot 補充人工審查，而非取代人工審查。

此外，還有一種稱為「自動化偏誤」的心理效應：人們對自動化評估的依賴程度會超出應有水平，尤其是當它通常都判斷正確時。如果拉取請求頂部寫着「Copilot 認為這項變更已準備就緒」，第二位審查者就會更快地略讀。如果 AI 的批准也計入必要的批准次數，可能就會缺少那位瞭解背景的人。因此，AI 可以在哪些地方批准，應由團隊決定，而不是由某位管理員切換一個開關。

AI 程式碼審查的紅綠燈模型

我不會用「是」或「否」來回答這個問題，而會按風險分級。簡單的紅綠燈模型就足以做到這一點，而且也很適合 GitHub 提供的 glob 欄位。

紅綠燈模型：路徑風險越高，越需要人工審查。

區域	常見路徑	AI 的角色	人工審查者的角色
綠色	文件、README、翻譯檔、註解中的錯字	進行審查，並可自行批准	抽查，例如每星期一次
黃色	一般應用程式程式碼、測試、內部工具	預先審查，批准不計入必要批准次數	至少一位人工審查者批准
紅色	驗證、付款、IAM 和基礎設施、資料庫遷移、CI 工作流程	深入審查（例如「Max」級別），批准不計入必要批准次數	兩位人工審查者，其中至少一位是程式碼擁有者

在 AI 程式碼審查中，綠色區域刻意設得很小，只涵蓋漏掉錯誤的代價低，而且能迅速發現的變更。黃色區域是日常工作：AI 會先修正明顯錯誤，為人工審查節省時間。紅色區域最能受惠於最徹底的 AI 審查，但批准權仍由團隊掌握。

順帶一提，GitHub 的更新日誌建議，在最容易因漏看問題而造成重大損害的地方，使用「Max」級別並配合批准流程。我對此有不同看法：錯誤代價最高的地方，我希望有最徹底的審查，並且由人工簽核。更多運算資源不能取代背景脈絡。

逐步建立團隊對 AI 程式碼審查的共識

以下是我會如何為 AI 程式碼審查制定協議。安排一次約 60 分鐘的團隊會議，並在四週後簡短跟進。你需要一個包含程式碼審查功能的 Copilot 方案（Pro、Pro+、Max、Business 或 Enterprise），以及儲存庫的管理員權限，才能修改設定。

1. 盤點

一起查看最近 20 至 30 個拉取要求。哪些路徑有變更？哪些有過實質討論，哪些只收到一句「LGTM」？這幾乎自然就能讓你初步劃分綠區、黃區和紅區。另外也要檢查目前已啟用哪些設定。很多時候，早已有人開啟自動審查，卻從未討論過這件事。

2. 定義各區域，並以 glob 模式記錄

綠區需要一份檔案模式清單，每行一個，最多 15 個。以下是虛構單車租賃項目的例子：

docs/**
**/*.md
locales/**/*.json
.vscode/extensions.json

文件沒有提供這個欄位的示例，也沒有説明確切語法。因此，請用一個只修改 README 的小型拉取要求，以及另一個同時涉及 TypeScript 檔案的拉取要求來測試這些模式。第二種情況下，Copilot 的核準不得計入合併規則。

3. 以程式碼擁有人保護紅區

紅區可以透過 CODEOWNERS 檔案和分支規則「必須由程式碼擁有人審查」來保護。這樣一來，指定羣組中的人員就必須一律核准這些路徑的變更，無論 AI 怎樣判斷。以下的羣組名稱當然只是示例：

# .github/CODEOWNERS
/src/auth/          @bike-rental/security
/src/payment/       @bike-rental/security
/infra/             @bike-rental/platform
/migrations/        @bike-rental/platform
/.github/           @bike-rental/platform
/AGENTS.md          @bike-rental/platform

4. 謹慎設定開關

到這時才進入設定。在儲存庫的 Copilot 程式碼審查設定中，你會找到自動核准部分。如果你希望 Copilot 可以核准拉取要求，就啟用「允許 Copilot 核准拉取要求」。只有在同時使用步驟 2 的 glob 清單時，才啟用「允許將 Copilot 核准計入合併要求」。至於自動審查，最妥當的做法是使用包含「自動要求 Copilot 進行程式碼審查」規則的分支規則集，因為它適用於所有人，而且不受個人設定影響。

別忘了成本。根據文件，Lite 級別的一次審查約需 0.05 至 1 美元的 AI 點數，Balanced 級別則需 0.25 至 5 美元，這還不包括 Actions 分鐘數。Max 的成本更高。用於紅區或許值得，但每次修正錯字大概就不值得。

5. 告訴 AI 你的標準

進行審查時，Copilot 會讀取儲存庫中的指示檔案，也就是拉取要求的 head 分支中的檔案。核心檔案是 .github/copilot-instructions.md，此外還有 .github/instructions/ 下按路徑指定的檔案，以及根目錄中適用於所有 AI Agent 的 AGENTS.md。寫下你重視哪些審查事項，以及 AI 應忽略哪些內容。如何使用 applyTo 和 excludeAgent 建立按路徑指定的檔案，請參閲按路徑指定的 Copilot 自訂指示：指南。示例：

# .github/copilot-instructions.md

## Review focus
- Check that inputs on all public endpoints are validated.
- Point out missing tests when business logic changes.
- Watch for secrets in code and overly broad IAM permissions.

## Please do not comment on
- Formatting (Prettier handles that in the pipeline).
- Pure matters of taste in variable names.

## Tone
- Write comments in English, short and with a reason.
- Mark optional hints with "Optional:".

由於檔案是從 head 分支讀取，拉取要求可以修改用於審查自身變更的規則。因此，請將 .github/ 和 AGENTS.md 列入紅區。否則，有人可能會為自己的變更量身修改審查規則。

6. 清楚説明人員的審查任務

當 AI 處理繁瑣工作後，人類審查者的重點也會轉變。寫下從現在起你們會檢查甚麼：領域正確性、架構和介面、方便下一位閲讀的程度、系統運作及故障情況。這不會縮短審查時間，但會令審查更有價值。如何撰寫容易讓人接受的評論，請參閲程式碼審查回饋：切中要點的評論。

7. 四週後再作調整

安排一次回顧。三個問題就夠：哪些 AI 提示確實防止了問題？哪些只是噪音？有沒有問題漏過了綠色區域？然後調整 glob 模式和指示。如果想更有系統地處理，評估 AI Agent：以 TypeScript 編寫小型評測提供了一些設計小型、可重複測試的構思。

如何評估 AI 程式碼審查中的評論？

AI 程式碼審查中最棘手的部分，是如何處理這些提示。我經常在討論中看到兩種極端做法：要麼每項建議都只需點兩下便獲接受，要麼所有評論都在未閲讀的情況下標記為「已解決」。兩種做法都不好。第一種情況下，沒有人理解的程式碼會被合併到項目中；第二種情況下，你花錢取得的提示卻沒有人閲讀。

一條簡單的規則很有幫助：每則 AI 評論都要作出以下三種回應之一。你可以接受，但必須先理解並測試；也可以拒絕，並用半句話説明理由，例如「誤報，驗證是在結構描述中進行」；如果不確定提示是否正確，就提出疑問，然後由作者找人協助。拒絕理由極具價值，因為你會在第 7 步利用它們改善指示檔案。

另外，留意一個影響很大的小細節：Copilot 會在概覽中評估拉取請求是否已準備就緒。請人類審查者先自行閲讀，再查看這項評估。這樣可避免他們的判斷受影響，也能減少自動化偏誤發揮作用的空間。

AI 程式碼審查中的常見錯誤

沒有設定 glob 模式，卻讓核准計入。路徑欄位留空，代表 AI 的核準會適用於所有檔案。如果只要求一個核准，程式碼便可能在沒有任何人類審查的情況下進入主分支。

沒有保護指示檔案。如上所述，Copilot 會讀取拉取請求分支中的規則。若沒有為 .github/ 設定程式碼擁有者，這裡就缺少一道防護措施。

沒有徵詢團隊意見。當經理或管理員單方面啟用核准要求，團隊很快就會覺得這代表不信任他們自行進行審查，或是一項削減成本計劃。相反，大家共同商定的紅黃綠燈模式，會獲得支持並持續維護。

不讓初級成員參與審查。審查是新團隊成員最好的學習途徑之一。如果 AI 把所有簡單情況都核准，留給他們的就只有難題。應刻意讓他們繼續審查黃色區域的項目，最好兩人一組。

給予 Agent 過於寬鬆的權限。Copilot 可以把建議交給雲端 Agent，由它自行開啟一個包含修正內容的拉取請求。Copilot 輔助權限：安全設定介紹瞭如何妥善限制這類權限。

我的看法

我認為 AI 程式碼審查確實帶來實際效益，尤其是在黃色區域。明顯錯誤在人工審查前已經排除，人工審查的質素便會提高：少一些吹毛求疵，多一些關於真正重要事項的討論。這是支持在審查中更多使用 AI 的理由，而不是減少人手的理由。

對於會計入所需審批數目的批准，我會更加謹慎。在範圍有限且界定清晰的情況下，這樣做有其道理。除此以外，這就把責任推給一個本身無法承擔責任的系統。夜間發生故障時，輪值工程師不會向 Agent 求助。因此我的建議是：先從一個很小的綠色區域開始，衡量成效、討論情況，只有團隊願意時才擴大範圍。「以人為先」在這裏有非常具體的含義：由人訂立規則，AI 遵從規則。

常見問題

Copilot 可否自行批准合併要求？

可以，只要管理員啟用這項功能。根據 GitHub 在 2026 年 10 月 28 日發布的更新紀錄，Copilot 的審批屆時會計入所需審批數目。此功能預設為關閉，而新增提交會使該審批失效。

AI 程式碼審查會否取代人工審查？

不會。GitHub 亦建議將 Copilot 作為輔助工具。AI 可能會漏掉錯誤，也可能誤報問題。此外，人工審查還有知識分享、建立共同標準等作用，這些並非 AI 可以取代。

Copilot 程式碼審查的費用是多少？

文件列出的 AI 點數大約費用範圍為：「Lite」約 0.05 至 1 美元，「Balanced」約 0.25 至 5 美元，兩者均不包括 Actions 分鐘數。「Max」費用較高。實際數字視乎修改的規模和複雜程度。

我在哪裏為 Copilot 設定審查規則？

整個儲存庫的規則設於 .github/copilot-instructions.md，特定路徑的規則設於 .github/instructions/ 底下的檔案，而適用於所有 AI Agent 的規則則設於 AGENTS.md。

下一步

如要開始使用 AI 程式碼審查，請檢查最重要的儲存庫目前啟用了哪些 Copilot 設定，並在下一次回顧會議中介紹紅黃綠燈模型。建立首個綠色區域，半小時便足夠。我也想知道：你會讓 AI 在你的團隊中批准合併要求嗎？如果會，會限定哪些檔案？歡迎在留言中告訴我。

來源

本文由 AI 協助撰寫。

👉 下一步：更多團隊主管相關內容：我的速查表將重點整理在一張可列印的頁面上。

最初刊登於 sascha-ms.de。更多關於無伺服器技術、日常開發中的 AI，以及科技團隊領導的文章：sascha-ms.de/en