LLM 知識庫

Appearance

Superpowers AI 開發方法論（與 OpenSpec 對比） ​

一套 AI 輔助開發方法論框架，透過強制性工作流（TDD、subagent 隔離、兩階段 code review）確保 AI agent 依紀律執行任務；與 OpenSpec SDD 框架 互補，各自解決「怎麼做（執行紀律）」與「做什麼 + 長期 Spec 管理」兩個問題。

概述 ​

Superpowers（obra/superpowers）是一套 AI 開發方法論框架，支援 Claude Code、Cursor、GitHub Copilot CLI、Codex、OpenCode、Gemini CLI 等六大平台。它的核心問題是「怎麼讓 AI agent 用紀律寫程式碼」，解法是透過一系列強制性工作流指令：TDD（先寫測試才能實作）、subagent 隔離（每任務派發全新 subagent 防止 context 污染）、以及 spec compliance + code quality 的兩階段 code review。

與之相對，OpenSpec SDD 框架 解決的是同一條鏈上的另一個問題：「怎麼讓人和 AI 在寫程式碼之前對齊需求，並在長期維護中保持 spec 和程式碼的一致」。一句話區分：Superpowers 管怎麼做，OpenSpec 管做什麼以及做完後怎麼記錄。兩者互補而非競爭。

核心內容 ​

定位差異 ​

工具類型核心問題
Superpowers開發方法論（methodology）怎麼讓 AI agent 用紀律執行任務
OpenSpec規格管理框架（spec management）如何對齊需求 + 長期保持 spec 與程式碼同步

各階段能力對比 ​

規劃階段 ​

能力SuperpowersOpenSpec
需求釐清對話✅ brainstorming skill（一次一個問題、選擇題優先、2-3 方案）✅ /opsx:propose 產出 proposal.md
設計文件產出✅ 存為 docs/superpowers/specs/✅ design.md + specs/
Spec 自我審查✅ inline self-review（規劃完成時即掃描 placeholder、矛盾、模糊度）⚠️ /opsx:verify 提供 AI 驅動的三維度驗證，但設計在實作後執行，非規劃時即時檢查
大型專案拆解✅ brainstorming 自動偵測並建議拆成子專案✅ 可建多個 change 並行
探索與構思❌ 無（brainstorming 可釐清需求，但無程式碼調查能力）✅ /opsx:explore：Greenfield 構思 / 需求釐清 / Brownfield 調查 / 架構比較；帶 implementation guardrail（嚴格禁止寫程式碼）
視覺化輔助（mockup）✅ 瀏覽器端 visual companion❌ 無

任務規劃階段 ​

能力SuperpowersOpenSpec
任務拆解粒度✅ 2-5 分鐘/任務，含精確檔案路徑、完整程式碼、驗證步驟✅ checkbox 格式，較高層次描述
No Placeholders 規則✅ TBD、vague description、// ... existing code ... 視為計畫失敗❌ 無 task-level 的 No Placeholders 品質檢查（artifact 層有 dependency chain 但粒度較粗）
計畫 vs. Spec 一致性✅ 寫完計畫後自動 self-review❌ 無（verify 在實作後才做）
檔案架構預規劃✅ 要求預先 map out 所有要建立/修改的檔案❌ 未明確要求

實作階段 ​

能力SuperpowersOpenSpec
TDD 強制✅ RED→GREEN→REFACTOR，anti-pattern 規則指示 agent 必須刪除未經 TDD 的程式碼並從測試重來❌ 無強制
Subagent 隔離✅ 每任務全新 subagent，防 context 隨任務累積而污染— 不適用（OpenSpec 不管理執行層 context 策略，由底層 agent 平台決定）
兩階段 Code Review✅ spec compliance review → code quality review（逐任務）❌ 無
實作中修改 Spec❌ brainstorming 後凍結✅ 隨時可改任何 artifact，fluid
Git Worktree 隔離✅ 專門的 using-git-worktrees skill 自動建立 worktree❌ 無（OpenSpec 不涉及 git 工作流管理）

