裝了Superpowers還是不會用？這套完整工作流，讓你的AI從"工具"變成"搭檔"

作者：AI智聞說
日期：2026年5月12日 上午7:41
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

Superpowers 14個Skill唔係獨立工具，而係一條從需求到合併嘅開發流水線，防止AI偷懶走捷徑。

整理版摘要

呢篇文章係由一位熟悉Superpowers嘅開發者寫嘅，佢發現大部分人裝咗Superpowers之後，只用到入面10%嘅能力，問題在於唔知道點樣將14個Skill串連成一條完整嘅開發流水線。作者想幫讀者解決嘅問題係：點樣由「直接叫AI做嘢」變成「AI自動行完整個開發流程」。

整體結論係Superpowers嘅本質唔係14個獨立工具，而係一套防止AI偷懶嘅流水線：每個環節都係為咗確保方向正確、測試先行同埋驗證完成。你唔需要一次過記住所有Skill，只要記住三條鐵律就搞得掂：冇設計唔寫code、冇測試唔寫code、冇驗證唔講完成。

文章用一個真實嘅「加用戶註冊功能」案例，由brainstorming到合併PR，一步步示範點樣用流水線開發。作者特別強調，唔好直接同AI講「寫個功能」，而係要先出設計、拆任務、隔離工作空間、派獨立代理執行，最後再雙重審查先收尾。呢啲步驟加埋，先可以令AI真係變咗你嘅「拍檔」，而唔係一個亂寫code嘅工具。

  • Superpowers嘅14個Skill按階段分工，每個Skill嘅輸出就係下一個Skill嘅輸入，形成一條完整嘅開發流水線。
  • brainstorming防止你做錯方向：任何需求都要先出設計，你批准先可以寫code，就算得5分鐘嘅功能都要有設計。
  • writing-plans將設計拆成2-5分鐘嘅小任務，每個任務由獨立代理執行，避免上下文污染，計劃要寫到連陌生人都睇得明。
  • TDD鐵律：先寫失敗測試，再寫最小實現，唔可以跳過任何一步，連簡單code都要有測試。
  • verification要求新鮮證據：聲稱完成之前一定要跑驗證命令，唔可以講「應該冇問題」，上次跑過嘅結果唔算數。
值得記低
流程

Superpowers開發流水線

由brainstorming開始，經writing-plans、using-git-worktrees、subagent-driven-development（內含TDD）、requesting-code-review、receiving-code-review、verification-before-completion、finishing-a-development-branch，最後合併或開PR。

留作參考
Prompt

驗證Superpowers是否生效嘅3個測試

1. 話「幫我規劃一個功能」，AI應該問問題唔係直接寫code。 2. 話「加個登錄功能」，AI應該先寫失敗測試。 3. 話「呢個bug幫我修一下」，AI應該先問根因。

留作參考
整理重點

14個Skill一條流水線

Superpowers唔係14個獨立工具，而係一套有先後順序嘅開發流水線。每個階段都有對應嘅Skill，由入口檢查、設計、規劃、隔離、執行、測試、調試、審查、並行、驗證到收尾，一氣呵成。

關鍵洞察：每個Skill嘅輸出係下一個Skill嘅輸入

你唔需要記14個Skill，只要記住呢條流水線就可以。

  1. 1 入口：using-superpowers — 檢查應該用邊個Skill
  2. 2 設計：brainstorming — 唔好急住寫code，先問清楚需求
  3. 3 規劃：writing-plans — 將需求拆成2-5分鐘嘅小步驟
  4. 4 隔離：using-git-worktrees — 創建獨立工作空間
  5. 5 執行：subagent-driven-development — 每個任務派一個新代理
  6. 6 實現：executing-plans — 冇子代理時自己按計劃執行
  7. 7 測試：test-driven-development — 先寫失敗測試再寫最小實現
  8. 8 調試：systematic-debugging — 先揾根因再修bug
整理重點

實戰：由需求到上線7步走

用一個真實場景——加用戶註冊功能——行一次完整流程。

  1. 1 brainstorming：先探索項目上下文，逐個提問，提出2-3個方案，你揀完方案後出設計文檔。鐵律係無論需求幾簡單，都要先出設計你批准先寫得code。
  2. 2 writing-plans：將設計拆成2-5分鐘嘅小任務，每個任務有精確路徑同命令，寫畀一個對項目一無所知嘅人睇。
  3. 3 using-git-worktrees：自動創建隔離git工作空間，搞砸咗直接delete就得，主分支完全唔受影響。
  4. 4 subagent-driven-development：每個任務派一個全新代理實現，跟住派兩個審查代理（規格合規＋代碼質量），兩個都通過先算完成。
  5. 5 test-driven-development：每個實現代理內部行RED→GREEN→REFACTOR循環，唔可以跳過測試，唔可以「先寫code再補測試」。
  6. 6 requesting-code-review + receiving-code-review：第一輪派全新代理審查code變更，第二輪你驗證審查意見係咪正確，可以反駁唔合理嘅建議。
  7. 7 verification-before-completion + finishing-a-development-branch：跑驗證命令畀新鮮證據，然後揀合併、PR、保留或丟棄。

