OpenSpec：把 AI 編碼拉回先寫規格的工作流

我最近在看 OpenSpec 的時候，第一個感覺不是「又一個 AI 編碼工具」，而是它終於把我一直想要的那件事講清楚了：先把需求寫成可追蹤、可修改、可回頭檢查的規格，再讓 AI 幫你做事。這件事聽起來很基本，但在實際開發裡其實很難。大多數 AI 編碼流程的問題，不是模型不會寫程式，而是我們太容易把「把東西做出來」和「把需求想清楚」混在一起。

我看過太多專案卡在這裡：一開始只丟一句話給 AI，結果第一版看起來很快，但很快就會出現需求漂移、命名混亂、邏輯散掉、後續修改比重寫還痛的狀況。OpenSpec 的有趣之處，在於它沒有把自己包裝成更會寫程式的模型，而是把重心放在工作流：/opsx:explore 先思考，/opsx:propose 先提案，/opsx:apply 再實作，最後 /opsx:archive 收尾。這套設計讓 AI 不只是產出程式碼，而是參與一條比較接近真實開發的路徑。

我為什麼覺得它不是普通的包裝器

OpenSpec 的 README 一開始就很直接：它的哲學是「流動，而不是僵化」、「迭代，而不是瀑布式」、「簡單，而不是複雜」，而且明講它是為了 brownfield，也就是既有專案，不只是新專案。這句話我很認同。因為真正麻煩的案子，往往不是從零開始，而是要在一個已經有歷史包袱的代碼庫裡插入新功能。這時候你最需要的，不是 AI 一口氣吐出一坨程式，而是它願不願意先讀懂上下文，先把規格、設計、任務拆開。

OpenSpec 讓我覺得值得注意的地方，是它把這些拆解成實際可操作的 artifacts。README 裡那段示意很清楚：提案會產生 proposal.md，接著有 specs/、design.md、tasks.md，最後才進到實作。這不是只是文件格式漂亮而已，而是把「先講清楚」變成工具層級的流程約束。對我來說，這比單純叫 AI「多想一下」有效得多，因為流程本身會推著你走。

另一個我很喜歡的點，是它沒有把使用者綁死在單一路徑。它有預設的 core workflow，也有更展開的 new、continue、ff、verify、bulk-archive、onboard。這代表它不是把一組固定 prompt 塞給你，而是允許你依照情境切換節奏。這種設計通常比較有機會活進真實團隊，而不是只在 demo 裡好看。

OpenSpec 的核心不是「叫 AI 寫」，而是「叫 AI 先對齊」

如果要我用一句話概括 OpenSpec，我會說它的重點不是讓 AI 更會寫，而是讓 AI 更容易跟人對齊。這件事在 /opsx:explore 和 /opsx:propose 特別明顯。

/opsx:explore 的定位很像一個沒有壓力的思考夥伴。它不是直接開工，而是先幫你釐清到底要做什麼、有哪些選項、哪個方案風險最低。這個步驟看起來慢，但我反而覺得它是最省時間的。因為在實務上，大部分返工都不是來自「程式寫錯」，而是來自「我們一開始就沒把問題定義對」。如果你曾經在某個功能上來回改了三次規格，最後才發現第一版需求就有歧義，你大概會懂我在說什麼。

接著是 /opsx:propose。這一步很重要，因為它會把想法變成一個 change 資料夾，裡面包含 proposal、specs、design、tasks。這種結構的價值，不只是好看，而是讓 AI 產出的內容可以被檢查、被回退、被局部修正。換句話說，OpenSpec 把「AI 可能會胡說八道」這件事當成正常風險處理，而不是假裝模型永遠正確。

再往後的 /opsx:apply 就不再只是「開始寫碼」，而是依照任務清單逐項推進。這裡我會把它理解成一個很實際的管理動作：不是叫 AI 一次完成所有事，而是讓它一次只處理一小段。這對大型專案尤其重要，因為大型專案最怕的不是失敗，而是失控。

我怎麼看它的使用方式

我覺得 OpenSpec 最適合被理解成「把規格驅動開發做成工具鏈」，而不是「又一個聊天式 coding assistant」。它的安裝方式很直接：官方 README 提到需要 Node.js 20.19.0 以上，然後可以用下面這個指令安裝：

