Superpowers 使用心得：讓 AI Coding Agent 具備工程紀律的開發工作流

Superpowers 開發工作流

最近因為專案需求，我深入研究了 Superpowers 這套專案，順手整理了一下它的開發流程與實務心得。原本只是好奇「這東西到底能解決什麼痛點」，結果仔細跑過幾次工作流之後發現，它根本就是一套專為 AI Agent 量身打造的工程紀律框架，早就超越了單純 AI coding 小工具的範疇。

現在很多人把大語言模型（LLM）投入日常開發，最大的痛點往往來自於它太會寫、寫太快，卻完全缺乏架構意識，反而讓人忽略了它到底會不會寫程式這個基本問題。
你一句話丟下去，它馬上幫你改檔案、加功能、修 bug，初期看起來極度有效率。但過不了多久，你可能就會面臨以下技術債：

它其實沒有真正理解核心需求，只解決了表面症狀。
測試覆蓋率極低，總是最後才想到要補 Unit Test。
改動範圍如同滾雪球般越來越大，破壞了原本的架構設計。
發 PR 的時候看起來很忙，但不知道到底解決了什麼根本性問題。
最終，身為資深工程師的你，還是得自己回頭「下足重本」去收拾殘局。

Superpowers 想解決的，正是這個業界痛點：
讓 Agent 擺脫「盲目寫碼機器」的標籤，強制它遵循一套可靠、具備可驗證性的開發流程來做事。

核心架構思考：先釐清架構，再動手寫 Code

Superpowers 的 README 裡定義了一段基礎開發流程，這套流程完美契合了優質軟體工程的原則。
其核心步驟如下：

brainstorming：先釐清需求與架構設計，絕對不一開始就盲目寫 code。
using-git-worktrees：開啟獨立的工作區（Worktree），避免污染主線或原本的開發環境。
writing-plans：將實作拆解成極小、高內聚且具體的任務清單。
subagent-driven-development 或 executing-plans：嚴格依照計畫步驟執行。
test-driven-development：落實 TDD（測試驅動開發），透過小步快跑驗證邏輯。
requesting-code-review：在任務節點之間進行嚴格的 Code Review。
finishing-a-development-branch：最終收尾、全面驗證，並決定整併策略。

    graph TD
    A[brainstorming] --> B[using-git-worktrees]
    B --> C[writing-plans]
    C --> D[executing-plans / subagent-driven-development]
    D --> E[test-driven-development]
    E --> F[requesting-code-review]
    F --> G[finishing-a-development-branch]

這個流程初看或許會覺得有些繁瑣，但在複雜度較高的專案中，這種設計反而能大幅降低重工成本。
因為 AI 寫 code 最常翻車的地方往往在於「系統方向」，語法錯誤反而是其次。方向一旦偏了，寫得越快，錯得越徹底。

實戰經驗分享：當 OpenCode 遇上 Superpowers

在我的實務專案中，目前的技術棧是 OpenCode 搭配 Superpowers。最直觀的感受是：它成功將一個「冰冷的工具」轉變成了「具備思考能力的協作同事」。

當我進入 plan 模式並輸入需求時，它跳脫了被動「等待指令碼」的模式，會直接根據當下的 Context（上下文）自動決策並調用適當的技能。

舉幾個我最近在實戰中遇到的例子：

遇到棘手的 HTTP 500 系統錯誤時：我直接把錯誤 Log 丟給它，它不會瞎猜或亂改程式。它會自動調用 systematic-debugging 技能，先去追蹤根因（Root cause tracing），透過 Call Stack 一步步定位問題瓶頸，最後才動手進行修復。這完全是資深工程師的 Debug 邏輯。
架構新功能與 API 設計時：當我丟出一個相對模糊的業務需求，它會自動進入 brainstorming 模式，跟我玩起蘇格拉底式提問。它會主動探討系統邊界、Edge Cases 並給出架構設計建議，確保我不是在盲目擴張功能。

整個工作流跑起來非常有節奏感且令人安心：

writing-plans：先產出修改計畫，讓我有機會在它動手前先進行邏輯 Review，確保架構不偏移。
test-driven-development：在正式實作前，強制執行 focused failing check，確保測試案例真的能抓到預期問題。
executing-plans：按部就班地執行修改與驗證。
verification-before-completion：在回報完成前，自動進行回歸驗證，避免常見的「修 A 壞 B」窘境。

這種「自動導航」的開發體驗，不僅省去了大量手動下 prompt 的溝通成本，更重要的是，它保證了產出程式碼的工程品質。

為什麼這些工作環節至關重要？

1. 寫計畫（Writing Plans）是確保可交付性的基石

這是我個人最推崇的 writing-plans 設計。它要求將任務拆解到極致，細到每一步都能被獨立驗證。
例如，一個標準的任務節點會長這樣：
先寫 failing test ➔ 跑測試確認 fail ➔ 寫最小實作 ➔ 跑測試確認 pass ➔ Commit。

它把 AI 常見的「感覺有做完」轉變成了「有明確證據顯示已達成」。AI Agent 最大的通病就是很容易「產生幻覺」並宣告完成，但有了這套紀律，它必須留下清晰的證據鏈。