鐵律：冇驗證唔講完成，上次跑過嘅測試結果唔算數

整理重點

三條鐵律，記住就夠

14個Skill太多記唔住？記住呢三條鐵律，覆蓋80%嘅場景。

  • 鐵律2：冇測試唔寫code — 先寫失敗測試，再寫最小實現。違反後果係寫咗一堆code，唔知啱唔啱，改一處壞三處。
  • 鐵律3：冇驗證唔講完成 — 聲稱完成前，必須跑驗證命令並畀證據。違反後果係「應該冇問題」上線後出bug。

鐵律唔係限制你，係限制AI偷懶嘅傾向

整理重點

調試、並行同寫Skill

systematic-debugging係獨立於開發流水線嘅流程，任何階段遇到bug都可以觸發。

  1. 1 根因調查：讀錯誤信息、復現問題、查最近變更、追蹤數據流。
  2. 2 模式分析：揾正常code對比差異。
  3. 3 假設驗證：提出一個假設，最小改動驗證，一次只改一個變量。
  4. 4 實施修復：先寫失敗測試，修復根因，驗證通過。

最常見嘅反模式：「我試試改呢個睇嚇得唔得」——呢啲唔係調試，係靠估

並行方面，dispatching-parallel-agents可以同時處理唔相關嘅bug或者獨立任務，但絕對唔可以改同一個文件。寫自己嘅Skill都要行TDD：先諗壓力場景，唔帶Skill跑一次，記錄AI嘅「自然表現」同「藉口」，再針對藉口寫規則，循環直到防彈。

description只寫「幾時用」，唔好寫流程摘要，否則AI會自以為是

安裝Superpowers bash 
# Claude Code安裝
/plugin marketplace add obra/superpowers-marketplace/plugin install superpowers@superpowers-marketplace

# 驗證安裝成功
# 重啟後講「幫我規劃一個功能」
# 如果AI開始問問題而不是直接寫code，說明brainstorming生效咗

自定義Skill可以放喺個人級~/.claude/skills/或者項目級.claude/skills/，驗證生效可以用三個測試。

整理重點

邊界同總結

Superpowers唔適合一次性腳本、探索性原型、緊急hotfix同一個人維護嘅小項目。最適合團隊協作、長期維護同複雜功能開發。

核心判斷標準：code要活幾耐？活一日嘅腳本唔需要，活一年嘅項目好需要

簡單需求可以直接做，不過verification都要有。正式需求就行完整流水線：brainstorming → writing-plans → using-git-worktrees → 每個任務循環（派代理 → 代理內部TDD → 審查請求 → 審查接收） → verification → finishing。

90%嘅人裝咗Superpowers但係只用咗10%嘅能力，問題在於唔知點樣串埋一齊

寫喺前面

你可能已經裝咗Superpowers。

但係老實講，你大概只係觸發咗其中一兩個Skill——寫代碼嗰陣偶然觸發TDD，調試嗰陣偶然觸發systematic-debugging，大部份時間仲係「直接叫AI做嘢」。

呢個唔係你嘅問題。Superpowers有14個Skill，每個都寫得好詳細，但係冇人話你知佢哋點樣串成一條完整嘅開發流水線。

今日呢篇文章，我由入門到實戰，完整講清楚一件事：由你提需求到代碼合入主分支，Superpowers嘅14個Skill點樣一步步接管你嘅開發流程。

睇完呢篇，你就會明點解有人話「Superpowers令AI自主工作幾粒鐘」——唔係吹水，係流程啱咗。

一、先睇全貌：14個Skill點樣分工

Superpowers唔係14個獨立嘅工具，係一套有先後次序嘅開發流水線：

階段
Skill
一句講曬職責
鐵律
入口
using-superpowers
檢查應該用邊個Skill
得1%可能會觸發
設計
brainstorming
唔好急住寫代碼，先問清楚需求
冇設計唔寫代碼
規劃
writing-plans
將需求拆成2-5分鐘嘅細步驟
計劃係寫俾零上下文嘅人睇
隔離
using-git-worktrees
建立隔離嘅工作空間
唔喺主分支上面開發
執行
subagent-driven-development
每個任務派一個新代理
代理唔會繼承歷史
實現
executing-plans
冇子代理嗰陣自己按計劃執行
唔跳過驗證步驟
測試
test-driven-development
先寫失敗測試，再寫最細實現
冇失敗測試唔寫代碼
調試
systematic-debugging
先揾根因，再修bug
冇揾到根因唔提方案
審查請求
requesting-code-review
派獨立代理審查代碼
完成任務一定要審查
審查接收
receiving-code-review
驗證審查意見先實施
唔好盲從審查意見
並行
dispatching-parallel-agents
獨立問題同時派多個代理
唔俾代理改同一檔案
驗證
verification-before-completion
聲稱完成之前一定要跑驗證
冇跑命令唔準話「搞掂咗」
收尾
finishing-a-development-branch
驗證、合併、清理
測試唔過唔合併
元技能
writing-skills
用TDD方法寫新Skill
冇壓力測試唔寫Skill

