---
title: "程式碼審查工作流"
description: "用 GitHub Copilot 做 review 預篩、建議修復和風險歸納，同時保留人工 reviewer 的最終責任。"
verifiedAt: "2026-05-06"
---

Copilot code review 的正確位置是**預篩風險和補充 reviewer 視角**。它可以給出評論（comments）和建議改動（suggested changes），但不能替代程式碼 owner 對行為、安全和釋出風險的判斷。

> [!WARNING]
> GitHub 官方頁面提示：從 2026-06-01 開始，Copilot code review runs 會消耗 GitHub Actions minutes。團隊啟用自動 review 前必須確認計費和用量邊界。

## 1. 入口地圖

GitHub 官方文件列出多個入口：GitHub.com、VS Code、JetBrains IDEs、Visual Studio、GitHub CLI、Xcode 和 Mobile。實際團隊裡先統一 2 個入口即可：PR 頁面 review 和本地未提交變更 review。

```mermaid
flowchart TD
    Diff["本地 diff / Pull Request"] --> Entry{"選擇入口"}
    Entry --> Local["IDE: review uncommitted changes"]
    Entry --> PR["GitHub PR: request Copilot reviewer"]
    Entry --> CLI["GitHub CLI / 其他入口"]
    Local --> Comments["Copilot comments"]
    PR --> Comments
    CLI --> Comments
    Comments --> Triage{"人工分流"}
    Triage --> Apply["採納 suggested change"]
    Triage --> Fix["手動修復"]
    Triage --> Dismiss["記錄原因後關閉"]
    Apply --> Rereview["必要時請求 re-review"]
    Fix --> Rereview

    style Comments fill:#dbeafe,stroke:#2563eb,stroke-width:2px
    style Triage fill:#fef3c7,stroke:#d97706,stroke-width:2px
```

## 2. 什麼時候請求 Copilot review

適合：

- PR 已經有明確目標、測試說明和範圍。
- diff 不大，Copilot 能完整看到主要上下文。
- 想在人工 reviewer 之前預篩可讀性、遺漏測試、明顯 bug 和安全問題。
- 本地提交前想快速檢查未提交變更。

暫時不要：

- PR 還在大規模重寫，diff 每幾分鐘都變。
- 需求本身還沒定，review 會變成產品討論。
- 涉及高風險遷移、許可權、支付、安全或資料刪除，卻沒有人工 owner。
- 團隊沒有決定自動 review 的計費和噪聲處理。

## 3. PR 頁面工作流

1. 建立 PR 或開啟現有 PR。
2. 在 Reviewers 選單裡選擇 Copilot。
3. 等待 Copilot 完成 review。
4. 逐條閱讀評論，不直接批次採納。
5. 對每條評論做分流：採納、手動修復、關閉並說明原因。
6. 推送修復後，必要時手動請求 re-review。

GitHub 官方說明，Copilot 不會因為你推送新提交就自動重新 review；需要重新請求。並且 re-review 時可能重複之前已經關閉或點踩的評論，所以團隊 SOP 要保留“重複評論如何處理”的規則。

## 4. 本地未提交變更工作流

本地 review 適合提交前快速攔截明顯問題：

1. 在 Source Control 裡確認 staged / unstaged 範圍。
2. 請求 Copilot review uncommitted changes。
3. 只處理與本次提交有關的評論。
4. 修復後重新跑測試，再提交。

這一步不替代 PR review。它只減少低階問題進入 PR 的機率。

## 5. Repository instructions

Copilot code review 可以讀取儲存庫自定義指令。常見做法是用 `.github/copilot-instructions.md` 放儲存庫級 review 規則，用 `.github/instructions/**/*.instructions.md` 放路徑級規則。

示例：

```md
Review rules:
- Prioritize input validation.
- For migrations, check rollback.
- For UI, check mobile layout.
```

注意兩個邊界：

- Copilot code review 只讀取每個自定義指令檔案前 4,000 個字元。
- PR review 時讀取的是 base branch 裡的指令，不是 feature branch 裡剛改的指令。

## 6. 人工 triage 清單

每條 Copilot 評論都按下面順序判斷：

1. **事實性**：評論引用的程式碼是否存在，路徑和行號是否正確？
2. **可復現**：能否用測試、型別檢查、lint、日誌或手動步驟證明？
3. **風險級別**：是 blocker、should-fix、nit，還是誤報？
4. **修復方式**：用 suggested change、手動改，還是拆新 issue？
5. **迴歸驗證**：修復後跑哪些檢查？

<details>
<summary>深讀：自動 review 的邊界</summary>

自動 review 適合穩定團隊和穩定儲存庫，不適合剛開始試點時直接全倉啟用。先選一個活躍但風險可控的儲存庫，統計一週評論質量、誤報率、reviewer 節省時間和 Actions minutes 消耗，再決定是否擴大。
</details>

## 本章自檢

1. 是否決定了 Copilot review 的入口和觸發條件？
2. 是否有 repository instructions 指定團隊 review 重點？
3. 是否知道 code review runs 的計費影響？
4. 是否對每條評論做人工 triage，而不是直接接受？
5. 是否在修復後重新跑測試並必要時請求 re-review？

透過標準：Copilot 評論能進入 reviewer 佇列，但最終合併判斷仍由人負責。

## 官方來源

- [Using GitHub Copilot code review](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review) —— GitHub 官方 code review 使用說明。
- [GitHub Copilot documentation](https://docs.github.com/en/copilot) —— GitHub 官方 Copilot 文件總入口。

## 接下來去哪

<Cards>
  <Card title="PR 摘要工作流" description="review 前先讓 reviewer 快速進入上下文。" href="/zh-Hant/docs/github-copilot/official/10-practical-playbooks/pr-summary" />
  <Card title="安全治理" description="啟用自動 review 前先看計費、策略和指標。" href="/zh-Hant/docs/github-copilot/official/08-security-governance" />
</Cards>
