前言
Vibe Coding 時代，當開發不再需要自己開發，使用者角色慢慢轉往 PM ，要怎麼管理持續不斷 AI 助手開發處理的新功能或交付文件？
答案是變動管理，例如在工廠流程中，是這樣管的：
- BOM: Bill Of Material，物料清單
- ECR: Engineering Change Request，工程變更申請
- ECO: Engineering Change Order，工程變更指令
- ECN: Engineering Change Notice，工程變更通知
在專案管理中，更簡化一般化的流程就是：
提案 -> 執行 -> 封存
Specification Driven Development 規格驅動開發
講點故事，開發模式百百種你知道幾種？BDD, ATDD, TDD, SDD 之後有機會在一一展開
SDD 正好是切合主題的模式，圍繞規格展開的一系列開發流程
說明一下步驟：
- 定義需求文件與規格
- 設計架構
- 實作（程式碼）
- 驗證（測試）
- 佈署與運營
Vibe Coding 與 SDD 一拍即合
Vibe Coding 可以迅速生成程式碼，不過死穴就是你說不清楚，AI 就用幻想填補空白，然後不斷修改返工，甚至必須放棄重來。
SDD 的規格優先特性，滿足了天馬行空的使用者跟有無比執行力 AI 之間的空白
使用前：人想很多但是講不清楚 > AI 開發通靈亂做一通 > 以上步驟無窮迴圈，無法預期成果
使用後：人想很多但是講不清楚 > AI 顧問釐清需求 > AI 開發一一開工 > 人中途回饋微調 > 快速產出對的成果 > AI 文管整理文件
適用 Vibe Coding 的 SDD工具
介紹影片連結：
# BMAD vs. Spek Kit vs. Open Spec: Which AI Coding Methodology is Best?
BMAD: 詳盡的流程跟角色，適合大公司大團隊協作使用
https://github.com/bmad-code-org/BMAD-METHOD
Spec Kit: GitHub 推廣的流程，適合 0-1 新專案打地基
https://github.com/github/spec-kit
OpenSpec: 簡單快速易上手，適合 1-100 的後續維護擴充
https://github.com/Fission-AI/OpenSpec
OpenSpec 五步簡單流程
完整十種命令說明可以參考：https://blog.cashwu.com/blog/2026/openspec-opsx-commands
官網連結：https://github.com/Fission-AI/OpenSpec
安裝一行文：需要 Node.js 20.19.0 以上的版本
npm install -g @fission-ai/openspec@latest
首先是第零步，安裝好 openspec 指令後，需要在專案目錄中執行一次：
openspec init
這步驟會要求用戶選擇開發環境（如 Claude Code, Codex, Gemini CLI, Antigraity）後，會自動設定對應的 Skills 指令到開發環境
對於大部分情境，以下五步驟足以涵蓋：
/opsx:explore -> /opsx:new <change-name> -> /opsx:ff -> /opsx:apply -> /opsx:archive
- explore：在動手前，AI 助手會跟你確認實作細節，直到沒有疑義為止，一切都搞清楚再動手
- new + ff (or)：確立規格後，創建一個新的變動 (Change) 並且生成對應的提案文件、規格文件跟工作項目清單
- apply：變動管理文件確認無誤之後，便能套用真正生成對應的程式碼或者成果
- archive：套用生成後，也經過人工驗證無誤，便能歸檔完成一次輪迴
中途若有任何需求異動，也能再次發起 explore 修正調整
結語
Vibe Coding 是個好東西，動動嘴程式碼就會長出來了，不過因為模型幻覺跟上下文限制，不能保證每次執行都能有完整記錄、都會參考過去成果、都能留下對應規格書，難免來來回回返工浪費時間
套用 OpenSpec 之後，以上的 "完整記錄、都會參考過去成果、都能留下對應規格書" 都能自動處理好，讓 Vibe Coding 無後顧之憂，不管新專案舊專案一體適用，對於 SOHO 中小型的案子非常適合，強烈建議上手操作看看
延伸閱讀
余小章大大的 Claude + OpenSpec 介紹
https://dotblogs.com.tw/yc421206/2025/10/25/claude_code_via_openspec_impl_spec_driven_development