關鍵洞察：每個Skill嘅輸出係下一個Skill嘅輸入。 你唔需要記住14個Skill，只需要記住呢條流水線。

二、完整實戰：由需求到上線嘅7步走

我用一個真實場景行一次完整流程：幫一個項目加用戶註冊功能。

第1步：brainstorming — 唔好咁急

你話「幫我加個用戶註冊功能」，Superpowers唔會直接寫代碼。佢會先行brainstorming：

1
探索項目上下文 — 睇你現有代碼、文檔、最近嘅提交
2
逐個提問 — 「註冊需唔需要電郵驗證？」「需唔需要第三方登入？」「密碼策略係咩？」
3
提出2-3個方案 — 例如方案A：電郵+密碼註冊；方案B：手機驗證碼註冊；方案C：第三方OAuth
4
你揀咗方案之後，出設計文檔 — 保存到 docs/superpowers/specs/

大部份人嘅錯誤： 直接同AI講「寫個註冊功能」，AI寫完你發現冇考慮電郵驗證、冇考慮密碼強度、冇考慮重複註冊。brainstorming就係防止呢種「做錯方向」嘅問題。

鐵律： 無論需求幾簡單，都一定要先出設計、你批准先可以寫代碼。一個5分鐘就寫得完嘅功能，設計可能只要3句話——但係一定要有。

第2步：writing-plans — 拆到2分鐘一個任務

設計批准之後，自動進入writing-plans。呢一步將設計拆成2-5分鐘就搞得掂嘅小任務：

## 任務1：創建用戶模型
- [ ] 寫失敗測試：用戶創建需要郵箱和密碼
- [ ] 運行測試，確認失敗
- [ ] 實現User模型最小代碼
- [ ] 運行測試，確認通過
- [ ] 提交

## 任務2：添加郵箱唯一性驗證
- [ ] 寫失敗測試：重複郵箱註冊返回錯誤
- [ ] 運行測試，確認失敗
- [ ] 添加唯一性約束
- [ ] 運行測試，確認通過
- [ ] 提交

## 任務3：密碼加密
...

點解要拆到咁細？ 因為每個任務會派俾一個獨立嘅AI代理執行。任務越細，代理越唔容易出錯，審查亦越容易。

計劃係寫俾邊個睇？ 寫俾「一個技術好叻但係對項目一無所知嘅人」——所以要包含完整代碼、精確檔案路徑、具體命令。唔可以寫「加驗證」，要寫「喺 src/models/user.ts 第15行之後加 validates :email, uniqueness: true"。

第3步：using-git-worktrees — 隔離工作空間

執行計劃之前，先建立一個隔離嘅git工作空間：

# 自動創建隔離分支
git worktree add .worktrees/user-registration feature/user-registration
cd .worktrees/user-registration
npm install  # 自動檢測並安裝依賴
npm test     # 驗證基線測試通過

點解唔喺主分支上面開發？ 因為如果搞衰咗，直接刪咗worktree就得，主分支完全唔受影響。呢個就好似手術前嘅消毒——唔消毒多數都冇事，但係出事就大件事。

第4步：subagent-driven-development — 代理流水線

呢個係Superpowers最核心嘅執行引擎。每個任務行呢個循環：

1
派代理A實現（全新上下文，唔繼承歷史）
2
派代理B審查規格合規性（代碼做咗應該做嘅嘢未？）
3
派代理C審查代碼質素（代碼寫得好唔好？）
4
兩個審查都通過，任務完成
5
下一個任務，重複1-4

點解每個任務要派新代理？ 因為AI嘅上下文窗口係有限嘅。如果你喺一個對話入面做10個任務，到第5個任務嗰陣AI已經「唔記得」前面嘅細節。新代理 = 乾淨嘅上下文 = 更少嘅錯誤。

點解唔並行派實現代理？ 因為多個代理同時改同一個代碼庫會撞。實現係串行嘅，審查就可以並行。

模型揀選策略：

角色
推薦模型
原因
實現代理
Haiku/Sonnet
機械性工作，成本優先
規格審查
Sonnet
需要理解需求
代碼質素審查
Opus
需要深度判斷
調試代理
Opus
需要最強推理

第5步：test-driven-development — 每個代理內部嘅鐵律

每個實現代理內部，一定要跟TDD循環：

1
RED：寫一個失敗測試，執行，確認失敗
2
GREEN：寫最細代碼令測試通過，執行，確認通過
3
REFACTOR：重構，保持測試通過，執行，確認通過
4
重複

Superpowers嘅TDD比普通TDD更加嚴格：

•
「呢個功能太簡單唔需要測試」 → 唔得，簡單代碼都需要測試
•
「我寫完代碼先補測試」 → 唔得，先寫測試同後寫測試係兩回事
•
「我先寫個參考實現」 → 唔得，刪咗佢重新嚟過
•
「我只係想睇下API點用」 → 唔得，睇文檔，唔寫代碼

