【2026 最新】OpenSpec vs Claude Code vs Spec Kit：規格稅 A/B Test 評估教學

OpenSpec vs Claude Code vs Spec Kit，真正該比的不是誰多產出幾份文件，而是多付出的「規格稅」，有沒有換回更少的錯改、返工與測試污染。本文給你一套同 Repo、三條工作流、Hidden Oracle、各跑三次的 A/B Test 方法；截至 2026 年 9 月，沒有可公開驗證的通用勝負數字，因此本文不把任何社群單次測試冒充成自己的實測結論。

如果你只想先拿走一句話：規格工具的淨收益＝少掉的錯改與返工成本－多出的規格、批准與維護成本。 高風險、多人協作、需求常變時，後半段可能值得付；低風險的一次性小改，文件本身很可能只是負擔。

OpenSpec vs Claude Code vs Spec Kit：先看結論

• plain Claude Code：啟動最快，也能用 Plan mode、SPEC.md、測試與 hooks 做出輕量 spec-first 流程；但沒有預設的持久規格生命週期。
• OpenSpec：把 proposal、spec、design、tasks 與 archive 串成可審閱的變更記錄，適合想保留需求差異、又不想導入太重流程的團隊。
• Spec Kit：把 constitution、spec、plan、tasks、analyze、implement、converge 拆得更細，治理能力較強，前置與維護成本通常也較高。

這三個選項都不會自動保證正確。OpenSpec 的 proposal 寫得漂亮、Spec Kit 顯示「Converged」、Claude Code 完成 todo，都不能取代獨立測試。選擇時先問：哪一條工作流讓外部 Oracle 更常通過，而且沒有用更多時間、token、批准與污染去換？

什麼是「規格稅」？文件數不是答案

規格稅不是「有 spec 就很慢」。它是為了維持流程而新增的總成本：安裝、初始化、理解指令、建立 artifact、回答澄清、人工批准、同步規格、清理產物，以及規格過時後的修正。它也有可能買到價值，例如更早發現缺漏、讓 reviewer 看得懂需求變更、避免 Agent 擅自碰到禁改檔案。

因此，最差的評估方式是比較「誰產出最多文件」；正確方式是先鎖定品質底線，再比較達到同一品質所付出的成本。這與我們先前談過的規格優先與收斂、Coding Agent 測試驗收是同一件事：規格是降低歧義的手段，Oracle 才是判定有沒有完成的尺。

三條工作流到底多了什麼？

1. plain Claude Code：最少框架，不等於沒有規格

Claude Code 原生就有 Plan mode，也可先請 Agent 訪談需求、寫成 SPEC.md，再開新 session 實作。Anthropic 的官方最佳實務也建議把探索、規劃、實作與驗證分開。plain baseline 的意思是「不安裝額外 SDD 框架」，不是叫 Agent 在沒有計畫、沒有測試的狀態下亂改。

優點是彈性高、一次性成本低；缺點是團隊若沒有自己定義 artifact 與審核點，每次 session 的規格深度可能不同。CLAUDE.md 是行為脈絡，不是硬性存取控制；不可觸碰檔案要靠 permissions、PreToolUse hook 或隔離環境執行。

2. OpenSpec：以 change 為中心的中量級流程

依 OpenSpec 官方 Repo目前的核心流程，常見順序是 /opsx:propose、/opsx:apply、視需要 /opsx:sync，最後 /opsx:archive；探索則可先用 /opsx:explore。proposal 階段會在變更目錄下建立 proposal、spec 與 tasks 等 artifact；design 依 change 條件產生，讓需求與實作工作有可審閱的落點。

OpenSpec 維護者把自己定位成較流動、較輕的選擇，但這是產品方的定位，不是獨立基準測試。你要驗證的是：這些 artifact 是否真的抓到 hidden requirement、減少錯檔與返工，而不是看到資料夾整齊就宣布勝利。

3. Spec Kit：治理與收斂階段更完整

GitHub Spec Kit 的 Claude 整合採連字號指令：一次性建立 constitution 後，短路徑可走 /speckit-specify → /speckit-plan → /speckit-tasks → /speckit-implement → /speckit-converge；完整路徑再加入 clarify、checklist 與 analyze。

但要小心三個常見誤解：requirements checklist 檢查的是需求品質，不是程式已完成；analyze 比對 artifact，不是執行測試；預設 tasks template 也不會在所有情況強制產生測試。即使 converge 說已收斂，仍要跑獨立 CI 或 Hidden Oracle。

OpenSpec vs Claude Code vs Spec Kit 的公平 A/B Test 設計

核心原則是只改「工作流」這一個變因。模型、Repo 狀態、功能 brief、權限、既有指令、測試資源與停止條件都要相同。若一條路徑用較強模型、另一條路徑能看見測試、第三條路徑又有更多人工提示，結果沒有可比性。

步驟一：選一個 brownfield 小功能

