GitHub官方出品的Spec Kit、Fission-AI的OpenSpec、Jesse Vincent的Superpowers——三個框架都號稱讓AI編程更可控，但它們的思路完全不同。我用同一個項目跑了一遍，告訴你各自的真實表現
寫在前面
AI編程工具越來越強，但問題也越來越明顯：AI寫代碼很快，可它寫出來的東西經常不是你要的。
三個框架都想解決這個問題，但路線不同：
Spec Kit（GitHub官方）——用SDD（規範驅動開發，Spec-Driven Development），讓AI先寫PRD再寫代碼OpenSpec（Fission-AI）——用增量規範（Delta Spec），讓AI在已有項目上對齊需求Superpowers（Jesse Vincent）——用紀律框架（Skill），讓AI按工程標準執行我花了三週時間，用同一個項目（給Go微服務添加JWT認證）分別跑了一遍三個框架的完整流程。這篇文章是我的完整測評：每個框架怎麼用、適合什麼場景、踩了什麼坑、以及最終我選了哪個。
（注：SDD領域還有GSD（61K+星標）、BMAD-METHOD（46K+星標）等框架，各有側重，本文聚焦於三個代表性框架。）
一、三個框架的核心定位
先搞清楚一個關鍵區別：三個框架解決的不是同一個問題。
| | | |
|---|
| | | |
| | | |
| | | |
| constitution、spec、plan、tasks | proposal、specs、design、tasks | |
| | | |
| | | |
| | | |
一句話區分：Spec Kit是"先審批再施工"，OpenSpec是"邊改圖紙邊施工"，Superpowers是"不管圖紙，按規矩施工"。
二、Spec Kit深度測評
背景
Spec Kit是GitHub官方開源的SDD框架，源自John Lam的研究，由GitHub Principal Product Engineer Den Delimarsky主導開發。2025年9月發佈，數天內突破50K星標，目前約96K+星標、5.5K+ Fork、200+貢獻者。最新版本0.8.9。
核心工作流：7步流程（3步可選）
Spec Kit的流程是最嚴格的，每個階段都有相位門（Phase Gate），前一階段不通過不能進入下一階段：
前置階段：Constitution（憲法）
定義項目不可協商的原則。比如"必須TDD"、"必須CLI-first"、"安全合規標準"。憲法會在後續所有階段中作為約束條件被引用。
# 項目憲法
## 不可協商的原則
1. 所有新功能必須先寫測試
2. 優先使用CLI交互，GUI為輔
3. 所有API必須通過安全審查
4. 數據存儲必須加密
階段一：/specify（規範）
只關注"做什麼"和"為什麼做"，不做技術決策。產出spec.md（相當於PRD），包含用戶故事、功能需求、預期結果、假設。生成後自動對照憲法做自評（self-assessment）。
階段二：/clarify（澄清，可選）
挖掘"未知的未知"——spec寫完後，AI自動發現需求中的模糊點和遺漏。比如spec寫了"支持多語言"，clarify會追問"支持哪些語言？切換方式是什麼？回退策略怎麼處理？"。這是Spec Kit獨有的防盲點機制。
階段三：/checklist（檢查清單，可選）
用"英文單元測試"方式檢查spec的覆蓋度——UX、安全、無障礙、邊界情況是否都被覆蓋。相當於給spec做一次全方位的代碼審查。
階段四：/plan（計劃）
關注"怎麼做"。產出plan.md和配套文檔：module-contracts.md（模塊契約）、data-model.md（數據模型）、research.md（技術調研）、quickstart.md（快速啓動指南）。所有技術決策必須符合憲法。
階段五：/tasks（任務分解）
將spec和plan分解為可執行的小任務，包含分階段實施計劃、任務與用戶故事的映射、檢查點、可並行標識、依賴關係。
階段六：/analyze（分析，可選）
跨產物一致性檢查——spec、plan、tasks之間是否有矛盾或遺漏。比如spec要求"支持離線使用"，但plan選了需要聯網的方案，analyze會抓到這個不一致。
階段七：Implement（實施）
AI按tasks.md逐項執行，每個階段有顯式檢查點供人工審查。
實測表現
優點：
階段門控真的管用——spec階段不允許提技術方案，強制你先想清楚需求。我第一次用Spec Kit時，在spec階段發現需求寫反了（把"30分鐘過期"寫成了"30秒過期"），這時候改成本幾乎為零憲法機制很實用——團隊裏新人不用猜項目的技術底線，憲法寫得很清楚擴展生態豐富——91個社區擴展、18個預設，安全合規、架構治理、無障礙等都有現成方案跨工具支持好——切換AI工具只需一條命令，規範在所有工具間保持一致缺點：
文檔量太大——Scott Logic的實測數據顯示，CRUD功能產生2,577行Markdown和689行代碼（文檔量3.7倍），GPS集成產生2,262行Markdown和約300行代碼（文檔量7.5倍）。功能越簡單，文檔和代碼的比例越失衡，審查負擔重對棕地項目不友好——Spec Kit按功能分片（每個功能獨立文件），在已有項目上增量開發時，理解完整系統需要拼裝多個來源。沒有OpenSpec那種Delta規範機制速度慢——同樣的JWT認證功能，Spec Kit從Constitution到Implement走完要1.5小時，OpenSpec只要40分鐘。多出來的時間主要花在階段門控和文檔審查上部分文檔價值有限——research.md有時在論證明顯的事實，比如"JWT比session更適合移動端"這種不需要調研的結論Presets和Extensions
這是Spec Kit區別於另外兩個框架的最大亮點：
Presets（預設）——定製模板、格式、術語，不改變工具本身。18個預設覆蓋安全合規、架構治理、無障礙等場景。甚至有"海盜語"預設來演示能力邊界。
Extensions（擴展）——添加新命令或工作流。91個擴展包括：
安裝
# Python版（官方主推）
uvx --from git+https://github.com/github/spec-kit.git specify init 項目名
# Bun/TypeScript版
bunx @spec-kit/cli init 項目名
# 指定AI工具
specify init 項目名 --ai claude
三、OpenSpec深度測評
背景
OpenSpec是Fission-AI開發的開源SDD框架，核心理念是"規範是source of truth，代碼是規範的派生產物"。支持30+種AI工具，專為棕地項目設計。
核心工作流：增量式
OpenSpec的流程是最靈活的，強調迭代而非門控：
/opsx:onboard — 將已有代碼庫反向工程成baseline規範，讓已有項目無痛接入/opsx:explore — 和AI討論技術方案，不生成任何產物/opsx:propose — 一次生成proposal.md、delta specs、design.md、tasks.md/opsx:apply — 按tasks.md逐項執行/opsx:archive — 把delta specs合併到主規範，歸檔變更擴展流程（workflows profile）：
多了verify、sync、bulk-archive、continue、ff等命令，適合需要更多控制的場景。
verify的三維驗證模型：
verify從三個維度檢查實現和規範的一致性，報告分CRITICAL（必須修）、WARNING（建議修）、SUGGESTION（可選優化）三級：
| |
|---|
| |
| |
| 代碼和design.md的決策一致嗎，命名規範統一嗎 |
Schema自定義： OpenSpec允許通過YAML定義自定義產物流程，比如添加"調研階段"：
# 自定義"調研先行"流程
name: research-first
artifacts:
- id: research
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research]
- id: tasks
generates: tasks.md
requires: [proposal]
不是每個項目都需要design.md，Schema讓你按需調整，而不是被工具綁架。
實測表現
優點：
Delta規範是殺手鐧——不需要重寫整個規範，只寫變化的部分。在已有項目上加功能時，這個設計省了大量時間。我的JWT認證功能，Delta規範只寫了3個新增場景和2個修改場景，不用重寫整個認證規範並行開發天然支持——每個變更獨立文件夾，兩個人同時改同一個spec的不同需求不衝突verify能抓到代碼審查抓不到的問題——verify在完整性、正確性、一致性三個維度檢查。實測中發現我的實現用了內存map存黑名單，而design.md選的是Redis。代碼審查沒發現，因為代碼本身質量沒問題，只是和規範不一致。verify的CRITICAL/WARNING/SUGGESTION三級報告讓問題一目瞭然迭代速度快——從propose到apply只要40分鐘（同一個項目，Spec Kit要1.5小時）缺點：
沒有憲法/治理機制——Spec Kit有Constitution作為不可協商的底線，OpenSpec沒有等價物。團隊協作時，不同人可能寫出風格不一致的規範apply階段缺少紀律——AI按tasks.md執行，但沒有TDD、沒有代碼審查、沒有驗證機制。實現質量完全取決於AI的"自覺性"規範和實現容易脱節——沒有Spec Kit那樣的階段門控，AI可能跳過規範直接寫代碼，或者在實現過程中偏離design.md的決策擴展性弱——有Schema自定義功能，可以自定義產物流程，但社區生態遠不如Spec Kit的91個擴展和18個預設目錄結構
| |
|---|
openspec/specs/ | |
openspec/changes/功能名/ | |
openspec/changes/archive/ | |
安裝
npm install -g @fission-ai/openspec@latest
cd 你的項目目錄
openspec init
openspec update
四、Superpowers深度測評
背景
Superpowers是Jesse Vincent開發的紀律框架，5個月內GitHub星標從零漲到91K+。核心理念：如果你的AI助手聰明但沒有紀律，那就給它紀律。
核心工作流：14條紀律
Superpowers的流程是最注重執行質量的，14個Skill組成一條嚴格的開發流水線：
using-superpowers — 檢查該用哪個Skill。核心是"1%規則"：只要當前任務有1%的可能性匹配到某個Skill，就必須先調用該Skill再響應。設計意圖是防止最常見的失敗模式——AI因為"覺得簡單"而跳過結構化流程brainstorming — 先問清楚需求再動手writing-plans — 拆成2-5分鐘小任務using-git-worktrees — 創建隔離工作空間subagent-driven-development — 每個任務派新代理executing-plans — 無子代理時自己執行test-driven-development — 先寫失敗測試再寫代碼systematic-debugging — 先找根因再修bugrequesting-code-review — 派獨立代理審查receiving-code-review — 驗證審查意見再實施dispatching-parallel-agents — 獨立問題同時派多個代理verification-before-completion — 聲稱完成前必須跑驗證finishing-a-development-branch — 驗證、合併、清理writing-skills — 用TDD方法寫新Skill實測表現
優點：
TDD鐵律真的有效——"沒有失敗測試不寫代碼"不是建議，是鐵律。AI先寫測試再寫實現，測試覆蓋率從0%直接到80%+獨立代理審查避免確認偏誤——審查代理只看代碼變更，不瞭解你的思考過程，能抓到你視而不見的問題調試方法論最成熟——systematic-debugging的"3次規則"（連續3次修復失敗，停下來討論）和"最急的時候最該用系統方法"的理念，實測節省2-3小時提交粒度最合理——8個任務8次提交，每次提交都是原子性的。對比沒有Superpowers時的1次大提交缺點：
方向校準依賴brainstorming而非顯式規範——brainstorming能發現需求問題，但不像Spec Kit那樣有憲法和spec門控來系統性約束方向。TDD做得再好，做出來的東西和需求對不上也白搭流程開銷大——每個任務派新代理、獨立審查、驗證，簡單功能也要走完整流程。一次性腳本用Superpowers是浪費時間成本高——代理鏈式調用顯著增加token消耗。多位實踐者反饋Superpowers的代理鏈式調用會更快觸及Claude Pro/Max的使用上限沒有規範累積機制——每次新對話，AI忘光之前的決策。不像OpenSpec有主規範累積，也不像Spec Kit有ConstitutionSkill分類（按官方四類劃分）
| | |
|---|
| brainstorming、systematic-debugging、verification-before-completion | |
| test-driven-development、writing-plans、executing-plans | |
| requesting-code-review、receiving-code-review、finishing-a-development-branch | |
| dispatching-parallel-agents、subagent-driven-development、using-git-worktrees | |
每類Skill的嚴格程度不同：TDD是鐵律（跳過的代價是指數級增長的bug），代碼審查接收是建議（人做最終決定）。判斷標準只有一個：AI跳過這一步的代價有多大。
安裝
# Claude Code安裝
claude plugin install superpowers
# 或者手動安裝：將skill文件複製到 ~/.claude/skills/ 目錄
# Gemini CLI：通過GEMINI.md配置
# 驗證：說"幫我規劃一個功能"
# AI應該先問問題而不是直接寫代碼
五、同一個項目的對比實測
我用"給Go微服務添加JWT認證"這個需求，分別用三個框架走了一遍完整流程。以下是關鍵數據：
| | | |
|---|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | 1次（proposal的排除範圍不夠完善，AI自動補充了非預期功能） | |
| | | |
關鍵發現：
Spec Kit最慢但最安全——階段門控和憲法機制確保方向不會偏，但文檔量太大，審查負擔重OpenSpec速度和質量最平衡——Delta規範+verify的組合，在速度和規範合規之間找到了最佳平衡點Superpowers代碼質量最高但方向容易偏——TDD+審查確保代碼質量，但方向校準依賴brainstorming而非顯式規範，AI可能做出不需要的功能六、三個框架的適用場景
Spec Kit適合什麼
安全合規要求高的項目（有現成的安全合規預設和擴展）需要跨AI工具的團隊（30+種工具集成，切換零成本）OpenSpec適合什麼
棕地項目（在已有代碼上加功能，Delta規範天然適合）需要快速迭代的場景（從propose到apply只要40分鐘）Superpowers適合什麼
不適合的場景
| |
|---|
| 一次性腳本、小改動、個人小項目（流程開銷遠大於收益） |
| 需要強治理的團隊、需要強治理的綠地項目（缺少憲法和門控機制時可配合Superpowers使用） |
| 一次性腳本、緊急hotfix、探索性原型（流程會卡住） |
七、框架組合：1+1大於2
三個框架不是互斥的，可以組合使用。
最佳組合：OpenSpec + Superpowers
為什麼？ OpenSpec管"做什麼"（方向），Superpowers管"怎麼做"（執行）。兩個框架互補：
OpenSpec的explore和propose確定需求和方案跳過OpenSpec的apply（Superpowers的TDD做得更好）把OpenSpec的design.md和specs餵給Superpowers作為上下文每個task完成後：代碼審查 + spec-compliance-check + verify實測數據： 兩個框架組合使用時，返工次數降到0-1次，同時保持代碼質量。具體踩坑和銜接方法，我之前寫過一篇《兩個AI編程框架一起用，我踩了7個坑》，這裏不重複。
可選組合：Spec Kit + Superpowers
Spec Kit的憲法和階段門控 + Superpowers的TDD和審查。適合需要強治理的大型團隊。但要注意：Spec Kit的文檔量已經很大了，加上Superpowers的流程開銷，總耗時可能翻倍。
不推薦：Spec Kit + OpenSpec
兩個都是SDD框架，功能重疊太大。Spec Kit的/specify和OpenSpec的/opsx:propose做的是同一件事，同時用只會增加混亂。
八、選擇決策樹
有多少人碰代碼？1個人 → 看第3步；3人以上 → 看第4步一個人維護：已有項目加功能選OpenSpec，新項目從零開始選Spec Kit，只關心代碼質量選Superpowers團隊協作：需要合規治理選Spec Kit，快速迭代為主選OpenSpec + Superpowers，代碼質量底線選Superpowers核心判斷標準：代碼要活多久 × 有多少人碰 × 合規要求多高。
九、三個框架的侷限性
每個框架都有自己解決不了的問題，誠實地說：
Spec Kit的侷限：
文檔量是代碼量的3.7-7.5倍（Scott Logic實測，功能越簡單比例越失衡），部分文檔價值有限被批評為"重返瀑布模型"——階段門控雖然安全，但降低了靈活性棕地項目上不如OpenSpec，需要完整重寫規範而不是增量更新OpenSpec的侷限：
社區生態不如Spec Kit，擴展和預設數量差距大Superpowers的侷限：
方向校準依賴brainstorming而非顯式規範，系統性需求容易被遺漏寫在最後
三個框架本質上是三種不同的AI編程哲學：
Spec Kit——"先想清楚再動手"，用階段門控確保方向OpenSpec——"邊做邊對齊"，用增量規範適應變化Superpowers——"按規矩做事"，用鐵律確保質量沒有最好的框架，只有最適合的框架。如果你的項目需要合規和治理，選Spec Kit。如果你在已有項目上快速迭代，選OpenSpec。如果你只關心代碼質量，選Superpowers。如果你既要方向對又要質量好，選OpenSpec + Superpowers。
3條起步建議：
先想清楚你的痛點是"方向偏"還是"質量差"——方向偏用SDD框架，質量差用紀律框架不要一次用上所有功能——Spec Kit從憲法開始，OpenSpec從propose開始，Superpowers從3條鐵律開始用同一個需求分別試一遍——不試不知道哪個順手，試過才知道哪個適合你掃碼關注「AI智聞說」，每天3分鐘掌握AI新知識