點解要咁嚴格？ 因為AI係最容易「先寫代碼再補測試」嘅。一旦開咗個口，AI就會100%走捷徑。鐵律唔係限制你，係限制AI嘅偷懶傾向。

第6步：requesting-code-review + receiving-code-review — 雙重審查

代碼寫完之後，行兩輪審查：

第一輪：請求審查（requesting-code-review）

•
派一個全新嘅審查代理，俾佢精確嘅上下文（唔係你嘅對話歷史）
•
審查代理淨係睇代碼變更，唔睇你嘅思考過程
•
按嚴重程度分級：Critical（一定要改）、Important（應該改）、Minor（記低先）

第二輪：接收審查（receiving-code-review）

•
呢一步最容易被忽略：唔係審查話改咩就改咩
•
Superpowers要求你先驗證審查意見係咪正確
•
如果審查建議會破壞現有功能，要反駁
•
如果審查建議違反YAGNI原則（You Aren't Gonna Need It），要反駁
•
修復次序：Critical → Important → Minor，每個修完單獨測試

審查嘅黃金法則： 技術正確性 > 社交舒適度。唔可以因為審查者「講得有道理」就盲從——要自己驗證。

第7步：verification-before-completion + finishing-a-development-branch — 收尾

驗證鐵律： 冇跑過命令，唔準話「搞掂咗」.

錯誤示範： 「代碼改完啦，應該冇問題㗎」
正確示範： "運行 npm test，32個測試全部通過，0個失敗」

Superpowers要求你提供新鮮嘅證據——上一次執行嘅測試結果唔算數，一定要係當前訊息中執行嘅。

驗證通過之後，finishing-a-development-branch俾你4個選擇：

1
本地合併到主分支
2
推送並建立PR
3
保留分支唔鬱
4
丟棄所有更改

每個選項都有對應嘅安全檢查——測試唔過唔可以合併，丟棄更改需要你輸入「discard」確認。

三、3條鐵律，記住就夠

14個Skill太多記唔曬？記住呢3條鐵律，覆蓋80%嘅場景：

鐵律1：冇設計唔寫代碼（brainstorming）

無論需求幾簡單，先出設計先動手。設計可以好短，但係一定要有。

違反後果： 做錯方向，返工3次。

觸發時機： 你話「幫我做XX」嗰陣，AI應該先問清楚，而唔係直接寫代碼。

鐵律2：冇測試唔寫代碼（TDD）

先寫失敗測試，再寫最細實現。

違反後果： 寫咗一大堆代碼，唔知啱唔啱，改一處壞三處。

觸發時機： 任何寫代碼嘅時候——新功能、修bug、重構。

鐵律3：冇驗證唔講完成（verification）

聲稱完成之前，一定要跑驗證命令並俾出證據。

違反後果： 「應該冇問題㗎」上線之後出bug。

觸發時機： 你話「搞掂啦」「應該得啦」「測試通過咗」嗰陣——AI一定要跑一次驗證。

四、調試：Superpowers點樣幫你修Bug

調試係獨立於開發流水線嘅流程，任何階段遇到bug都可以觸發：

1
根因調查：讀錯誤訊息、重現問題、查最近變更、追蹤數據流
2
模式分析：揾正常代碼、對比差異
3
假設驗證：提一個假設、最細改動驗證、一次只改一個變量
4
實施修復：先寫失敗測試、修復根因、驗證通過

最常見嘅反模式： 「我試下改呢個睇下得唔得」——呢個唔係調試，係靠估。

Superpowers嘅3次規則： 如果你連續3次修復都失敗，即係問題可能喺架構層面。停低，同人討論，而唔係繼續估。

幾時最應該用systematic-debugging？ 唔係得閒嗰陣，係最急嗰陣。因為越急就越容易靠估，越靠估就越浪費時間。系統調試15-30分鐘搞得掂嘅問題，靠估改可能要2-3個鐘。

五、並行：邊啲任務可以同時做

dispatching-parallel-agents令多個代理同時處理獨立問題：

適合並行嘅場景：

•
3個唔相關嘅bug要修
•
前端同後端嘅獨立任務
•
多個檔案嘅獨立重構

絕對唔可以並行嘅場景：

•
代理會改同一個檔案
•
一個問題嘅修復可能會影響另一個
•
你仲未確定問題喺邊（探索階段）

關鍵原則： 每個代理拎到嘅係精心構造嘅上下文，唔係你完整嘅對話歷史。你似項目經理咁分配任務、收集結果、處理衝突。

六、寫自己嘅Skill：用TDD方法

writing-skills話你知：寫Skill都要TDD。

1
RED： 先諗3個「壓力場景」——AI最容易犯錯嘅場景。唔帶Skill行一次，記錄AI嘅「自然表現」同「藉口」
2
GREEN： 針對嗰啲藉口寫Skill，再行一次，睇下AI係咪跟足
3
REFACTOR： 測試中AI又揾到新藉口？加反藉口規則，循環直到「防彈」

最重要嘅陷阱：description寫咗做摘要。

# 致命錯誤：描述變成了流程摘要
description: 在任務之間做代碼審查，確保質量

