我試過 spec-kit 和 superpowers,最後選 superpowers——三個實測理由
選 agent 工作流的時候,大多數比較表都在比功能:支援幾種模型、有沒有 plan mode、能不能跑 subagent。我兩個主流都實際跑過——spec-kit 和 superpowers——最後選了 superpowers。但我的理由跟功能清單沒什麼關係,而是一個更難量化的問題:哪些紀律是被機制逼出來的,哪些只是寫在 prompt 裡求模型自律。
先講 skill 出現之前我怎麼做
還沒有 skill 這個東西之前,我的標準流程是手動的:先要 AI 讀完相關的 Markdown(把脈絡灌進去)、確認它理解的做法跟我一致、才讓它動手。這就是後來大家叫的 context engineering,只是當時得我自己每次盯著走完。
skill 出來之後,真正打動我的不是它新增了什麼能力,而是它把「讀脈絡 → 確認意圖 → 才動手」這個原本要人盯的迴圈,寫成了模型每次自動會走的流程。從「我每次手動灌」變成「我寫一次、它每次自己跑」。理解這一點,後面兩個理由才講得通——好的 skill 不是給模型更多自由,是把原本靠我盯的紀律固定下來。
理由一:TDD 的強制落在哪一層——spec-kit 在 template,superpowers 在 red-green 迴圈
兩邊都預設要你先寫測試,這點 spec-kit 並不輸——它的 template 會把測試任務排在實作之前。差別不在有沒有,而在強制落在哪一層。
spec-kit 的 test-first 是靠 template 約束模型的產出順序:它把「先寫測試」寫進指示,引導模型照著做。但說到底,執行的還是模型——它有沒有真的照順序走、有沒有真的讓測試先紅再綠,仰賴它讀懂並遵守那套結構。superpowers 的 TDD 則更接近機制驅動:紅燈、綠燈、重構卡在實際的測試結果上,模型想跳過,流程不讓。
這個差別在弱一點的模型上會立刻放大。靠 template 約束、要模型自己守順序的那套,模型狀態好就走得對、狀態差就漏(spec-kit 社群裡也有人抱怨它有時只是生出一堆看起來像在做事的文字);被實際 red-green 迴圈逼著小步走的那套,穩定得多。同一個模型之下,我要的是後者那種不靠模型自覺的穩,所以選它。
理由二:systematic-debugging 逼出 root cause,擋住「猜了就改」
這是我用下來覺得最有價值的一塊。
AI 除錯最常見的失敗,不是它不會修,而是它把自己覺得機率最高的那個錯,直接拿去解。看起來在動工,實際上在賭。賭對了你以為它很強,賭錯了它改了一圈把問題搬到別的地方。
superpowers 的 systematic-debugging 做的事,是先逼它講清楚 root cause、提出假設、再去驗證,然後才准動手改。它把除錯從「憑直覺出手」變成「先定位、後驗證」。這跟理由一其實是同一件事的兩面:不確定的環節,用流程鎖住,不交給模型的直覺。
共同的那條線
把三點接起來,我選 superpowers 的真正理由只有一句:它把關鍵的紀律從「希望模型記得」變成「流程強制它做」。
skill 把灌脈絡這件事制度化、TDD 把小步前進這件事 script 化、systematic-debugging 把先定位這件事變成必經關卡。它們的共通點都不是讓模型更聰明,而是讓我不必賭模型每次都自覺。
這也是我後來一切都建在 superpowers 上的原因。工具選型對我而言,從來不是挑那個在好模型上跑得最漂亮的,而是挑那個在普通模型上也不會崩的——因為我大多數時候,用的就是普通的、租來的模型。
來源
- spec-kit 預設以 template 強制 test-first(測試任務排在實作前):github/spec-kit 的 spec-driven 文件與官方說明
- spec-kit「生出一堆看起來像在做事的文字」的社群批評:github/spec-kit Discussion #1784