官方教程中文版實戰工作流
實戰工作流
把 GitHub Copilot 的官方能力落成 TDD、程式碼審查、PR 摘要和團隊上線的可複用劇本。
這一組不是功能清單，而是把 Copilot 放進真實工程流程的操作劇本（playbook）。判斷標準很簡單：第二個開發者照著做，能得到同樣的輸入、檢查點和退出條件——能復現，才是工作流；只能講故事，是 demo。
1. 本組定位
flowchart TD
Need["真實工程任務"] --> Pick{"先選劇本"}
Pick --> TDD["TDD: 測試先行"]
Pick --> Review["Code Review: 風險審查"]
Pick --> Summary["PR Summary: 上下文壓縮"]
Pick --> Rollout["Rollout: 團隊上線"]
TDD --> Gate["測試 / diff / 人工確認"]
Review --> Gate
Summary --> Gate
Rollout --> Governance["許可權 / 內容排除 / 計費 / 指標"]
Gate --> SOP["沉澱團隊 SOP"]
Governance --> SOP
style Pick fill:#dbeafe,stroke:#2563eb,stroke-width:2px
style Gate fill:#fef3c7,stroke:#d97706,stroke-width:2px
style SOP fill:#dcfce7,stroke:#16a34a,stroke-width:2px2. 本組頁面
TDD 工作流
用 Red / Green / Refactor 三段迴圈約束 Copilot，先寫失敗測試，再做最小實現。
程式碼審查工作流
把 Copilot review 變成風險預篩，而不是讓它替代 reviewer。
PR 摘要工作流
讓 Copilot 生成摘要草稿，再由作者補齊背景、風險、測試和回復。
團隊上線清單
從目標、試點、策略、內容排除、計費、指標到回復，完成組織級 rollout。
3. 先選哪一篇
個人開發者先讀 TDD 和 PR 摘要。它們改動小、反饋快，能立刻看出 Copilot 是否真正改善工作流。
團隊負責人先讀程式碼審查和團隊上線。它們決定 Copilot 能否進入 reviewer、儲存庫策略、計費和指標體系。
已經有治理壓力的組織先回到 安全、治理與計費，再讀本組。沒有內容排除、訪問策略和計費檢視時，劇本越多，風險越難解釋。
4. 劇本寫法
每一條 Copilot 劇本都要寫清 4 件事：
- 輸入：issue、需求、測試檔案、diff、PR、儲存庫規則或組織目標。
- Copilot 動作：生成測試、解釋 diff、審查風險、生成摘要、建議 rollout 指標。
- 人工檢查：測試是否失敗在正確原因、review 是否可復現、摘要是否覆蓋風險、策略是否符合組織邊界。
- 退出條件：測試透過、review 關閉、PR 描述完成、試點指標達標或回復。
深讀：為什麼這裡不用表格
教程站會在手機、平板、窄屏文件欄和桌面寬屏之間切換。劇本內容經常包含長連結、命令、檔案路徑和中文長句，表格在移動端容易產生橫向滾動。
這一組統一使用卡片、編號清單、摺疊說明和 Mermaid 圖，保證移動端也能讀。
本組自檢
- 是否每篇都有清楚的輸入、動作、人工檢查和退出條件？
- 是否避免把 Copilot 的自然語言輸出當最終事實？
- 是否能從失敗樣例反推應該修改 prompt、測試、規則還是許可權？
- 是否有團隊 SOP、儲存庫說明或管理員策略承接這些經驗？
透過標準：Copilot 不只是“能回答”，而是進入了可複用、可驗證、可回復的工程流程。
官方來源
- GitHub Copilot documentation —— GitHub 官方 Copilot 文件總入口。
- GitHub Copilot in VS Code —— VS Code 官方 Copilot 入口。
- Set up a test-driven development flow in VS Code —— VS Code 官方 TDD 指南。
- Achieving your company's engineering goals with GitHub Copilot —— GitHub 官方組織 rollout 目標頁。