開發方法 OpenSpec, superpowers, mattpocock/skills
- Fission-AI/OpenSpec: Spec-driven development (SDD) for AI coding assistants.
https://github.com/Fission-AI/OpenSpec - obra/superpowers: An agentic skills framework & software development methodology that works.
https://github.com/obra/superpowers - mattpocock/skills: My personal directory of skills, straight from my .claude directory.
https://github.com/mattpocock/skills
這三個 GitHub 專案代表了目前在「AI 輔助開發（AI Coding Assistants / Agentic Workflows）」領域中，三種截然不同但都非常前沿的開發方法論。它們的核心目標都是為了解決：當 AI 能夠寫程式時，人類該如何有效地引導、約束與管理 AI 的產出？
以下為您詳細比較這三者的核心理念、運作方式，並分析哪一個最適合你們的團隊。
1. Fission-AI/OpenSpec：規格驅動開發 (Spec-Driven Development, SDD)
- 核心理念：「在寫任何程式碼之前，先達成共識 (Agree before you build)」。
- 運作方式：它建立了一個輕量級的「規格層（Spec layer）」。當你有新想法時，透過 CLI 指令（如
/opsx:propose），AI 不會立刻寫 code，而是先生成一個包含proposal.md、specs/、design.md和tasks.md的資料夾。人類與 AI 在這些 Markdown 文件上反覆修改，確認需求無誤後，才讓 AI 根據清單執行任務（/opsx:apply）。 - 特點：
- 強大的交付物管理：每一次的 Feature 變更都有獨立的狀態與文件追蹤，避免 AI 忘記上下文。
- 跨工具支援：不綁死單一 IDE，支援 20 多種 AI 工具。
- 靈活但有秩序：適合現有的大型專案（Brownfield），可以隨時修改規格，AI 會根據文件同步更新程式碼。
2. mattpocock/skills：模組化技能庫 (Modular Agentic Skills)
- 核心理念：「給 AI 裝備特定的開發技能卡」。
- 運作方式：這是知名 TypeScript 開發者 Matt Pocock 的個人 prompt/skill 集合。它不強加一個龐大的工作流，而是提供了各種獨立的「技能指令」，例如：寫 PRD (
write-a-prd)、將 PRD 拆解成 Issue (prd-to-issues)、執行 TDD (tdd)、查修 Bug (triage-issue)、架構重構 (improve-codebase-architecture) 等。 - 特點：
- 極度輕量與自由：隨插即用，你只需要挑選你需要的技能放進你的 AI Agent 中。
- 專注於單點突破：不會干涉你整體的開發流程，而是在你需要「設計介面」或「寫測試」時，給予 AI 最好的專家級 Prompt 模板。
3. obra/superpowers：全自動化與強意見工作流 (Opinionated E2E Workflow)
- 核心理念：「讓 AI 成為一個守紀律、懂流程的資深工程師」。
- 運作方式：這是一個極度完整且「強勢（Opinionated）」的自動化流程框架。當你請 AI 做事時，它會接管並強迫觸發一系列標準流程：先進行蘇格拉底式的腦力激盪（Brainstorming）確認需求 ➡️ 開啟獨立的 Git Worktree 分支 ➡️ 制定拆解計畫（每步 2-5 分鐘的微型任務） ➡️ 派發子代理（Subagent）執行 ➡️ 強制執行紅燈/綠燈的測試驅動開發 (TDD) ➡️ 程式碼自我審查 ➡️ 最後決定是否 Merge。
- 特點：
- 高度自動化：AI 可以在無需人類頻繁介入的情況下，自主工作數小時，並且因為有嚴格的檢查點，不易偏離軌道。
- 強制最佳實踐：嚴格執行 TDD、YAGNI（你不需要它）、DRY，以及安全的 Git 隔離開發。
- 平台深度整合：以外掛形式深度整合至 Claude Code, Cursor 等主流 AI 開發工具。
總結比較表
| 比較維度 | OpenSpec (Fission-AI) | Skills (Matt Pocock) | Superpowers (obra) |
|---|---|---|---|
| 開發方法論 | 規格與文件驅動 (Spec-Driven) | 工具箱/技能驅動 (Skill-Driven) | 嚴格測試與流程驅動 (TDD + Subagents) |
| 對 AI 的控制力 | 透過靜態文件 (Markdown) 約束 | 透過單次 Prompt/技能引導 | 透過自動化流程強迫執行 |
| 系統重量級 | 中等（需維護文件結構） | 輕量（隨插即用） | 重量級（接管整個開發生命週期） |
| 適合的開發場景 | 需求複雜、需團隊對齊與留檔的專案 | 個人開發者日常解題、針對特定痛點優化 | 希望 AI 高度自治並完成大特性的全包式開發 |
哪個適合你們？
因為不確定你們的團隊規模與專案性質，我提供以下三種情境建議，您可以根據團隊現況來對號入座：
情境 A：你們是正規「軟體團隊」，有 PM/工程師協作，重視架構與歷史文件
👉 推薦選擇：OpenSpec
原因：它能完美橋接人類與 AI 的溝通。團隊可以先審查 AI 寫出來的 design.md 和 tasks.md，避免 AI 在龐大的 codebase 中「幻覺」暴走。它留下的規格文件也能成為團隊寶貴的知識庫，非常適合已經有一定規模、需要多人協作維護的商業專案。
快速模式： /opsx:propose ──► /opsx:apply ──► /opsx:archive
精細模式： /opsx:new ──► (選用 /opsx:continue 或 /opsx:ff) ──► /opsx:apply ──► /opsx:archive
情境 B：你們是「希望最大化 AI 產出的獨立開發者/小團隊」，且信任 TDD 紀律
👉 推薦選擇：Superpowers
原因：如果你希望只要丟出一個大方向，AI 就能自己切 Git 分支、寫測試、實作、修 Bug 然後發 PR，這個框架最適合。它透過極度嚴格的流程（尤其是 TDD 和 Subagent 審查）彌補了 AI 容易寫出「看起來能跑但缺乏邊界條件考慮」的缺陷。
情境 C：你們「已經有自己的開發節奏」，只想讓目前的 AI 工具變聰明一點
👉 推薦選擇：Matt Pocock's Skills
原因：引入大型框架的學習成本有時太高。你們可以直接參考或複製他的技能定義（例如 triage-issue 的排錯邏輯），將其融入你們現有的 Cursor 規則 (rules) 或 Claude 提示詞中，以最低的成本無痛提升開發體驗。
Comments ()