OpenSpec v1.13.0 – 輕量級、可配置的 AI 規格框架

OpenSpec v1.13.0 – 一個輕量級、可配置的 AI 規格框架

重點摘要： OpenSpec v1.13.0 提供了一種低負擔的方式，利用 AI 代理來編寫、管理和驗證軟體規格。然而，從業人員警告，大型且不斷演進的程式碼庫可能會面臨規格漂移（spec drift）、過多的產出物生成以及審查負擔過重等問題。

---

OpenSpec 聲稱解決的問題

• 目標： 讓團隊與 AI 程式設計代理在「要建構什麼」以及「如何建構」上達成一致，減少實作偏差。
• 核心概念： 編寫規格（例如 proposal.md、design.md、tasks.md），並讓框架驅動可重複的工作流程：探索 → 提案 → 實作 → 驗證 → 歸檔。
• 支援的工具： Claude Code、Codex、Cursor、GitHub Copilot、Gemini、CLI、OpenCode 以及其他 33 種以上工具（請參閱官方文件）。
• 目前狀態： v1.13.0，GitHub 上擁有 68.8k 顆星，開源於 https://github.com/Fission-AI/OpenSpec/。

---

工作流程結構

階段	指令	目的
探索 (Explore)	/opsx:	繪製問題空間並了解現有的程式碼庫。
提案 (Propose)	/opsx:	生成 proposal.md、specs/、design.md、tasks.md。
實作 (Implement)	/opsx:	執行從規格中導出的任務。
驗證 (Verify)	/opsx:	檢查實作是否符合規格。
歸檔 (Archive)	/opsx:	儲存已完成的變更以供未來參考。

該框架刻意保持輕量：它不指定語言或建置系統，僅提供一套基於 Markdown 的產出物以及一個協調 LLM 呼叫的 CLI。

---

社群反應 – 讚賞與痛點

正面觀察

• 流程紀律有幫助 – 使用者 @mafro 指出，即使他們放棄了規格檔案本身，其「流程」（提案 → 審查 → 實作 → 審查）仍然具有價值。
• 迭代式規格可行 – @jmathai 報告了一個成功的 471 行規格，代理程式毫無問題地完成了實作，突顯了大規模功能生成的潛力。
• 存在輕量級替代方案 – @pramodbiligiri 建立了一個類似的工具（shipsmooth），每個工作單元僅建立一個規格和任務檔案，強調極簡主義。

主要批評

• 規格與程式碼脫節 – @mafro 觀察到經過數月的開發後，程式碼與規格之間存在「巨大的分歧」，並得出結論：「程式碼本身就是規格」。
• 產出物爆炸 – 多位評論者（例如 @whinvik、@open‑paren）抱怨 OpenSpec 生成了過多的 Markdown 檔案，導致審查變得繁瑣，並增加了文件過時的風險。
• 缺乏理論基礎 – @ricardobeat 指出，文件側重於使用方法，而非解釋該框架「為什麼」有效或提供基準測試。
• 與舊方法的比較 – @twen_ty 詢問 OpenSpec 與 1990 年代的 UML 轉程式碼流程有何不同，並指出「規格漂移」仍然是一個根本性的問題。
• 採用阻力 – @gps372 警告說，對於已經被 JIRA、SharePoint 等工具淹沒的組織來說，如果沒有領導層的支持，OpenSpec 將很難推廣。
• 以人為本的擔憂 – @hmokiguess 認為 AI 目前在「寫作」方面仍優於「閱讀」，真正的瓶頸在於人類的決策；像 OpenSpec 這樣的框架僅解決了「錦上添花」的工作流程層面。

---

實際使用模式

• 個人或小型團隊專案 往往能從結構化的工作流程中受益，特別是當規格保持簡短且與實作緊密耦合時。
• 大型、多開發者的程式碼庫 會經歷「規格腐爛」，文件變得過時；審查人員最終花在審查規格上的時間比審查程式碼的時間還多。
• 混合方法正在興起：一些團隊保留輕量級規格以說明高層意圖，同時依賴 ADR、不變量日誌（invariant logs）和單元測試來提供具體保證（如 @mafro 所述）。
• 工具整合：使用者經常將 OpenSpec 任務列表傳送到自訂腳本（例如 @recroad 的 Bash 迴圈）中，以減少 Token 使用量並保持每次 LLM 呼叫的精簡。

---

與相關框架的比較

框架	主要焦點	Token 效率	產出物管理
OpenSpec	迭代式 Markdown 規格 + CLI 協調	中等 – 每個步驟都是獨立的 LLM 呼叫	每個功能生成多個 Markdown 檔案
GSD (opengsd.net)	端到端可追溯性、自主模式	高 Token 消耗 (~4×)	集中式專案管理，檔案較少
SpecKit / SpecDD	系統組件邊界 vs. 變更流程	視實作而定	重疊極小；更專業化
Spekk‑CLI	宣告式規格、可安裝的代理技能 (Go 二進位檔)	低 – 單一二進位檔，無執行時期依賴	每個單元一個規格 + 任務

---

實務建議

1. 從小處著手 – 在擴展到整個儲存庫之前，先將 OpenSpec 用於單一功能或小型實驗。
2. 將規格與 ADR 和不變量日誌結合 – 這可以透過記錄無法在單元測試中捕捉的決策來減輕漂移。
3. 自動化審查 – 編寫「規格到程式碼差異」檢查腳本（例如在生成的檔案上使用 git diff），以便儘早發現過時的產出物。
4. 定義「快速通道」 – 對於微小的變更，跳過完整的規格生成，改用輕量級計畫，正如 @cg‑enterprise 所建議的。
5. 監控 Token 使用量 – 將大型任務列表拆分為小塊；對相關步驟重複使用相同的 LLM 上下文，以保持在模型限制內。

---

展望

OpenSpec 證明了「輕量級、以 Markdown 為中心」的規格層可以與現代 AI 程式設計代理整合。社群的混合回饋突顯了兩個待解決的挑戰：

• 在長開發週期中維持規格的忠實度。
• 在產出物粒度與人類審查頻寬之間取得平衡。

未來的版本需要更強大的機制來處理規格版本控制、自動過時檢測以及與現有專案管理工具的整合，才能成為重量級問題追蹤系統的可行替代方案。