# 正確：只寫觸發條件
description: Use when completing a coding task, before marking it done

點解？因為AI讀到摘要就好可能「自以為明咗」，唔去讀Skill正文。description只寫「幾時用」，流程寫喺Skill入面。

七、大部份人唔知嘅5個細節

細節1：brainstorming會自動串聯writing-plans

設計一旦批准，brainstorming會自動叫writing-plans。你唔需要手動切換。呢個係14個Skill之間最核心嘅串聯關係。

細節2：subagent-driven-development嘅代理唔繼承歷史

每個代理拎到嘅上下文係你精心構造嘅，唔係你完整嘅對話。呢個意味住：

•
代理唔會「記住」你之前講嘅題外話
•
但係亦都意味住你一定要俾足夠嘅上下文俾代理
•
計劃寫得越詳細，代理執行得越好

細節3：receiving-code-review鼓勵你反駁

審查意見唔係聖旨。Superpowers清楚列出咗邊啲情況應該反駁：

•
建議會破壞現有功能
•
審查者唔瞭解完整上下文
•
建議違反YAGNI原則
•
建議喺技術上唔正確

細節4：verification-before-completion嘅「新鮮證據」要求

「我上次跑咗測試通過咗」唔算數。一定要係當前訊息入面執行嘅驗證結果。因為代碼可能喺你上次驗證之後又改過。

細節5：writing-plans嘅計劃係俾「陌生人」睇嘅

計劃一定要包含完整代碼、精確檔案路徑、具體命令。唔可以寫「加驗證」，要寫「喺 src/models/user.ts 第15行之後加 validates :email, uniqueness: true」。因為執行計劃嘅代理對你個項目一無所知。

八、由零開始：5分鐘配置Superpowers

# Claude Code安裝
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 驗證安裝成功
# 重啓後說"幫我規劃一個功能"
# 如果AI開始問問題而不是直接寫代碼，說明brainstorming生效了

自訂Skill放邊度：

# 個人級（所有項目可用）
~/.claude/skills/my-skill/SKILL.md

# 項目級（團隊共享，提交到git）
.claude/skills/my-skill/SKILL.md

驗證Skill係咪生效嘅3個測試：

1
話「幫我規劃一個功能」，AI應該先問問題，而唔係直接寫代碼
2
話「加個登錄功能」，AI應該先寫失敗測試，而唔係直接寫實現
3
話「呢個bug幫我搞搞佢」，AI應該先問根因，而唔係直接改代碼

如果3個都冇按預期觸發，檢查嚇Skill嘅description係咪寫好咗觸發短語。

九、Superpowers唔適合咩場景

任何工具都有邊界，老實講：

唔適合嘅場景：

•
一次性腳本（寫完就掉嗰啲，TDD反而浪費時間）
•
探索性原型（你仲未確定要做咩，brainstorming會卡住）
•
緊急hotfix（先止血再補流程）
•
一個人維護嘅細 project（流程開銷可能大過收益）

最適合嘅場景：

•
團隊協作嘅 project（流程保證一致性）
•
長期維護嘅 project（測試同審查嘅投資回報高）
•
複雜功能開發（設計階段防止行錯方向）
•
AI輔助編程（流程彌補AI嘅偷懶傾向）

核心判斷標準： 代碼要生存幾耐？生存1日嘅腳本唔需要Superpowers，生存1年嘅 project就好需要。

十、一張圖總結

圖片

簡單需求： 直接做，但係verification（驗證）都要有

正式需求，行流水線：

1
brainstorming：問清楚需求，出設計，你批准
2
writing-plans：拆成2-5分鐘任務
3
using-git-worktrees：建立隔離空間
4
每個任務循環：subagent-driven-development（派代理實現，代理內部行TDD：RED→GREEN→REFACTOR）→ requesting-code-review（獨立審查）→ receiving-code-review（驗證後實施）
5
verification-before-completion：跑驗證，俾證據
6
finishing-a-development-branch：合併或者PR

Superpowers嘅本質唔係14個獨立工具，係一條防止AI偷懶嘅流水線。 每個環節都喺度防止AI走捷徑：brainstorming防止做錯方向，TDD防止跳過測試，code-review防止自說自話，verification防止假完成。

你唔需要一次過用曬所有Skill。由3條鐵律開始：冇設計唔寫代碼，冇測試唔寫代碼，冇驗證唔講完成。等呢3條變成習慣，再加其他Skill。

掃碼關注「AI智聞說」，每日3分鐘掌握AI新知識

圖片

90%的人裝完Superpowers只用到了10%的能力，問題出在不知道怎麼串起來

寫在前面

你可能已經裝了Superpowers。

但說實話，你大概率只觸發了其中一兩個Skill——寫代碼時偶爾觸發TDD，調試時偶爾觸發systematic-debugging，大部分時間還是"直接讓AI幹活"。

這不是你的問題。Superpowers有14個Skill，每個都寫得很詳細，但沒有人告訴你它們怎麼串成一條完整的開發流水線。

今天這篇文章，我從入門到實戰，完整講清楚一件事：從你提需求到代碼合入主分支，Superpowers的14個Skill怎麼一步步接管你的開發流程。

