Claude Code進階：用 Superpowers 打造靠得住的 AI 開發工作流程

一、日常開發的痛點

大家好，我是卡卡。

相信很多人現在用 AI 寫程式已經很日常了。Cursor、Claude Code、Copilot，工具換了又換，模型也越來越強——Claude 4.6、GPT-5.4，寫程式的能力確實沒話說。隨便丟個需求過去，它能給你吐出一整段甚至整個專案的程式碼，看起來很厲害。

可能這也跟我們使用的模型有關，最新的模型確實聰明，能理解複雜的上下文，也能寫出品質不錯的程式。甚至在某些場景，比我們自己寫得還規範、還快。

但是不可否認的是，大多數人用 AI 程式開發的方式，其實跟幾年前沒太大差別——就是「提需求，等結果」。

例如我們說一句「幫我加個登入功能」，AI 給我們一段程式碼。我們看了覺得還行，複製貼上去。跑一下，出錯了。再讓 AI 改。改完又出錯，或者功能跟我們要的不一樣。來回折騰好幾輪，最後發現 AI 根本沒理解我們真正想要什麼。

更糟的是，AI 寫完的程式碼看似能跑，但沒寫測試、沒考慮邊界情況、沒留文件。等我們過段時間再回頭看，根本不知道當初寫了什麼、為什麼那麼寫。後面接手的人更是一頭霧水。

其實問題不在於 AI 不夠強，而是我們跟 AI 的合作方式從一開始就有問題。我們把它當成一個「去做事的人」，丟個需求就等結果。但軟體開發不是這麼簡單——需求要理清、方案要設計、測試要先寫、寫完還要驗證。這些環節以前靠自己自覺去做，現在指望 AI，但 AI 並不會主動幫我們走完這些流程。

於是就變成：AI 寫程式很快，但返工更頻繁。我們看似效率提升了，實際產出品質並沒有真正提高。

二、Skills 和 MCP 能帶來什麼

那有沒有辦法讓 AI 不只是「寫程式」，而是按照一套可靠的流程來幫我們做事？

這就要提到目前很火的 Skills 和 MCP 了。

簡單來說，Skills 就是一套預設好的「工作流程範本」，MCP 則是讓 AI 能連上更多外部工具與資料來源。這兩樣東西配合起來，AI 就不只是「寫程式的機器」，而是能按照我們設定的流程一步步做事——先理解需求、再寫計畫、再實作、再驗證。

我們前面提到的那些問題——需求理解偏差、沒寫測試、邊界情況沒考慮、文件缺失、返工成本高——這些其實都是「流程缺失」導致的。有了 Skills，這些環節就不是會被忘記的問題，而是 AI 會主動提醒我們、甚至強制要求走完這些步驟。

例如有的 Skill 會在我們說「寫個功能」的時候，先停下來問清楚需求細節；有的 Skill 會強制我們先寫測試再寫實作；有的 Skill 會在我們聲稱完成後，強制跑一遍檢查，確保真的完成。

所以 Skills 和 MCP 的價值，本質上不是讓 AI 變更聰明，而是讓 AI 變得更可靠。聰明是模型的事，可靠是流程的事。模型再聰明，流程不對，結果也是一團糟。流程對了，模型哪怕沒那麼強，產出也更穩定、更可控。

三、Superpowers 技能介紹

既然 Skills 能幫我們把開發流程變得更可靠，那具體要裝哪個？有沒有一套現成的框架，把常用的 Skill 都整合好，裝完就能用？

這裡我要提到 Superpowers。

Superpowers 是目前 Claude Code 社群裡最熱門的 Skills 框架之一，專門用來強化 AI 的開發流程。它內建了好幾個 Skill，覆蓋了從需求理解到程式驗證的整個開發周期。我們前面說的那些問題——需求沒理清楚、測試沒寫、寫完不驗證——Superpowers 都有對應的 Skill 來解決。

相信很多同學在程式提效方面都聽過或安裝過 Superpowers。但具體要怎麼用，可能還是不太清楚。

很多同學裝完之後，每天寫程式還是原本的對話模式——「幫我寫個功能」、「幫我改下這段程式」。Skills 放在那裡，什麼時候該用哪個、怎麼觸發、觸發後會是什麼樣子，仍是一頭霧水。甚至很多人以為這些 Skill 是自動生效的，裝完就不用管了，結果發現寫程式的方式一點都沒變。

今天這篇文章，我們就來聊聊 Superpowers 的每個 Skill：什麼時候用、怎麼觸發、觸發後會是什麼樣子、能解決什麼問題。

