上一篇用「忘記密碼」的例子，把需求怎麼整理成規格、拆成工作，再拿規格核對結果走過一次。接著就可以回到我最早選擇的 Spec Kit，這些工作又是怎麼被安排進不同 commands 裡的呢？

這一篇先不談實驗結果，我們先看看 Spec Kit 會在專案裡放進哪些檔案，再按照 workflow 的順序，看看每個步驟會使用或留下什麼。

這篇使用哪個版本？ 我沒有保留當時安裝的精確版本，所以下面主要依照 2025 年 10 月左右的操作方式來說明。遇到寫文章時已經不同的地方，我會再另外補充。

初始化後，Spec Kit 會放進哪些檔案？

Spec Kit 有自己的 Specify CLI。我們可以在要執行的專案中，執行 specify init 並選擇要使用的 AI Agent。初始化完成後，Specify CLI 會把 workflow 需要的 commands、scripts 與 templates 放進專案；接著真正讀取需求、產生文件與修改 code 的，仍然是 AI。Spec Kit 做的事情，是先替 AI 準備好一條工作路線，以及每個階段要使用的文件格式。

以我當時使用的 Claude Code 來說，初始化後，commands 與 .specify/ 裡的 constitution、scripts、templates 會分別放在兩個目錄中，兩邊的關係大致如下：

圖中的 .claude/commands/ 放的是 Markdown prompt templates。呼叫 /speckit.* 時，Claude Code 會把對應內容帶進當次 session 的 context，讓 AI 依照裡面的 workflow 執行。

當時的 Spec Kit 用什麼形式提供流程？ 我在 2025 年 10 月使用 Spec Kit 搭配 Claude Code 時，這些流程是透過 commands 提供的。當時 Skills 才剛推出，也還沒有正式標準化，所以這幾篇介紹當時操作方式的文章，都會沿用 commands 的稱呼。

.specify/ 則放著這些 commands 執行時會用到的內容。memory/ 保存專案長期遵循的原則，scripts/ 負責準備或更新流程需要的檔案，templates/ 則提供各階段文件的基本格式。這裡只畫出跟本文有關的大致結構，對應的 PowerShell scripts 與部分設定檔就先省略不看。

知道這些檔案放在哪裡後，接下來就來看：實際處理一個需求時，會按照什麼順序呼叫這些 commands？

這裡先統一一下名稱： 接下來的文章，我會直接用流程名稱代替完整的 command 名稱，畢竟每次都把整串 command 打出來覺得很累XD。例如，/speckit.constitution → constitution、/speckit.specify → specify，其他流程也是相同的用法。

Spec Kit 的 workflow 怎麼跑？

我們先不要急著打開每一份文件，先看整套 workflow 會用到哪些流程，以及它們分別在做什麼：

把這些流程串起來後，整套 workflow 大致可以分成兩層。第一次把 Spec Kit 導入專案時，會先建立 constitution；完成這層基礎後，平常真正會一輪一輪重複的，是從 specify 到 implement 的流程。做完一次變更，下一個需求再從 specify 重新開始。

clarify 是可選流程，當時的說明建議在 plan 前先執行一次，透過結構化問題補上 spec 沒有說清楚的地方。不過，我不是一開始就想到要把它接進自己的流程，而是在後面的實驗中，才真正感受到 clarify 帶來的差別，這段會留到後面再說。

當時也已經有 analyze 與 checklist，分別用來檢查 artifacts 之間的一致性，以及產生需求品質檢查表。不過，我當時都沒有把它們接進流程，所以這裡也先不展開介紹。

每一個流程會留下哪些文件？

知道 workflow 怎麼走後，再回頭看每個流程實際會留下什麼就比較清楚了。Spec Kit 並不是只產生一份 spec.md：有些流程會建立新的 artifact，有些則是修改前一階段留下的文件，到了 implement 才真正開始改 code。

這些 artifacts 不是把同一段內容換個檔名重寫，而是各自回答不同問題：這次要改什麼、還有哪些地方沒說清楚、準備怎麼做，以及實際要先完成哪些工作。

現在回頭看，Spec Kit 的確比丟下一句需求就讓 AI 開始改 code，多了不少可以停下來確認的地方。不過，我當時只有大概理解 workflow 怎麼跑，也簡單看過各個階段的說明，並沒有再深入研究。每份文件該寫多深、spec 的範圍該切多大，我其實都沒有概念。

其中，第一份讓我開始困惑的文件，就是 constitution。

constitution 裡會放什麼？

constitution 和 spec、plan、tasks 不太一樣。它不是用來描述某一個功能要做什麼，而是放整個專案長期都要遵循的開發原則，例如架構方向、測試要求、複雜度限制，以及這些原則之後要怎麼修改與維護。簡單來說，它比較像是專案的「憲法／規章」。