驗證與收尾 ​

能力SuperpowersOpenSpec
逐任務品質閘門✅ critical issues 阻擋下一任務，必須修復才能繼續❌ 無阻擋機制
全局 Spec 驗證❌ 只有逐任務 review，無全局視角✅ /opsx:verify（完整性、正確性、一致性三維度）
Spec 歸檔持久化❌ spec 留在獨立檔案，不聚合為系統規格✅ delta spec 自動合併到 openspec/specs/

長期管理能力 ​

能力SuperpowersOpenSpec
Spec 為 Source of Truth❌ 每份 spec 獨立，無跨 session 聚合✅ 每次 archive 後 spec 自動合併
Brownfield 專案支援❌ 無專門機制，每次從零理解 codebase✅ /opsx:explore + /opsx:onboard + config.yaml
Spec 漂移偵測❌ 無✅ /opsx:sync 偵測 drift 並更新 spec
多 change 並行管理⚠️ 透過 git worktree 檔案隔離，無上層管理視圖✅ openspec list + bulk-archive
跨工具支援✅ 6 平台✅ 25+ 工具
除錯方法論✅ 4 階段系統化除錯（Superpowers 獨有）❌ 無

Superpowers 的核心強項 ​

  1. 執行紀律的強制性：TDD、code review、subagent 隔離是以強制性 prompt 指令約束的工作流，不是建議。agent 的 skill 指令明確定義了違規時的處理方式（例如未經 TDD 的程式碼必須刪除並從測試重新開始），且 subagent-driven-development 流程中 reviewer 不通過會阻擋任務推進。OpenSpec 的 apply 只是「逐任務執行」，沒有對應的品質紀律 enforcement。
  2. Subagent 架構（限 Claude Code、Codex 等支援 subagent 的平台）：每任務派發全新 subagent，context 不會隨任務累積而污染；controller 專注協調而非執行。不支援 subagent 的平台（Gemini CLI、Copilot CLI 等）會 fallback 到 executing-plans 單一 session 順序執行模式。
  3. 計畫嚴謹度（No Placeholders）：No Placeholders 規則確保每個任務有精確的檔案路徑、完整程式碼範例、預期的輸出，而不是 TBD 的待填坑。
  4. 系統化除錯：4+1 階段根因分析（D-1 觀察收集證據 → D-2 建立假設 → D-3 驗證假設 → D-4 修復驗證，外加 D-4.5 架構評估——3 次修復失敗後觸發）是 Superpowers 獨有能力。
  5. Git Worktree 自動化：平行開發的隔離性由 git 層級保證，不只是邏輯上的「不同任務」。

OpenSpec 的核心強項 ​

  1. Spec 為活文件（Source of Truth）：每次 archive 把 delta spec 合併回主 spec，系統規格自然成長。Superpowers 的 spec 是散落的獨立檔案，無跨 session 的規格聚合。
  2. Thinking Phase 與 Brownfield 漸進式導入：/opsx:explore 是 OpenSpec 的 Thinking Phase 指令，涵蓋 Greenfield 構思、需求釐清、Brownfield 調查、架構決策比較，並帶有 implementation guardrail（嚴格禁止寫程式碼，強制思考/實作分離）。與 Superpowers brainstorming 的關鍵差異：explore 原生支援程式碼調查、產出可直接持久化為 OpenSpec artifacts。搭配 /opsx:onboard 與 config.yaml 提供完整的既有專案導入路徑；詳見 OpenSpec 導入現有專案（Brownfield 指南）。
  3. 全局驗證：/opsx:verify 拿完整程式碼比對 proposal/specs/design.md，可見 Superpowers 逐任務 review 看不到的全局盲點。
  4. Spec 漂移偵測（sync）：程式碼改了但 spec 沒跟上時，主動偵測並修復——這是長期維護中的關鍵能力。
  5. 多 change 並行的上層管理：openspec list 一覽所有進行中的 change 及完成度，bulk-archive 處理 spec 衝突。