四、Superpowers 的運作方式

那 Superpowers 具體是怎麼工作的？先建構一個整體認知。

Superpowers 的核心理念很簡單，就是四個步驟：設計 → 計畫 → 測試 → 品質（Design → Plan → Test → Quality）。

簡單說就是在寫程式之前，我們先想清楚要做什麼（設計）；想清楚之後，把任務拆成一步步的計畫（計畫）；開始寫程式時，先寫測試再寫實作（測試）；最後在說「完成」之前，必須跑驗證確認沒問題（品質）。

這套流程不是可選的，而是強制執行的。AI 每走完一個階段都會停下來，等我們確認才繼續下一步，不會自己偷偷跳過。這樣我們始終能掌握關鍵節點，而不是讓 AI 一路跑到底再回頭看。

我們來比較一下，沒有 Superpowers 與有 Superpowers 之後，寫程式的方式差異：

GitHub 程式碼倉庫在這裡，如果有興趣可以去看看原始碼：
https://github.com/obra/superpowers

Superpowers 內建的 Skill 可以分成兩類：自動觸發與手動觸發。

自動觸發：AI 偵測到特定場景後會自動呼叫，無需我們主動輸入命令。例如：

• brainstorming：偵測到要做新功能開發時，自動停下來問清楚需求
• systematic-debugging：偵測到 bug 或測試失敗時，自動進入除錯流程
• test-driven-development：開始實作功能時，要求先寫測試
• verification-before-completion：我們說「完成了」時，自動跑驗證檢查

手動觸發：需要我們主動輸入命令或明確告訴 AI 使用哪個 Skill。例如：

• writing-plans：輸入 /superpowers:writing-plans 觸發
• using-git-worktrees：輸入 /superpowers:using-git-worktrees 觸發
• dispatching-parallel-agents：輸入 /superpowers:dispatching-parallel-agents 觸發
• requesting-code-review：輸入 /superpowers:requesting-code-review 觸發

整體執行流程大致如下：每個階段都是一個關卡，AI 走到這裡會停下來等我們確認或決策。我們始終掌握關鍵節點，不會讓 AI 一路跑到終點再回頭看。

五、技能總覽

Superpowers 內建了 13 個 Skill，每個都有特定用途。但對於初學者來說，先掌握核心流程就夠了。

核心流程其實就是從需求開始到工作完成的完整主線，一共 6 個技能：

• brainstorming —— 需求理解，寫程式前先把要做的事弄清楚
• writing-plans —— 編寫計畫，把任務拆成明確步驟
• subagent-driven-development —— 用子代理並行執行計畫（推薦）
• executing-plans —— 依序執行計畫（備選）
• verification-before-completion —— 完成驗證，說完成之前必須跑檢查
• finishing-a-development-branch —— 工作收尾，完成後決定合併或保留分支

subagent-driven-development 與 executing-plans 都是用來執行計畫的，只是方式不同：前者用子代理並行處理，後者一步步順序執行。選一個就行，大多數情況推薦前者。

學會這 6 個技能，日常開發就能用 Superpowers 的方式運作：先理解需求，再寫計畫，再按計畫執行，執行完驗證，驗證完再整合。每一步都有章法，不再是「提需求 → 等程式碼」的原始模式。

其他技能在特定場景也很實用，下面簡單介紹：

下面會把核心流程的 6 個技能逐一拆開說明：什麼時候用、怎麼觸發、觸發後長什麼樣、能解決什麼問題。

六、核心技能詳解

6.1 brainstorming —— 先搞清楚要做什麼

每次想做新功能、新模組、新元件時，先別急著讓 AI 寫程式。這時 brainstorming 會自動觸發，幫我們把需求理清楚。

例如我在 Claude Code 詢問「我想設計一個廣告回傳功能」，AI 不會直接寫程式，而是先觸發 brainstorming，然後一步步問清楚需求。

這個技能是自動觸發的。當 AI 偵測到我們要做新功能開發時，會自己進入 brainstorming 流程。觸發後會看到類似的提示：

Skill(superpowers:brainstorming) Successfully loaded skill

這時 AI 會先搜尋專案中相關的邏輯，了解上下文，然後開始提問。

提問是一步步進行，而不是一次丟一大堆問題。例如我要做廣告回傳功能，AI 可能會如此提問：

就這樣一步步問，直到把需求細節都弄清楚。問完之後 AI 會說：

我已經收集了足夠的資訊，現在讓我提出設計方案。

接著它會給我們一個設計方案，包含架構思路、關鍵模組、資料流程等。

