「不合格程式碼直接刪除」這條規則實際上會怎麼運作，會不會有誤刪已經寫好、只是還沒補測試的程式碼的風險？
這條規則的觸發條件是「實作程式碼先於對應測試存在」，也就是說它針對的是開發順序本身,而不是事後判斷程式碼品質好壞。實務上這代表 Superpowers 期待的工作流程,是每一段實作都先有一個會失敗的測試存在,才能開始寫讓它通過的程式碼——如果你習慣的做法是先寫完一大段功能,之後才回頭補測試,這條規則會直接跟這種工作習慣衝突,因為「先寫完的那段功能」在測試補上之前,就已經違反了規則所定義的順序。
這確實是一個相對激進的設計選擇,好處是能徹底避免「測試事後補、流於形式」這種常見的 TDD 執行不力問題,代價是它要求使用者(或團隊)真正願意照紅燈綠燈重構的順序工作,不能只是把 TDD 當成口號。如果你的團隊本來就沒有嚴格照這個順序寫程式碼的習慣,直接導入這條規則,前期會有明顯的適應成本。
子代理驅動開發跟一般的多人協作開發流程有什麼實質不同，為什麼需要特別強調上下文乾淨這件事？
一般的多人協作,是把不同任務分給不同的人,每個人各自維持自己腦中的專案理解;子代理驅動開發表面上類似,但差異在於「上下文」本身是一種有限、會被逐步消耗的資源——Claude 在單一對話裡處理的資訊越多、越雜,可用來做出正確判斷的空間就相對被壓縮。如果資料庫遷移、前端樣式、API 路由這些完全不相關的工作都塞進同一個上下文視窗,即使每項任務本身不難,混雜在一起處理時,前一項任務殘留的細節仍然會佔用空間、干擾對當前任務的專注度。
子代理驅動開發解決的正是這個問題:把每項工程任務個別交給一個乾淨、獨立的子代理處理,這個子代理只帶著完成這項任務所需的必要資訊,做完之後只把結果回報給主線,不會把處理過程中產生的所有中間細節都留在主要對話裡。這跟單純把任務分工不同,分工只解決「誰做什麼」,子代理驅動開發同時解決的是「怎麼確保每個人(或每個子代理)做事時,腦子裡不被無關的雜訊干擾」。
跨工具可攜性聽起來很吸引人，但如果團隊裡有人用 Claude Code、有人用其他工具，實際協作起來會不會出現落差？
會有落差,而且官方文件本身也承認這一點——雖然核心工作流程(腦力激盪、TDD 強制執行、基本的技能組合)可以在支援的所有平台上運作,但 Claude Code 因為有工具使用範圍的沙箱限制、外掛自動更新、原生子代理支援這些平台特性,部分進階功能(尤其是子代理驅動開發)在其他平台上不一定能發揮同等效果,其他工具能拿到的是核心工作流程,但拿不到最進階的協調機制。
對於團隊裡工具不統一的情況,比較實際的預期是:所有人都能享受到「強制 TDD 紀律」「brainstorming 先釐清需求」這類方法論層面的一致性,但如果某些成員的工作高度仰賴子代理平行處理複雜任務這類進階功能,用非 Claude Code 平台的人,在這部分的實際體驗會跟用 Claude Code 的人有落差。如果團隊決定要導入 Superpowers,值得先確認核心協作場景是不是主要落在「方法論一致」這個層次,而不是仰賴每個人都要有完全一致的進階功能表現。
如果我是個人開發者、不是團隊作業，這個框架的強制性對我來說是加分還是負擔？
這取決於你目前寫程式碼的習慣，跟 Superpowers 期待的紀律之間差距有多大。如果你原本就有寫測試的習慣,只是流程沒有這麼嚴格,導入 Superpowers 更多是把既有習慣「正式化」,摩擦感會比較小;但如果你原本傾向快速把功能寫出來、測試通常是後補甚至經常被跳過,直接套用這套框架,前期會感覺處處被規則卡住,原本能快速完成的任務,現在得先過腦力激盪、寫計畫、紅燈綠燈這幾道關卡才能真正動手。
比較務實的判斷方式,是先想清楚你現在要做的專案性質:如果是需要長期維護、日後可能有其他人接手、或本身邏輯複雜容易出錯的專案,前期多花的紀律成本,通常能在後續減少除錯、減少返工的時間裡賺回來,官方文件本身也提到,雖然初期腦力激盪跟規劃會有十到二十分鐘的額外開銷,但整體專案下來,實作階段的錯誤與返工減少,反而能讓開發速度比傳統做法快上兩到三倍;但如果只是想快速驗證一個想法、專案生命週期很短,這套框架的強制性可能反而是不必要的摩擦,更適合先用原生、沒有額外規則的 Claude Code。
由開發者 Jesse Vincent（GitHub 帳號 obra）打造的 Superpowers，是目前 GitHub 上星數最高的 Claude Code Skill 專案之一，透過 /Plugin marketplace add obra/superpowers-marketplace 加入市集後，即可用 /plugin install superpowers@superpowers-marketplace 安裝。它不是單一一個 Skill，而是一整套打包了二十多個 Skill 的方法論框架，核心訴求很直接：把「vibe coding」——那種鬆散下指令、指望 AI 自己猜出正確實作的做法——改造成一套有紀律的工程流程。
Superpowers 裡最引人注目、也最能說明它「認真」到什麼程度的機制，是它對 TDD（測試驅動開發）的執行方式。標準的 TDD 流程是紅燈（寫一個會失敗的測試）、綠燈（寫最小可行的實作讓測試通過）、重構,Superpowers 把這個流程寫成強制規則,而且是真的強制——框架的指示裡明確要求:如果 Claude（或使用者自己)在對應的測試存在之前就先寫了實作程式碼,這段程式碼要被直接刪除,以維持專案的完整性。這不是一句警告或建議,是寫進 Skill 指令裡的具體行為要求。
另一個核心設計,是用子代理(subagent)驅動整個開發流程,而不是把資料庫遷移、前端樣式、API 路由這些性質完全不同的工作,全部塞進同一個上下文視窗裡處理。使用者說「開始」之後,Superpowers 會啟動一個子代理驅動的開發流程,讓 Claude 把每個工程任務分別交給獨立的子代理處理,每個子代理各自檢視與審核自己負責的那部分,主線的上下文因此能維持乾淨、專注,不會被不相關的實作細節塞滿。搭配這個設計的還有 git worktree 隔離——在正式開始實作之前,會先在一個新分支上建立獨立的工作區,避免實驗性質的修改直接影響到主要的程式碼。
Superpowers 從 5.0 版之後,原生支援的範圍不只 Claude Code,還包括 Cursor、Gemini CLI、GitHub Copilot CLI、Codex、OpenCode 等多個平台,同一套技能可以在不同工具之間攜帶使用。不過即使支援多平台,Claude Code 仍然是整合最深的一個——例如針對工具使用範圍的沙箱限制、外掛自動更新、原生的子代理支援,這些特性讓部分進階功能(尤其是子代理驅動開發這塊)在 Claude Code 上的表現優於其他平台,其餘工具則能取得核心工作流程,但拿不到最進階的協調機制。
如果你的團隊已經有明確的工程規範,想確保「不管誰用 Claude Code 寫程式碼,都照同一套紀律走」,Superpowers 提供的是一個現成、經過大量使用者驗證的骨架,不需要自己從零打造一套 TDD 強制機制。但它的強制性本身也是一種取捨——「不合格就刪除」這種規則,對真正需要嚴謹紀律的正式專案是資產,但對快速原型、探索性質的實驗,反而可能是不必要的摩擦。安裝前值得先確認:你現在要做的這件事,究竟需要的是紀律,還是速度。