不要用全新 todo app。選現有測試、既有架構與真實相依性的 Repo，小到三次重跑付得起，大到必須理解需求。例如：「看板任務拖到另一日期欄後，前端立即更新；後端拒絕無效日期；重新整理仍保留結果。」

• 允許改動：任務 API、看板互動元件、相對應公開測試。
• 禁止改動：資料庫 seed、Oracle fixture、驗收 runner、鎖定檔與非必要設定。
• 隱藏需求：時區邊界、無效日期、重複提交與失敗後 UI rollback。

「禁止改動」不能只寫進 prompt；用 PreToolUse hook 封鎖路徑，或把 Oracle 放在 Agent 看不到、寫不到的外部目錄。否則 Agent 可能改測試讓自己通過，這就是測試污染。

步驟二：凍結環境與版本

從同一 commit 建三份乾淨 working copy；每次 run 都從相同 snapshot 開始。把模型完整 ID、Claude Code 版本、OpenSpec／Spec Kit 版本、Node／Python 版本、系統、權限模式與 run 順序寫進 manifest。順序要隨機化，避免第一次跑學到的人工操作偏向後面的工具。

git rev-parse HEAD
claude --version
node --version
python3 --version
openspec --version
specify version

截至 2026 年 9 月 20 日，本文核對的穩定版是 OpenSpec v1.13.1 與 Spec Kit v1.0.8；版本會變，真正重跑時請重新核對 release，並在實驗中 pin 住，而不是直接安裝移動中的 main 或 latest。

步驟三：用同一份功能 brief 與回答表

三條路徑都收到相同 brief，但不必硬性要求完全相同的每一句對話，因為工具本來就會提出不同澄清。公平做法是預先寫一份「問題→答案」表；遇到等價問題，只能從表中回覆，不額外透露 Oracle。所有未列出的人工提示一律記錄。

目標：完成指定功能並通過現有測試。
限制：不得修改 [forbidden paths]，不得新增非必要依賴。
完成條件：自行執行公開測試；回報改動檔案、測試與未解風險。
不可見條件：Hidden Oracle 由外部 runner 在 session 結束後執行。

步驟四：設定三個 intervention

plain Claude Code 不安裝額外框架，但允許原生 plan、既有 CLAUDE.md 與同一組 hooks。這才是有能力的 baseline，而不是刻意削弱的稻草人。

claude --permission-mode plan
# 看完計畫後，依預先定義的核准規則進入實作。

OpenSpec 目前要求 Node.js 20.19 以上。建議先固定版號，初始化後關閉 telemetry，再走核心流程。官方說明列出的 opt-out 包括設定值與環境變數：

npm install -g @fission-ai/openspec@1.13.1
openspec init --tools claude
openspec config set telemetry.enabled false
# 或在測試 shell：
export OPENSPEC_TELEMETRY=0

OpenSpec 的匿名 telemetry 預設為 opt-out；官方表示它收集指令名、版本與本機隨機識別碼，不收集路徑或檔案內容，CI 中停用。隱私偏好與 A/B 可重現性都支持先明確關閉，詳細規則以官方 SECURITY 文件為準。

Spec Kit 可用 v1.0.8 的固定來源安裝。既有 Repo 初始化會寫入框架檔案，所以先 commit 或備份；Claude 整合要明確指定，不要讓非互動預設值改變 intervention。

uv tool install specify-cli \
  --from git+https://github.com/github/spec-kit.git@v1.0.8
specify init --here --force --non-interactive \
  --integration claude --script sh
specify version

步驟五：各跑三次，Oracle 最後才揭曉

每條路徑至少三個獨立 session；不要讓第二次 run 繼承第一次 context 或產物。Agent 宣告完成後先封存 log 與 diff，再由外部 runner 執行 Hidden Oracle。失敗也不能現場提示答案後繼續，否則那一次已變成另一種 intervention。

該記哪些數字？先品質，再成本

不要急著做一個華麗的總分。先設定不能交換的主結果，再列成本。推薦順序如下：

1. Hidden Oracle 通過率：核心行為、邊界案例與回歸測試分開記。
2. 安全與污染：禁改檔案觸碰次數、測試被弱化、fixture 殘留、非必要依賴。
3. 返工：Oracle 首次失敗後需要幾輪、多少人工提示才修好。
4. 成本：牆上時間、輸入／輸出／cache token、用戶端估算費用、tool calls。
5. 互動負擔：PermissionRequest 次數、其他人工核准、澄清問題與人工編輯。
6. 變更足跡：diff 行數、改動檔案、依賴、artifact 數量與清理時間。

批准數要用 hook 或結構化 log 記，不要靠記憶。Anthropic 的 hooks 文件說明 PermissionRequest 會在工具需要權限決策時觸發；但同一個設定可能把操作預先 allow 或 deny，所以必須連權限模式一起保存。token 與費用也要標成用戶端估算，不能當成信用卡帳單。

一張決策樹：什麼時候值得付規格稅？

