---
title: "審查輸出"
description: "說明如何審查 Copilot cloud agent 的 pull request、diff、Actions、merge conflicts 和 follow-up comments。"
verifiedAt: "2026-05-06"
---

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

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

## 1. Review 的基本順序

建議順序：

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

```mermaid
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 結論，只是質量訊號。

<details>
<summary>深讀：為什麼 Actions 預設不自動執行是合理的</summary>

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

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

## 本章自檢

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

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

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

## 官方來源

- [Review output from Copilot](https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/review-copilot-output) —— 官方審查輸出頁，覆蓋 PR review、`@copilot`、merge conflicts、Actions 和反饋。
- [Troubleshooting GitHub Copilot cloud agent](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/troubleshoot-cloud-agent) —— 官方排障頁，覆蓋 session logs、write access 和 stuck session。
- [Responsible use of GitHub Copilot cloud agent](https://docs.github.com/en/copilot/responsible-use/copilot-cloud-agent) —— 官方 responsible use 頁面。

## 接下來去哪

<Cards>
  <Card title="Copilot CLI" description="如果要把 cloud session 帶回本地，繼續學習 Copilot CLI。" href="/zh-Hant/docs/github-copilot/official/05-copilot-cli" />
  <Card title="安全、治理與計費" description="繼續學習 access policies、usage、billing 和 content exclusion。" href="/zh-Hant/docs/github-copilot/official/08-security-governance" />
</Cards>
