AI 程式碼審查（code review）的下一步，是把一部分修正接進 PR 流程，同時讓團隊控制代理（agent）讀哪些規則、看哪些檔案、跑在哪種執行器（runner）、最後由誰負責合併。
５ 月 １９ 日，GitHub 更新 Copilot 程式碼審查回饋（code review feedback）流程：原本的 Implement suggestion 改名為 Fix with Copilot，並加入對話框（dialog）讓使用者控制如何套用修正。Pull Request Overview 裡的 Implement all suggestions 也改成 Fix batch with Copilot，可批次選擇多個審查意見（comments）交給 Copilot 雲端代理（cloud agent）。
６ 月 １２ 日，GitHub 補上企業控管：組織層 runner 控制（organization runner controls）、內容排除（content exclusion）支援，以及移除 custom instructions 的 4000 字元讀取限制。６ 月 １８ 日又新增 repository root AGENTS.md 支援；如果 repo 已經有 AGENTS.md，Copilot code review 會自動使用其中相關指令來產生審查回饋。
這篇更新後的重點，是把 Copilot code review 當成可治理的審查代理（review agent）：先定義指令、資料邊界、執行環境與人工審核責任，再決定哪些審查意見可以交給 Fix batch。
判斷依據是 GitHub 2026-05-19、2026-06-12 與 2026-06-18 變更公告（changelog），以及 GitHub Copilot / Actions 既有文件脈絡。這次沒有實測企業組織後台，因此不把 runner 政策（runner policy）、內容排除、billing 或每個帳號的 UI 可用性寫成保證；實際可用性仍要看 Copilot plan、organization policy 與管理員權限。
2026-06 更新：指令、資料邊界與執行環境補齊
６ 月的連續更新，讓 Copilot code review 更接近可納入工程治理的代理。對團隊來說，按鈕變方便只是表層變化；真正要追的是審查代理的規則來源與可見上下文能不能分層管理。
| 更新 | 改了什麼 | 對團隊的意義 |
|---|---|---|
AGENTS.md support | Copilot code review 會讀取 repository root 的 AGENTS.md，並使用相關指令產生 review feedback | 可把 repo 慣例、review 風格與高風險檢查寫在單一根目錄文件，讓 feedback 更貼近專案脈絡 |
| Organization runner controls | organization admin 可設定 Copilot code review 預設 runner，並鎖定讓 organization 設定覆蓋 repository 設定 | 不必每個 repo 各自設定 runner，適合大型組織統一治理 |
| Content exclusion support | Copilot code review 會遵守 repository、organization、enterprise 層級的 Copilot content exclusion | 可用 path-based rules 排除機密、產生檔、供應商程式碼或不該進入 review context 的目錄 |
| Custom instructions limit removed | .github/copilot-instructions.md 與 .github/*.instructions.md 不再因 4000 字元限制停止讀取 | 可放更完整的 review 規則，但仍要保持可執行、可測試、可維護 |
６ 月 １８ 日的 UI 更新比較小，但會改變日常習慣：草稿 PR（draft pull request）的審查者選單（reviewer picker）會在 Copilot 旁顯示 Request 按鈕，讓團隊在 PR 還沒正式打開前就請 Copilot 做第一輪 review；Conversation timeline 裡部分 Copilot review events 也會收合，降低噪音。這些都是便利性改善，不會取代 branch protection、required reviewer 或 CI 證據。
Copilot code review 的代理式架構（agentic architecture）建立在 GitHub Actions 上。預設會跑在標準 GitHub-hosted runner；團隊也可以設定自管 runner（self-hosted runner）或 large runner。新更新讓 runner 類型可以在組織層設定，而且同一組設定在同時啟用時會套用到 Copilot code review 與 Copilot cloud agent。
這點對企業很重要。以前 code review agent 看起來像 PR 裡的一個功能；現在它實際上會啟動執行環境、讀取 repo context、依照指令分析與產生建議。治理它，不能只靠「請 reviewer 小心」。
Fix with Copilot 改了什麼？
過去按 Implement suggestion 會產生一則 comment，標記 @Copilot，由 Copilot 開新 PR 修正。
新流程多了一個 handoff dialog，使用者可以先設定：
| 選項 | 用途 |
|---|---|
| Apply directly to pull request | 直接在目前 PR 套用變更 |
| Open a new pull request targeting branch | 另開 PR 指向目前 branch |
| Select model | 選擇要用哪個模型實作 |
| Additional instructions | 補充修正方向與限制 |
這比原本更適合正式開發流程，因為 reviewer 或作者可以決定修正要進同一個 PR，還是另開一個隔離 PR。
Fix batch with Copilot 適合做什麼？
Fix batch 的重點是一次選多個 Copilot review comments，交給 cloud agent 批次處理。
適合的情境：
- 多個命名風格問題。
- 重複型別錯誤。
- 多處 lint 建議。
- 小型重構，例如抽 helper。
- 測試檔缺少相同 setup。
- 文件註解需要同步更新。
不適合的情境：
- 架構方向有爭議。
- 安全修正需要 threat modeling。
- 修改跨多個服務邊界。
- 涉及資料庫 schema 或 migration。
- Review comment 本身需要產品決策。
Reviewer 要怎麼看待 agent 修正？
Copilot cloud agent 產出的修正仍然是程式碼變更，不能當成保證正確的答案。
Reviewer 應該檢查：
- 是否只處理選定 comments。
- 是否改到不相關檔案。
- 是否加入新 dependency。
- 是否刪除重要測試。
- 是否讓測試只是表面通過。
- 是否符合團隊 style。
- 是否需要額外 regression test。
Agent 可以節省手動改小問題的時間，但不能取代 review responsibility。
若團隊還沒有自己的 AI PR 檢查清單，應先建立基本 review discipline。可搭配站內的 AI 產生的 PR 怎麼 Review？２０２６ 年工程團隊必備檢查清單 與 AI Coding Agent 工作流實戰：從 Issue 到 PR 的 ６ 步驟，先把任務邊界、測試證據、權限與 rollback 條件定清楚，再開放 Fix batch。
AGENTS.md 要寫什麼，才不會讓 review 變吵？
AGENTS.md 的價值在於讓 review feedback 先對齊 repo 的真實慣例；它不適合承載整份工程手冊。GitHub 這次公告只確認 Copilot code review 會讀取 root AGENTS.md 並使用相關指令；因此團隊應把它當成「review 起點」，不要把它寫成可以繞過安全、測試或人工審核的授權書。
比較實用的寫法，是把規則分成四層：
| 規則層 | 建議寫在 AGENTS.md 的內容 | 避免寫法 |
|---|---|---|
| 專案慣例 | 主要語言、測試命令、重要目錄、常見命名規則 | 把整份 onboarding 文件原封不動貼上 |
| 高風險檢查 | authentication、input validation、migration、API backward compatibility 要優先看 | 只寫「注意安全」這類無法執行的抽象要求 |
| 自動修正邊界 | 哪些 comments 可交給 Fix batch，哪些需要真人判斷 | 允許 agent 修改資料庫、權限或部署設定卻沒有額外 review |
| 驗證證據 | 修正後要附上測試、lint、截圖或手動驗證摘要 | 只要求「讓 CI 綠」而不說明要驗證什麼 |
AGENTS.md、Copilot instructions 和 content exclusion 應該分工，不要互相取代：
| 控制項 | 最適合放什麼 | 檢查問題 |
|---|---|---|
AGENTS.md | repo 層級慣例、review 風險、測試與修正邊界 | Reviewer 看這份文件，是否能理解 Copilot 為什麼提出某個 comment？ |
.github/copilot-instructions.md / .github/*.instructions.md | 更細的 Copilot 行為規則、檔案類型或任務指令 | 規則是否具體到 agent 可判斷，而不是口號？ |
| Content exclusion | 不該進入 Copilot context 的路徑 | 排除後，agent 是否仍保留足夠 domain code、tests 與 schema 來判斷行為？ |
| Runner controls | Copilot code review 實際執行環境 | Runner 是否能碰到過多 secrets、內網資源或部署權限？ |
這張分工表可以直接變成導入會議的檢查清單：先檢查 AGENTS.md 是否可讀、可維護，再檢查 content exclusion 是否保護敏感資料，最後才開放 Fix batch 處理低風險 comments。
Content exclusion 要怎麼用才有意義？
Content exclusion 應用來定義 AI review agent 的資料邊界：哪些內容可以進 review context，哪些內容必須排除。
建議先排除四類內容：
| 類型 | 例子 | 為什麼排除 |
|---|---|---|
| 機密與合規資料 | secrets 範例、客戶資料 fixture、內部合約、資安 playbook | 即使只是 review context，也不該被 agent 讀取 |
| 產生檔 | build output、lockfile 大量區塊、generated clients | 會污染 context，讓 review focus 偏掉 |
| 第三方 vendor code | vendored library、外部 SDK mirror | 團隊通常不希望 agent 對不可維護程式碼給修正建議 |
| 高風險基礎設施 | production Terraform、Kubernetes secrets template、部署腳本 | 可以讓人 review，但不一定要讓 AI agent 自動分析或修正 |
這裡要避免兩個極端。
第一個極端是完全不設 exclusion，讓 Copilot code review 看整個 repo。這在小型開源專案可能還行，但在企業 monorepo 裡風險太高。
第二個極端是排除太多，讓 agent 只看到局部 diff，結果無法判斷跨檔案行為。比較好的做法是：把機密和無關內容排掉，保留足以理解程式行為的 domain code、tests、API schema 與 README。
Runner controls 應該怎麼選？
Copilot code review 既然跑在 GitHub Actions 架構上，runner 牽涉效能、網路、權限、成本與稽核。
| 團隊狀況 | 建議 runner 策略 |
|---|---|
| 小型團隊、一般 SaaS 專案 | 先用 GitHub-hosted runner，搭配 branch protection 與 required review |
| 大型 monorepo、review context 很重 | 考慮 large runner，避免 review agent 因資源不足變慢或失敗 |
| 金融、醫療、政府、內部網路依賴 | 優先評估 self-hosted runner，但要限制網路與 secrets 權限 |
| 多個 repo 共用政策 | 在 organization level 設定預設 runner 並鎖定，避免 repo 各自放寬 |
如果同時使用 GitHub Actions 失敗可用 Copilot cloud agent 一鍵修，runner policy 更要一致。否則 code review agent 和 CI 修復 agent 可能跑在不同環境，權限邊界也不一致。
模型選擇也要一起治理。若團隊已經在用 GitHub Copilot Model Rules，應把程式碼審查、雲端代理、CLI 與 IDE 裡可用的模型策略對齊；低風險批次修正可以參考 GitHub Copilot cloud agent 新增低成本模型 的任務分級，不要把所有 review comment 都丟給最貴模型。
建議工作流程
小型 PR
小型 PR 可直接使用 Fix with Copilot 套用到目前 PR，但仍要重新跑 CI 並由作者確認 diff。
中型 PR
中型 PR 若 comments 多，先用 Fix batch 處理低風險項目，再把設計問題留給真人討論。
大型 PR
大型 PR 不建議一次 batch 全部 comments。應該分批：
- 先處理 lint、格式、命名。
- 再處理測試與文件。
- 最後由真人處理架構與行為變更。
和 Actions 一鍵修有什麼差別？
| 功能 | 起點 | 適合任務 |
|---|---|---|
| Fix with Copilot | Code review comment | 修 reviewer 指出的局部問題 |
| Fix batch with Copilot | 多個 review comments | 批次處理低風險 feedback |
| Actions Fix with Copilot | CI logs | 修測試、lint、workflow 失敗 |
三者會把 Copilot cloud agent 帶進不同開發節點：review、PR、CI。
企業管理注意事項
若公司打算開放 Fix batch、AGENTS.md 指令與 organization-level runner 設定，建議搭配：
- Branch protection。
- Required reviewer。
- 禁止 agent 直接 merge。
- model policies。
- sensitive repo 限制。
- audit log 保存。
- CI 必跑。
- content exclusion rules。
- runner type lock。
- custom instructions version control。
AGENTS.mdowner 與 PR review 流程。
特別是 model selection、runner 與 content exclusion。若團隊能在 dialog 裡選模型，管理員要確保可選模型符合公司政策與資料駐留需求；若團隊能讓 Copilot code review 跑在不同 runner，也要確保 runner 不會讀到不該暴露的 secrets 或內網資源。
AGENTS.md 與 custom instructions 也不能放著自然長大。4000 字元限制移除後，團隊很容易把整份工程手冊塞進 .github/copilot-instructions.md，或把根目錄 AGENTS.md 變成沒有人維護的政策堆疊。更好的做法是把 instructions 寫成 review agent 可執行的規則，例如：
- 優先檢查 auth、input validation、資料庫 migration 與 API backward compatibility。
- 對安全問題只提出風險與建議，不自動套用修正。
- 所有 batch fix 必須附上測試證據。
- 不修改 content exclusion 排除的路徑。
- 不新增 dependency，除非 review comment 明確要求。
這些規則比「請寫出高品質、安全、可維護的程式碼」更有用，因為 agent 可以依照它們做具體判斷。
導入前的 30 分鐘試點檢查
正式開放 Fix batch 前，先用一個低風險 repository 做小型試點，比直接把功能丟給整個 organization 更安全。
| 檢查項 | 建議做法 | 不要做的事 |
|---|---|---|
| 試點範圍 | 選一個測試完整、資料敏感度低、PR 量穩定的 repo | 一開始就套到 monorepo 或 production infra repo |
| Runner | 先確認 GitHub-hosted、large runner 或 self-hosted runner 的權限、網路與 secrets 暴露面 | 只為了加速 review 就讓 agent 跑在能碰內網與部署憑證的 runner |
| Content exclusion | 把 secrets 範例、客戶資料 fixture、產生檔與 vendor code 先排除，再觀察 review 品質 | 用 exclusion 隨手排掉整個 domain code，讓 agent 只剩 diff 可看 |
| Instructions | 把 .github/copilot-instructions.md 寫成可執行規則，並要求 PR review | 把整份工程手冊貼進 instructions，卻沒有優先順序與衝突處理 |
| Model policy | 和 GitHub Copilot Model Rules 對齊，區分低風險修正與高風險分析 | 讓 reviewer 在 dialog 裡任意選模型，卻沒有成本與資料政策 |
| Review responsibility | 規定 agent 只能提交修正初稿，作者與 reviewer 仍要看 diff、測試與風險 | 把 Fix batch 視為通過 review 的替代品 |
如果團隊想把這類 agent 從 PR review 擴大到 issue triage、CI 失敗分析或文件維運，就應該另外評估 GitHub Agentic Workflows；那是 repo 事件與 Actions pipeline 層級的自動化，不應和 PR 裡的 batch fix 混在同一組權限討論。
採用判斷：先定 agent 邊界，再開 Fix batch
Fix with Copilot 與 Fix batch with Copilot 讓 AI 程式碼審查更接近完整開發循環：發現問題、委派修正、重新 review。６ 月的企業控管與 AGENTS.md 更新，補上更關鍵的前置條件：管理員能控制 agent 的執行環境、可見資料與可遵循的 repo 規則。
它的最佳定位，是把大量重複、清楚、低風險的 review feedback 交給 agent 做初稿；AI 不替團隊承擔品質責任，真正需要工程判斷的地方仍然要由作者與 reviewer 決定。
用得好，它能減少 PR 來回；用得太放，會把 review 變成 rubber stamp。採用前要先定清楚：哪些 comments 可以交給 agent、哪些檔案不能進 context、runner 能碰到什麼資源、最後誰對 merge 負責。
成熟度可以用一句話判斷：如果團隊無法清楚回答 Copilot code review 看得到什麼、跑在哪裡、能改什麼、誰審核它，就還不該把 Fix batch 當成預設工作流。
FAQ
AGENTS.md 會取代 .github/copilot-instructions.md 嗎？
不建議把它當成單純取代。GitHub 2026-06-18 公告確認 Copilot code review 會讀取 repository root 的 AGENTS.md 並使用相關指令；實務上可把 AGENTS.md 放 repo-wide 慣例與風險邊界，把 .github/copilot-instructions.md 或 .github/*.instructions.md 用於更細的 Copilot 行為規則。兩者都應該經過 PR review，避免規則彼此矛盾。
Copilot code review 的 content exclusion 會讓 review 變差嗎？
可能會，所以不要把所有上下文都排掉。content exclusion 應該排除機密、產生檔、vendor code 與高風險基礎設施內容，同時保留足以理解行為的 domain code、tests、schema 與文件。目標是降低不必要風險，同時保留 agent 能判斷行為的必要上下文。
organization runner controls 適合小團隊使用嗎？
小團隊通常可以先用預設 GitHub-hosted runner。organization runner controls 對多 repo、大型 monorepo、受監管產業、需要 self-hosted runner 或 large runner 的團隊更有價值。若公司已經有統一 Actions runner policy，就應該把 Copilot code review 一起納入。
custom instructions 字元限制移除後，應該放越多規則越好嗎？
不建議。instructions 應該寫成 agent 可執行的 review 規則，例如哪些風險優先、哪些檔案不能改、什麼情況必須要求真人判斷。太長、太抽象、彼此矛盾的規則會讓 review 品質下降。
Fix batch with Copilot 可以取代真人 reviewer 嗎？
不可以。Fix batch 適合處理低風險、重複、可測的 feedback，例如 lint、命名、測試 setup、文件同步。架構、安全、資料模型、產品行為和 migration 仍然需要真人 reviewer 決策。