筆記：AI for SDD with speckit 隨筆

昨天試著把 speckit 用在既有專案上跑跑看。

一開始我挑了個小 module（一個 solution 裡只有二個 project files，然後二、三個 controller），這時候把 speckit 套進去使用加點新需求，一切都還順利。

但當我挑了另一個較大的 module（一個 solution 裡有十幾個 project files，然後彼此相依），這時候使用 speckit 就覺得很卡了。

情境上是，我只是想要加一點新的小需求在這個大 module 裡，可是要把 speckit 的整個流程在這個大 module 上面跑一次，其實沒那麼容易。

就跟上一篇筆記提到的一樣，一開始套入 SDD 時，光要描述這種大 module 的規格就是種煎熬。(筆記：AI for SDD with speckit brownfield)

所以我先縮小範圍，讓 speckit 先只局限在特別的二、三個 project 裡，但依舊是相當的卡。

卡的點是，就算 prompt 已經限縮在二、三個 project 裡，speckit 產出的 md 檔案依舊是蠻盡責的多……

是那種多到這個小需求我已經手動做好了，那些規格的 md 檔案我都還 review 不完。

在那個時間點，我突然覺得，對於這種已經長得很噁心又複雜的 brownfield 系統，要把 speckit 套用進來，可能要有很多的愛才有辦法。

如果沒有在前期花很多的時間把這個大 module 的規格一塊一塊的拼起來，就算工具不是用 speckit，而是使用別套 SDD 工具，我認為在過程中應該只會被卡的不要不要的。

後續

忍不住上網繼續爬文看別人是怎麼使用 speckit，結果翻到馬丁花的部落格裡，有他們的一位同仁寫的文章裡，有部份提到的內容就是我有遇到也蠻認同的。

連結：Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

一堆 spec md 檔案

在試到 speckit 的時候，她也是覺得可能只是要改個小需求，但 speckit 卻搞了一堆 md 檔案給她。

在第一次把 speckit 套到 module 裡（尤其是較大的 module），光是看跟整理這些文件，時間會大到讓人覺得是不是先手動改掉就好了。

功能規格 & 技術實作規格

在 speckit 的流程式，簡單概述流程的話，會是 constitution->specify->plan->tasks->implement。每個動作幾乎都會產生相對應的 md 檔案。

在這麼多檔案裡面，功能要放在哪些；而技術實作的又要放在哪邊，她自己基本上是一直都搞不太懂。

註：目前我個人是把功能相關的盡量都放在 specify 產生得文件，技術相關的都放在 plan & tasks。

個人心得

SDD 是一種開發的流程，跟我以前所熟悉的看完需求->分析->改程式流程是不太一樣的。SDD 應該是看完需求->維護規格文件->AI coding。

而我會一直覺得卡，是除了要補足 module 一開始都沒有的規格文件外，要把親手修改程式換成 AI 能執行的規格文件實在是另一大挑戰。

參考連結

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl