OpenSpec vs Spec Kit：為 AI 代理開發選擇規格驅動框架

AI 編碼代理撰寫程式碼的速度比任何人類都快。瓶頸已經轉移：規格現在才是產品本身。 如果你的代理沒有清晰、結構化的規格可循，它會產生架構幻覺、虛構需求，並產出通過沒人要求過的測試的程式碼。

已有兩個框架興起以解決此問題：OpenSpec（約 28k GitHub 星）與 GitHub 的 Spec Kit（約 75k 星）。兩者皆為 MIT 授權。兩者都產生 AI 代理可直接使用的斜線指令。但它們在速度與治理之間做出了根本不同的取捨——選錯框架會讓你的團隊付出數週的重做成本。

以下是如何選擇。

核心分歧：流暢反覆運算 vs. 結構化治理

OpenSpec 是一個 Node.js CLI（@fission-ai/openspec），將規格視為輕量、原生於儲存庫的產物。它將工作組織為 change folder，其中包含 proposal、specs、design 與 task 檔案。其理念是最低儀式——快速將規格放到代理面前、反覆運算、完成後封存。

Spec Kit（GitHub 的框架，以 specify CLI 與 /speckit.* 指令為核心）將一切錨定於 constitution——一份專案層級文件，其中編碼了限制、編碼標準、TDD 需求與合規規則。每個功能都流經結構化的階段管線，在每個閘道都有範本與檢查清單。

差異並非表面功夫。它決定了你的團隊在每個功能上吸收多少額外負荷、代理在每次提示時消耗多少上下文，以及你的稽核線索是否能滿足合規審查者。

工作流程比較

OpenSpec：四個指令，最低摩擦

OpenSpec 的工作流程刻意簡短：

graph LR
    A["/opsx:propose"] --> B["/opsx:explore"]
    B --> C["/opsx:apply"]
    C --> D["/opsx:archive"]

1. /opsx:propose — 以 proposal 文件建立 change folder
2. /opsx:explore — 在該資料夾內反覆運算規格與設計
3. /opsx:apply — 根據最終規格執行實作
4. /opsx:archive — 將完成的工作移至封存

就這樣。沒有 constitution。沒有強制釐清階段。沒有任務分解閘道。你提出、探索、套用、封存。如果你需要從套用回到探索，就直接做——沒有階段閘道會阻止你。

OpenSpec 強制 50KB 上下文限制 以防止提示膨脹。這是刻意的設計選擇：使用 OpenSpec 規格的代理不會在過大的上下文視窗上噎住，這在於 monorepo 中執行多個代理時很重要。

Spec Kit：六個階段，錨定於 Constitution

Spec Kit 的管線更為廣泛：

graph LR
    A["/speckit.constitution"] --> B["/speckit.specify"]
    B --> C["/speckit.clarify"]
    C --> D["/speckit.plan"]
    D --> E["/speckit.tasks"]
    E --> F["/speckit.implement"]
    G["/speckit.analyze"] -.-> B

1. /speckit.constitution — 定義專案層級規則、限制與標準
2. /speckit.specify — 建立詳細的功能規格
3. /speckit.clarify — 解決歧義與開放問題
4. /speckit.plan — 產生實作計畫
5. /speckit.tasks — 將計畫分解為離散、可指派的任務
6. /speckit.implement — 以 TDD 閘道與檢查清單驗證執行任務
7. /speckit.analyze（選用）— 在指定變更前分析現有程式碼

constitution 是關鍵差異化因素。它是一份每個後續指令都會尊重的活文件。如果你的 constitution 說「所有資料庫變更都需要移轉指令碼」或「沒有重試邏輯不得直接呼叫 API」，代理會在每個階段強制執行這些規則。對受管制的產業——醫療、金融、政府——這正是你將合規需求編碼到開發工作流程本身所需的機制。

正面對決比較

Context Tax 問題

Spec Kit 的能力伴隨成本。每個安裝的斜線指令、每個範本、每個 constitution 規則都會在代理的上下文視窗中添加權杖。執行 Spec Kit 並搭配多個延伸的團隊回報顯著的 context tax——代理花費權杖解析框架指令，而非對你的程式碼進行推理。

