12 · 真實團隊工作流 · AI 程式設計教程中文版

工具教程最終要回到工作流。Copilot 真正的價值不是多生成幾行程式碼，而是把團隊每天反覆做的工程動作變短：寫測試、解釋 diff、拆 issue、補文件、跑遷移、做 review——本章把前 11 篇的能力按"團隊真實場景"重新組裝。

本章目標：你會把前面 11 篇的入口、上下文、許可權、Cloud Agent、CLI、MCP 和治理放進真實團隊 SOP。

1. 總工作流

flowchart TD
  Issue["Issue / 需求"] --> Triage["Copilot Chat / Plan"]
  Triage --> Decide{"本地還是雲端?"}
  Decide -->|本地| IDE["VS Code Agent Mode / CLI"]
  Decide -->|非同步| Cloud["Cloud Agent branch"]
  IDE --> Diff["Diff / tests"]
  Cloud --> PR["Pull request"]
  Diff --> Summary["PR summary"]
  PR --> Summary
  Summary --> Review["Copilot review + human review"]
  Review --> Checks["CI / 手動驗證"]
  Checks --> Merge{"合併?"}
  Merge -->|是| Ship["上線"]
  Merge -->|否| Iterate["迭代或回復"]

這個流程裡，Copilot 是每個環節的加速器，但每個環節都有人工驗收點。

2. 工作流一：TDD 小步實現

用 Copilot 做 TDD（test-driven development，測試驅動開發），不是讓它一次寫完功能，而是限制在 Red（先寫一個會失敗的測試）、Green（讓測試最快透過）、Refactor（保持測試透過的前提下整理程式碼）三段。

Red：

只寫失敗測試。
不改生產程式碼。
確認失敗原因就是目標行為缺失。

Green：

只做最小實現。
不新增抽象。
跑相關測試。

Refactor：

只清理結構。
不改外部行為。
相關測試仍透過。

證據：Red 失敗輸出、Green 透過輸出、Refactor 後透過輸出，以及每一步 diff。

3. 工作流二：Issue 到 PR

適合 Cloud Agent：

issue 寫清目標、範圍和驗收標準。
任務可以透過 branch、checks、PR review 驗收。
不依賴本機登入態或私密環境。
風險中低，可以非同步推進。

流程：

用 Chat 或 Plan 梳理 issue。
決定 assign issue 直接 PR，還是 prompt 到 branch 先迭代。
審 research 和 implementation plan。
審 branch diff。
建立 PR。
走普通 review 和 CI。

不要讓 Cloud Agent 處理“還沒想清”的需求。先讓它 research 和 plan，不要直接改程式碼。

4. 工作流三：PR 摘要

PR 摘要不是 changelog。它要幫助 reviewer 快速進入上下文。

結構：

## What changed

## Why

## Risk

## Tests

## Rollback

Copilot 可以生成第一版，但作者必須補齊業務背景、風險、測試和回復。測試只能寫真實執行過的命令，不要讓 Copilot 編造。

5. 工作流四：程式碼審查

Copilot code review 適合預篩風險，不替代人工 reviewer。

使用方式：

PR 目標和範圍已經清楚。
請求 Copilot review。
逐條 triage 評論：採納、手動修、關閉並說明原因。
修復後跑測試。
必要時請求 re-review。

官方文件提示，Copilot 不會因為推送新提交就自動重新 review；需要重新請求。自動 review 還要考慮 Actions minutes 和評論噪聲。

6. 工作流五：文件和教程維護

適合 Copilot：

根據程式碼 diff 補 README。
同步 API 示例。
給配置項補說明。
檢查站內連結和過期路徑。
用 PR summary 草稿整理釋出說明。

不適合：

編造官方事實。
複製沒有核驗的價格、計劃和模型資訊。
忽略截圖、斷點和實際構建。

教程類內容要有來源、核驗日期、連結和可執行驗證。

7. 工作流六：遷移和批次改造

遷移任務可以用 Copilot，但必須分階段：

Ask / Plan：列影響檔案和風險。
Agent / CLI：只做第一小批。
Tests：跑區域性測試。
Review：人工看 diff。
Expand：再擴大到下一批。

適合用 prompt file 或 skill 固化遷移步驟；高風險命令用 hook 或許可權策略攔住。

8. 團隊 SOP 模板

任务类型：
TDD / issue-to-PR / review / docs / migration

入口：
GitHub.com / VS Code Agent / CLI / Cloud Agent

上下文：
issue、文件、PR、测试输出、MCP 工具

权限：
允许改哪些路径
允许跑哪些命令
禁止哪些工具和系统

验收：
diff、tests、checks、review、rollback

一個 SOP 要能讓新人按同樣流程復現，而不是隻靠某個老員工的經驗。

本章自檢

你應該能回答：

這個任務屬於哪類工作流？
入口為什麼選 GitHub.com、IDE、CLI 或 Cloud Agent？
上下文和許可權邊界是什麼？
驗收證據在哪裡？
失敗時怎麼回復或人工接管？

透過標準：Copilot 被放進工程流程，而不是游離在流程外單獨“生成程式碼”。

官方來源

Set up a test-driven development flow in VS Code：VS Code 官方 TDD 指南。
Using GitHub Copilot code review：GitHub 官方 code review 使用說明。
Creating a pull request summary with GitHub Copilot：GitHub 官方 PR summary 使用說明。
Achieving your company's engineering goals with GitHub Copilot：GitHub 官方團隊目標和 rollout 思路。

12 · 真實團隊工作流