最後 AI 會問：

這個設計看起來是否合適？如果沒問題我將寫入設計文件。

我們確認後，AI 就會把設計整理成文件並保存下來，整個 brainstorming 流程就完成了。

使用這個技能可以解決的問題包括：避免需求理解偏差、保留設計紀錄、確保對關鍵決策有共識等。

6.2 writing-plans —— 把任務拆成清晰的步驟

brainstorming 完成後，需求弄清楚了，接下來要寫實作計畫。這時用 writing-plans，把任務拆成一個個小步驟，每一步都寫得清清楚楚。

這個技能需要手動觸發。可以直接說「幫我寫個實作計畫」，或輸入命令：/superpowers:writing-plans

觸發後，AI 會在專案目錄下建立兩個資料夾：

• docs/superpowers/specs/ ← 存放設計文件（brainstorming 產出的設計方案）
• docs/superpowers/plans/ ← 存放執行計畫（writing-plans 產出的實作步驟）

這兩個資料夾是 Superpowers 的標準目錄結構：

• specs：記錄 brainstorming 階段確認的設計方案，方便日後回顧「當初為何這樣設計」
• plans：記錄具體的執行步驟，每一步該做什麼、如何驗證，執行時照著做就行

AI 會根據設計方案生成詳細的計畫文件，將整個任務拆成多個子任務，每個子任務再拆成小步驟。計畫寫好後，AI 會把它保存到 docs/superpowers/plans/，並推薦執行方式：

計畫已保存到 docs/superpowers/plans/YYYY-MM-DD-xxx.md

推薦執行方式：

1. 使用 superpowers:subagent-driven-development（在當前會話中執行，推薦）
2. 使用 superpowers:executing-plans（在獨立會話中執行）

兩者差異：

• subagent-driven-development：在當前對話內繼續執行，適合小專案或想即時監控的情況
• executing-plans：在獨立會話中執行，適合大型專案或需要隔離環境的情況

可能有人會覺得，自己對功能設計心裡有數就好，幹嘛還要寫文件？其實這一步很必要。文件不是只給當下自己看，而是給以後的自己或接手專案的人看：

6.3 執行計畫 —— 選擇適合的執行方式

writing-plans 完成後，計畫寫好了，接下來就是執行。AI 會提供兩種執行方式讓你選。

這個選擇會自動出現在 writing-plans 完成後，AI 會問你：

推薦執行方式：

1. 使用 superpowers:subagent-driven-development（在當前會話中執行，推薦）
2. 使用 superpowers:executing-plans（在獨立會話中執行）

差異如下：

大多數情況我們選第一種就好，除非有特殊需求（例如想隔離環境、想手動控制每一步）。

當你選好計畫執行方案後，AI 就會呼叫 superpowers:subagent-driven-development 來實作計畫。

接著它會建立多個子代理（subagents），每個子代理負責執行一部分任務。子代理可以並行工作，不用等上一個做完才做下一個，效率更高。

這樣一來，以前我們沒有執行計畫時，AI 常常一口氣輸出一堆程式，改了好幾個檔案，我們來不及看就過去了。等發現問題時，不知道哪一步錯了，只能從頭排查，返工要改一堆。

有了執行計畫後，AI 會按計畫一步步來，做完一步回報一次。我們每一步都能檢查，發現問題立刻修正，不用等到最後才發現。

6.4 verification-before-completion —— 說完成不代表真完成

先解釋為什麼需要這個技能。

很多時候，AI 說「功能做好了」、「bug 修好了」、「測試通過了」，我們就信了，直接提交程式。結果上線才發現測試沒跑、lint 有報錯、邊界情況沒考慮。我們習慣說一句「應該沒問題吧」就提交，但實際上問題一堆。

這個技能就是為了阻止這種情況。當 AI 想聲稱完成時，它會強制介入，必須跑驗證、拿出證據，才能算完成。這個不是我們請求驗證才觸發，而是 AI 想聲稱完成時自動觸發。

而且這個技能是自動觸發的，AI 無法繞過。為什麼要強制執行？因為太多次 AI 說完成了，但其實測試沒跑、lint 有錯、建置失敗。這個技能就是要阻止自欺欺人的情況——你說完成就要拿出證據證明真的完成。

驗證不只是語法層級，而是全面性的驗證，舉例：