這在規模化時很重要。如果你在大型程式庫上執行 Claude Code 或 Codex 並載入 Spec Kit 的完整指令集，你正在將上下文消耗於框架額外負荷。有些團隊回報需要修剪延伸或拆分 constitution 才能維持在實用的權杖預算內。

OpenSpec 以其 50KB 上下文限制避開此問題。這是個鈍器工具——你無法編碼相同深度的治理——但它讓代理專注於實際規格而非框架中介資料。

企業結論：如果你的代理已受上下文限制（大型程式庫、複雜系統提示、多檔案變更），在承諾之前先測量 Spec Kit 指令集的權杖成本。OpenSpec 的上限較低但可預測。

何時使用 OpenSpec

在以下情況選擇 OpenSpec：

• 你正在進行快速原型或概念驗證工作，速度比流程更重要
• 你的團隊使用多種 AI 代理工具，並想要一個適用於所有工具的單一、輕量規格層
• 你需要在中途反覆運算——在實作開始後變更規格而無需與階段閘道抗爭
• 你的程式庫大到上下文預算成為真實限制
• 你想要規格驅動開發而不採用完整治理框架

OpenSpec 的「core」設定檔是進入規格驅動 AI 開發最低摩擦的入口。安裝 CLI、建立 change folder，你的代理就有結構化規格可循。無需撰寫 constitution，無需策展延伸目錄。

何時使用 Spec Kit

在以下情況選擇 Spec Kit：

• 你正在建置生產系統，治理與可重複性證明額外負荷是值得的
• 你的組織在受管制的領域（醫療、金融、政府）運作，需要將合規規則編碼到開發工作流程
• 你希望將 TDD 強制內建於框架，而非事後附加
• 你的團隊受益於結構化階段閘道——規劃前先釐清、實作前先規劃
• 你需要透過 hook 與策展延伸目錄為組織特定工作流程提供擴充性

Spec Kit 的 constitution 模型對企業情境真正強大。將「每個 API 端點都需要 OpenAPI 文件」或「所有狀態變更都需要事件溯源」編碼為 constitution 規則，意味代理會自動、每次都強制執行它們。那不是治理劇場——那是實際執行的治理。

混合方式：從輕開始，逐步加結構

這些框架在理念上並非互斥。對許多企業團隊而言的實務路徑：

1. 從 OpenSpec 開始 進行初步探索與原型。在無額外負荷下建立規格習慣。
2. 當專案進入生產並需要治理、合規編碼與可重複階段工作流程時，改用 Spec Kit。
3. 對附帶專案、內部工具與快速實驗保留 OpenSpec，在這些情境 Spec Kit 的儀式會拖慢你。

最糟的結果是完全沒有規格框架——代理根據模糊提示工作，產出沒人對照沒人寫下的需求審查過的程式碼。

可執行的重點

1. 規格驅動開發已不再是選用。 如果你的 AI 代理沒有結構化規格，你正在對幻覺需求進行除錯。選一個框架。

2. 先測量你的上下文預算。 以 Spec Kit 完整指令集載入執行你的代理，並檢查有多少權杖用於框架額外負荷。如果超過上下文視窗的 15-20%，考慮 OpenSpec 或修剪過的 Spec Kit 組態。

3. 對受管制的產業，Spec Kit 的 constitution 會自我回本。 將代理自動強制執行的合規規則編碼，值得額外的產物額外負荷。替代方案是對每個代理產生的變更進行人工合規審查。

4. 對快速原型，OpenSpec 在速度上勝出。 四個指令、50KB 上下文限制、無需維護的 constitution。快速將規格放到代理面前。

5. 不要跳過封存/清理步驟。 兩個框架都支援封存完成的工作。儲存庫中陳舊的規格會在未來執行時混淆代理。積極封存。

6. 針對你的實際堆疊評估兩者。 複製各框架的範例儲存庫，以你偏好的 AI 代理對你的程式庫執行，並比較輸出品質與權杖成本。正確的選擇取決於你團隊的治理需求，而非 GitHub 星數。