npm install -g @fission-ai/openspec@latest

接著進到專案目錄初始化：

cd your-project
openspec init

到這裡為止，它已經不是在空談概念，而是開始往你的專案裡落地。README 也說得很清楚，openspec init 會建立對應的 skills，通常放在 .claude/skills/ 或等價位置，讓 AI 工具可以自動感知。這點我很在意，因為很多工具講半天工作流，最後還是要人手動複製貼上。OpenSpec 至少在這裡有把流程和檔案結構打通。

如果你問我第一次上手應該怎麼走，我會建議這樣：

先跑 openspec init，讓專案具備基本結構。
用 /opsx:explore 讓 AI 先幫你釐清需求。
用 /opsx:propose 產生可審核的規格與設計。
等你確認規格沒問題後，再讓 /opsx:apply 真正動手。
完成後再用 /opsx:archive 收尾，保留變更歷史。

這一套流程最好的地方，不是它很完整，而是它很像真的在做團隊協作。你不需要假裝 AI 一次就懂全部，只要把每一步做成可以討論、可以驗收的單位，結果通常就會穩很多。

它特別適合哪些情境

我會把 OpenSpec 的適用情境分成三種。

第一種是既有專案的功能增補。也就是 README 提到的 brownfield。這類專案通常已有既定架構、命名風格、測試方式與部署路徑，AI 如果直接生成很容易撞牆。OpenSpec 先把上下文放進 config，讓規格與設計有地方承接，這時候它的價值會很高。

第二種是團隊共用的工作方式。尤其是多人協作時，最常見的問題不是技術，而是每個人對「做到哪裡算完成」的理解不同。OpenSpec 把 proposal、spec、design、tasks 變成明確產物，對齊成本會比口頭溝通低很多。README 甚至提到 Stores 這個 beta 功能，目的是讓跨 repo 的計畫也能有單一來源。這個方向我很看好，雖然它還在 beta，但概念上非常合理。

第三種是你已經開始把 AI 當成日常開發夥伴。如果你已經不是在問「要不要用 AI」，而是在問「怎麼讓 AI 不要每次都亂跳」，那 OpenSpec 這種工具就會很有吸引力。它不是幫你隱藏 AI 的不穩定，而是幫你把不穩定關進一個可管理的流程裡。

但我也不覺得它是萬靈丹

我喜歡 OpenSpec，但我不會把它說成可以解決所有 AI 編碼問題。它最明顯的限制，就是它要求你更早做決策。這對一些人來說是好事，對另一些人來說可能很煩。因為如果你平常習慣先丟一句話、看 AI 跑出什麼再說，OpenSpec 會逼你停下來，先把問題說清楚。這種約束不一定舒服，但往往是必要的。

第二個限制是，它對工作流紀律有假設。換句話說，如果團隊本來就不想寫規格、不想維護 proposal、不想在任務之間保留可追蹤的中介產物，那工具再好也會被用壞。這不是 OpenSpec 的錯，而是任何規格驅動流程都會遇到的現實：流程本身要有人願意尊重，才會有價值。

第三個限制，是它仍然需要你理解自己的專案。OpenSpec 不是替你做架構判斷，它只是讓架構判斷更容易被記錄與執行。這意味著如果你的需求本身很模糊、你的上下文很亂、你的邊界條件沒整理好，OpenSpec 也只能把混亂變得更有條理，不能憑空幫你變出正確答案。

我最後的判斷

如果你問我，OpenSpec 值不值得關注，我的答案是：值得，而且它值得的原因不是因為它更像聊天工具，而是因為它更像一套可執行的開發方法。

我現在對很多 AI 開發工具的看法，都慢慢從「能不能幫我寫」轉成「能不能幫我對齊」。OpenSpec 正好踩在這個轉折點上。它把規格、設計、任務、實作、歸檔串成一條可重跑的路徑，讓 AI 不只是回覆你，而是跟著你一起維護開發過程。對我來說，這種改變比單次產碼能力更重要。

如果你已經受夠了 AI 一下子寫很多、但每次都偏題的感覺，我會建議你認真看一次 OpenSpec。它不一定適合每個團隊，也不一定會成為你的主力工具，但它提出的方向很值得借鑑：不要只讓 AI 產生結果，讓它也參與生成規則的過程。

參考資料