Superpowers：讓 coding agent 先定義問題，再開始寫 code

很多 coding agent 的問題不是不會寫，而是太快寫。你只要丟一句需求，它們常常就直接開工，最後交出一段看起來完整，實際上卻缺少上下文與驗證的程式。Superpowers 把這個順序反過來：先問清楚你到底想做什麼，再把需求收斂成 spec，接著拆成可執行的計畫，最後才進入 subagent 驅動的開發流程。

我覺得它最值得看的地方，不是某一個神奇指令，而是它把一套可靠的開發節奏包進了 agent 裡。先理解問題，再對齊設計，再做實作，再做檢查。這個順序很像一位成熟工程師的工作方式，只是它被寫進了可重複執行的 workflow。

它解決的是什麼問題

如果你有用過 coding agent，大概都碰過同一個痛點：

需求還沒釐清，agent 就開始寫程式
結果看起來很多，但真正可合併的內容不多
沒有明確計畫時，後面越改越散
缺少測試節奏，最後只能靠人工收尾

Superpowers 的做法是把這些步驟前移。它不是單純叫 agent 變聰明，而是要求 agent 先停一下，先問目標，再把設計拆成 chunk，讓你有機會在真正動工前看到方向。

它的核心不是提示詞，而是流程

從 README 看，Superpowers 的核心節奏很清楚：

先問你真正想完成什麼
把對話收斂成 spec
將 spec 拆成容易閱讀與審核的小段
在你確認後，生成 implementation plan
進入 subagent-driven development，讓多個 agent 依序執行、檢查與推進

這裡最有價值的地方，是它把「先想清楚」變成強制步驟。很多團隊不是缺 AI，而是缺一個讓 AI 不亂衝的工作節奏。Superpowers 其實是在補這一塊。

我會怎麼開始用它

如果你用的是 Claude Code，最直接的路徑就是官方插件安裝。

/plugin install superpowers@claude-plugins-official

安裝完成後，我不會急著拿它做大專案，而是先拿一個很小但真實的任務測試，例如：

幫現有專案加一個小功能
把一段流程整理成可執行的計畫
讓 agent 先提出 spec，再決定是否要改需求

我想看的不是它一次能不能寫很多，而是它會不會在最前面就把問題問對。只要這一步做對，後面的實作通常會穩很多。

如果你同時在用多個 harness，README 也提醒要分開安裝，因為不同環境的安裝方式不一樣。這點很實際，也很符合它的定位：它不是一個單獨的模型，而是一套跨工具的工作方法。

什麼情況下它特別有價值

我會把 Superpowers 視為以下場景的放大器：

需求常常變動，但又不想每次都從頭講
團隊希望 agent 先做設計，再動手寫碼
你在意測試與審核順序，不想讓 AI 直接衝進實作
你想把 coding agent 變成可預期的協作夥伴，而不是一次性的產出機器

它最適合的不是「什麼都丟給 AI」，而是「我希望 AI 有工程節奏」。如果你的需求本來就很模糊，Superpowers 反而會逼你更早面對模糊點。這不一定舒服，但通常是好事。

我會保留的幾個現實限制

這類工具很容易被誤解成魔法。實際上，Superpowers 仍然有幾個前提：

你要願意參與 spec 與計畫的確認
你要接受 agent 不是一鍵完工，而是要走流程
你還是需要判斷範圍、風險與測試深度

換句話說，它不是要取代工程判斷，而是把工程判斷前置並制度化。這種設計對認真做事的人很友善，但對只想快速亂衝的人，反而可能嫌它太慢。

我的結論

如果把 coding agent 想成一個很會寫字的人，Superpowers 做的事情就是幫它加上工作方法。它沒有承諾神奇增幅，而是把 spec、計畫、TDD、subagent 協作串成一條可重複執行的路線。這也是我覺得它值得寫成文章的原因。

如果你已經開始把 AI 納入開發流程，我會建議你把 Superpowers 當成一個很好的參考案例。它提醒我們一件事：真正有價值的，往往不是更會寫的 agent，而是更會工作的 agent。

參考資料