當時的 constitution template 並沒有直接塞進一套完整規範，而是先留好 Core Principles、Additional Constraints、Development Workflow 與 Governance 等區塊，等使用者依照專案情況填寫。至於裡面可以放什麼，官方在同時期的 Spec-Driven Development 說明 中，另外列出九項 development articles，讓使用者可以參考 constitution 裡需要放上哪些原則。我把它簡化後大概會像這樣：

# [PROJECT_NAME] Constitution

## Core Principles

### I. Library-First
每個功能先從可以獨立測試與使用的 library 開始，避免直接塞進 application code。

### II. CLI Interface
Library 需要提供 CLI；以文字作為輸入與輸出，並支援 JSON 等結構化格式。

### III. Test-First（NON-NEGOTIABLE）
先寫測試、確認測試會失敗，再開始實作，完整走過 Red-Green-Refactor。

### IV. Integration Testing
新增或修改 library contract、跨 service 溝通與 shared schema 時，需要安排 integration tests。

### V. Observability
使用可以追查的文字輸出與 structured logging，讓系統行為容易除錯與觀察。

### VI. Versioning & Breaking Changes
定義版本編號方式，並清楚處理 breaking changes 與相容性。

### VII. Simplicity
從簡單的結構開始，不預先加入還用不到的設計；額外複雜度必須說明原因。

### VIII. Anti-Abstraction
優先直接使用 framework 提供的能力，不為了包裝而增加多餘的 abstraction layer。

### IX. Integration-First Testing
測試優先使用真實 database 與 service，並在實作前先準備 contract tests。

## Additional Constraints
補上 security、performance、technology stack 等專案限制。

## Development Workflow
說明 code review、測試、品質檢查與 release 前需要經過哪些步驟。

## Governance
記錄 constitution 的優先順序、修改方式、版本與日期。

這九項只是官方當時提供的例子，不需要全部照抄。真的建立 constitution 時，還是要換成自己的專案需要長期遵守的原則。像 Library-First 如果不適合自己的專案，不需要因為官方範例有寫，就硬把它塞進 constitution。

知道 constitution 裡會放什麼後，下一個問題就是：後面的 workflow 會在什麼時候用到這些原則？

constitution 會在哪些流程被使用？

constitution 建立後，也不是放在 memory/ 裡當參考而已。從當時的 command templates 來看，plan 會讀取它並填寫 Constitution Check，analyze 也會拿它檢查 spec、plan 與 tasks 是否違反專案原則。之後如果更新 constitution，constitution 流程還會檢查相關 templates 是否也要一起調整。

現在有什麼不同？ 寫文章時的 Spec Kit，specify、plan、tasks、analyze 與 implement 都會直接讀取 constitution。constitution 仍然是整個專案共用的一份文件；如果想替單一階段調整 commands 或 templates，則要另外使用 presets、project-local overrides 或 extensions。

到這裡，我大概知道 constitution 會放哪些原則，也知道 plan 與 analyze 會使用它。不過，對照專案裡原本就有的 CLAUDE.md，以及 plan 裡又要重新交代的技術內容，我反而多了兩個疑問。

constitution 又讓我多了兩個疑問

第一個問題是：我使用的是 Claude Code，而專案裡又已經有一份 CLAUDE.md。

CLAUDE.md 是什麼？ 如果沒有用過 Claude Code，可以先把它理解成 AI Agent 在每次開始 session 時會讀取的專案指引檔，裡面可能包含怎麼 build、怎麼 test、專案架構與開發規範。

而且，我當時也還在摸索 CLAUDE.md 到底該怎麼寫，所以也常常把原則與規範、專案架構、使用的技術全部塞進去，整份文件寫得落落長（台語）。這樣一來，官方說 constitution 要放專案原則，我的 CLAUDE.md 裡卻也有一大堆規範，兩邊到底有什麼不一樣？我當時還為了這個查了不少資料，但看完還是很困惑：哪些內容該放 constitution，哪些又該寫進 CLAUDE.md 呢？

第二個問題則出現在 plan。前面提到，plan 會說明這次準備使用的技術與架構，但既然我的 CLAUDE.md 已經放了專案架構與使用的技術，為什麼每次跑 plan 還要再寫一次？我當時真的想不通。

這兩個問題我當時都沒有答案。我大概就是帶著這些理解與疑問開始第一次實驗：知道 workflow 怎麼跑，也知道會產生哪些文件，但還不知道每一份到底要寫到什麼程度。

這些疑問，後續回頭分析實驗結果時會再談到。下一篇，我們先回到我第一次真正拿 Spec Kit 實驗 SDD 的現場：明明工具已經替我準備好這麼多步驟與文件，為什麼我還是把整個專案做壞了呢？

參考資料

• Spec Kit 0.0.79 README
• Spec Kit 0.0.79 Spec-Driven Development：The Nine Articles of Development
• Spec Kit 0.0.79 constitution template
• Spec Kit 0.0.79 plan command template
• Spec Kit 0.0.79 analyze command template
• Spec Kit 0.16.4 Release
• Anthropic：Equipping agents for the real world with Agent Skills
• Claude Code：How Claude remembers your project