Superpowers 是什麼?Claude Code TDD 框架完整教學(2026)
Superpowers 是一套讓 Claude Code 強制遵守 TDD 紀律的技能框架——沒寫測試就刪 code、沒驗證不能說做完。這篇教學說明怎麼安裝、核心設計,以及跟 GSD 框架的差別。
目錄
系列文章地圖
點節點可以直接跳到那一篇。
Superpowers 是什麼? 一套 Claude Code 的紀律框架,透過 15 個技能強制 AI 在寫完測試、驗證結果之前不能宣稱任務完成,解決 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 的!
我們下一篇見!
相關文章
Claude Code /verify 指令教學:內建自動驗證怎麼用(2026)
Claude Code /verify 完整教學 | 內建驗證指令怎麼用、/run-skill-generator 錄製啟動配方、commit 前自動驗證的條件,以及什麼時候還是要自己寫 verify skill。
AI-native SDLC 是什麼?Anthropic 官方 Playbook 重點整理(2026)
AI-native SDLC 重點整理 | Anthropic 官方 playbook 把開發流程從線性改成迴圈,每個階段 commit 一個 artifact 交給下一階段:intent.md、spec.md、plan.md、evals、PR review。
Claude Code 多 Agent 怎麼管:Handoff + Takeover,只盯一個主 Agent(2026)
Claude Code 多 agent 管理經驗 | agent 一多很容易忘了叫哪個 AI 做什麼。我的做法是先命名、讓 AI 提案並把建議分級、討論完 handoff 成文件,再交給一個主 agent takeover。
留言討論
Facebook 留言