關鍵要點 ​

  • Superpowers 與 OpenSpec 是互補關係：前者管執行紀律，後者管需求對齊與 spec 持久化
  • Superpowers 的強制性工作流（TDD、subagent 隔離）是其不可取代的核心差異化
  • OpenSpec 的 spec 持久化和全局驗證填補了 Superpowers 的長期管理盲點
  • 除錯場景應優先使用 Superpowers 的 systematic-debugging（OpenSpec 無此能力）
  • Greenfield 專案可從 Superpowers brainstorming 開始；Brownfield 專案應先用 OpenSpec explore 建立脈絡

實際應用 ​

整合工作流 ​

階段使用工具原因
專案脈絡建立OpenSpec init + config.yamlSuperpowers 無此機制
探索與構思（可選）OpenSpec /opsx:explore（Greenfield 構思 / 需求釐清 / Brownfield 調查）；必要時加 /opsx:onboard 建立正式基線Greenfield 可改用 Superpowers brainstorming（但無程式碼調查、無 guardrail）；Brownfield 場景 Superpowers 無此機制
需求對齊與 Spec 產出OpenSpec /opsx:propose產出有結構的 artifact 且持久化為 source of truth
任務計畫拆解Superpowers writing-plans更嚴謹（No Placeholders、精確到檔案路徑和程式碼）
實作執行Superpowers subagent-driven-development（或 executing-plans）強制 TDD + 兩階段 review；subagent context 隔離僅限 Claude Code/Codex，其餘平台 fallback 為順序執行
全局驗證OpenSpec /opsx:verifySuperpowers 只有逐任務 review，缺乏全局視角
歸檔OpenSpec /opsx:archiveSpec 自動合併回主 spec，成為活文件；archive 會在需要時自動提示執行 sync
除錯Superpowers systematic-debuggingOpenSpec 無除錯能力

流程圖：

OpenSpec init + config.yaml + onboard     ← 建立專案基線（Brownfield 必做）
         ↓
（可選）OpenSpec /opsx:explore            ← Thinking Phase：構思 / 需求釐清 / 調查（需 init 後才能執行）
         ↓
OpenSpec /opsx:propose                    ← 產出 spec artifact
         ↓
Superpowers writing-plans                    ← 基於 spec 寫嚴謹計畫（No Placeholders）
         ↓
Superpowers subagent-driven-development   ← TDD + 兩階段 review（同步更新 tasks.md）
         ↓
OpenSpec /opsx:verify                     ← 全局驗證 spec vs. 實作
         ↓
OpenSpec /opsx:archive                    ← 歸檔 + spec 合併（含自動 sync 提示）

CLAUDE.md 整合設定 ​

在專案 CLAUDE.md 中加入以下指示，讓 Superpowers agent 知道如何銜接 OpenSpec artifact：

markdown
## OpenSpec + Superpowers Integration

- When Superpowers brainstorming would normally produce a spec, instead read the
  existing OpenSpec artifacts from `openspec/changes/<name>/` as the design input.

- **REQUIRED after every plan task completes** (subagent-driven-development,
  executing-plans, or manual execution): update the corresponding checkbox in
  `openspec/changes/<name>/tasks.md` with `[x]` syntax **before** calling
  TaskUpdate/TodoWrite to mark it complete. Do this per task, not at the end.

  Checklist to run after each task:
  1. Edit `openspec/changes/<name>/tasks.md` — mark completed task items `[x]`
  2. Then mark the task complete in TaskUpdate/TodoWrite

  **Why this is easy to forget in subagent-driven-development:** subagents handle
  implementation and do not update openspec tasks. The controller (you) must do
  it after each subagent returns DONE, before moving to the next task.

- Do NOT use Superpowers' finishing-a-development-branch for archiving; use
  `/opsx:verify` then `/opsx:archive` instead.

相關概念 ​

來源 ​