Superpowers 使用心得：從翻車到上手
整理版優先睇
Superpowers 係一套結構化軟件工程流程，用前要先練好AI編程基本功
作者係Claude Code嘅原教旨主義者，一直唔裝插件，想先將原生功能用透。但Superpowers被身邊人反覆推薦，加上自己對Claude Code已經好熟，就決定試一試。佢想透過呢篇文章分享點樣有效使用Superpowers，避免翻車。整體結論係：先練內功（理解AI邊界），再上裝備；用好工具，但唔好放棄判斷力。
Superpowers本質係將成熟嘅軟件工程實踐——TDD、代碼審查、分支隔離、任務拆分——系統性封裝成一個可執行嘅工作流，分為七個階段：頭腦風暴、隔離開發環境、編寫計劃、Sub-agent分發執行、測試驅動開發、代碼審查、收尾。對唔熟悉呢套流程嘅人嚟講，佢係一個好嘅腳手架。
作者實測兩次，第一次失敗，第二次調整後成功。失敗教訓係執行階段冇果斷取捨，硬推做唔好嘅步驟。成功嘅關鍵係喺每個確認環節真正停下來審視，該砍就砍。佢建議初學者唔好一嚟就用Superpowers，要從小工具、小功能開始，透過不斷造輪子練習對AI嘅掌控力，理解能力邊界。最終角色要從執行者轉向規劃者同決策者。
- Superpowers本質係將TDD、代碼審查、分支隔離等成熟實踐封裝成可執行工作流，分七個階段
- 唔好一嚟就用Superpowers，要先熟練Claude Code原生功能，理解AI能力邊界
- 實測發現Superpowers無法完全自動化重構大型項目，人的判斷仍然不可或缺
- 失敗教訓：執行階段要果斷取捨，硬推難以完成的步驟只會累積不確定性
- 初學者應從小項目開始，透過不斷造輪子練習對AI的掌控力，角色轉向規劃與決策
Superpowers 係咩？唔係超能力，係流程架構
作者一開始係Claude Code嘅原教旨主義者，認為插件會俾人一種「我已經掌握咗」嘅錯覺，問題被繞過，基礎冇打實。但Superpowers唔同，佢本質係一套結構化嘅軟件工程流程，將完整開發週期拆成七個階段。
- 1 頭腦風暴：透過蘇格拉底式提問，產出設計文檔，避免一句話開幹
- 2 隔離開發環境：用Git Worktree搭建獨立工作空間，唔會污染主分支
- 3 編寫計劃：將設計拆成2-5分鐘嘅微任務，標註文件路徑同驗證步驟
- 4 Sub-agent分發執行：派獨立sub-agent執行，做完兩階段審查
- 5 測試驅動開發：嚴格嘅RED-GREEN-REFACTOR循環，跳過測試會要求重來
- 6 代碼審查：對照計劃逐項檢查，嚴重問題會阻斷後續進度
- 7 收尾：驗證測試通過後，提供合併、PR等選項
所以Superpowers無真正嘅超能力，只係將TDD、代碼審查等實踐系統化。對唔熟悉呢套流程嘅人，佢係一個好嘅腳手架。
實測：一次翻車，一次成功
作者兩次實測，第一次失敗，第二次調整後成功。呢個經驗令佢更清楚Superpowers嘅能力邊界：佢並唔能夠實現完全自動化重構，尤其喺代碼量巨大、歷史悠久的項目。社區啲「AI從零寫編譯器」案例，細睇其實經唔起推敲。
第一次失敗嘅最大教訓係：雖然有清晰嘅任務計劃，但執行時冇果斷判斷「邊啲該做、邊啲唔該強推」。有啲步驟做唔好就應該留到下一步，唔好硬住頭皮衝。
第二次佢學識咗喺每個確認環節真正停下來審視，該砍就砍，該延後就延後，結果順利完成。呢個經驗嘅核心係：AI嘅參與需要人喺關鍵位把關。
俾初學者嘅建議：先練內功，再上裝備
作者明確建議：唔好一嚟就用Superpowers，亦唔好直接上大項目。應該先從小工具、小功能開始，例如搭一個簡單網站或者改一個小bug，用Claude Code自帶嘅plan模式走一遍「先規劃、再執行」嘅流程。
透過呢個過程，你會慢慢感受到AI編程嘅邊界：邊啲嘢佢做得好，邊啲容易翻車，幾時要介入。用武俠嘅話講：「內功唔夠就強練高階功法，容易走火入魔。」
咁點樣練內功？就係不斷造輪子。以前係練習編程能力，而家係練習對AI嘅掌控力——瞭解佢嘅能力邊界，知道幾時信佢、幾時接管。呢種感覺要靠實踐積累，手感係練出來嘅。
另外，唔好一股腦接受AI嘅建議。Superpowers每個階段都有確認環節，唔係要你無腦撳「繼續」嘅。你要睇、要諗、要判斷邊啲位唔對路，該查資料就去查。
作者一句總結：「先練內功，再上裝備；用好工具，但別丟了判斷力。」
我嘅立場：先將原生能力用到盡
我係一個 Claude Code 嘅「原教旨主義者」——由佢發佈到而家，我基本上唔裝插件。
原因好簡單：社區裏面嘅插件好壞參差，好多睇落好勁，實際體驗一般。更加重要嘅係，如果你未將原生功能用到盡就急住用插件，插件會畀你一種「我已經掌握咗」嘅錯覺——問題被插件繞過咗，但基礎冇真正打穩。
但 Superpowers 的確有啲唔同。身邊有人不斷推薦，加上我對 Claude Code 本身已經比較熟悉，覺得係時候試嚇喇。
Superpowers 到底係乜嘢
揭開神秘面紗，Superpowers 本質上係一套結構化嘅軟件工程流程，將一個完整嘅開發週期拆成七個階段：
1. 腦震盪（Brainstorming）：喺動手之前，透過蘇格拉底式嘅提問，將需求、方案、技術選型、潛在問題都攤開諗清楚，最後出一份設計文檔。好多人習慣「一句說話就開工」，簡單任務就冇問題，但複雜項目往往衰喺呢度——你以為自己知道要做乜，但可能仲有更好嘅方案未被考慮到。到執行階段先發現方向唔啱，翻工成本好高。 2. 隔離開發環境（Using Git Worktrees）：設計通過後，Superpowers 會自動建立 Git Worktree，喺獨立分支上面搭建隔離嘅工作空間，並驗證測試基線係咪乾淨。咁樣你嘅實驗性代碼就唔會污染主分支。 3. 編寫計劃（Writing Plans）：將設計文檔拆解成一系列 2–5 分鐘嘅微任務，每個任務都標註咗具體嘅檔案路徑、預期代碼同驗證步驟。同普通嘅 Claude Code plan 唔同，呢度嘅粒度更細，可審查性更強。 4. Sub-agent 分發執行（Subagent-Driven Development）：確認計劃後，Superpowers 為每個任務派發獨立嘅 sub-agent 執行，執行完成後進行兩階段審查——先檢查係咪符合 spec，再審查代碼質素。 5. 測試驅動開發（Test-Driven Development）：呢個係 Superpowers 嘅一個核心特色。成個實現過程入面，嚴格執行 RED-GREEN-REFACTOR 循環：先寫一個會失敗嘅測試，確認佢確實失敗咗，再寫最少嘅代碼等佢通過，然後提交。如果 Claude 諗住跳過測試直接寫代碼，Superpowers 會叫佢刪咗重新嚟過。 6. 代碼審查（Requesting Code Review）：每完成一個任務塊，自動觸發代碼審查，對照計劃同編碼規範逐項檢查。嚴重問題會阻礙後續進度，一定要先修復先可以繼續。 7. 收尾（Finishing a Development Branch）：所有任務完成後，驗證測試通過，然後提供合併、建立 PR、繼續開發或丟棄分支等選項，最後清理 worktree。
所以佢並冇乜嘢真正嘅「超能力」，佢只係將成熟嘅軟件工程實踐——TDD、代碼審查、分支隔離、任務拆分——系統性咁封裝成一個可執行嘅工作流程。對於唔熟悉呢套流程嘅人嚟講，呢個係一個好好嘅腳手架。
我嘅實測：一次失敗，一次成功
瞭解咗 Superpowers 係乜之後，講下我嘅實際體驗。
上手之後，第一次明顯失敗咗，第二次調整之後成功。兩次經驗令我對佢嘅能力邊界有咗更清晰嘅認識。
Superpowers 並唔能夠實現完全自動化重構。 面對代碼量好大、歷史悠久嘅項目，指望一句話就等 AI 重寫，目前仲係天方夜譚。社區入面嗰啲「AI 從零寫編譯器」「AI 自己造瀏覽器」嘅案例，仔細睇落往往經唔起推敲。
根本原因在於：AI 嘅每一步操作都包含不確定性，呢啲不確定性會逐步累積，最終導致結果偏離預期。人嘅參與同判斷，仍然不可或缺。
我第一次失敗時最大嘅教訓就係：雖然有咗清晰嘅任務計劃，但喺執行過程中冇果斷判斷「邊啲應該做、邊啲唔應該夾硬嚟」。有啲步驟當下做唔好，就應該留到下一步，而唔係死頂落去。第二次我學識咗喺每個階段嘅確認環節真正停落嚟審視，該斬嘅果斷斬，該延後嘅唔硬上，反而順利完成咗。
俾初學者嘅建議：先練內功，再上裝備
結合我嘅經驗，俾初學者一條明確嘅建議：唔好一開頭就用 Superpowers，都唔好直接上大項目。
先由細工具、細功能開始——整一個簡單嘅網站，改一個細 bug，用 Claude Code 自帶嘅 plan 模式行一次「先規劃、再執行」嘅流程。喺呢個過程入面，你會慢慢感受到 AI 編程嘅邊界：邊啲嘢佢做得好，邊啲位容易出事，幾時應該介入。
用武俠嘅話講：內功唔夠就夾硬練高階功法，容易走火入魔。
咁點樣練呢個「內功」？
不停造輪子。 以前我哋透過重複造輪子來練習編程能力，而家我哋透過重複造輪子來練習對 AI 嘅掌控力——瞭解佢嘅能力邊界，知道幾時應該信任佢，幾時應該接手。呢種感覺必須靠實踐累積，別人只可以話畀你方法論，但手感係練出嚟嘅。
唔好一味接受 AI 嘅建議。 Superpowers 嘅每個階段都會叫你確認，呢啲確認環節唔係叫你無腦㩒「繼續」。你要睇，要諗，要判斷邊啲位唔啱、邊啲位含糊，該查資料就去查。
角色轉變，而唔係能力退化。 用 AI 工具並唔代表你可以做甩手掌櫃。我哋嘅角色係由「執行者」轉向「規劃者」同「決策者」——呢個唔係降級，而係升級。但前提係，你真係具備規劃同決策嘅能力，而唔係淨係「我要呢個、我要嗰個」嘅需求轉發器。
以上就係我今次嘅分享。一句話總結：先練內功，再上裝備；用好工具，但唔好冇咗判斷力。
我的立場：先把原生能力用透
我是一個 Claude Code 的"原教旨主義者"——從它發佈到現在，我基本不裝插件。
原因很簡單：社區裏的插件良莠不齊，很多看起來很厲害，實際體驗一般。更重要的是，如果你還沒把原生功能用透就急着上插件，插件會給你一種"我已經掌握了"的錯覺——問題被插件繞過去了，但基礎並沒有真正打牢。
但 Superpowers 確實不太一樣。身邊有人反覆推薦，加上我對 Claude Code 本身已經比較熟悉了，覺得是時候試一試了。
Superpowers 到底是什麼
揭開神秘面紗，Superpowers 本質上是一套結構化的軟件工程流程，把一個完整的開發週期拆成了七個階段：
1. 頭腦風暴（Brainstorming）：在動手之前，通過蘇格拉底式的提問，把需求、方案、技術選型、潛在問題都攤開想清楚，最終產出一份設計文檔。很多人習慣"一句話開幹"，簡單任務沒問題，但複雜項目往往栽在這裏——你以為自己知道要做什麼，但可能還有更好的方案沒被考慮到。在執行階段才發現方向不對，返工成本很高。 2. 隔離開發環境（Using Git Worktrees）：設計通過後，Superpowers 會自動創建 Git Worktree，在獨立分支上搭建隔離的工作空間，並驗證測試基線是否乾淨。這樣你的實驗性代碼不會污染主分支。 3. 編寫計劃（Writing Plans）：將設計文檔拆解為一系列 2–5 分鐘的微任務，每個任務都標註了具體的文件路徑、預期代碼和驗證步驟。和普通的 Claude Code plan 不同，這裏的顆粒度更細，可審查性更強。 4. Sub-agent 分發執行（Subagent-Driven Development）：確認計劃後，Superpowers 為每個任務派發獨立的 sub-agent 執行，執行完成後進行兩階段審查——先檢查是否符合 spec，再審查代碼質量。 5. 測試驅動開發（Test-Driven Development）：這是 Superpowers 的一個核心特色。在整個實現過程中，嚴格執行 RED-GREEN-REFACTOR 循環：先寫一個會失敗的測試，確認它確實失敗了，再寫最少量的代碼讓它通過，然後提交。如果 Claude 試圖跳過測試直接寫代碼，Superpowers 會讓它刪掉重來。 6. 代碼審查（Requesting Code Review）：每完成一個任務塊，自動觸發代碼審查，對照計劃和編碼規範逐項檢查。嚴重問題會阻斷後續進度，必須先修復才能繼續。 7. 收尾（Finishing a Development Branch）：所有任務完成後，驗證測試通過，然後提供合併、創建 PR、繼續開發或丟棄分支等選項，最後清理 worktree。
所以它並沒有什麼真正的"超能力"，它只是把成熟的軟件工程實踐——TDD、代碼審查、分支隔離、任務拆分——系統性地封裝成了一個可執行的工作流。對不熟悉這套流程的人來說，這是一個很好的腳手架。
我的實測：一次失敗，一次成功
瞭解了 Superpowers 是什麼之後，聊聊我的實際體驗。
上手之後，第一次明顯失敗了，第二次調整後成功。兩次經歷讓我對它的能力邊界有了更清晰的認識。
Superpowers 並不能實現完全的自動化重構。 面對代碼量巨大、歷史悠久的項目，指望一句話就讓 AI 重寫，目前還是天方夜譚。社區裏那些"AI 從零寫編譯器""AI 自己造瀏覽器"的案例，細看下來往往經不起推敲。
根本原因在於：AI 的每一步操作都包含不確定性，這些不確定性會逐步累積，最終導致結果偏離預期。人的參與和判斷，仍然不可或缺。
我第一次失敗時最大的教訓就是：雖然有了清晰的任務計劃，但在執行過程中沒有果斷判斷"哪些該做、哪些不該強推"。有些步驟當下做不好，就應該留到下一步，而不是硬着頭皮往前衝。第二次我學會了在每個階段的確認環節真正停下來審視，該砍的果斷砍，該延後的不硬上，反而順利完成了。
給初學者的建議：先練內功，再上裝備
結合我的經歷，給初學者一條明確的建議：不要一上來就用 Superpowers，也不要直接上大項目。
先從小工具、小功能開始——搭一個簡單的網站，改一個小 bug，用 Claude Code 自帶的 plan 模式走一遍"先規劃、再執行"的流程。在這個過程中，你會慢慢感受到 AI 編程的邊界：哪些事情它做得好，哪些地方容易翻車，什麼時候該介入。
用武俠的話說：內功不夠就強練高階功法，容易走火入魔。
那怎麼練這個"內功"？
不斷造輪子。 以前我們通過重複造輪子來練習編程能力，現在我們通過重複造輪子來練習對 AI 的掌控力——瞭解它的能力邊界，知道什麼時候該信任它，什麼時候該接管。這種感覺必須靠實踐積累，別人只能告訴你方法論，但手感是練出來的。
不要一股腦地接受 AI 的建議。 Superpowers 的每個階段都會讓你確認，這些確認環節不是讓你無腦點"繼續"的。你得看，得想，得判斷哪些地方不對、哪些地方含糊，該查資料就去查。
角色轉變，而非能力退化。 使用 AI 工具並不意味着你可以當甩手掌櫃。我們的角色是從"執行者"轉向"規劃者"和"決策者"——這不是降級，而是升級。但前提是，你真的具備規劃和決策的能力，而不只是"我要這個、我要那個"的需求轉發器。
以上就是我這次的分享。一句話總結：先練內功，再上裝備；用好工具，但別丟了判斷力。