沒有永久冠軍，只有適合當下風險的流程。先從最輕的方案開始，當錯改代價、協作介面或需求變動提高，再加重 artifact 與核准點。

• 偏向 plain Claude Code：一人、低風險、小 diff、需求穩定，而且現有測試已是可靠 Oracle。
• 偏向 OpenSpec：需要把 change proposal、需求差異與實作 tasks 留給 reviewer，但團隊還不需要完整治理鏈。
• 偏向 Spec Kit：跨角色、需求模糊、外部介面多、需要 constitution 與多階段 review，且團隊願意維護 artifact。

如果你是第一次建立 Agent 工程流程，可先讀AI Agent Harness 入門，再用從零打造 Agent Harness把 hooks、驗收與隔離補齊。框架名稱不會替你完成這一層。

七個最容易讓 A/B Test 失真的坑

1. 只比相同 prompt，不比相同環境：版本、模型、權限與 Repo snapshot 才是更大的混淆因子。
2. 把 Hidden Oracle 放在 Repo 裡：Agent 看得到就可能針對答案最佳化。
3. 把 artifact 數當品質：文件多只證明流程多，沒有證明需求抓對。
4. 只跑一次：Agent 輸出有變異，單次漂亮或翻車都可能是偶然。
5. 把框架初始化混入每次成本：一次性 setup 與每個 feature 的邊際成本要分開。
6. 人工救援不記帳：多給一句關鍵提示，就已經不是同一個 intervention。
7. 把維護者比較頁當獨立證據：產品定位可用來理解設計，不足以證明優勝。

尤其注意「改得更多」不等於「做得更好」。若 Agent 順手重構周邊、加上沒要求的依賴，會增加 review 面積與回歸風險。這也是Coding Agent 過度編輯要單獨記分的原因。

社群的 84 次 Allow 能證明什麼？

一篇 2026 年的 Reddit 作者自述測試，用相同功能比較四套 spec-driven 工具，作者記錄到其中一套需要 84 次 Allow，也觀察到額外依賴、測試資料殘留等差異。最重要的是，作者自己明說還缺 plain Claude Code baseline。

它可以提出好問題，不能直接回答「OpenSpec 一定比較省」或「Spec Kit 一定比較重」：數字是手動計數，公開貼文不足以獨立稽核完整環境，而且不同權限設定就能大幅改變 Allow 次數。本文的 protocol 正是補上 baseline、外部 Oracle、重跑與環境凍結，讓讀者自行產生可比較證據。

常見問題 FAQ

OpenSpec 值得裝嗎？

如果 change 需要跨 session、交給別人 review，或規格差異要長期保留，值得先在一個中風險 feature 試跑；若只是單人低風險小改，plain Claude Code 通常是更合理的起點。

OpenSpec 和 Spec Kit 哪個比較輕？

從目前預設 artifact 與階段看，OpenSpec 核心路徑較短，Spec Kit 的治理階段較多；但「比較輕」不等於一定更快，仍要用你的 Repo、團隊與 Oracle 測量。

plain Claude Code 可以做 spec-driven development 嗎？

可以。Plan mode、SPEC.md、CLAUDE.md、測試與 hooks 足以組成輕量流程；額外框架的價值是標準化 artifact 與生命週期，不是解鎖「能不能先規格後實作」。

為什麼 Hidden Oracle 不能給 Agent 看？

因為你要測的是需求理解與泛化，不是針對答案修測試。Agent 仍應看得到公開測試與完成條件；只有用來抓邊界與污染的驗收留在外部。

每條工作流一定要跑三次嗎？

三次是小團隊能負擔的最低實用起點，不是統計魔法。結果接近或變異很大時，應增加 run，而不是用一個平均數過度解讀。

批准次數越少越好嗎？

不一定。少批准可能代表流程順，也可能代表權限過寬。先確認安全邊界相同，再把批准視為人機互動成本。

Spec Kit 的 Converged 等於測試通過嗎？

不等於。converge 對照實作與 artifact，能補出缺漏 tasks；runtime、整合與邊界行為仍要由實際測試或 CI 證明。

實驗完成後要清掉什麼？

先封存 manifest、prompt、log、diff 與 artifact，再重置三份 working copy。正式 Repo 只保留團隊決定採用的設定；移除試驗用 hooks、產物、額外依賴與測試資料，OpenSpec telemetry 設定則依團隊隱私政策保留或明確關閉。

七個重點帶走

1. OpenSpec vs Claude Code vs Spec Kit 要比外部驗收，不是比文件數。
2. plain baseline 也要有 plan、測試與相同安全邊界，不能故意做弱。
3. 同 commit、同模型、同版本、同權限、同 brief，才只剩工作流這個變因。
4. Hidden Oracle 要放在 Agent 不可讀寫的位置，防止測試污染。
5. 每條路徑至少三次獨立 session，並隨機化順序。
6. 先看通過率、禁改與返工，再看時間、token、批准與 diff。
7. 從最輕流程開始；只有避免的錯改成本大於規格稅，才升級治理重量。