最近都使用 AI 進行開發，常常發現在整個開發過程中如果沒有軟體工程的概念，如果沒有特別指定做法，AI 會缺乏系統架構層面的觀點及流程，這樣一來極易生成未經解耦的程式碼（全部的程式都混在一起）、忽略邊界條件，甚至忽視基礎的資安規範。

要將 AI 從單純的「語法補齊工具」提升為能融入矩陣型組織、具備高度工程紀律的「虛擬資深開發者」，GitHub 上的開源專案 obra/superpowers 提供了一套具參考價值的 Agentic 技能框架與軟體開發生命週期（SDLC）方法論。本次注重在這套框架的基礎工作流，至於安裝細節與其他延伸技能就不多介紹。

圖1

一般來說，當你給 AI 一個指令，它通常會直接開始劈頭寫程式。但導入 Superpowers 後，你的 AI 會變成一個嚴謹的「工程師」，被迫遵循所規定的開發流程：先跟你確認需求、進行系統設計、拆解任務，最後才透過測試驅動開發（TDD）來寫程式碼。

1. 腦力激盪 (Brainstorming)：寫程式碼之前先別急

它會先釐清你的想法，探討替代方案，然後將設計分成小段落讓你審閱並確認，最後產出一份設計文件（Design Document）。這一步其實最重要，因為多數人跟 AI 溝通時都是想到什麼就講什麼，少了這道關卡，後面寫出來的東西再漂亮都是空中閣樓。

圖2

2. 建立工作區 (Using Git Worktrees)：隔離才安心

確認設計文件並核准後，AI 會在新的分支上建立一個隔離的工作區（Isolated Workspace），執行專案設定，並確認目前的測試基準（Test Baseline）是乾淨無錯誤的。不會讓你的主分支莫名其妙多出一堆垃圾 commit。

3. 制定開發計畫 (Writing Plans)：拆解成數個小任務

AI 會將設計拆解成最小的任務單位，每個任務都會明確列出：要修改的檔案路徑、完整的程式碼結構，以及如何驗證。這個顆粒度拆得夠細，才有辦法讓後面的子代理各自認領，互不打架。

圖3

4. 子代理驅動開發 (Subagent-Driven Development)：任務外包給小弟

AI 會為「每一個小任務」派出一個全新的子代理（Subagent）去執行，完成後會進行兩階段審查：先檢查是否符合規格（Spec Compliance），再檢查程式碼品質（Code Quality）。等於自己請了一批工程師，還自己當 code reviewer。

圖4

5. 測試驅動開發 (Test-Driven Development)：貫穿整個實作階段

強制執行 RED-GREEN-REFACTOR 循環：寫一個會失敗的測試 → 看著它失敗 → 寫最少的程式碼讓它通過 → 看著它通過 → Commit。AI 會主動刪除任何「沒有對應測試」的程式碼，這一點對於習慣先求有再求好的人來說算是強迫症式的紀律。

6. 程式碼審查 (Requesting Code Review)：任務之間的檢查點

AI 會對照最初的計畫進行自我審查，並按嚴重程度回報問題。如果有嚴重（Critical）的問題，會阻擋進入下一個任務，不會讓小問題滾成大雪球。

7. 完成開發分支 (Finishing a Development Branch)：收尾也不隨便

所有任務完成後，AI 會最後驗證一次測試，然後給你幾個選項：Merge（合併）、發 PR、保留或捨棄這個分支，最後清理工作區。連善後都幫你想好了。

在 GitHub Copilot CLI 安裝 Superpowers，等於是把一個「單純幫你自動補齊程式碼的工具」，升級成一個「會強迫自己做計畫、寫測試、並審查自己程式碼的資深工程師」。

這個部分的實際應用，再次突破了我對 AI 開發系統的認識，原本我以為技能框架與軟體開發生命週期都需要由操作人自主控制，沒想到透過強大的提示工程就可以將這些判斷流程注入 AI 的決策流程中。透過 Superpowers，不僅是讓 AI 寫出可以運作的程式，更是將軟體工程標準、資安規範以及微服務的防禦性設計，深度融合進每一次的程式碼生成之中，對於身於其他產業想導入 AI 協作的我們，這套「先計畫再動手」的紀律其實也很值得參考。

沒事，我先去把自己那個從來沒認真寫過測試的專案默默關掉分頁了。