系列文章: Openspec (2/6)
為什麼沒有 spec 的 AI 開發，最終都很貴
你叫 AI 加一個功能，它動手寫了，看起來好像沒問題，結果跑起來發現走偏了，改了兩次還不對，第三次才勉強對了——但這時候你已經把一個下午燒完了。這不是模型的問題，也不是你的 prompt 不夠強，是根本沒有人在動工前把「要做什麼、不做什麼、怎樣算完成」寫清楚。
AI 很努力，但沒有跑道
代理很拼命——這不是問題。問題是，它的推理只能靠你對話裡提供的資訊。你說「加個深色模式」，它就照著理解實作，但它不知道你只想改 CSS 變數還是要整套 theme 系統，不知道 localStorage 要不要保存偏好，也不知道你現有的元件庫是不是已經有一套 theming 機制。
沒說清楚，它就自己猜。自己猜的結果，就是改完你看著它做的東西說：「不對不對，我想要的不是這樣。」
然後重來。
需求只活在對話裡，命很短
還有另一個慘狀——你上週跟 AI 說好的設計決策，這週開新對話，它完全不記得了。上一輪辛苦建立的共識，全部不見，你又要從頭講一次，或者靠自己記得然後重新貼進去。
這就是「需求只活在對話裡」的副作用。對話是揮發的，spec 是持久的。沒有 spec，每次對話都是在重建一個會消失的認知地基。
OpenSpec 在解什麼
OpenSpec 不是另一套需求文件格式，它更像是一條讓代理有跑道可以衝的機制：
- 先同意，再動工 — 你和 AI 在開始寫程式前，先把「要做什麼」對齊清楚
- 每個改動有自己的資料夾 — proposal、spec、design、tasks 都放在一起，不散落在對話裡
- 流動而非剛性 — 隨時可以更新 artifact，沒有死板的階段鎖定
- 用你現有的工具 — 支援 20+ AI coding assistant，用 slash command 就能操作
跟傳統規格管理工具比，它更輕；跟什麼都不寫比，它帶來的是穩定性——不是保證，是大幅降低「做完才發現做錯了」的機率。
它的四個核心哲學
值得記一下，因為這四句話解釋了為什麼 OpenSpec 長成這樣：
流動而非剛性（fluid not rigid）
不鎖定階段。proposal 寫了可以改，設計寫了可以回頭修，實作中發現問題可以更新 spec。這不是鼓勵混亂，是承認現實——你在實作途中才會真正理解需求。
迭代而非瀑布（iterative not waterfall）
不要求你把所有細節在開始前就想清楚，允許你邊做邊補。重點是「有個起點的共識」，而不是「完美的事前規劃」。
簡單而非複雜（easy not complex）
初始化一條指令，核心工作流三個 slash command，不要求你學新的語法或工具鏈。
適合現有專案（brownfield-first）
不是只有新專案才能用，大部分情況是要在既有 codebase 上做修改——OpenSpec 的 delta spec 設計就是為此而生。
那什麼時候開始用比較合適
不需要等到大專案。個人專案要加新功能的時候就可以試，花在 /opsx:propose 上的十分鐘，大概率比你之後改錯再重來省時間。規模越大、協作越多，效益越明顯——但就算一個人幹，能少個「做完發現方向錯」的循環，就值了。