Superpowers 與 SpecKit 比較

#AI#Claude Code#Superpowers#Speckit

之前寫過一篇 2025 使用 Speckit 的心得感想，用 SpecKit 做了幾個專案後，最近看到另外一套叫 Superpowers 的東西

本來以為只是又一個 slash command 工具包，但裝下去跑過才發現，它和 SpecKit 是完全不同的思路，雖然目標看起來很像（都是要逼 AI 照流程走、不要亂衝）。

用下來的感想，Superpowers 是一套被動觸發的技能庫，而 SpecKit 是一套主動規劃的工作流程。兩者都能解決 Vibe Coding 的混亂，但適合的情境差很多。這篇記錄一下我的觀察。

Superpowers 是什麼

簡單說：它是一包 Claude Code（也支援 Cursor、Codex、OpenCode、GitHub Copilot CLI、Gemini CLI）的 plugin，裡面預先寫好十幾個「skills」，每個 skill 是一組關於「怎麼做某件事」的指示文件。

差別是這些 skill 不用你手動呼叫，Claude 在判斷情境時會自動去找對應的 skill 來參考。比如：

  • 你說「幫我 debug 這個問題」→ 自動觸發 systematic-debugging skill，走四階段根因分析
  • 你說「我想加一個新功能」→ 自動觸發 brainstorming skill，先用蘇格拉底式問題釐清需求
  • 你在寫測試 → 自動觸發 test-driven-development，強制走 RED-GREEN-REFACTOR

安裝也很簡單，一行指令：

/plugin install superpowers@claude-plugins-official

完裝後直接開始對話就可以，不用像 SpecKit 那樣先 init 再建立一整組規格文件。

使用流程（對比 SpecKit）

SpecKit 的流程是先寫文件再寫程式，七個指令從 /speckit.constitution 到 /speckit.implement 一路往下走，每一步都會產出一份文件。

Superpowers 的流程則是在對話中自動介入，你不需要記得什麼時候該呼叫哪個 skill。舉一個實際例子，我要加一個登入功能：

  1. 我說「幫我加一個 email + OTP 登入」
  2. Claude 自動觸發 brainstorming，開始反問我：「要 rate limit 嗎？OTP 幾位數？過期時間？」
  3. 釐清後觸發 writing-plans，把任務拆成 2-5 分鐘可完成的小單位，每個都標好要動哪個檔案
  4. 我確認 plan 後，觸發 executing-plans 開始執行，過程中遇到要寫測試就自動套 test-driven-development
  5. 完成後觸發 requesting-code-review 做自我 review

整個過程我沒有打過任何一個 slash 指令，都是 Claude 自己判斷該套哪個 skill。

對照一下，在 SpecKit 上做同樣這件事，要跑過 /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.tasks → /speckit.implement 這五個指令，每一步都會產出文件。Superpowers 這邊就是一句話講完需求，流程會自己走到對的地方。

使用心得

比起 SpecKit 要記得一套指令、產出一堆文件，Superpowers 的心智負擔明顯更低。它不會逼你先定規章再寫 spec，而是在需要的時候才把方法論帶進來。

對我來說最有感的是 systematic-debugging 這個 skill。以前遇到 bug，Claude 很容易一看到錯誤訊息就開始亂改，改一個地方壞三個。裝了 Superpowers 之後，它會被強制走「重現 → 定位 → 假設 → 驗證」的四階段流程，不准跳步驟。這點在複雜一點的 bug 上真的省了不少來回。

另外 using-git-worktrees 搭配 dispatching-parallel-agents 也很有意思，可以開多個分支同時讓不同 subagent 跑不同任務，回來再統一 review。SpecKit 沒有內建這個，要平行作業得自己手動開多個 session 才能湊出類似效果。

還有一個值得提的是學習曲線。SpecKit 至少要記熟 constitution、specify、clarify、plan、tasks、analyze、implement 這七個指令，才知道每一步該跑什麼。Superpowers 幾乎零學習，裝完就用一般中文或英文跟 Claude 講需求就行，這對剛接觸這類工作流程的人友善很多。

兩者該怎麼選

用下來覺得兩者的定位很不同：

SpecKit 比較適合的情境

  • 全新專案從零開始：因為有 /speckit.constitution 可以先定下規章，整個專案會長得比較整齊
  • 需要把 spec 產出物交接給團隊：每一步都留文件，後續有人要接手時很好讀
  • 長任務但需要階段性 gate：七個指令天然就是七個檢查點，適合重要專案

Superpowers 比較適合的情境

  • 現有專案加功能：不用先建立一整組 constitution 文件，直接對話就能開始
  • 除錯與重構：systematic-debugging 和 verification-before-completion 這兩個 skill 在日常維護工作上很有用，SpecKit 這方面比較弱
  • 需要平行作業：subagent + worktree 的組合能處理多工
  • 不想記指令：自動觸發的設計對我來說比較符合直覺，寫 code 時不用一直想「現在該用哪個 slash」
