GH-300 GitHub Copilot 認證 - 第三天課程筆記

「從寫程式碼轉向定義規範讓 AI 寫程式碼。」

第三天課程開場，講師丟了這句話。聽起來像口號，但整天下來把 TDD 和 SDD 跟 Copilot 結合的實作流程走了一遍之後，這句話的份量就不一樣了。

前兩天快速回顧

前兩天的核心是上下文工程（Context Engineering）。Copilot 的輸出品質直接取決於你給它的上下文品質。三種機制要記住：

Instructions（.github/instructions/*.md）是全域或目錄層級的編碼規範，透過 applyTo 自動匹配。Prompts（.github/prompts/*.md）是封裝好的提示詞，用 /slash 指令調用。Agents（.github/agents/*.md）定義推理環境和思考方式，切換整個對話模式。

一個重要觀念：結構化提示詞不直接用在對話裡，而是放進 Instructions / Prompts 這些檔案。你跟 Copilot 的日常對話就用自然語言，結構化的東西讓檔案系統處理。

Instructions 的上下文管理也有意思——它不是略讀，而是完整讀取。反覆被匹配到的內容會保留更久，沒被用到的會被壓縮甚至移除，需要的時候再重新載入。這是 Copilot 在有限 context window 裡動態調配資源的策略。

Coding Agent 的競爭模式

第三天深入講了 Coding Agent 的兩種啟動方式。

從 Chat 對話框啟動是單選——挑一個 Agent 執行。但從 Issue 指派可以多選，同時指派 Copilot、Codex、Claude，讓它們各自建 Branch 和 Draft PR，最後比較結果。這是競爭模式。

協作模式則是只選一個 Agent，做完不滿意再轉交另一個繼續。兩種模式各有適用場景：探索性任務用競爭，確定性任務用協作。

Agent 建立的 PR 有個安全設計要注意——GitHub Actions 會顯示 pending for approval，不會自動執行。Agent 本身不算 Reviewer，一定需要真人 Review。

GitHub Copilot 三種互動模式

Auto-completion（Ghost Text）：行內自動補全，不保存歷史。Inline Chat：選取程式碼後行內對話修改，也不保存歷史。Copilot Chat（側邊欄）：完整對話模式，可以匯出 JSON，唯一保存歷史的方式。

一個實用的配置建議：可以按副檔名停用自動補全。記憶相關的 Markdown 檔案（像是日誌、筆記）建議排除，避免 Copilot 對這些檔案做不必要的分析。

訂閱方案差異重點

考試會考的幾個區分點：

Repo 層級檔案排除只有 Business 和 Enterprise 有。Knowledge Base 只有 Enterprise 有。公共代碼匹配過濾是所有方案都有的——Copilot 生成的建議會跟 GitHub 公共程式碼庫比對，匹配度太高就自動 Block，防的是版權風險和安全風險。

Enterprise 的 Knowledge Base 跟 Copilot Instructions 不同：Instructions 到目錄層級，Knowledge Base 是組織級的 High-level 規則。思維鏈修改影響很大，建議由專責團隊管理。

Codespaces 和 devcontainer.json

GitHub Codespaces 就是雲端版 VS Code，跑在遠端容器裡。預設綁定某個 Branch，但可以在裡面切換。

devcontainer.json 的一個實用建議：讓 Copilot 或 ChatGPT 幫你生成，因為 Extensions 之間有依賴和衝突關係，模型能識別大部分相容性問題。自己手寫容易踩到版本衝突的坑。

Instructions / Prompts / Agents 三層架構

這是第三天最重要的架構觀念之一。

Instructions 透過 applyTo 自動載入，你不用管它，Copilot 碰到對應目錄就會讀取。裡面放編碼規範、例外處理、推理思維鏈。

Prompts 需要用 /slash 指令主動調用，裡面放具體操作步驟。

Agents 定義整個推理環境。有趣的是，Prompt 檔案可以只寫一行 follow instructions in agent，把執行轉交給同名 Agent。這樣你用 /spec-analyze 調用 Prompt 時，實際上是在 Agent 環境裡執行。

TDD 跟 Copilot 的結合

Red-Green-Refactor 的經典 TDD 循環，在 Copilot 裡面用三個 Agent 來跑。

Red Agent 根據功能需求寫測試用例，而且一定是失敗的測試。它只能寫測試，不能動實現程式碼。Green Agent 用最小程式碼讓測試通過，不能改測試也不能多寫測試。Reflect Agent 檢查覆蓋率、跟需求比對、提出重構建議，但不動任何程式碼。

三個 Agent 各司其職，互相制約。這個設計很聰明——把 TDD 的紀律用 Agent 的職責邊界來強制執行，不靠人的自律。

一個關鍵前置條件：功能必須先拆到夠小的粒度。直接丟一個包含二三十個子功能的大特性給 TDD Agent，上下文壓力會很大，迭代效果不好。

TDD Agent 的模板網路上很多，而且可以跨平台用——Copilot、Codex、Claude 都通用。

SDD（Spec-Driven Development）規範驅動開發

SDD 的核心理念是：強制模型在寫程式碼之前先理解 Codebase、先產生規範文件，確保文件跟程式碼始終同步。

SpecKate 框架

SpecKate 是 GitHub 官方發布的 SDD 框架，跟 Copilot 深度整合。完整流程分六步：

Constitution：讓模型理解整個 Codebase，生成架構記憶庫。Specify：定義需求和驗收條件。Plan：規劃實現方案。Task：分解任務，對應到 GitHub Issue。Implement：在新 Branch 上實現。Analyze / Sync：同步文件跟程式碼的一致性，更新 Constitution 和 Lessons。

記憶體系有三層：constitution.md 是 Codebase 架構和約束、architecture_map 是專案架構圖、lessons 是每次迭代累積的開發經驗。Constitution 建議讓模型自己理解 Codebase 後生成，效果比人工寫更好。

分支命名策略

每個 Feature 建立獨立 Branch，帶序號：spec-001-add-auth/、spec-002-add-auth/。同個功能可以多次迭代，序號自動累加。.specification/ 目錄記錄所有實現過的特性。

Constitution vs Copilot Instructions

這兩者的定位不同：Instructions 是全域規範，相對穩定。Constitution 隨每次 Feature 實現而動態更新。建議 Instructions 保留初始版本作基準，Constitution 當作演進中的文件。

SDD 的優劣勢

優勢是文件跟程式碼強制同步、需求可追溯、驗收條件前置、跟 GitHub Issue/PR 深度整合。劣勢是流程相對僵硬、文件維護成本高、Constitution 更新頻繁。

考試重點整理

幾個必記的判斷題考點：

Agent 建立的 PR 不會自動合併——一定需要真人 Review。Knowledge Base 只有 Enterprise 方案才有。Instructions 是自動載入的，Prompts 需要 /slash 調用。TDD 的三個 Agent 各有嚴格職責邊界——Red 只寫測試、Green 只寫實現、Reflect 只提建議。Constitution 會動態更新，Instructions 相對穩定。

第三天的核心訊息很清楚：AI 輔助開發不是讓 AI 直接寫程式碼，而是用結構化的流程確保 AI 的產出品質。不管是 TDD 的 Agent 微循環還是 SDD 的 SpecKate 框架，核心都是「規範先行」。