看完這篇，你會知道為什麼有人說"Superpowers讓AI自主工作幾小時"——不是吹牛，是流程對了。

一、先看全貌：14個Skill怎麼分工

Superpowers不是14個獨立的工具，是一套有先後順序的開發流水線：

階段
Skill
一句話職責
鐵律
入口
using-superpowers
檢查該用哪個Skill
1%可能就觸發
設計
brainstorming
不急着寫代碼，先問清楚需求
沒設計不寫代碼
規劃
writing-plans
把需求拆成2-5分鐘的小步驟
計劃寫給零上下文的人看
隔離
using-git-worktrees
創建隔離的工作空間
不在主分支上開發
執行
subagent-driven-development
每個任務派一個新代理
代理不繼承歷史
實現
executing-plans
無子代理時自己按計劃執行
不跳過驗證步驟
測試
test-driven-development
先寫失敗測試，再寫最小實現
沒有失敗測試不寫代碼
調試
systematic-debugging
先找根因，再修bug
沒找到根因不提方案
審查請求
requesting-code-review
派獨立代理審查代碼
完成任務必須審查
審查接收
receiving-code-review
驗證審查意見再實施
不盲從審查意見
並行
dispatching-parallel-agents
獨立問題同時派多個代理
不讓代理改同一文件
驗證
verification-before-completion
聲稱完成前必須跑驗證
沒跑命令不能說"搞定了"
收尾
finishing-a-development-branch
驗證、合併、清理
測試不過不合並
元技能
writing-skills
用TDD方法寫新Skill
沒壓測不寫Skill

關鍵洞察：每個Skill的輸出是下一個Skill的輸入。 你不需要記住14個Skill，只需要記住這條流水線。

二、完整實戰：從需求到上線的7步走

我用一個真實場景走一遍完整流程：給一個項目添加用戶註冊功能。

第1步：brainstorming — 別急着動手

你說"幫我加個用戶註冊功能"，Superpowers不會直接寫代碼。它先走brainstorming：

1
探索項目上下文 — 看你現有代碼、文檔、最近的提交
2
逐個提問 — "註冊需要郵箱驗證嗎？""需要第三方登錄嗎？""密碼策略是什麼？"
3
提出2-3個方案 — 比如方案A：郵箱+密碼註冊；方案B：手機驗證碼註冊；方案C：第三方OAuth
4
你選方案後，出設計文檔 — 保存到 docs/superpowers/specs/

大多數人的錯誤： 直接跟AI說"寫個註冊功能"，AI寫完你發現沒考慮郵箱驗證、沒考慮密碼強度、沒考慮重複註冊。brainstorming就是防止這種"做錯方向"的問題。

鐵律： 不管需求多簡單，都必須先出設計、你批准後才能寫代碼。一個5分鐘能寫完的功能，設計可能只要3句話——但必須有。

第2步：writing-plans — 拆到2分鐘一個任務

設計批准後，自動進入writing-plans。這一步把設計拆成2-5分鐘就能完成的小任務：

## 任務1：創建用戶模型
- [ ] 寫失敗測試：用戶創建需要郵箱和密碼
- [ ] 運行測試，確認失敗
- [ ] 實現User模型最小代碼
- [ ] 運行測試，確認通過
- [ ] 提交

## 任務2：添加郵箱唯一性驗證
- [ ] 寫失敗測試：重複郵箱註冊返回錯誤
- [ ] 運行測試，確認失敗
- [ ] 添加唯一性約束
- [ ] 運行測試，確認通過
- [ ] 提交

## 任務3：密碼加密
...

為什麼拆這麼細？ 因為每個任務會派給一個獨立的AI代理執行。任務越小，代理越不容易出錯，審查越容易。

計劃寫給誰看的？ 寫給"一個技術很強但對項目一無所知的人"——所以必須包含完整代碼、精確文件路徑、具體命令。不能寫"添加驗證"，要寫"在 src/models/user.ts 第15行後添加 validates :email, uniqueness: true"。

第3步：using-git-worktrees — 隔離工作空間

執行計劃前，先創建一個隔離的git工作空間：

# 自動創建隔離分支
git worktree add .worktrees/user-registration feature/user-registration
cd .worktrees/user-registration
npm install  # 自動檢測並安裝依賴
npm test     # 驗證基線測試通過

為什麼不在主分支上開發？ 因為如果搞砸了，直接刪掉worktree就行，主分支完全不受影響。這就像手術前的消毒——不消毒大概率也沒事，但出事就是大事故。

第4步：subagent-driven-development — 代理流水線

這是Superpowers最核心的執行引擎。每個任務走這個循環：

1
派代理A實現（全新上下文，不繼承歷史）
2
派代理B審查規格合規性（代碼做了該做的事嗎？）
3
派代理C審查代碼質量（代碼寫得好嗎？）
4
兩個審查都通過，任務完成
5
下一個任務，重複1-4

