審查輸出

GitHub 官方文件明確提醒：Copilot pull request 要像任何貢獻一樣認真 review。PR 摘要只能當導覽，不能替代 diff、測試、workflow 和 reviewer 判斷——把"AI 寫的"當成審查透過的理由，是這一節最常見的錯誤。

閱讀目標：讀完本章，你應該能審查 cloud agent 生成的 PR，並知道何時用 @copilot 請求修改、何時人工接管。

1. Review 的基本順序

建議順序：

看 PR 目標和 Copilot summary。
看 changed files，確認沒有越界檔案。
看 tests、linters 和 workflow 狀態。
特別檢查 .github/workflows/ 變更。
留 review comments 或 @copilot follow-up。
需要時 checkout branch 人工修。
滿足團隊規則後再合併。

flowchart TD
    PR["Copilot PR"] --> Summary["讀 summary"]
    Summary --> Diff["審 changed files"]
    Diff --> Workflows["審 Actions / workflows"]
    Workflows --> Tests["測試和 lint"]
    Tests --> Decision{"可接受?"}
    Decision -->|否| Comment["@copilot 請求修改"]
    Comment --> PR
    Decision -->|人工接管| Push["checkout branch / push commits"]
    Push --> PR
    Decision -->|是| Merge["merge"]

    style Workflows fill:#fef3c7,stroke:#d97706,stroke-width:2px
    style Comment fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Merge fill:#dcfce7,stroke:#16a34a,stroke-width:2px

2. Pull request approval 規則

官方頁面說明，如果儲存庫要求 PR approvals，你自己批准 Copilot PR 不會計入所需 approval 數量；仍需要另一個 reviewer 批准。

這條規則很重要：Copilot 開的 PR 不應繞過團隊保護分支和 review gate。

3. 用 `@copilot` 請求修改

可以在 PR comment 裡 mention @copilot 請求修改。官方文件說明：

預設情況下，Copilot 會直接向當前 PR branch push commits。
如果你希望它建立單獨 PR，要在評論裡明確說明。
Copilot 只響應對儲存庫有 write access 的使用者評論。
當它開始新 session 時，評論會出現 eyes reaction，並在 PR timeline 裡出現 started work event。
同一 PR 的後續 session 會記住之前上下文。

建議把 review comments batch 後再提交，減少來回干擾。

4. GitHub Actions 要謹慎

官方頁面說明，Copilot push changes 後，GitHub Actions workflows 預設不會自動執行。原因是 workflows 可能有特權並訪問 secrets。

你需要先審 PR，確認可以執行 workflow，再點選 Approve and run workflows。尤其要檢查：

.github/workflows/ 是否被修改。
workflow 是否新增 secrets 訪問。
是否新增 deployment、release、cloud 操作。
是否執行來自不可信路徑的指令碼。

也可以配置 cloud agent 自動執行 workflows，但商業專案預設應先人工審。

5. Merge conflicts 和反饋

官方文件說明，遇到 merge conflicts 可以用 Fix with Copilot 按鈕，或用 @copilot 評論請求解決。Copilot 會分析衝突、解決並驗證 build/tests/linter，然後請求你 review。

也可以用 thumbs up / thumbs down 給 Copilot PR 或 comment 反饋。反饋不是 review 結論，只是質量訊號。

深讀：為什麼 Actions 預設不自動執行是合理的

CI/CD workflow 可能接觸 secrets、部署許可權和外部服務。一個 agent 修改 workflow 後直接觸發，風險明顯高於普通程式碼 diff。

所以預設先審再執行，是把自動化的速度放在安全邊界之後。團隊可以放開，但應該基於儲存庫成熟度和許可權模型，而不是為了省一次點選。

本章自檢

完成本章後，用這 4 個問題檢查：

PR changed files 是否只在任務範圍內？
是否檢查了 workflow、secrets、deployment 和 release 相關改動？
是否需要另一個 reviewer 批准？
失敗時是用 @copilot 繼續迭代，還是人工 push 修復？

透過標準：Copilot PR 的合併標準不低於人類 PR。

官方來源

Review output from Copilot —— 官方審查輸出頁，覆蓋 PR review、@copilot、merge conflicts、Actions 和反饋。
Troubleshooting GitHub Copilot cloud agent —— 官方排障頁，覆蓋 session logs、write access 和 stuck session。
Responsible use of GitHub Copilot cloud agent —— 官方 responsible use 頁面。

1. Review 的基本順序

2. Pull request approval 規則

3. 用 `@copilot` 請求修改

4. GitHub Actions 要謹慎

5. Merge conflicts 和反饋

本章自檢

官方來源

接下來去哪

Copilot CLI

安全、治理與計費

本頁目錄