50 個 Task。50 個 GitHub Issue。50 個 Coding Agent 各自開 Branch、各自寫 Draft PR。人類只負責最後的 Code Review。

這不是簡報上的願景圖，是 SpecKit 框架在第四天課堂上實際示範的流程。當然，現實中你可能不會真的開 50 個 Agent 同時跑，但這個架構的設計意圖很明確：開發者的角色正在從「寫程式的人」變成「定義規則讓 AI 寫程式的人」。

Coding Agent：像指派工程師一樣指派 AI

GitHub 的 Coding Agent 做了一件很聰明的事——它把 AI 塞進了開發者本來就在用的工作流程裡。

你在 Issue 頁面指派 Agent（可以選 Copilot、Codex 或 Claude），它自動建立一個新的 Branch，在上面寫程式碼，完成後產出 Draft PR。整個過程跟你指派一個新進工程師做事的流程一模一樣：分配任務、獨立開發、提交 PR、等 Code Review。

有趣的是競爭模式。同一個 Issue 可以同時指派多個 Agent，各自產出方案，最後挑最好的那個 Merge。這就像面試時給三個候選人同一道題目，看誰的解法最漂亮。

安全設計值得注意：Agent 建的 PR 在 GitHub Actions 裡會顯示 pending for approval，不會自動跑 CI/CD。Agent 自己也不算 Reviewer——一定需要真人點頭才能 Merge。

SDD：比 TDD 更重的武器

TDD 的節奏是 Red → Green → Refactor，核心是測試先行。SDD（Spec-Driven Development）走得更遠——它不只要求先寫測試，還要求先定義整個專案的遊戲規則。

想像你在蓋一棟大樓。TDD 是每砌一面牆就檢查牆壁是不是直的。SDD 則是蓋之前先畫完整張藍圖，定好建築法規，然後每蓋一層就回頭對照藍圖和法規，有衝突就停下來讓建築師決定怎麼改。

SpecKit 的六步驟流程是一個循環：

Constitution 是全局唯一的專案公約，定義命名規範、設計原則、依賴注入規則。整個專案只有一份，所有 Feature 共用。它不是法律，是指南針——Agent 會刻意控制它的長度，反覆做 Summarizing 避免佔太多上下文。

Specify 是需求定義。從這步開始建 Feature Branch，所有改動都在新分支上。寫清楚要做什麼、不做什麼。

Plan 把需求轉成可執行的分階段計畫。這一步會先做 Constitution Check——計畫有沒有違反公約？有的話先修正，不要等到寫完程式才發現方向錯了。

Task 把計畫拆解成可以直接編碼的操作級任務。拆到什麼程度？拆到一個 Task 就是一張 GitHub Issue，一個 Coding Agent 就能獨立完成。

Implement 是真正寫程式碼的階段。可以手動寫，也可以把 Task 同步成 Issue 讓 Agent 批量執行。

Sync（Analyze） 是整個 SDD 最核心的品質保證步驟。它掃描所有程式碼和 SpecKit 相關檔案，比對跟 Constitution 有沒有衝突，產出衝突清單、嚴重程度標記和修復建議。

但這裡有一個刻意的設計決策：Sync 不會自動修復任何東西。

即便衝突很明顯、修法很簡單，它還是會停下來等人類決定。為什麼？因為 SpecKit 團隊在做一件事——觀察人類工程師在衝突情境下怎麼做判斷。目前 lessons.md（經驗記錄）需要手動觸發生成，但未來版本可能會根據觀察到的人類決策模式，自動學會什麼時候該建議「直接修」、什麼時候該建議「先討論」。

記憶系統：三份檔案撐起整個上下文

SpecKit 在 spec/memory/ 目錄下維護三份核心記憶文件：

1
2
3
4
5
6
7
8
9
10
spec/
├── memory/
│   ├── constitution.md      ← 全局公約（SpecKit 內建生成）
│   ├── architecture-map.md  ← 架構圖（自訂提示詞生成）
│   └── lessons.md           ← 踩坑記錄（Sync 後手動觸發）
├── templates/               ← Spec/Plan/Task 模板
└── <feature-branch-name>/   ← 每個 Feature 獨立目錄
    ├── specification.md
    ├── plan.md
    └── task.md

