筆記：AI for SDD with speckit brownfield

這次試著把 speckit 套用到既有的專案裡，而不是開發一個全新的。

畢竟我最大的需求應該都是在既有的系統上新增或是修改功能。

specify init

起手式基本上沒什麼特別。先把專案檔開啟，然後執行 specify init . 指令，讓 speckit 先初始化一次。

執行完之後，一些初始的設定應該就出來了。例如：.cursor(或 .claude), .specify。

constitution

再來就是建立專案的最高原則了。這裡可以先填入這個既有專案的一些結構拆分、程式風格等的描述。

後面的描述算是非必要的，如果你的專案也像我的一樣，已經長得又臭又長，那也可以只下指令，然後再去調整 constitution.md 檔案也可以。

speckit.constitution 專案採用駝峰命名原則，interface 內只能有方法定義，沒有 property 或預設實作

specify

再來就是讓 speckit 知道這個專案是在做什麼的。個人覺得這裡算是蠻高難度的，因為既有專案很容易就是所謂的**單體式(monolithic)。

這種單體式系統，在經過長時間的摧殘，很容易就整個長歪。比如說功能多到不可能幾句話就描述完，或是有太多的人都在這個 module 上實作過功能，然後實作的方法又都不同。

這一堆噁心的東西要整理出來，真的是勞命又傷財。但 SDD 也不是一次到位的開發模式，簡單點，就是先用個人對這個 module 的第一印象主要功能來進行描述。然後再慢慢的來進行調整。

speckit.specify 這是一個只有內部會呼叫的 email 發送 module。負責接受請求，整理好內容後，來執行發送 email

plan

我用來測試的 module 是一個只接受請求，然後發送 email 的 module。

我的目的是要在這個 module 多開一個接口，讓它有一個入口可以進行所謂的開關動作。

所以我就多寫一個 spec.md 的檔案，例：spec_switch.md 檔案。

然後在進行 plan時，讓 ai 參照這個新的規格檔案。

speckit.plan 請在這個既有專案新增功能。新功能規格請參照 @spec_switch.md

在這個動作裡，會產生比較多的檔案，例：plan.md, data-model.md or contracts/*.md...。

這時候可以去看一下內容，也就是 AI 預期要實作的規格跟我們想象的有沒有一樣了。

假設不一樣，就可以開始來調整；覺得單一個檔案太大，也可以開始把它給拆掉。

tasks

讓 AI 依剛才的規格內容，來規劃準備要做的事。

speckit.tasks

跑完指令後還沒有真的上工，這時候還是可以再檢查一下 tasks.md 的內容有沒有想再加碼或調整的。

##implement

準備發車，讓 ai 開始真正的開工，等驗收。

speckit.implement

個人心得

我認為 AI coding 確實是已經過了一個門檻了。因為在檢驗 AI 所產出來的程式後，的確有一定的準確度在。

只是還是會有美中不足的地方。

程式微調

review 完程式後，雖然大部份的實作都 ok，但總會有一些地方需要調整（不管是規則或實作方式）。

如果這時候要繼續用 SDD 來開發，那就是繼續把前面的那些 md 檔案維護後，再繼續丟給 AI。

不然就是自己手動上工，把剩下的這些來微調掉。

context 太短

當所需要的功能越複雜，或是範圍過大的時候，context 200k 其實一下就爆掉了。

這時候可能可以把一些規格的檔案繼續拆小，但這裡要怎麼拆個人覺得是一門大學問。

因為有些功能的相依很高，要描述的讓 ai 懂，然後又不會走針，應該是蠻吃功力的。

總結來說，如果你 ai 用得好，那真的會是很大的助力。這種感覺就像是你在那種是往前的手扶梯上，跟別人比賽賽跑一樣。

所以當二個水平相同的人，一個擅長用 ai 來幫忙，另一個沒有，那在手扶梯 上跑的那個人絕對是佔盡優勢。

參考資料
github speckit