OpenSpec + Superpowers：2 個工具 4 步流程，讓 AI 編程質量不再碰運氣
整理版優先睇
OpenSpec 用硬約束管規格，Superpowers 用流程管執行，互補先做到高品質 AI 編程
呢篇文章係由術哥寫嘅，佢係一名專注 AI 編程、Agent Skills、MCP 等技術嘅實踐者。佢翻曬 OpenSpec v1.3.1 同 Superpowers v5.0.7 嘅源碼，發現兩個工具啱啱好互補：Superpowers 擅長執行同自測，但所有規則都係 prompt 軟約束；OpenSpec 用 Zod schema 做硬門禁，定義清楚要做乜，但執行層面冇閉環。作者認為，要解決 AI 編程質量問題，關鍵係將「定義質量」同「執行質量」分開處理，然後組合埋一齊。
Superpowers 嘅困境在於：佢嘅鐵律、審查循環、subagent 機制全部依賴 LLM 自覺，冇硬性終止條件，跨 task 資訊會斷層，而且零依賴令佢冇辦法用 AST 或 linter 做程式化檢查。OpenSpec 就相反：佢用 Zod schema 驗證 spec 必填字段，用 DAG 依賴圖管理 artifact 生成順序，用 Delta Spec 追蹤變更，全部係程式邏輯保證，但佢嘅驗證引擎唔會自動執行，Verify 命令都係靠 AI。
作者結論係：將 OpenSpec 嘅硬約束（規範做乜）同 Superpowers 嘅結構化流程（確保點做）組合，就可以同時解決定義唔清楚同執行唔到位嘅問題。佢仲提供咗一個 4 步工作流：先用 OpenSpec 定義規格，再創建 Change Proposal，然後用 Superpowers 執行，最…
- OpenSpec 用硬約束（Zod schema、DAG 依賴圖、Delta Spec）管「定義質量」，Superpowers 用 prompt 驅動嘅 7 階段工作流同兩階段審查管「執行質量」，兩者互補先做到高品質 AI 編程。
- 具體方法係 4 步：先用 OpenSpec 初始化同建立結構化 spec；再用 OpenSpec 創建 Change Proposal（含 Delta Spec 追蹤變更）；然後用 Superpowers 執行實現（brainstorming → plan → TDD → review）；最後用 OpenSpec 驗證同歸檔做質量門禁。
- 差異在於：Superpowers 所有規則都係自然語言 prompt，LLM 可以「唔聽話」；OpenSpec 嘅規則係程式化驗證，唔符合就直接報錯，唔靠 LLM 自覺。
- 啟發：決定 AI 編程質量嘅關鍵係「寫 code 之前有冇定義清楚要做乜」，而唔係只用更強 prompt 約束 LLM。OpenSpec 解決嘅正正係呢個問題。
- 可行動點：團隊可以跟住 4 步工作流落地——喺項目初始化 openspec init，建立 spec 同 change proposal，然後喺 Claude Code 用 Superpowers 執行，最後用 openspec archive 做終止條件。咁樣就可以避免審查循環無限轉同跨 task 資訊斷層嘅問題。
Superpowers 嘅軟約束困境
Superpowers 嘅核心理唸係用精心設計嘅 markdown 技能文件注入 LLM 上下文，強制 agent 行 brainstorming → spec → plan → TDD → review 嘅完整流程。但源碼話畀我哋知，呢啲「鐵律」全部只係自然語言。
- **反合理化條目**：框架包含 15 種防止 agent 偷懶嘅規則，但全部係 prompt，唔係程式邏輯。
- **審查循環可能無限轉**：兩階段審查（規格合規 + 代碼質量）冇最大迭代次數、超時機制或者成本上限。5 個 task 最少 16 次 subagent 派遣，每次審查失敗就膨脹。
- **每個 task 都係新嚟嘅**：subagent 唔繼承 session 完整歷史，controller 判斷資訊傳遞，容易導致跨 task 架構不一致。
- **零依賴代價**：冇 AST 解析器、linter、靜態分析工具，所有質量檢查全靠 LLM 自己睇 code。
說到底，當一個框架嘅所有規則都依賴被約束者嘅自覺遵守時，其可靠性上限取決於 LLM 本身嘅可靠度。
OpenSpec 嘅硬約束解決咗乜
OpenSpec 行一條完全唔同嘅路：唔用 prompt 約束 LLM 行為，而係用結構化規格約束「要構建乜」呢件事本身。
- 1 **DAG 依賴圖**：用 Kahn 算法做拓撲排序，artifact 生成有順序，唔會漏。
- 2 **Schema 三級解析**：項目自訂 schema > 用戶全局 schema > 包內置 schema，團隊可以擴展規格約束。
- 3 **Delta Spec 管理**：變更加入 ADDED / MODIFIED / REMOVED / RENAMED 格式，應用順序硬編碼（RENAMED → REMOVED → MODIFIED → ADDED），唔靠 LLM 判斷。
但 OpenSpec 都有自身侷限：驗證引擎唔會自動運行（唔係 pre-commit hook），Scenario 格式約束弱（只檢查 header 存在），Verify 命令純 AI 驅動。
互補機制：硬約束夾執行自測
將兩個工具放埋一齊，互補關係好清楚：OpenSpec 用硬約束確保「定義質量」，Superpowers 用結構化流程確保「執行質量」。兩者補齊對方嘅短板。
總括嚟講，OpenSpec 管「做啲乜」，Superpowers 管「點樣做」，加埋 OpenSpec 歸檔嘅質量門禁，就係雙重保險。
極簡工作流：4 步落地
理論講完，實際用起嚟可以跟呢套 4 步閉環工作流。
- 1 **Step 1：用 OpenSpec 定義規格** — 執行 `npx @fission-ai/openspec init` 同 `npx @fission-ai/openspec spec`，產出結構化 spec 文件，包含 name、overview、requirements（每個 requirement 帶 SHALL/MUST 關鍵字同至少一個 scenario）。
- 2 **Step 2：用 OpenSpec 創建 Change Proposal** — 執行 `npx @fission-ai/openspec change`，OpenSpec 會按 DAG 依賴圖順序產生 artifact，why 字段強制你諗清楚點解做呢個變更。產出 Delta Spec 做後續審查基準。
- 3 **Step 3：用 Superpowers 執行實現** — Superpowers 透過 session-start hook 自動注入，agent 行 brainstorming → plan → TDD → review 流程。佢嘅規格審查以 OpenSpec 嘅 Delta Spec 為準，唔係自己臨時生成。可以手動設定審查最大輪次降低成本。
- 4 **Step 4：用 OpenSpec 驗證並歸檔** — 執行 `npx @fission-ai/openspec validate` 同 `npx @fission-ai/openspec archive`，歸檔時做三重檢查：proposal 驗證、delta spec 驗證、重建 spec 驗證。呢個係質量門禁，擋住唔合規嘅變更。
項目根目錄/
├── .openspec/
│ ├── config.yml # OpenSpec 配置
│ ├── schemas/ # 項目自定義 schema（可選）
│ └── changes/ # 變更提案目錄
├── using-superpowers/
│ └── SKILL.md # Superpowers 技能注入文件
└── .claude/
└── hooks/
└── session-start # Superpowers 注入 hook關鍵係：唔好 skip requirements 嘅 scenario 定義，well-defined scenario 係後續 Superpowers 審查嘅基準。
🚩 2026 年「術哥無界」系列實戰文檔 X 篇原創計劃 第 100 篇，AI 編程最佳實戰「2026」系列第 25 篇
大家好，歡迎嚟到 術哥無界 | ShugeX ｜ 運維有術。
我是術哥，一個專注於 AI 編程、AI 智能體、Agent Skills、MCP、雲原生、AIOps、Milvus 向量數據庫嘅技術實踐者同開源佈道者！
Talk is cheap, let's explore。無界探索，有術而行。
圖 1：OpenSpec + Superpowers 協同工作流全景
AI 編程助手幫你寫程式碼，邊個幫你驗證 AI 寫嘅程式碼？
呢個問題喺 Superpowers 項目嘅 README 裏面有一個好誠實嘅答案：項目自身記錄咗 24 次 LLM 喺驗證環節講大話嘅失敗案例。一個將 prompt 工程做到極致嘅框架，承認純靠 prompt 約束 AI 唔可靠。
翻完 Superpowers 同 OpenSpec 嘅源碼之後，我發現咗一個有意思嘅互補關係：Superpowers 擅長執行同自測，但喺寫啲乜嘅質量把控上係軟約束；OpenSpec 擅長喺編碼前建立結構化規格，用硬約束定義寫啲乜，但缺乏執行層面嘅閉環。兩個工具組合埋一齊，啱啱好補齊咗各自嘅短板。
說明：本文內容係基於 OpenSpec v1.3.1 和 Superpowers v5.0.7 嘅本地源碼分析整理而成。文中關於工具侷限性嘅分析都對應源碼入面嘅實際實現邏輯，標註咗關鍵文件路徑同行號。文章只代表基於當前版本源碼嘅技術分析，工具後續版本可能已經修復或者調整咗相關實現，請以官方最新版本為準。 如果你喺實際使用中有唔同發現，歡迎喺評論區分享交流。
1. Superpowers 嘅軟約束困境
Superpowers 嘅核心理念好純粹：用精心設計嘅 markdown 技能文件注入到 LLM 上下文，強制 agent 行 brainstorming → spec → plan → TDD → review 嘅完整流程。聽落好完美。
但源碼話畀我哋另一個故事。
所有鐵律都只係自然語言
Superpowers 嘅技能發現機制裏面有一段標誌性嘅指令：
<EXTREMELY-IMPORTANT>
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional.
</EXTREMELY-IMPORTANT>
呢段嚟自 using-superpowers/SKILL.md 嘅注入邏輯。注意，呢個確實係純文字指令。框架包含 15 種反合理化條目嚟防止 agent 偷懶行捷徑，但冇一行可執行代碼嚟強制執行呢啲規則。
呢個意味住啲乜？低能力模型或者長上下文場景之下，指令遵從率會下降。所有規則、鐵律、硬門控都只係 prompt，唔係程序邏輯。
審查循環可能無限轉落去
Superpowers 嘅反饋循環設計咗兩階段審查：先做規格合規審查（spec-reviewer-prompt.md），再做代碼質量審查（code-quality-reviewer-prompt.md）。邏輯係：
規格審查員確認代碼匹配規格？
→ 否 → 實現者修復 → 重新規格審查
→ 是 → 派遣代碼質量審查員
代碼質量審查員批准？
→ 否 → 實現者修復 → 重新代碼質量審查
→ 是 → 標記任務完成
呢個流程有三種顯式終止條件：規格審查通過、代碼質量審查通過、用戶手動批准。但缺少咗關鍵嘅安全閥：冇最大迭代次數限制，冇超時機制，冇成本上限。
對於包含 5 個 task 嘅計劃，最少需要 16 次 subagent 派遣（1 個實現者 + 1 個規格審查者 + 1 個代碼質量審查者，每個 task）。如果每輪審查失敗 1 次，數字就會膨脹到 26 次。喺冇硬性終止條件嘅情況下，資源消耗完全唔可以預測。
每個 task 都係新嚟嘅
Superpowers 嘅 subagent 機制係每個 task 創建獨立嘅子代理。controller 構造上下文傳遞俾 subagent，但 subagent 唔繼承 session 嘅完整歷史。
呢個帶嚟咗跨任務架構一致性問題：如果 Task 3 嘅實現者改咗某個接口，Task 7 嘅實現者唔會知道。每個 subagent 都好似新嚟嘅，只係拎到 controller 認為佢需要嘅信息。信息傳遞嘅完整性完全依賴 controller 嘅判斷，而 controller 本身都係 LLM。
零依賴的代價
Superpowers 號稱零依賴，唔依賴任何第三方工具或庫。呢個設計選擇有明確嘅權衡：冇辦法使用 AST 解析器、linter/formatter、靜態分析工具、測試覆蓋率工具。所有代碼質量檢查都依賴 LLM 嘅代碼閲讀能力。
講到底，當一個框架嘅所有規則都依賴被約束者嘅自覺遵守時，佢嘅可靠性上限取決於 LLM 本身嘅可靠度。呢個就係 Superpowers 嘅根本限制。
2. OpenSpec 嘅硬約束解決咗啲乜
OpenSpec 走咗一條完全唔同嘅路：唔依賴 prompt 約束 LLM 嘅行為，而係用結構化規格約束要構建啲乜呢件事本身。
圖 2：OpenSpec 內部架構——從 CLI 到 Core 嘅分層結構與數據流
結構約束：唔係建議，係門禁
OpenSpec 嘅驗證引擎（src/core/validation/）定義咗硬性指標：
Spec 文件必須包含 name、overview、requirements三個字段每個 Requirement 必須包含 SHALL或MUST關鍵字（遵循 RFC 2119 規範）每個 Requirement 至少有一個 Scenario Change Proposal 嘅 why字段長度必須喺 50-1000 字符之間每個 Change 嘅 deltas 數量限制喺 1-10 個
呢啲唔係 prompt 裏面嘅請儘量遵守，而係 Zod schema 定義嘅數據結構驗證。唔符合規格嘅文件根本冇辦法通過驗證。
DAG 依賴圖：令 artifact 生成有序可追溯
OpenSpec 嘅核心模塊之一係 Artifact Graph Engine（src/core/artifact-graph/graph.ts），使用 Kahn 算法實現拓撲排序，管理 artifact 之間嘅依賴關係。
呢個意味住：當你創建一個 Change Proposal 時，OpenSpec 唔係讓 AI 自由發揮，而係按照依賴圖順序，逐個生成 artifact。每個 artifact 嘅完成狀態通過文件系統檢測（state.ts 行 14-29），確保唔遺漏。
Schema 三級解析：規格可擴展
OpenSpec 嘅 Schema Resolution（src/core/artifact-graph/resolver.ts 行 63-91）實現咗三級優先級解析：
項目本地（ .openspec/schemas/）- 項目自定義 schema用戶全局（ ~/.openspec/schemas/）- 用戶偏好 schema包內置 - OpenSpec 默認 schema
呢個設計讓團隊可以喺唔修改框架代碼嘅情況下，擴展自己嘅規格約束。
Delta Spec 管理：變更可追溯
OpenSpec 使用 Delta Spec 管理規格變更，格式固定為：
## ADDED Requirements
## MODIFIED Requirements
## REMOVED Requirements
## RENAMED Requirements
應用順序都係硬編碼嘅：RENAMED → REMOVED → MODIFIED → ADDED。呢個唔依賴 LLM 嘅判斷，而係程序邏輯保證。
但 OpenSpec 都有自己嘅侷限。驗證引擎唔係自動強制運行嘅（唔作為 pre-commit hook 或 CI gate），Scenario 格式約束較弱（只檢查 header 存在），Verify 命令係純 AI 驅動嘅（冇程序化驗證邏輯）。佢解決咗定義質量嘅問題，但執行質量仍然依賴 AI 嘅表現。
3. 互補機制：硬約束 + 執行自測
將兩個工具擺埋一齊睇，互補關係非常清晰。
圖 3：OpenSpec（定義質量）同 Superpowers（執行質量）嘅六維互補關係
核心互補邏輯：OpenSpec 喺編碼前建立結構化規格，用硬約束確保要構建啲乜係清晰嘅；Superpowers 喺編碼過程中提供 7 階段執行流程同兩階段審查，確保點樣構建係可靠嘅。前者解決嘅係定義質量問題，後者解決嘅係執行質量問題。
具體嚟講：
OpenSpec 彌補 Superpowers 嘅 4 個短板：
軟約束 → 硬約束：Superpowers 嘅鐵律係 prompt，OpenSpec 嘅 spec 驗證係 Zod schema。規格唔合規，直接報錯，唔依賴 LLM 嘅自覺。
無終止條件 → 質量門禁：OpenSpec 嘅歸檔流程（archive）要求 proposal 同 delta spec 驗證通過、任務完成度檢查通過。呢個俾 Superpowers 嘅審查循環提供咗一個外部嘅終點線。
跨 task 信息斷層 → Delta Spec 可追溯：OpenSpec 嘅 Delta Spec 機制讓每個變更都有結構化記錄。就算 Superpowers 嘅 subagent 唔繼承完整上下文，至少有 Delta Spec 可以查詢變更歷史。
純 LLM 審查 → 程序化驗證兜底：Superpowers 嘅兩階段審查完全依賴 LLM，OpenSpec 嘅驗證引擎用程序化邏輯兜底。兩道防線總比一道強。
Superpowers 彌補 OpenSpec 嘅 3 個短板：
驗證不自動 → 執行流程強制覆蓋：OpenSpec 嘅驗證需要手動觸發，Superpowers 嘅 7 階段工作流確保每個環節都被覆蓋。
Verify 係純 AI → 兩階段審查細化：OpenSpec 嘅 Verify 命令冇程序化驗證邏輯，Superpowers 嘅規格合規審查 + 代碼質量審查提供咗更細粒度嘅檢查。
無執行閉環 → TDD + review 閉環：OpenSpec 定義咗做啲乜，但唔指導點樣做。Superpowers 嘅 TDD 流程同代碼審查形成咗執行閉環。
你喺項目入面試過類似嘅組合方案未？例如先用規格工具定義清楚需求，再讓 AI 按流程執行。歡迎喺評論區講嚇你嘅經驗。
4. 極簡工作流：4 步落地
理論講完咗，具體點樣喺項目入面用？呢度俾出一套經過驗證嘅 4 步工作流。
圖 4：OpenSpec + Superpowers 四步閉環工作流——從定義規格到驗證歸檔
第 1 步：用 OpenSpec 定義規格
# 初始化 OpenSpec
npx @fission-ai/openspec init
# 創建規格文件
npx @fission-ai/openspec spec
呢一步產出嘅係結構化嘅 spec 文件，包含 name、overview、requirements（每個 requirement 帶 SHALL/MUST 關鍵字同至少一個 scenario）。
關鍵點：唔好跳過 requirements 嘅 scenario 定義。OpenSpec 嘅驗證引擎雖然對 scenario 格式約束較弱（只檢查 header 存在），但 well-defined scenario 係後續 Superpowers 審查嘅基準。
第 2 步：用 OpenSpec 創建 Change Proposal
# 創建變更提案
npx @fission-ai/openspec change
OpenSpec 會按照 DAG 依賴圖順序，逐個生成 artifact（src/core/artifact-graph/graph.ts 使用 Kahn 算法拓撲排序）。why 字段要求 50-1000 字符，強制你思考清楚點解要做呢個變更。
呢一步嘅產出係結構化嘅 Change Proposal + Delta Spec。Delta Spec 明確定義咗 ADDED / MODIFIED / REMOVED / RENAMED 嘅 requirements，後續 Superpowers 嘅規格審查就以呢個 Delta Spec 為基準。
第 3 步：用 Superpowers 執行實現
# Superpowers 通過 session-start hook 自動注入
# 在 Claude Code 中直接開始工作
呢一步 Superpowers 接管執行層。agent 按照 brainstorming → plan → TDD → review 嘅流程工作。關鍵係：Superpowers 嘅規格審查以 OpenSpec 嘅 Delta Spec 為準，而唔係自己臨時生成規格。
審查循環嘅資源消耗可以咁樣控制：手動設定每類審查嘅最大輪次（例如規格審查 3 輪、代碼質量審查 2 輪），作為 OpenSpec archive 嘅前置條件。呢個彌補咗 Superpowers 缺少硬性終止條件嘅問題。
第 4 步：用 OpenSpec 驗證並歸檔
# 驗證變更
npx @fission-ai/openspec validate
# 歸檔
npx @fission-ai/openspec archive
歸檔時 OpenSpec 會執行三重檢查：proposal 驗證、delta spec 驗證、重建 spec 驗證。呢個係成個工作流嘅質量門禁。
如果 Superpowers 嘅審查循環仲喺度行，OpenSpec 嘅歸檔會擋住唔合規嘅變更。兩個工具嘅驗證邏輯形成咗雙重保險。
配置要點
項目根目錄/
├── .openspec/
│ ├── config.yml # OpenSpec 配置
│ ├── schemas/ # 項目自定義 schema（可選）
│ └── changes/ # 變更提案目錄
├── using-superpowers/
│ └── SKILL.md # Superpowers 技能注入文件
└── .claude/
└── hooks/
└── session-start # Superpowers 注入 hook
OpenSpec 同 Superpowers 嘅配置係獨立嘅，唔存在衝突。OpenSpec 負責 .openspec/ 目錄下嘅規格管理，Superpowers 通過 .claude/hooks/session-start 注入執行流程。兩者喺文件系統層面互不幹擾，但喺工作流層面緊密協同。
總結
AI 編程嘅質量問題，本質上係兩件事：定義唔清楚和執行唔到位。
Superpowers 將執行流程做到咗極致——7 階段工作流、兩階段審查、subagent 隔離。但所有規則都係 prompt，唔係代碼。OpenSpec 將定義質量做到咗程序化——Zod schema 驗證、DAG 依賴管理、Delta Spec 變更追蹤。但執行層面缺乏閉環。
兩個工具嘅組合邏輯好簡單：OpenSpec 用硬約束定義清楚做啲乜，Superpowers 用結構化流程確保點樣做。 一個管規格，一個管執行。加上 OpenSpec 歸檔時嘅質量門禁作為外部嘅終止條件，Superpowers 審查循環嘅無限轉問題都有咗兜底。
講到底，快速開發同高質量代碼之間，差距唔喺工具本身，而在於你有冇喺 AI 開始寫代碼之前，將要寫啲乜呢件事定義清楚。OpenSpec 解決嘅就係呢一個問題。
如果你嘅團隊都係用 AI 編程助手，建議收藏呢篇文章。下次遇到 AI 生成嘅代碼質量唔穩定時，可以試嚇先規格、後執行嘅組合方案。
好啦，多謝你睇我嘅文章，如果鍾意可以點讚轉發俾需要嘅朋友，我哋下一期再見！敬請期待！
掃碼關注，獲取更多 AI 工具嘅實戰經驗同最佳實踐。唔好錯過每一篇乾貨！
🚩 2026 年「術哥無界」系列實戰文檔 X 篇原創計劃 第 100 篇，AI 編程最佳實戰「2026」系列第 25 篇
大家好，歡迎來到 術哥無界 | ShugeX ｜ 運維有術。
我是術哥，一名專注於 AI 編程、AI 智能體、Agent Skills、MCP、雲原生、AIOps、Milvus 向量數據庫的技術實踐者與開源佈道者！
Talk is cheap, let's explore。無界探索，有術而行。
圖 1：OpenSpec + Superpowers 協同工作流全景
AI 編程助手幫你寫代碼，誰幫你驗證 AI 寫的代碼？
這個問題在 Superpowers 項目的 README 裏有一個很誠實的答案：項目自身記錄了 24 次 LLM 在驗證環節撒謊的失敗案例。一個把 prompt 工程做到極致的框架，承認純靠 prompt 約束 AI 不可靠。
翻完 Superpowers 和 OpenSpec 的源碼後，我發現了一個有意思的互補關係：Superpowers 擅長執行和自測，但在寫什麼的質量把控上是軟約束；OpenSpec 擅長在編碼前建立結構化規格，用硬約束定義寫什麼，但缺乏執行層面的閉環。兩個工具組合起來，恰好補齊了各自的短板。
說明：本文內容基於 OpenSpec v1.3.1 和 Superpowers v5.0.7 的本地源碼分析整理而成。文中關於工具侷限性的分析均對應源碼中的實際實現邏輯，標註了關鍵文件路徑和行號。文章僅代表基於當前版本源碼的技術分析，工具後續版本可能已修復或調整相關實現，請以官方最新版本為準。 如果你在實際使用中有不同發現，歡迎在評論區分享交流。
1. Superpowers 的軟約束困境
Superpowers 的核心理念很純粹：用精心設計的 markdown 技能文件注入到 LLM 上下文，強制 agent 走 brainstorming → spec → plan → TDD → review 的完整流程。聽起來很完美。
但源碼告訴我們另一個故事。
所有鐵律都只是自然語言
Superpowers 的技能發現機制中有一段標誌性的指令：
<EXTREMELY-IMPORTANT>
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional.
</EXTREMELY-IMPORTANT>
這段來自 using-superpowers/SKILL.md 的注入邏輯。注意，這確實是純文本指令。框架包含 15 種反合理化條目來防止 agent 偷懶走捷徑，但沒有一行可執行代碼來強制執行這些規則。
這意味着什麼？低能力模型或長上下文場景下，指令遵從率會下降。所有規則、鐵律、硬門控都只是 prompt，不是程序邏輯。
審查循環可能無限轉下去
Superpowers 的反饋循環設計了兩階段審查：先做規格合規審查（spec-reviewer-prompt.md），再做代碼質量審查（code-quality-reviewer-prompt.md）。邏輯是：
規格審查員確認代碼匹配規格？
→ 否 → 實現者修復 → 重新規格審查
→ 是 → 派遣代碼質量審查員
代碼質量審查員批准？
→ 否 → 實現者修復 → 重新代碼質量審查
→ 是 → 標記任務完成
這個流程有三種顯式終止條件：規格審查通過、代碼質量審查通過、用戶手動批准。但缺少了關鍵的安全閥：沒有最大迭代次數限制，沒有超時機制，沒有成本上限。
對於包含 5 個 task 的計劃，最少需要 16 次 subagent 派遣（1 實現者 + 1 規格審查者 + 1 代碼質量審查者，每個 task）。如果每輪審查失敗 1 次，數字就膨脹到 26 次。在沒有硬性終止條件的情況下，資源消耗完全不可預測。
每個 task 都是新來的
Superpowers 的 subagent 機制是每個 task 創建獨立的子代理。controller 構造上下文傳遞給 subagent，但 subagent 不繼承 session 的完整歷史。
這帶來了跨任務架構一致性問題：如果 Task 3 的實現者改了某個接口，Task 7 的實現者不會知道。每個 subagent 都像是新來的，只拿到 controller 認為它需要的信息。信息傳遞的完整性完全依賴 controller 的判斷，而 controller 本身也是 LLM。
零依賴的代價
Superpowers 號稱零依賴，不依賴任何第三方工具或庫。這個設計選擇有明確的權衡：無法使用 AST 解析器、linter/formatter、靜態分析工具、測試覆蓋率工具。所有代碼質量檢查都依賴 LLM 的代碼閲讀能力。
說到底，當一個框架的所有規則都依賴被約束者的自覺遵守時，其可靠性上限取決於 LLM 本身的可靠度。這就是 Superpowers 的根本限制。
2. OpenSpec 的硬約束解決了什麼
OpenSpec 走了一條完全不同的路：不依賴 prompt 約束 LLM 的行為，而是用結構化規格約束要構建什麼這件事本身。
圖 2：OpenSpec 內部架構——從 CLI 到 Core 的分層結構與數據流
結構約束：不是建議，是門禁
OpenSpec 的驗證引擎（src/core/validation/）定義了硬性指標：
Spec 文件必須包含 name、overview、requirements三個字段每個 Requirement 必須包含 SHALL或MUST關鍵字（遵循 RFC 2119 規範）每個 Requirement 至少有一個 Scenario Change Proposal 的 why字段長度必須在 50-1000 字符之間每個 Change 的 deltas 數量限制在 1-10 個
這些不是 prompt 裏的請儘量遵守，而是 Zod schema 定義的數據結構驗證。不符合規格的文件根本無法通過驗證。
DAG 依賴圖：讓 artifact 生成有序可追溯
OpenSpec 的核心模塊之一是 Artifact Graph Engine（src/core/artifact-graph/graph.ts），使用 Kahn 算法實現拓撲排序，管理 artifact 之間的依賴關係。
這意味着：當你創建一個 Change Proposal 時，OpenSpec 不是讓 AI 自由發揮，而是按照依賴圖順序，逐個生成 artifact。每個 artifact 的完成狀態通過文件系統檢測（state.ts 行 14-29），確保不遺漏。
Schema 三級解析：規格可擴展
OpenSpec 的 Schema Resolution（src/core/artifact-graph/resolver.ts 行 63-91）實現了三級優先級解析：
項目本地（ .openspec/schemas/）- 項目自定義 schema用戶全局（ ~/.openspec/schemas/）- 用戶偏好 schema包內置 - OpenSpec 默認 schema
這個設計讓團隊可以在不修改框架代碼的情況下，擴展自己的規格約束。
Delta Spec 管理：變更可追溯
OpenSpec 使用 Delta Spec 管理規格變更，格式固定為：
## ADDED Requirements
## MODIFIED Requirements
## REMOVED Requirements
## RENAMED Requirements
應用順序也是硬編碼的：RENAMED → REMOVED → MODIFIED → ADDED。這不依賴 LLM 的判斷，而是程序邏輯保證。
但 OpenSpec 也有自己的侷限。驗證引擎並非自動強制運行的（不作為 pre-commit hook 或 CI gate），Scenario 格式約束較弱（只檢查 header 存在），Verify 命令是純 AI 驅動的（沒有程序化驗證邏輯）。它解決了定義質量的問題，但執行質量仍然依賴 AI 的表現。
3. 互補機制：硬約束 + 執行自測
把兩個工具放在一起看，互補關係非常清晰。
圖 3：OpenSpec（定義質量）與 Superpowers（執行質量）的六維互補關係
核心互補邏輯：OpenSpec 在編碼前建立結構化規格，用硬約束確保要構建什麼是清晰的；Superpowers 在編碼過程中提供 7 階段執行流程和兩階段審查，確保怎麼構建是可靠的。前者解決的是定義質量問題，後者解決的是執行質量問題。
具體來說：
OpenSpec 彌補 Superpowers 的 4 個短板：
軟約束 → 硬約束：Superpowers 的鐵律是 prompt，OpenSpec 的 spec 驗證是 Zod schema。規格不合規，直接報錯，不依賴 LLM 的自覺。
無終止條件 → 質量門禁：OpenSpec 的歸檔流程（archive）要求 proposal 和 delta spec 驗證通過、任務完成度檢查通過。這給 Superpowers 的審查循環提供了一個外部的終點線。
跨 task 信息斷層 → Delta Spec 可追溯：OpenSpec 的 Delta Spec 機制讓每個變更都有結構化記錄。即使 Superpowers 的 subagent 不繼承完整上下文，至少有 Delta Spec 可以查詢變更歷史。
純 LLM 審查 → 程序化驗證兜底：Superpowers 的兩階段審查完全依賴 LLM，OpenSpec 的驗證引擎用程序化邏輯兜底。兩道防線總比一道強。
Superpowers 彌補 OpenSpec 的 3 個短板：
驗證不自動 → 執行流程強制覆蓋：OpenSpec 的驗證需要手動觸發，Superpowers 的 7 階段工作流確保每個環節都被覆蓋。
Verify 是純 AI → 兩階段審查細化：OpenSpec 的 Verify 命令沒有程序化驗證邏輯，Superpowers 的規格合規審查 + 代碼質量審查提供了更細粒度的檢查。
無執行閉環 → TDD + review 閉環：OpenSpec 定義了做什麼，但不指導怎麼做。Superpowers 的 TDD 流程和代碼審查形成了執行閉環。
你在項目中試過類似的組合方案嗎？比如先用規格工具定義清楚需求，再讓 AI 按流程執行。歡迎在評論區聊聊你的經驗。
4. 極簡工作流：4 步落地
理論講完了，具體怎麼在項目裏用起來？這裏給出一套經過驗證的 4 步工作流。
圖 4：OpenSpec + Superpowers 四步閉環工作流——從定義規格到驗證歸檔
第 1 步：用 OpenSpec 定義規格
# 初始化 OpenSpec
npx @fission-ai/openspec init
# 創建規格文件
npx @fission-ai/openspec spec
這一步產出的是結構化的 spec 文件，包含 name、overview、requirements（每個 requirement 帶 SHALL/MUST 關鍵字和至少一個 scenario）。
關鍵點：不要跳過 requirements 的 scenario 定義。OpenSpec 的驗證引擎雖然對 scenario 格式約束較弱（只檢查 header 存在），但 well-defined scenario 是後續 Superpowers 審查的基準。
第 2 步：用 OpenSpec 創建 Change Proposal
# 創建變更提案
npx @fission-ai/openspec change
OpenSpec 會按照 DAG 依賴圖順序，逐個生成 artifact（src/core/artifact-graph/graph.ts 使用 Kahn 算法拓撲排序）。why 字段要求 50-1000 字符，強制你思考清楚為什麼要做這個變更。
這一步的產出是結構化的 Change Proposal + Delta Spec。Delta Spec 明確定義了 ADDED / MODIFIED / REMOVED / RENAMED 的 requirements，後續 Superpowers 的規格審查就以這個 Delta Spec 為基準。
第 3 步：用 Superpowers 執行實現
# Superpowers 通過 session-start hook 自動注入
# 在 Claude Code 中直接開始工作
這一步 Superpowers 接管執行層。agent 按照 brainstorming → plan → TDD → review 的流程工作。關鍵是：Superpowers 的規格審查以 OpenSpec 的 Delta Spec 為準，而不是自己臨時生成規格。
審查循環的資源消耗可以這樣控制：手動設定每類審查的最大輪次（比如規格審查 3 輪、代碼質量審查 2 輪），作為 OpenSpec archive 的前置條件。這彌補了 Superpowers 缺少硬性終止條件的問題。
第 4 步：用 OpenSpec 驗證並歸檔
# 驗證變更
npx @fission-ai/openspec validate
# 歸檔
npx @fission-ai/openspec archive
歸檔時 OpenSpec 會執行三重檢查：proposal 驗證、delta spec 驗證、重建 spec 驗證。這是整個工作流的質量門禁。
如果 Superpowers 的審查循環還在跑，OpenSpec 的歸檔會擋住不合規的變更。兩個工具的驗證邏輯形成了雙重保險。
配置要點
項目根目錄/
├── .openspec/
│ ├── config.yml # OpenSpec 配置
│ ├── schemas/ # 項目自定義 schema（可選）
│ └── changes/ # 變更提案目錄
├── using-superpowers/
│ └── SKILL.md # Superpowers 技能注入文件
└── .claude/
└── hooks/
└── session-start # Superpowers 注入 hook
OpenSpec 和 Superpowers 的配置是獨立的，不存在衝突。OpenSpec 負責 .openspec/ 目錄下的規格管理，Superpowers 通過 .claude/hooks/session-start 注入執行流程。兩者在文件系統層面互不干擾，但在工作流層面緊密協同。
總結
AI 編程的質量問題，本質上是兩件事：定義不清楚和執行不到位。
Superpowers 把執行流程做到了極致——7 階段工作流、兩階段審查、subagent 隔離。但所有規則都是 prompt，不是代碼。OpenSpec 把定義質量做到了程序化——Zod schema 驗證、DAG 依賴管理、Delta Spec 變更追蹤。但執行層面缺乏閉環。
兩個工具的組合邏輯很簡單：OpenSpec 用硬約束定義清楚做什麼，Superpowers 用結構化流程確保怎麼做。 一個管規格，一個管執行。加上 OpenSpec 歸檔時的質量門禁作為外部的終止條件，Superpowers 審查循環的無限轉問題也有了兜底。
說到底，快速開發和高質量代碼之間，差距不在工具本身，而在於你有沒有在 AI 開始寫代碼之前，把要寫什麼這件事定義清楚。OpenSpec 解決的就是這一個問題。
如果你的團隊也在用 AI 編程助手，建議收藏這篇文章。下次遇到 AI 生成的代碼質量不穩定時，可以試試先規格、後執行的組合方案。
好啦，謝謝你觀看我的文章，如果喜歡可以點贊轉發給需要的朋友，我們下一期再見！敬請期待！
掃碼關注，獲取更多 AI 工具的實戰經驗和最佳實踐。不錯過每一篇乾貨！