只有 constitution.md 是 SpecKit 系統級預置的。architecture-map.md 和 lessons.md 是實務中發現「少了這兩份檔案，重構專案會很痛苦」才補上的。

為什麼不把所有規範都塞進 Copilot Instructions？因為 Instructions 會佔用上下文窗口。你公司有 50 套內部系統的 API 文件，如果全部塞進 Instructions，模型會被不相關的內容淹沒。Enterprise 版的 Knowledge Base 解決了這個問題——規範集中存放，用 # 符號按需引用，只把當下需要的東西拉進上下文。

TDD 代理流程：輕量版的替代方案

不是每個功能都需要 SDD 的六步完整流程。小功能用 TDD 代理就夠了。

三個 Agent 接力：Red Agent 根據需求寫出必定失敗的測試，Green Agent 用最小程式碼讓測試通過，Refactor Agent 在不破壞測試的前提下改善程式碼品質。

關鍵細節：Agent 之間的 Handoff 是 Hint，不是自動跳轉。也就是說，Red Agent 做完之後不會自動把工作丟給 Green Agent——你需要手動點擊切換。這是刻意設計的人類檢查點。

TDD 代理的優勢是輕量和快速迭代。劣勢是它不管全局一致性——如果你的修改影響了其他模組的規範，TDD 不會幫你檢查。需要全局一致性保證的，還是得回到 SDD。

上下文爆炸的求生指南

用 SDD 跑一個中等規模的 Feature，從 Specify 到 Implement，上下文窗口基本會撐到極限。這不是 bug，是 SDD 本身的特性——它需要大量的規範、計畫、任務定義同時存在於上下文中。

講師給了一個實用建議：壓縮上下文之前，先跑一次 Analyze。 定位問題比解決問題更吃上下文。先把問題清單拿到手，然後壓縮掉中間的推導過程，再讓模型根據問題清單去修復。

模型選擇也有講究。SpecKit 流程建議始終用同一個模型走完整個循環。原因是 Constitution 到 Implement 在同一上下文中操作，模型自己理解的架構比你直接告訴它結論更準確。如果中途換模型，新模型對專案的理解要從頭建立，反而浪費更多上下文。不滿意的話，從 Constitution 步驟換模型重新開始。

非 SDD 場景下，選模型可以更靈活：Claude 在語意理解和規劃方面比較強，適合 Specify 和 Plan；Codex 在程式碼生成和 Bug 排查方面更專注，適合 Implement 和 Debug。

舊專案導入：不需要推倒重來

把 SDD 套用到現有專案比想像中簡單。SpecKit 的安裝就是把 .github/agents/、.github/instructions/、spec/ 這幾個目錄複製到專案裡面——純檔案，不裝套件，不改 build 流程。

安裝完之後讓模型讀一遍 Codebase，自動生成 Constitution。這裡有個技巧：不要只說「幫我分析這個專案」，而是給它方向——告訴它重點看哪些目錄、哪些檔案實作品質最好（Gold Standard），甚至用挑戰式互動讓模型反過來 Challenge 你對架構的理解，找出你自己沒意識到的認知差異。

重構專案特別建議額外建立 architecture-map.md。Constitution Agent 的提示詞刻意控制長度，不會深入描述架構細節。獨立的架構圖文件能在後續的 Plan 和 Implement 步驟中提供更精確的上下文。

SpecKit vs OpenSpec：看功能大小選框架

SpecKit 適合中大型 Feature 和全量重構，特點是嚴格的 Constitution Check 和反覆 Sync。代價是流程比較重——反覆 Sync 的工作量可能佔整個開發時間的五分之一以上。

OpenSpec 更輕量、更靈活，適合獨立性高的小功能。不需要全局 Constitution，也不需要反覆比對一致性。

踩坑提醒：用 SpecKit 最常犯的錯是定義 Constitution 時過度設計。Constitution 是指南針，不是六法全書。寫太多規則反而會讓 Agent 在 Sync 時產生大量誤報，真正重要的衝突反而被淹沒。

第四天的核心不是某個工具或某個框架，而是一個正在發生的角色轉變：開發者從「親手寫程式」變成「設計規則系統，讓 AI 在規則內執行，衝突時人類仲裁」。Constitution 定義邊界，Agent 在邊界內工作，Sync 在邊界被突破時拉警報。這三個角色的配合方式，大概就是未來幾年軟體開發的基本節奏。