用 speckit 來試寫一個前一陣子很愛玩的遊戲吸血鬼倖存者，試試看用所謂的 SDD 開發起來感覺如何。（遊戲連結）
不得不說，對於全新開發的專案，我可以很快的就有一個傻瓜版遊戲可以玩，不過但卻也帶給我一些用 AI SDD 開發程式的不同的靈感。
這個問題可能跟 SDD 沒什麼關係，基本上只要是用 AI 來進行開發都可能會有這種狀況。
在這個 side project 裡，因為是要寫網頁遊戲，所以 AI 用了一些前端的框架來實作。但……我不會這些前端框架啊……
所以這遊戲在一開始的確都可以跑，但玩了一、二分鐘之後，整個畫面就停住，然後遊戲就整個卡死再也不動了。
這時候的我，其實也不知道可以做些什麼。因為我連想要找出是哪裡出問題都不會。
更慘的是，照 SDD 流程來走的話，理論上我應該是要回去去把某一個規格文件改到正確，然後讓 AI 再實作一次。但……我連要改哪裡都不知道……
所以我就又回到懶人模式，直接在 AI agent 的視窗，請他幫我找出遊戲會卡住的原因。
就這樣，這個動作來來回回了二、三次，AI 終於幫我把 Bug 給修掉了。
這裡確確實實的印證了一件事，AI 可以加快你的速度，但前提是你自己要「看得懂」，並且你這個「人」也要有能力判斷這個產出到底能不能用。
每當我以為我的規格文件該寫的都有寫到時，AI 的 implement 總是讓我有些小驚喜。像是武器的投擲方向、敵人的移動方式等。
雖然 SDD 的開發方式可預期的就是要不斷的迭代，但是改了好幾次的規格卻實作還是有問題時，還是會讓人有點懷疑人生。
可能已經是習慣性的工程師腦袋，有些東西在腦子裡想的時候是直覺反應，但真的要把它用文字給清楚的寫下來，並且逐條逐條的表列，還真不是件簡單的事。
SDD 對我而言，不止是要練習這個工具怎麼操作，練習怎麼寫規格跟怎麼套進流程裡更是另一項很重要的 to-do 了。
有同仁提醒了我，當我在請 AI 直接幫忙改 bug 的同時，應該也請它順便更新我的規格 md 文件就好。可惜當時沒有想到，只顧著要把問題修好。下一個 SDD 遊戲再來試試看~~
不寫個部落格都不知道怎麼換工作
npm install
npm run dev
iThome鐵人賽
看影片追技術