• 前端驗證指令、後端驗證指令
• 測試全部通過（例如：npm test、pytest、go test ./...、cargo test）
• Lint 通過（例如：npm lint、flake8、golangci-lint、cargo clippy）
• 建置成功（例如：npm build、cargo build、go build、mvn compile）
• 確認原本失敗的測試已修復
• 逐項對照需求清單驗證功能行為
• 必要時做手動驗證或整合測試

核心原則：證據優先於聲明

• 不能說「測試應該通過」→ 必須跑測試看到 0 failures
• 不能說「lint 應該沒問題」→ 必須跑 lint 看到 0 errors
• 不能說「bug 應該修好了」→ 必須跑原本失敗的測試確認已通過

觸發方式有兩種：

1. 自動觸發：AI 嘗試說「完成」、「修復」、「通過」等詞時，技能會介入強制驗證。
2. 手動觸發：輸入 /superpowers:verification-before-completion 明確要求執行驗證步驟。

簡單說，這個技能讓證據比聲明更可信。

6.5 finishing-a-development-branch —— 工作做完了怎麼收尾

當功能開發完、驗證通過後，就要決定怎麼把程式碼合併到主分支。這時 finishing-a-development-branch 會自動觸發，給我們幾個選項讓我們選擇。

AI 會提供 4 個選項，其中一個是「保留分支，由我自己處理」——選這個就等於跳過自動收尾，由你自行決定後續流程。

觸發時機：

• 有時候會在 subagent-driven-development 或 executing-plans 完成後自動呼叫。
• 也可以手動觸發：/superpowers:finishing-a-development-branch

執行後 AI 會先確認測試確實通過，然後呈現 4 個選項供你選擇：

這樣一來，以前我們改完程式碼，不知道怎麼合併，要不直接推送到主分支，要不手動操作，分支凌亂。有了這個技能後，它會先確認測試通過，然後給出清楚選項：想合併就合併、想建立 PR 就建立 PR、不想合併就保留分支。整個過程有流程、有清理，不用我們自己操心如何收尾。

七、其他技能簡介

核心流程的 6 個技能講完了，Superpowers 還有其他技能，在特定場景下很有用。下面用表格再簡要整理一次：

八、寫在最後

Claude Code 可用的技能其實很多，官方插件市集裡有一大堆，社群也有人做了不少。但我今天特別寫這篇文章講 Superpowers，是因為它和別的技能不太一樣。

其他技能多半針對某個具體任務，例如幫我們寫 API 文件、幫我們優化資料庫、幫我們跑測試覆蓋率。Superpowers 不一樣，它是一套完整的開發流程框架。從需求理解到計畫編寫、從執行到驗證、從驗證到收尾，整個過程都被涵蓋。它不是單一工具，而是把整個開發工作流串連起來。

這篇文章把 Superpowers 的核心技能都介紹了一遍，就是希望大家知道這套流程如何運轉、每個技能該怎麼用。

Superpowers 做的事情其實很簡單：把「我說需求 → AI 寫程式」變成「我說需求 → 先理解 → 再計畫 → 再執行 → 再驗證 → 再收尾」。每個技能就是一個關卡，AI 走到這裡會停下來等我們確認或決策。我們始終掌握關鍵節點，而不是讓 AI 一路跑到終點再回頭看。

為什麼我建議大家多學 Superpowers？與傳統簡單對話方式相比，有好幾個明顯好處：

1. 減少返工。AI 會先停下來問清楚需求，把細節確認好才開始動手，方向一開始就對，後面就少來回修改。
2. 每一步都清楚知道改了什麼。先寫計畫，每一步要做什麼、改哪些檔案、如何驗證都寫清楚，執行時一步步回報，有問題直接看計畫就知道哪裡出錯。
3. 程式碼品質有保障。驗證是強制的，AI 說「完成」之前必須跑測試、跑檢查，有證據才能說沒問題。品質不是靠自覺，而是靠流程保證。
4. 後續維護省心。specs 與 plans 文件都保存著，當初怎麼設計、為什麼那樣設計、每一步做了什麼，一看就明白。換人接手或日後維護，溝通成本大幅降低。

簡單來說，Superpowers 幫我們省的是：省返工、省溝通、省排查、省維護。剛開始可能會覺得流程多、步驟慢，但少折騰幾輪，總體時間反而更短，而且程式碼更可靠、日後更省心。

日常使用記住這三個就夠了：
brainstorming → writing-plans → executing-plans

先理解需求，再寫計畫，再按計畫執行。其他技能遇到再用就行。

有興趣可以去看原始碼，每個技能的 SKILL.md 裡都有詳細流程說明：
https://github.com/obra/superpowers

原文出處：https://juejin.cn/post/7625943321220005903