今年AI圈最火的兩種開發方法論：Vibe Coding vs SDD。
Vibe Coding 沒有正式的中文翻譯，一般是翻譯為「氛圍編程」，或者也可以依原意翻譯為「直覺編程」。其特色就是不先嚴謹的規範，而是依照「直覺」用自然語言像 AI 描述「我想要什麼」，再由其生成程式碼，開發者再透過執行與測試（可以透過單元測試）來驗證結果是否符合預期。
至於 SDD（規格驅動開發），則是強調「先定義規格 (Specification)，再由規格驅動程式碼產出」的開發原則。通常 SDD 會搭配工具（如 Spec Kit）以制度化流程，從撰寫規格 → 拆解任務 → AI 或開發者實作 → 最後部署/整合。
從這兩種方法論核心的作法來看，它們是否在實踐上存在衝突？
我問了三家AI（ChatGPT, DeepSeek, Gemini 3 Pro），它們倒都是不約而同而且還挺含蓄的回答了這個問題，以一句話總結：這兩種開發方法論在「理念」上存在潛在衝突（前者追求「快與自由」，後者追求「穩與規範」），但它們在「實踐」上可以（且應該）互補。
我無意比較這兩種方法論是否是對立衝突還是互補，倒是讓我聯想起傳統兩大對立的開發方法論：Waterful（瀑布式）與 敏捷（Agile）開發。前者就是強調需求規格等必須要完整、而後者則採以 I&I (Iterative & Increment) 迭代漸增並持續演進的方式，不在前期就要求完整的規格。
那麼，是否 Vibe Coding 其實就是承襲 Agile-based 的開發原則；而 SDD 則自承襲傳統工程思維的 Waterful 要求完整的規格呢？
同樣把這問題餵給三家 AI，它們竟然也是一致認同，而且全都首先稱讚我：你這個觀察其實非常敏銳，而且本質上抓到兩種方法論的哲學差異。哈。
當然它們都拉拉雜雜地生成一堆分析說明與對照表內容等等，這裡只列出最核心的要點：
- SDD ≈ Waterfall：計畫先行，規格驅動，線性可控
- Vibe Coding ≈ I&I：迭代即興，探索導向，非線性快速試錯
以上是 ChatGPT 最後的總結，不過我覺得以下 Gemini 的總結回覆得更為傳神！
- SDD 是現代版的 Waterfall 精神復興：用來對抗 AI 帶來的混亂，強調秩序與規範。
- Vibe Coding 是極致的 Agile/I&I 實踐：利用 AI 的速度優勢，將迭代週期壓縮到極限。
如果問我個人偏好哪種方式？近20年來我一直都是主張 I&I 開發方式的，當然會傾向自由度高的 Vibe Coding。但如今是以 AI 為「工具人」的開發時代，確實沒有一些規範（例如要求採用的技術規格、前後端分離策略、專案配置等等），太容易引起 AI 的 "幻覺"，造成開發者與AI「溝通的障礙」，還影響開發成本（耗費巨量的 tokens）。
作為軟體架構師的角色，我還是秉持最最基本的原則：讓變動侷限在可變動的範圍！
在這個原則下，開發方式我仍舊會採 I&I 並仍會實行單元測試（但可以交給 AI 生成）。但是在整個專案的開發歷程中，確實需要要求一些AI的標準化，尤其是偏向非功能性需求議題的技術規格（如採用 Java/Spring 特定版本、某些特定開源套件、前端技術 …）。至於關於功能性需求，我還是比較主張不用初期作過度的細節分析，仍可以採迭代開發漸增功能。
一個是：「先想清楚再做」（SDD）、一個是：「先做了再想」（Vibe Coding）。作為架構師，就是如何在專案中調和這兩種「時區」不同的開發模式。
🔗 延伸閱讀
- Vibe Coding 的原始理論來源PDF文件（arXiv）
- SDD／Vibe Coding 的開發者社群討論（Reddit vibecoding / SpecDrivenDevelopment）
- GitHub Spec-Kit：SDD 實作工具套件