沒錯，你提到了一個非常關鍵且目前在開源社群極具話題性的工具：**OpenSpec**。 如果你把剛剛提到的那幾個工具放在一起看，它們其實是在解決 AI 輔助開發中不同層次的痛點。社群現在非常流行將它們**「三合一」**使用，建立一套完整的工程化防線。 以下是 OpenSpec 的定位，以及它與前兩者的關聯： ## 什麼是 OpenSpec？ OpenSpec 是一個輕量級的**「規格驅動開發 (Spec-Driven Development, SDD)」**框架。 它的核心哲學是：**在讓 AI 寫任何一行程式碼之前，人類與 AI 必須先達成一份「書面契約」。** 它解決了傳統開發中「文件永遠落後於程式碼」的頑疾，並透過標準化的指令讓 AI 乖乖照著文件施工。 * **它的運作方式：** 它提供了一套標準化的 CLI 指令（例如 /opsx:propose 提議變更、/opsx:apply 按表實作、/opsx:archive 歸檔更新文件）。 這會在你的專案中建立一個特殊的 .openspec 目錄結構，將「專案的當前真實狀態 (Source of Truth)」和「進行中的變更 (Proposed Changes)」分開管理。 * **最大特色（Brownfield-first）：** 它非常適合導入到「已經存在很久的舊專案（存量專案）」中，不需要一開始就把整個專案的文件補齊，而是透過增量（Delta）的方式，改到哪裡、文件就補到哪裡。 ## 為什麼社群流行「三件套」混搭？ 社群（例如 AtomGit 和 GitHub 上的討論）將這三個工具形容為軟體工程流水線上的**三個不同工位**，把它們疊加在一起，就能讓 AI 寫程式從「碰運氣（Vibe Coding）」變成「可複製的工程實踐」： | 工具名稱 | 扮演的角色 | 一句話總結 | 核心目的 | |---|---|---|---| | **OpenSpec** | **架構師 / 需求方** | **管「說清楚」** | 在你和 AI 之間建立一份書面契約，防止需求漂移。 | | **Superpowers** | **專案經理 (PM)** | **管「做對事」** | 強制 AI 遵守工作流程（規劃 -> 切任務 -> 隔離分支）。 | | **Matt Pocock Skills** | **資深工程師 / 監工** | **管「做得好」** | 確保 AI 產出的程式碼符合高標準（如 TDD、架構重構）。 | ### 協作流程範例： 1. **OpenSpec 啟動：** 你叫 AI 使用 /opsx:propose 寫下一份新功能的 Spec 文件，確認功能範圍與架構設計。 2. **Superpowers 接手：** 進入實作階段，Superpowers 強制 AI 開啟一個獨立的 Git Worktree，並將 OpenSpec 寫好的規格書切碎成 2~5 分鐘的微型任務清單。 3. **Skills 執行：** 針對每一個小任務，AI 透過 Matt Pocock 的 /tdd 技能，嚴格執行「紅燈-綠燈-重構」來寫出高品質的程式碼，遇到問題就用 /diagnosing-bugs 來抓蟲。 4. **OpenSpec 收尾：** 功能完成後，呼叫 /opsx:archive，AI 會自動把剛剛修改的邏輯更新回主文件的「真實狀態 (Source of Truth)」中。 **結論：** 比起互相競爭，這三者是**完美互補**的關係。OpenSpec 解決的是「需求對齊與文件留存」；Superpowers 解決的是「流程控管與防呆」；而 Matt Pocock 的 Skills 解決的則是「程式碼品質與單點技術突破」。