TIP 兩者其實不衝突。我現在的做法是：全新專案用 SpecKit 開頭定規章、拆 tasks，實作階段再開 Superpowers 輔助 debug 和 code review。兩個都是 Claude Code plugin，可以並存。

不好用的地方

Superpowers 也不是完美的。用下來幾個比較卡的地方：

1. 文件量太大導致 Token 爆炸

它每個 skill 都是一份 markdown 文件，幾十個 skill 加起來文件量不小。雖然是自動觸發（只會載入相關的），但在長對話中還是很容易把 context 吃爆。這點在 Claude Code 5 小時額度上特別明顯，跑兩三個比較重的任務就要等重置。

2. Skill 觸發的判斷有時候會跑掉

理論上 Claude 會自動判斷什麼時候該套什麼 skill，但實際上偶爾會漏觸發，或是明明只是要問個小問題，它卻硬要跑 brainstorming 問一堆。這時候要手動講「不用 brainstorm 直接做」才會停。

3. 沒有 SpecKit 的明確規格產出

因為是隨對話動態觸發的，最後不會像 SpecKit 那樣留下一套結構化文件（spec、plan、tasks）。如果這個專案未來要交接，光看 Superpowers 跑的結果會比較難 trace。

4. 中文環境一樣要提醒

和 SpecKit 同樣的問題，這些 skill 原文都是英文寫的，Claude 跑到後面很容易忘記要用繁體中文回覆或寫註解。開頭或每個大任務前最好都提醒一次。

Token 消耗的比較與省法

兩個工具都會明顯吃 Token，但吃的方式不太一樣，用下來整理出來的觀察：

SpecKit 的 Token 特性

吃 Token 的模式是累積型的。前期 constitution、spec、plan、tasks 產出時會一次性寫大量文件，之後每執行一個 /speckit.implement 任務都會把這些文件重新帶進 context。跑到第 80、90 個任務時，加上中途 SpecKit 自己寫的執行紀錄，每次呼叫載入的內容會越滾越大，這也是上一篇提到「越後面越容易忘記規章」的主因——不是 AI 失憶，是 context 被前面的文件塞滿了。

在 Claude Code 上跑 SpecKit 我大概 2-3 小時就會把 5 小時的額度刷爆。

Superpowers 的 Token 特性

是按需觸發型。它不會一開始就把所有 skill 載進來，而是遇到特定情境才把對應的 skill 內容載入。單次觸發的成本相對低，但如果一個對話裡連續觸發很多 skill（比如 brainstorm → plan → execute → review 全套走一遍），累積起來也不輕。

另外它的自動觸發有時會過度活躍，連小修改也硬要套 brainstorming，這種時候就是在白燒 Token。

建議的省法

幾個實測下來有效的做法：

  • SpecKit 配 VSCode + GitHub Copilot：上一篇就提過了，這個組合額度寬鬆很多，跑長任務比較不怕。Claude Code 留給需要 Superpowers 進階功能（例如平行 subagent）時再用
  • Superpowers 配合 /fork 和 /btw：這是我寫上一篇《還我一個乾淨的對話》後才真正看出來的組合技。當 skill 跑完一個大任務，用 /fork 開乾淨分支跑下一個，避免前面那輪載入的 skill 文件繼續佔 context。側問不重要的小問題用 /btw，不讓它觸發 skill
  • 明確關掉不需要的 skill：Superpowers 有些 skill 對你的情境沒意義，可以在 CLAUDE.md 或系統提示裡直接說「跳過 brainstorming，直接 execute」，省去反覆被問的來回
  • SpecKit 分批 implement：不要一口氣讓它跑 100 個 task，拆成幾批執行，每批之間手動開新對話，就能避免 context 無止境累積

如果真的追求最省，我現在的組合是：用 SpecKit（在 Copilot 上）產出 spec 和 tasks 文件 → 切回 Claude Code 開新對話 → 用 Superpowers 一次實作一批 tasks → 每批結束 /fork 重開。前期規格走便宜通道，執行期享受 Superpowers 的自動化，兩邊都沒被單一工具吃光。

什麼時候其實兩個都不用

最後補一句：這兩個工具都有適合的情境，但也不是什麼專案都需要它們。

像是一些探索型的小腳本、一次性的資料處理、純粹試個想法的 MVP，其實直接 Vibe Coding 比較快。硬要走 SpecKit 七個指令或是觸發 Superpowers 一整套 skill，反而讓簡單的事變複雜，也浪費 Token。

我自己的經驗是：預期會寫 200 行以內、不會有人接手、功能單一的東西，就直接跟 Claude 講話寫就好；會長期維護、有架構決策、或是需要留下文件的，才需要這兩個工具出場。

總結

如果要用一句話定位：

  • SpecKit = 規格驅動的「專案開始的安裝精靈」，適合新開專案時把整套流程定清楚
  • Superpowers = 方法論內化的「對話助理」，適合在既有工作流程中幫你守住品質底線

我目前的用法是兩者並用，SpecKit 處理「要做什麼」的前期規劃，Superpowers 處理「怎麼做得更穩」的日常執行。如果只能選一個，全新專案我選 SpecKit，維護既有專案我選 Superpowers。

留言