GitHub Copilot Code Review 可以在 pull request 中找問題並提出可套用的修正。開啟 PR 後，在右側 Reviewers 找到 Copilot 並按 Request；它會留下 Comment 類型的 review，不算 required approval，也不會自行阻止合併。發現可修正的問題時，可用 Fix with Copilot 把意見交給 Copilot cloud agent。
團隊導入前要先管好三件事：Copilot 讀取哪些指令與程式碼、review 在哪個 runner 和網路環境執行、修正完成後由誰驗證。官方也明確提醒 Copilot 可能遺漏問題或做出錯誤判斷，人工 review 仍是必要步驟。
Copilot Code Review 怎麼用？
- 在 GitHub.com 建立或開啟 pull request。
- 在右側
Reviewers區塊找到 Copilot，按下Request。 - 等待 review 完成，逐則檢查問題、嚴重度、檔案位置與建議修正。
- 可直接套用明確的 suggested change；需要代理修改時，按
Fix with Copilot。 - 選擇讓 cloud agent 直接提交目前 PR，或另開一個以目前分支為目標的 PR。
- 檢查完整 diff、執行測試，再請真人 reviewer 決定是否合併。
也能從 GitHub CLI 請求 review：建立 PR 時使用 gh pr create --reviewer @copilot，既有 PR 可用 gh pr edit PR-NUMBER --add-reviewer @copilot。在 Copilot CLI 內，/review 可先檢查本機尚未提交的變更；這和 GitHub.com 上針對 PR 的 review 是不同時點。
Copilot 預設只 review 一次。後續 push 若要自動重審，必須在 ruleset 的 automatic code review 設定勾選 Review new pushes；否則要在 reviewer 選單手動要求 re-review。官方也提醒，重審可能重複先前已解決的 comment。
Fix with Copilot 適合修哪些問題？
適合交給 cloud agent 的項目具有三個特徵：範圍清楚、風險低、能用測試或靜態檢查驗證。例如命名不一致、缺少 null check、重複的型別錯誤、lint 問題、測試 setup 或文件與程式碼不同步。
架構選擇、authentication、授權規則、資料庫 migration、付款邏輯和跨服務契約，應由工程師先決定方向。即使 Copilot 的 comment 正確，自動修正也可能擴大修改範圍、移除測試或用另一種方式掩蓋失敗。
每次 Fix 完成後至少核對：
- 修改是否只涵蓋指定 comment，是否碰到無關檔案。
- 有沒有新增 dependency、改動設定或放寬權限。
- 測試是否真的覆蓋錯誤情境，而非只讓現有 CI 轉綠。
- API、schema、migration 與相容性有沒有改變。
- agent 執行紀錄、測試結果與剩餘風險是否足夠讓 reviewer 判斷。
團隊可直接搭配 AI 產生的 PR Review 檢查清單；若任務從 issue 一路委派到 PR，再參考 AI Coding Agent 從 Issue 到 PR 的流程。
AGENTS.md 與 Copilot instructions 怎麼分工？
截至 2026 年 7 月，Copilot Code Review 會從 PR 的 head branch 讀取自訂指令。這讓你能在 feature branch 修改規則，並在合併前觀察同一個 PR 的 review 結果；也代表惡意或錯誤的指令可能隨程式碼變更進入 review context，規則檔本身必須納入 CODEOWNERS 或人工審查。
| 檔案 | 適合放的規則 |
|---|---|
.github/copilot-instructions.md | 全 repo、專門給 Copilot 的固定規則 |
.github/instructions/**/*.instructions.md | 依路徑或檔案類型套用的 Copilot 規則 |
根目錄 AGENTS.md | 希望不同 AI agent 共用的 repo 慣例與邊界 |
REVIEW.md、GEMINI.md、CLAUDE.md | 團隊既有的 review 或模型指令，Copilot review 現在也會讀取 |
.github/skills/... | 需要時才啟動的特定 review 工作流 |
AGENTS.md 可寫主要測試命令、重要目錄、API 相容性要求與高風險區域。規則要能檢查，例如「變更公開 API 時，確認舊欄位仍可解析並新增 backward compatibility test」；「注意安全、保持高品質」沒有具體驗收方式，幫助有限。
Copilot Code Review 目前也能在 public preview 使用 repository-level agent skills 和 MCP servers。MCP 可補入 issue、incident、文件或 service catalog 的 context；GitHub MCP 與 Playwright MCP 預設啟用。開啟第三方 MCP 前，先確認可呼叫的 tools、憑證範圍與 session logs，避免 review 為了補背景而取得過多資料。
自動 Review 與 Medium effort 怎麼設定？
Repository owner 可在 Settings → Rules → Rulesets 建立 branch ruleset，開啟 Automatically request Copilot code review。可另外選擇 review 每次新 push、以及 draft PR。組織也能建立套用多個 repository 的規則。
Review effort 目前有 Low 與 Medium。Low 是預設的一般 review；Medium 屬 public preview，會做更深的複雜邏輯、安全敏感與跨服務分析，也會耗用更多 Actions minutes 和 AI credits。不要讓所有小型 PR 一律使用 Medium，先把它用在 authentication、資料流、跨服務契約或較大重構，再比較新增 findings 是否值得成本。
建立一組 10 至 20 個已知問題的測試 PR，比較 Low、Medium 與真人 review。記錄真正有用的 finding、誤報、漏報、等待時間與成本；只看 Copilot 留了多少 comments，會鼓勵噪音而非品質。
Runner、setup 與防火牆怎麼管？
Copilot Code Review 的 agentic context gathering 由 GitHub Actions 執行。預設使用標準 GitHub-hosted runner，也可選 large 或 self-hosted runner；2026 年 7 月更新後，Code Review 的 runner 設定能和 Copilot cloud agent 分開管理。
需要安裝依賴或準備工具時，在 .github/workflows/copilot-code-review.yml 設定 review 專用 setup。若這個檔案不存在，系統才會回退使用既有的 copilot-setup-steps.yml。setup 只準備 review 需要的環境，避免在其中部署、修改外部資料或取得 production secrets。
Copilot Code Review 現在預設在防火牆後執行，網路存取可由 repository 或 organization 設定，並與 cloud agent 分開控制。Self-hosted runner 不應因為「在內網」就自動取得廣泛權限；限制出站網路、secrets、雲端角色與可寫資源，並檢查 setup workflow 的變更者。
Content exclusion 可在 repository、organization 或 enterprise 層用 path rules 排除不該進入 Copilot context 的內容。適合排除客戶資料 fixture、內部合約、產生檔與 vendor code；不要把理解行為必需的 schema、domain code 和 tests 全部排掉，否則 review 只能看到局部 diff。
Copilot Code Review 怎麼計費？
官方文件把成本分成兩部分：模型互動使用 GitHub AI credits，agentic context gathering 與 tool use 消耗 GitHub Actions minutes。Medium effort 會使用更多資源；large 或 self-hosted runner 也有各自的執行成本。
試點時記錄每個 repository 的 PR 數、平均 review 次數、effort level、Actions minutes、AI credits 與有效 findings。若同一 PR 每次 push 都自動 review，成本會隨 push 次數放大。管理員應設定 budgets 與通知，並區分「自動 review 找問題」和「Fix with Copilot 實作」兩段成本。
如果團隊也用 Actions Fix with Copilot，要分清楚觸發點：Code Review 從 PR diff 找問題，Actions Fix 從失敗的 CI log 修問題。兩者都可能叫用 cloud agent，但驗收證據不同。
導入前檢查清單
- 選一個測試完整、資料敏感度低的 repository 試點。
- 讓
AGENTS.md、Copilot instructions、skills 和 setup workflow 都需要 review。 - 限制 runner 的 secrets、網路與寫入權限，確認防火牆規則。
- 設定 content exclusion，同時保留判斷行為所需的程式碼與測試。
- 先只自動 review draft PR 或特定分支，觀察重複 comment 與成本。
- 把 Fix with Copilot 限定在低風險、可測的意見。
- 規定 Copilot review 不算 required approval，合併仍需真人負責。
- 每月檢查有效 finding、誤報、漏報、Actions minutes 與 AI credits。
若團隊要把代理擴大到 issue triage、文件或其他 repository 事件，可另外評估 GitHub Agentic Workflows；它的事件、token 與權限邊界和 PR review 不同。
FAQ
GitHub Copilot Code Review 會自動核准 PR 嗎？
不會。Copilot 留下的是 Comment review，不是 Approve 或 Request changes；它不算 required approval，也不會單靠 review 阻止合併。Branch ruleset、CI 與真人 reviewer 仍要照團隊政策執行。
Fix with Copilot 會直接改目前 PR 嗎？
你可以選擇讓 Copilot cloud agent 直接提交目前 PR，或另開一個以目前分支為目標的 PR。兩種方式都要檢查完整 diff、測試與權限變更。
Copilot Code Review 會讀哪個分支的 AGENTS.md？
目前會讀 PR 的 head branch，也就是含本次變更的來源分支。這方便在合併前測試指令，也要求團隊審查規則檔變更，避免 PR 自行放寬 review 標準。
Copilot Code Review 為什麼還會消耗 Actions minutes？
模型 review 使用 AI credits；搜尋 repository context、執行 setup 與其他 agentic 工具會在 GitHub Actions 架構上運作，因此同時消耗 Actions minutes。
Medium review effort 值得開嗎？
複雜邏輯、安全敏感與跨服務變更值得先試 Medium；小型格式或文件 PR 通常用 Low 即可。用一組已知問題的測試 PR 比較 finding、誤報與成本，再決定哪些 repository 或路徑採用。
參考來源
- GitHub Docs：About GitHub Copilot code review（查閱日期：2026-08-12）
- GitHub Docs：Using GitHub Copilot code review on GitHub（查閱日期：2026-08-12）
- GitHub Docs：Configuring automatic code review（查閱日期：2026-08-12）
- GitHub Changelog：Customization and configurability improvements（發布日期：2026-07-17）
- GitHub Changelog：Analysis depth and efficiency updates（發布日期：2026-06-25）
- GitHub Changelog：New configurations and controls（發布日期：2026-06-12）
- GitHub Changelog：Updates to Copilot billing and plans（發布日期：2026-06-01）