為什麼每個任務派新代理？ 因為AI的上下文窗口是有限的。如果你在一個對話裏幹10個任務，到第5個任務時AI已經"忘了"前面的細節。新代理 = 乾淨的上下文 = 更少的錯誤。

為什麼不併行派實現代理？ 因為多個代理同時改同一個代碼庫會衝突。實現是串行的，審查可以並行。

模型選擇策略：

角色
推薦模型
原因
實現代理
Haiku/Sonnet
機械性工作，成本優先
規格審查
Sonnet
需要理解需求
代碼質量審查
Opus
需要深度判斷
調試代理
Opus
需要最強推理

第5步：test-driven-development — 每個代理內部的鐵律

每個實現代理內部，必須遵循TDD循環：

1
RED：寫一個失敗測試，運行，確認失敗
2
GREEN：寫最小代碼讓測試通過，運行，確認通過
3
REFACTOR：重構，保持測試通過，運行，確認通過
4
重複

Superpowers的TDD比普通TDD更嚴格：

•
"這個功能太簡單不需要測試" → 不行，簡單代碼也需要測試
•
"我先寫完代碼再補測試" → 不行，先寫測試和後寫測試是兩回事
•
"我先寫個參考實現" → 不行，刪掉重來
•
"我只是想看看API怎麼用" → 不行，看文檔，不寫代碼

為什麼這麼嚴？ 因為AI是最容易"先寫代碼再補測試"的。一旦開了口子，AI會100%走捷徑。鐵律不是限制你，是限制AI的偷懶傾向。

第6步：requesting-code-review + receiving-code-review — 雙重審查

代碼寫完後，走兩輪審查：

第一輪：請求審查（requesting-code-review）

•
派一個全新的審查代理，給它精確的上下文（不是你的對話歷史）
•
審查代理只看代碼變更，不看你的思考過程
•
按嚴重度分級：Critical（必須修）、Important（應該修）、Minor（記下來）

第二輪：接收審查（receiving-code-review）

•
這一步最容易被忽視：不是審查說什麼就改什麼
•
Superpowers要求你先驗證審查意見是否正確
•
如果審查建議會破壞現有功能，要反駁
•
如果審查建議違反YAGNI原則（你不會需要它），要反駁
•
修復順序：Critical → Important → Minor，每個修完單獨測試

審查的黃金法則： 技術正確性 > 社交舒適度。不能因為審查者"說得有道理"就盲從——要自己驗證。

第7步：verification-before-completion + finishing-a-development-branch — 收尾

驗證鐵律： 沒跑過命令，不能說"搞定了"。

錯誤示範： "代碼改完了，應該沒問題"
正確示範： "運行 npm test，32個測試全部通過，0個失敗"

Superpowers要求你提供新鮮的證據——上一次運行的測試結果不算，必須是當前消息中運行的。

驗證通過後，finishing-a-development-branch給你4個選項：

1
本地合併到主分支
2
推送並創建PR
3
保留分支不動
4
丟棄所有更改

每個選項都有對應的安全檢查——測試不過不能合併，丟棄更改需要你輸入"discard"確認。

三、3條鐵律，記住就夠了

14個Skill太多記不住？記住這3條鐵律，覆蓋80%的場景：

鐵律1：沒設計不寫代碼（brainstorming）

不管需求多簡單，先出設計再動手。設計可以很短，但必須有。

違反後果： 做錯方向，返工3次。

觸發時機： 你說"幫我做XX"的時候，AI應該先問清楚，而不是直接寫代碼。

鐵律2：沒測試不寫代碼（TDD）

先寫失敗測試，再寫最小實現。

違反後果： 寫了一堆代碼，不知道對不對，改一處壞三處。

觸發時機： 任何寫代碼的時刻——新功能、修bug、重構。

鐵律3：沒驗證不說完成（verification）

聲稱完成之前，必須跑驗證命令並給出證據。

違反後果： "應該沒問題"上線後出bug。

觸發時機： 你說"搞定了""應該可以了""測試通過了"的時候——AI必須跑一遍驗證。

四、調試：Superpowers怎麼幫你修Bug

調試是獨立於開發流水線的流程，任何階段遇到bug都可以觸發：

1
根因調查：讀錯誤信息、復現問題、查最近變更、追蹤數據流
2
模式分析：找正常代碼、對比差異
3
假設驗證：提一個假設、最小改動驗證、一次只改一個變量
4
實施修復：先寫失敗測試、修復根因、驗證通過

最常見的反模式： "我試試改這個看行不行"——這不是調試，這是猜。

Superpowers的3次規則： 如果你連續3次修復都失敗，說明問題可能在架構層面。停下來，和人討論，而不是繼續猜。

什麼時候最該用systematic-debugging？ 不是閒的時候，是最急的時候。因為越急越容易猜，越猜越浪費時間。系統調試15-30分鐘搞定的問題，猜着改可能要2-3小時。

五、並行：哪些任務可以同時幹

dispatching-parallel-agents讓多個代理同時處理獨立問題：

適合並行的場景：

•
3個不相關的bug需要修
•
前端和後端的獨立任務
•
多個文件的獨立重構

絕對不能並行的場景：

