筆記：AI for SDD with speckit 起手式

心血來潮玩了一下 speckit，把一些想法跟心得先筆記起來。

使用 speckit 時依序會執行的指令
speckit.constitution
speckit.specify
speckit.plan
speckit.tasks
speckit.implement

Constitution 建立憲法規章 for 專案

專案的最底線或是最高指導原則的概念，整個專案之後的設計都必須要遵守。

speckit.constitution 變數命名使用駝峰命名、公開的方法都需用介面隔開、不採用 TDD 但公開方法都要有測試包住

預期產生檔案

• .specify\memory\constitution.md

Specify 開始說明你想要做什麼

在這裡不用提到任何跟技術有關的字樣，重點只需要放在一個，你想要做什麼。

speckit.specify 建立一個串接金流的站台程式，可以用來接收內部系統的請求，然後整理成第三方套件 sdk 的 payload 來進行呼叫。算是 gateway or adapter pattern 的概念。主要實作「存錢」 & 「領錢」的功能。

預期產生檔案

• specs\專案目錄\checklists\requirements.md
• specs\專案目錄\spec.md 檔案

Plan 說明跟技術相關的內容

在這裡可以說明要使用的技術、語言、框架、套件、資料庫……等，任何跟技術有關的都可以在這裡補充說明。

speckit.plan 使用 .net 8/C#，建置 .net core web api 程式。主要都以 http 協定來溝通（post）。然後串接第三方套件 http://github.com/linepay 所提供的「存錢」 & 「領錢」的功能。

預期產出檔案：

• specs\專案目錄\contracts\api-endpoints.md
• specs\專案目錄\data-model.md
• specs\專案目錄\plan.md
• specs\專案目錄\quickstart.md

Tasks 拆分工作項目

分析前面動作所產生出的 md 檔案，開始歸劃及拆分工作項目。

speckit.tasks

預期產出檔案：

• specs\專案目錄\tasks.md

Implement 開始實作

開始讓 AI 進行實作。

speckit.implement

預期產出

• 整個專案

個人心得

用 speckit 套件的走完標準動作後，確實又被 AI 驚豔到。先來把第一次玩的一些想法記錄下來~

每個指令產出的 md 檔可以再多補充細節

就跟用 AI 寫程式一樣，一開始的產出拿來當第一個版本。

接著用這個版本，來調整成接近自己想法的內容。

規格描述的檔案要細分

大部份的 md 檔都是一個。對於比較大的專案來講，這些單一檔案只會越長越大。

看網路上跟 AI 的建議，都是會開始把單檔拆開，開始來進行分類。

然後在 speckit.plan 的時候，把範圍只鎖定在有異動到規格的那些檔案。

包括像 speckit.tasks & speckit.implement 也是，都可以把範圍限縮起來。

不然不止 token 燒得兇，就連執行的時間也蠻長的。

開發的流程改變了

如果是使用 SDD 來進行開發，最核心的東西就是規格了。

以前的系統如果遇到問題時，都是工程師介入查找問題，然後看哪一段有 bug 把程式碼開起來進行修改。

SDD 的流程會變成不會直接改程式碼，要被改的是規格。

也就是最後系統的產出會有問題，有很大的機會是 spec md 沒有寫清楚或規則不夠明確。

所以流程上是要回頭把規格改好，然後讓 AI 再重新 plan & implement。

透過這種不斷迭代的過程，讓這份規格可以使 AI 穩定的有最終的產出。

其實在 github 上看到 speckit 的核心哲學寫的真不錯。

• 在定義怎麼做之前，先定義做什麼。這的確很符合所謂的 SDD 精神。如果連要做什麼都說得不清楚，那要怎麼做其實根本就不會是重點。
• 這是一種類似迭代的開發，不會是一次到位。所以一個專案的開發，就是慢慢的、慢慢的修改，然後越來越接近我們想要的目標。