AI reviewer 說「Approve」，PR 旁邊亮起綠色勾勾。這一刻很容易讓人誤以為工作少了一份：既然機器看過，required approval 也湊齊了，那就合併吧。
可是程式上線後出事，值班群組裡不會有人問那個勾勾的感想。大家只會追兩件事：當時看過哪些證據，以及誰決定讓這個 commit 進主分支。
GitHub 在 2026 年 9 月讓 Copilot code review 可以實際核准 pull request。每次 review 都會有 approval assessment；真正送出 approval 的功能預設關閉，可由 enterprise、organization 或 repository 層級啟用。啟用後，Copilot 的 approval 還能計入 required approvals。
真正的新風險從它開始影響 merge gate 才出現。挑出問題只是多一個 review signal；改動 gate，會直接改寫誰能把程式送進主分支。
團隊的 PR 流程至少有三層：
| 層次 | 它回答的問題 | 常見證據 |
|---|---|---|
| review signal | 這份 diff 看起來有沒有問題？ | Copilot assessment、人工 review comment、靜態分析結果 |
| merge gate | 系統現在允不允許合併？ | required approvals、required status checks、ruleset 狀態 |
| accountability | 誰理解風險，並決定接受它？ | human owner、決策理由、incident 或變更單連結 |
Copilot approval 可以同時出現在前兩層，但它不會自動補上第三層。
這個差異在小團隊特別容易被忽略。兩位工程師的 repository 原本要求一個 approval，大家心裡知道那代表「另一個人看過」。當 AI 的 approval 也能計票後，同樣是一個綠色勾勾，背後的人際約定卻已經變了。Branch protection 沒壞，壞的是團隊把技術計數器當成責任設計。
我不會先把 Copilot approval 接進所有 repository。比較穩的做法，是讓權限跟證據一起長出來。
先讓 Copilot review，但不讓它送出可計票的 approval。連續觀察一段時間，把 AI assessment 跟人工結論放在一起看：哪些類型的變更常被漏掉？哪些 comment 很吵，卻不影響 merge 決策？
這一段的目的不是算出一個漂亮的「AI 準確率」。真實 PR 的風險分布不均，十個文件修正也抵不過一次錯誤的權限變更。團隊需要知道它在哪些變更上能提供訊號，不能只看整體命中率。
挑一個爆炸半徑小、回滾容易，而且 CI 已經穩定的 repository 試行。即使 Copilot approval 能滿足 required approval，仍保留一位 human owner；沒有 owner、required checks 沒跑完，或 PR 在 review 後又補推，就不合併。
這裡的「低風險」應由團隊自己定義。它可能是內部工具、文件網站或沒有正式資料的 demo service。不要把「檔案很少」直接翻譯成低風險，一行 IAM policy 往往比五百行測試危險。
試行後看具體事件：人工覆核推翻過幾次 AI approval？新 commit 進來後，有沒有沿用舊結論？出現 incident 時，決策紀錄能不能還原當時的 checks、owner 與 SHA？
如果這些問題答不出來，先退回 observe-only。功能已經能開，不代表團隊非得一直開著。
別把所有 PR 都塞進同一條規則。可以先做一張團隊自己的 approval map：
| 變更類型 | AI approval 可否計票 | 必要證據 | 人工邊界 |
|---|---|---|---|
| 文件、註解、測試資料 | 可在試行 repo 計票 | lint、連結檢查或測試 | 指定 owner 可抽查，不省略作者自查 |
| 一般 application code | 視服務風險決定 | unit／integration tests、型別與靜態分析 | 至少一位服務 owner 對合併負責 |
| auth、billing、infra、secrets、migration | 不以 AI approval 取代人工核准 | 專屬測試、部署或回復計畫、必要的安全檢查 | 對應 CODEOWNER 或指定團隊必須簽核 |
這張表不是 Copilot 內建的 path-level 設定，也不是 GitHub 官方 schema。它是團隊用來回答「什麼證據才足以打開 gate」的政策。實作時，可以再把其中一部分映射到 CODEOWNERS、ruleset、required status checks 或內部變更流程。
GitHub 的 CODEOWNERS 能在 PR 修改特定檔案時要求 code owner review；ruleset 也能要求 status checks 通過，或要求最後一次可審查的 push 由另一個人核准。這些機制各自解一小塊問題，沒有一個設定能替團隊承擔全部責任。
GitHub 對 Copilot approval 做了一個很重要的限制：PR 出現新 commit 後，先前的 Copilot approval 會被 dismiss。這項限制很合理，因為 review 的對象是某一版 diff，不是那張永遠不變的 PR 卡片。
團隊流程也該跟著這個邏輯走。任何補推都重新確認：
一般 ruleset 本來就能設定新 commit 後 dismiss stale approvals，也能要求最近一次 push 由另一個人核准。Copilot approval 的新行為只是把一個常被含糊處理的事實攤開：approval 是有版本的。
如果團隊已經讓 AI approval 進入 gate，我建議至少保留這些欄位：
ryanvale
commit_sha: 8d3f2c1
risk_class: high
ai_assessment: approved
required_checks:
- unit-tests: passed
- migration-dry-run: passed
human_owner: team-platform
merge_decision: approved
decision_reason: "rollback tested; schema change reviewed by data owner"
這同樣是團隊自訂的紀錄格式，不是 GitHub API 回傳欄位。它的價值很樸素：三個月後出問題時，不必從一串綠色 icon 猜測當初為什麼敢合併。
紀錄不一定要另建一套系統。PR template、check run summary、deployment ticket 或內部 bot 都可以承載。重點是 commit_sha、證據、owner 與決策理由要能對在一起，而且新 commit 進來後不能沿用舊紀錄。
讓 AI 參與 merge gate 沒有問題。它可以提供 review signal，也可以在明確範圍內替 required approval 計票。風險出在團隊刪掉句子的主詞，只留下「已核准」。
比較完整的句子應該是：某位 owner 根據這個 commit 的 AI assessment、CI 證據與風險分類，決定允許合併。
工具可以畫勾，但團隊仍得寫出是誰允許那個勾打開主分支。
iThome鐵人賽
看影片追技術