2. TDD 在這裡不再只是理想口號

坦白說，在敏捷開發的壓力下，平常自己寫 code 真的很難 100% 貫徹 TDD。但在 AI Agent 的協作場景中，TDD 反而是確保品質的最有效手段。
因為測試案例等同於是在明確告訴 Agent：「你的實作邊界就在這裡，滿足這個行為即可，不要自己腦補過度設計（Over-engineering）。」雖然初期建置測試案例會慢一點，但從全局來看，這能有效防止 Agent 亂加一堆未定義的功能，大幅減少了後續維護的技術債。

嚴謹的品質保證：連「溝通對話」都要寫測試

在翻閱其底層實作 docs/testing.md 時，我發現 Superpowers 測試自己 workflow 的方式非常有借鑒意義。它不僅僅是跑單元的 Function Test，而是跑真實的 Agent Session，然後去驗證整段對話紀錄（Transcript）。
它會嚴格檢查：

特定情境下，對應的技能有沒有真的被觸發？
子 Agent（Subagent）有沒有被正確派發出去處理併發任務？
檔案變更與目錄結構是不是如預期建立？
Git Commit 歷史是否乾淨、語意是否合理？

如果你要驗證的是「AI 到底會不會照標準作業流程（SOP）做事」，那只測程式碼邏輯是遠遠不夠的。必須要驗證它在真實的複雜任務中，是不是真的「具備工程紀律」。

Skills Library：解構高階開發行為的技能池

Superpowers 最大的技術亮點，在於它將抽象的軟體開發行為，拆解成了高內聚、可自由組合的 skills 模組。Agent 會在 Context 合適的時機點自動觸發這些技能，確保每一步動作都符合最佳實踐（Best Practices）。

1. 測試驅動（Testing）

test-driven-development：嚴格執行 RED-GREEN-REFACTOR 循環。它不僅僅是寫測試，內部還維護了一套「測試反模式（Anti-patterns）」的過濾機制，防止 Agent 寫出無效或不穩定的 Flaky Tests。

2. 系統除錯（Debugging）

systematic-debugging：這套技能徹底告別了「瞎猜亂改」，直接落實一套嚴謹的四階段根因分析流程（涵蓋了 Root-cause-tracing、Defense-in-depth、Condition-based-waiting 等進階維運技術）。
verification-before-completion：在發布「修復完畢」的信號前，強制進行最後防線的驗證。

3. 團隊協作與流程控制（Collaboration）

brainstorming：透過蘇格拉底式的引導提問，在動手前先釐清業務邏輯與模糊邊界。
writing-plans / executing-plans：將巨型任務（Epic）降維拆解成可執行的任務（Task）並批次處理。
dispatching-parallel-agents：支援強大的併行處理能力，讓多個 Subagent 同時執行 I/O 密集型或獨立模組的工作。
requesting-code-review / receiving-code-review：內建自動化的 Code Review 機制，從規格符合度到架構品質都有嚴格的把關。
subagent-driven-development：這可以說是目前最核心的高階玩法，讓 Agent 在受控的沙盒環境下進行快速的微迭代。

4. 元技能擴充（Meta）

writing-skills：甚至內建了一套技能是教 Agent「如何為自己撰寫並擴充新的技能」，這讓系統具備了極強的擴展性。
using-superpowers：整個系統的入口引導與使用手冊。

結語與展望

導入這套流程後，讓原本容易失控的 AI 產出，變成了可以預期且具備高品質的程式碼交付，說白了就是替團隊節省了大量回頭修 Bug 與 Review 的隱性成本。

我對 Superpowers 的整體評價是：它把 AI 訓練成一個成熟、可以放心把任務交給他的資深工程師，完全沒有在那邊跟你玩程式碼炫技。

這套系統會強制你：

先釐清業務需求與邊界
規劃具體的技術實作計畫
採取小步快跑的迭代實作
透過自動化測試來驗證結果
運用 Code Review 攔截潛在風險
最後有條理地收尾與合併

這些概念在軟體工程領域都不是什麼新名詞，但真正令人驚豔的是，它成功把這些「人類容易偷懶的流程」，封裝成了 Agent 會主動嚴格執行的 Skills。
對我來說，這甚至比單純升級底層的 LLM 模型還要來得有價值。模型能力再強，如果缺乏系統化的工作流，最後往往還是會產出一大堆需要人類工程師來收拾的「技術債」。
但只要流程框架夠穩健，即使模型偶爾出現微小的判斷失誤，也能輕易地被 TDD、嚴謹的 Review 和細粒度的 Commit 機制給攔截下來。

AI 輔助開發的下一步，目標已經轉向「AI 能不能在既有的工程規範下，穩定且可靠地交付價值」，單純追求「AI 能寫出多少 Code」已經是過去式了。

如果你的團隊也正準備將 AI 深度整合進日常開發流程，或是目前正面臨 AI 產出品質難以控管的痛點，Superpowers 的這套思維非常值得借鏡。

技術交流與顧問諮詢
正在思考如何將 AI Coding Agent 導入團隊工作流、或是遇到專案架構上的瓶頸嗎？歡迎隨時與我交流，或是討論技術顧問與接案合作機會！