上個月上了保哥的 SDD 課程，立刻找個簡單的專案來練習。
先說結論：有用但不多。以下講講我的使用心得，以及推薦的使用情境。
SpecKit 是什麼？
SpecKit 是 GitHub 推出的開源專案，核心理念基於 **SDD (Spec-Driven Development，規格驅動開發)**。想把軟體開發標準化成一套結構化流程：從建立專案憲章(Constitution)、定義需求(Specify)、規劃實作(Plan)、拆解任務(Tasks)到最後的自動化實作(Implement)。
整個流程透過 specify CLI 初始化專案，並在 agent 環境中使用一系列指令推進開發：
| 指令 | 用途 |
|---|---|
/speckit.constitution |
建立專案憲章，定義開發原則與標準 |
/speckit.specify |
描述要開發的 feature（what & why） |
/speckit.clarify |
針對模糊需求進行釐清 |
/speckit.plan |
根據指定的技術與架構選擇產生實作計畫 |
/speckit.tasks |
將實作計畫拆解為任務清單 |
/speckit.analyze |
檢查憲章、Spec、實作計畫、任務清單是否一致 |
/speckit.implement |
依任務清單自動實作 |
支援的 agent 涵蓋 GitHub Copilot、Claude Code、Gemini CLI 等等。
使用心得
我是使用 Copilot 搭配 SpecKit 在前人的商品分類小程式上實驗 SpecKit，想要將原本的同步 API 呼叫改成非同步的 batch API 呼叫。總共跑了 3 個 iteration，用掉 80% tokens ，心得可以用下面這張圖表示：
真的滿傻眼的， Spec 和 Plan 看起來都很完美(我真的有認真一行行 review)，但到了 Task 和 Implement 階段就會逐漸失控，出現看起來很棒實際很 shit 的東西。
我的看法
我認為翻車的原因主要有以下幾個：
AI 的幻覺
現今 AI 的本質都只是預測下一個 token，只是精巧地模仿著心的機能。
對 AI 來說，文件與規範是透過很隱含的關係影響著程式碼， AI 的產出並不是經過邏輯上嚴密的推論而來。
Context 的長度有限
基本上 AI 不會載入所有文件，所以寫在文件裡的規範不一定真的對 AI 造成效果。即使載入了也不一定獲得足夠的關注 (Attention is All You Need)。
人類的幻覺
從 spec 到規劃到實作之間存在大量的細節，通常人類覺得 AI 應該知道吧的部分 AI 並不知道。
btw 保哥一直說人類的幻覺比 AI 嚴重。
尋找共存之道
經過了兩次大失敗之後，我想尋找與 AI 共存的方法。
我做了 Coding 的逆向工程：用已知的答案反推規格。
具體做法是：
- 我先寫好程式碼
- 從程式碼產生 spec 後移除實作，只留下 interface
- 根據 spec 與 interface 進行 plan 與 task ，刪除 interface
- 人工審閱所有文件並微調後執行 implement
這樣得到的結果大概就與我的實作有八九成像了，只需要進行一些實作細節微調。
從這個逆向工程可以得出：只要把握好 spec 與 interface，基本可以讓 AI 照著所想的規劃進行。
實際上這也很符合軟體工程的做法：維持介面穩定、抽換底層實作。
還需要 SpecKit 嗎？
回到 SpecKit ，如果我已經把 spec 和 interface 都想得很清楚了， SpecKit 是不是就毫無用武之地了。
我的答案是：是也不是。
SpecKit 仍然可以幫我釐清 spec 上的細節 (藉由 prompt 工程師精美的 prompt)，在 plan 時提供工程細節供 implement 階段參考。
只是，以上的流程並不一定要透過 SpecKit 完成，其他工具可能可以完成得更好 (Superpower 看起來很 super)。
我認為 SpecKit 過於重視流程與形式，產生了一堆中間文件(review 真的很花時間)，但這些文件對開發並不一定有帶來助益。
結語
我之後應該不會再使用 SpecKit 來進行開發，但我透過 SpecKit 學習到了 SDD 的精神。
我會去找 SDD 的書籍來看 (Specification by Example 看起來不錯) ，提升與 AI 的溝通能力。
另外 OpenSpec 看起來更輕量且彈性，也可以嘗試看看。