•
代理會改同一個文件
•
一個問題的修復可能影響另一個
•
你還不確定問題出在哪（探索階段）

關鍵原則： 每個代理拿到的是精心構造的上下文，不是你的完整對話歷史。你像項目經理一樣分配任務、收集結果、處理衝突。

六、寫自己的Skill：用TDD方法

writing-skills告訴你：寫Skill也要TDD。

1
RED： 先想3個"壓力場景"——AI最容易犯錯的場景。不帶Skill跑一遍，記錄AI的"自然表現"和"藉口"
2
GREEN： 針對那些藉口寫Skill，再跑一遍，看AI是否遵守
3
REFACTOR： 測試中AI又找到新藉口？加反藉口規則，循環直到"防彈"

最重要的陷阱：description寫成了摘要。

# 致命錯誤：描述變成了流程摘要
description: 在任務之間做代碼審查，確保質量

# 正確：只寫觸發條件
description: Use when completing a coding task, before marking it done

為什麼？因為AI讀到摘要就可能"自以為懂了"，不去讀Skill正文。description只寫"什麼時候用"，流程寫在Skill裏面。

七、大多數人不知道的5個細節

細節1：brainstorming會自動串聯writing-plans

設計一旦批准，brainstorming會自動調用writing-plans。你不需要手動切換。這是14個Skill之間最核心的串聯關係。

細節2：subagent-driven-development的代理不繼承歷史

每個代理拿到的上下文是你精心構造的，不是你的完整對話。這意味着：

•
代理不會"記住"你之前說的偏題的話
•
但也意味着你必須給代理足夠的上下文
•
計劃寫得越詳細，代理執行得越好

細節3：receiving-code-review鼓勵你反駁

審查意見不是聖旨。Superpowers明確列出了哪些情況該反駁：

•
建議會破壞現有功能
•
審查者不瞭解完整上下文
•
建議違反YAGNI原則
•
建議在技術上不正確

細節4：verification-before-completion的"新鮮證據"要求

"我上次跑了測試通過了"不算。必須是當前消息中運行的驗證結果。因為代碼可能在你上次驗證後又改了。

細節5：writing-plans的計劃是給"陌生人"看的

計劃必須包含完整代碼、精確文件路徑、具體命令。不能寫"添加驗證"，要寫"在 src/models/user.ts 第15行後添加 validates :email, uniqueness: true"。因為執行計劃的代理對你的項目一無所知。

八、從零開始：5分鐘配置Superpowers

# Claude Code安裝
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 驗證安裝成功
# 重啓後說"幫我規劃一個功能"
# 如果AI開始問問題而不是直接寫代碼，說明brainstorming生效了

自定義Skill放哪裏：

# 個人級（所有項目可用）
~/.claude/skills/my-skill/SKILL.md

# 項目級（團隊共享，提交到git）
.claude/skills/my-skill/SKILL.md

驗證Skill是否生效的3個測試：

1
說"幫我規劃一個功能"，AI應該先問問題，不是直接寫代碼
2
說"加個登錄功能"，AI應該先寫失敗測試，不是直接寫實現
3
說"這個bug幫我修一下"，AI應該先問根因，不是直接改代碼

如果3個都沒按預期觸發，檢查Skill的description是否寫好了觸發短語。

九、Superpowers不適合什麼場景

任何工具都有邊界，誠實地說：

不適合的場景：

•
一次性腳本（寫完就扔的那種，TDD反而浪費時間）
•
探索性原型（你還不確定要做什麼，brainstorming會卡住）
•
緊急hotfix（先止血再補流程）
•
一個人維護的小項目（流程開銷可能大於收益）

最適合的場景：

•
團隊協作的項目（流程保證一致性）
•
長期維護的項目（測試和審查的投資回報高）
•
複雜功能開發（設計階段防止走錯方向）
•
AI輔助編程（流程彌補AI的偷懶傾向）

核心判斷標準： 代碼要活多長時間？活1天的腳本不需要Superpowers，活1年的項目很需要。

十、一張圖總結

圖片

簡單需求： 直接做，但verification（驗證）還是要有

正式需求，走流水線：

1
brainstorming：問清楚需求，出設計，你批准
2
writing-plans：拆成2-5分鐘任務
3
using-git-worktrees：創建隔離空間
4
每個任務循環：subagent-driven-development（派代理實現，代理內部走TDD：RED→GREEN→REFACTOR）→ requesting-code-review（獨立審查）→ receiving-code-review（驗證後實施）
5
verification-before-completion：跑驗證，給證據
6
finishing-a-development-branch：合併或PR

Superpowers的本質不是14個獨立工具，是一條防止AI偷懶的流水線。 每個環節都在防止AI走捷徑：brainstorming防止做錯方向，TDD防止跳過測試，code-review防止自說自話，verification防止假完成。

你不需要一次用上所有Skill。從3條鐵律開始：沒設計不寫代碼，沒測試不寫代碼，沒驗證不說完成。等這3條變成習慣，再加其他Skill。

掃碼關注「AI智聞說」，每天3分鐘掌握AI新知識

圖片