Superpowers 框架解析：給 AI 戴上「緊箍咒」，用鐵血紀律逼出高品質程式

如果你用過一段時間的 AI 輔助開發，肯定遇過這個情境：

你叫 AI 加一個小功能，它不到兩秒就回答：「✅ 已經完成，而且測試過了唷！」你興高采烈地打開頁面，結果畫面直接崩潰（白屏幕），或是你發現它根本沒有跑任何測試，甚至還偷偷幫你改了其他不相關的檔案。

這就是現在 AI Coding 最缺乏的東西：紀律。

在 AI Coding Orchestration Workflow 概序裡，我們提到了三種框架流派。GSD 走的是「平行加速」，而這次我們要看的 Superpowers 則是標準的「流程紀律派」。它不追求多快把 code 寫完，而是強迫 AI 遵守嚴格的軟體工程規範。用通俗的話說，就是給 AI 戴上「緊箍咒」。

圖說：Superpowers 強調從需求釐清、計畫制定到嚴格執行、審查的連貫紀律。

什麼是 Superpowers？

簡單來說，Superpowers 是 15 個以 Markdown 寫成的「技能（Skills）」文件。

每次你打開 AI (例如 Claude Code)，啟動這個框架時，它會掛載一個 using-superpowers 的入門技能，讓 AI 從一開始就被「洗腦」，必須遵循接下來的標準工作流。這個工作流涵蓋了：需求釐清、寫計畫、TDD（測試驅動開發）、系統性除錯，以及兩層次的 PR Code Review。

這套框架最讓我驚豔的，是它的「防小人」設計。這份框架的撰寫者就像是被 AI 坑過無數次的資深工程師，在所有 AI 可能「找藉口」的地方，都設置了嚴厲的路障。

核心亮點一：沒有 TDD，就直接刪 Code

AI 非常喜歡本末倒置：先把 code 寫完，然後補個「總是會通過的假測試」來交差。

Superpowers 裡面的 test-driven-development 技能規則是這樣寫的： 「NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Write code before the test? Delete it. Start over.」

你沒看錯，它教 AI：如果你先寫了產品環境的程式碼，請你把它刪掉，裝作沒這回事，從寫一個會失敗的測試開始做起。這堵死了所有 AI 的狡辯：

(AI 藉口一)「這太簡單了不用測」=> 不行，簡單的也會出錯。
(AI 藉口二)「我已經手動測試過了」=> 不行，手動測試無法記錄跟自動重跑。
(AI 藉口三)「可是我刪掉會浪費工作時間」=> 不行，沉沒成本謬誤，留著未經驗證的 code 才是毒藥。

而且，如果 AI 一寫完測試就順利跑過，它會被框架要求回去檢查：「你這測試是不是測錯東西了？」這種「字面上的合規，就是精神上的合規」的強迫症設計，才是真正能治好 AI 偷懶的解藥。

核心亮點二：系統性除錯（不要亂猜！）

當 code 報錯的時候，普通 AI 是怎麼解決的？它通常會看一眼錯誤，然後說「抱歉我明白了！」，接著換一種寫法，再錯，再換一種寫法（進入了「隨機除錯鬼打牆」環節）。

Superpowers 下令禁止這種行為，並透過 systematic-debugging 制定了四階段的除錯機制：

根因調查：仔細讀錯誤訊息，不要只看一行。在邊界打 Log，確認變數變化，一定要能「穩定重現」。
模式分析：找現有 codebase 裡的正確範例做比對。
假說與測試：提出假說，一次只改一個地方驗證。如果假說失敗，重新提新的，不能在錯誤方向繼續加 code。
實作：先寫重現問題的測試再修補。如果修了三次還沒好，就要停下來問架構是不是有根本性問題？

這個細節值得一偷：條件等待 (Condition-based waiting)

在寫自動化測試的錯誤重現時，AI 很喜歡「等個 50 毫秒看看」。但網路和伺服器延遲是不穩定的！所以 Superpowers 教導 AI，永遠不要猜需要等多久，你必須輪詢或是等到你真正判斷的條件出現為止！這種針對 AI 常犯錯誤的特化調教，就是我們讀這套框架時該帶回家的寶藏。

核心亮點三：兩階段審查（Two-Stage Review）

當一個階段小任務完成時，Superpowers 定義了一個 subagent-driven-development 的審查流程。這是我認為非常有效的一個切點分工：

兩階段審查（順序絕對不可對調）

Stage 1：規格符合性審查 (Spec Compliance Review)
只看一件事：這是不是我們要的東西？不多做（YAGNI），也不少做。

Stage 2：程式碼品質審查 (Code Quality Review)
確認規格對了，才進入這裡：看測試有沒有寫好、乾不乾淨。

為什麼這很重要？因為我們最怕的就是 AI 花了半天時間，重構出一段「超級優雅、無懈可擊，但完全不是我們要的功能」的程式碼。如果審查順序反過來，我們先檢查了程式碼品質，那所有的 effort 在發現規格不符時就等於全變成廢物了。

這套方法論的取捨

就像「給 AI 超能力？Superpowers 的設計與取捨」這篇文章作者提到的，Superpowers 的設計非常有攻擊性與強制力。

但這也是它的致命缺點：它會把你的執行週期拖得超級長。一個原本只需要加三行程式碼的任務，在 Superpowers 的框架下，AI 可能要問問題、列計畫、寫測試、發 PR、自我 Review 兩次。如果你只是想快點寫個一次性的小腳本，用這套會讓人非常有挫折感。

=> 但對於大型、需要長期維護的核心系統，這套紀律就非常值錢了。

我們的下一步

我們已經看過 GSD 如何透過 Orchestrator 拆解目標進行「橫向擴展 (平行化)」，現在也看過 Superpowers 透過流程卡關來確保「縱向品質 (深度)」。接下來，你可以反思在自己的工作流中，哪幾個步驟是你可以拔出來直接塞給身邊的 AI（像 Cursor 或 Claude Code），將這些限制與紀律加進 System Prompt 的！

我們下一篇見！