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

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
團隊工作流	workflow	團隊裡串起 Copilot 各能力。
分工	division	補全 / Agent / Cloud 各管什麼。
審查	review	AI 產出必須有人審。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你為團隊設計一套順手、可治理的 Copilot 工作流。

你是 Copilot 團隊工作流設計顧問。

【角色】
Copilot 團隊工作流設計顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。

【輸入】
- 團隊規模和技術堆疊：___
- 最常做的任務型別：___
- 現有的協作和審查流程：___
- 最想改善的環節：___
- 經驗水平：___

【工作流程】
1. 診斷目前流程的不順點
2. 按補全 / Agent / Cloud 分工設計工作流
3. 把 AI 產出納入審查
4. 把長期約定沉澱進指令
5. 給落地建議

【輸出規範】
▌一、不順點
▌二、分工工作流
▌三、審查機制
▌四、落地建議

【硬約束】
- 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 · 真實團隊工作流