【Day - 1】最後留下了一個問題：照著 Spec Kit 的指令順序操作，就算是在做 SDD 了嗎？如果換一套工具，步驟和文件都不同，又該怎麼判斷？

同樣叫 SDD，流程與產出的文件卻差很多

一開始我以為，只要都是 SDD 工具，核心流程與產出的文件應該都差不多。不過，拿我後來也用過的 OpenSpec 放在一起看，就會發現兩套工具的做法其實很不一樣。

以 2025 年 10 月的 Spec Kit 官方文件 來看，流程表面上可以簡化成 Spec → Plan → Tasks → Implement，實際留在 repo 裡的卻不只 spec.md、plan.md 與 tasks.md，還包含 constitution、research、data model、contracts 等文件。

constitution 是什麼？ 這是 Spec Kit 用來保存專案長期原則的文件，後面的 spec、plan 與 tasks 都要遵守裡面的約束。這裡先知道它屬於 Spec Kit 的流程就好，下一篇再打開來看實際內容。

OpenSpec 的預設做法則是把一次工作整理成 change，主要 artifacts 包含 proposal、specs、design 與 tasks，再接到 apply 與 archive。到了目前的版本，OpenSpec 還可以透過 schema 自訂要產出哪些 artifacts，以及它們之間的相依關係。

artifacts 與 schema 是什麼？ artifacts 可以泛指 workflow 執行後留下的文件與產物，所以這個系列也會把 Spec Kit 的 spec、plan 與 tasks 統稱為 artifacts；OpenSpec 則直接用這個名稱表示 change 裡的 proposal、specs、design 與 tasks。schema 是 OpenSpec 用來決定需要哪些 artifacts，以及它們之間先後關係的設定，後面介紹 OpenSpec 時會再完整打開來看。

從 Spec Kit 與 OpenSpec 就看得出來，兩套工具雖然都在實踐 SDD，核心流程和產出的文件卻不一樣。SDD 沒有規定所有人都要走同一套流程，也沒有一份固定的文件清單。

那麼，難道少了其中一個步驟，就不算 SDD 嗎？還是一定要安裝某一套工具，才算在使用 SDD？

答案：都不是。

SDD 本身是一套方法論

簡單來說，SDD 本身就是一套讓規格持續參與需求討論、實作、驗證與後續修改的方法論，而不是某一套特定工具的名稱。

這裡的重點不是「有沒有一份 spec」，而是這份規格後來有沒有真的被拿來使用。需求討論完之後，它能不能幫助我們確認要做什麼？準備實作時，能不能依照它拆出工作？AI 說完成了之後，我們能不能再拿同一份規格回頭確認，最後做出來的是不是原本談好的東西？如果實作途中改變方向，新的決定有沒有回到規格裡？

至於 workflow、Skills、commands 和 artifacts，則是不同工具用來實踐 SDD 方法論的方式。它們可以幫忙固定步驟、保存進度，也可以提醒我們什麼時候該停下來確認，但工具本身並不是 SDD。

不裝 SDD 工具，也可以自己跑一輪

假設今天想做一個「忘記密碼」功能，我們當然可以直接對 AI 說：「幫我做忘記密碼」，然後讓它開始修改 code。不過，如果想用 SDD 的方式處理，就不會馬上讓 AI 動手，而是先把目前想到的需求與限制整理出來：重設連結多久失效？同一個連結能不能使用第二次？輸入不存在的 Email 時要怎麼回應？新密碼又有哪些限制？

如果連自己都不確定還漏了什麼，也可以先請 AI 幫忙思考一輪，從使用者操作、例外情況或可能失敗的地方繼續追問。例如：「除了我剛才提到的內容，這個功能還有哪些情境沒有討論到？」AI 提出的內容不一定都要納入需求，最後還是要由我們確認哪些問題真的需要處理。這一步還不表示需求已經談清楚，但至少可以先把原本沒有想到的空白攤開來。

等需求討論到可以開始動手的程度後，先把需求、限制與成功條件寫成可以驗證的 spec，再請 AI 依照 spec 拆出範圍清楚的 tasks。接下來依照 tasks 執行，並在適合的時點確認結果。這個檢查點可能放在每個 task、每個 phase，也可能是在整份 tasks 完成之後，取決於目前掌握的需求有多明確、spec 的範圍，以及這次修改的風險。重點不是固定要停幾次，而是 AI 完成後，我們有沒有清楚的規格可以核對結果。如果途中發現原本的設計行不通，或需求需要改變，也不是只把 code 改掉就算了，而是先確認新的方向，再一起更新 spec 與 tasks。

整個流程可以簡化成這樣：

你會發現，這一輪完全不需要安裝 Spec Kit、OpenSpec 或其他 SDD 工具。只要有一個地方可以保存 spec 和 tasks，再和 AI 按照這套方式工作，就已經可以開始實踐 SDD 了。

不過，小修改不一定要跑完一套很完整的流程。很快就會丟掉的 prototype，或是一眼就能確認的低風險修改，可能只需要幾句足以驗證的規格。功能越複雜、工作要跨越的時間越長，或修改既有行為的風險越高，才越需要把中間的決定、tasks 與驗證留下來。

當規格、討論與驗證開始變多，只靠自己維持這些步驟也會越來越麻煩，這時才是工具真正派上用場的地方。回到我當時選擇的 Spec Kit，眼前最直接的問題就是：這一大排 commands，究竟怎麼把需求一路接到實作？每個步驟產生的文件，又各自在回答什麼？

下一篇，我們就先回到 2025 年 10 月，看看 Spec Kit 當時是怎麼運作的吧！

參考資料

• GitHub Spec Kit：2025 年 10 月的 SDD workflow 文件
• OpenSpec：Core Concepts at a Glance
• OpenSpec：Customization