你有沒有過這種經驗：用 AI 寫程式，來回改了十幾次，結果還是不如預期？
問題可能不在 AI，而在你給指令的方式。
這篇文章要介紹一個正在改變 AI 開發方式的方法——Spec Driven Development（規格驅動開發），簡稱 Spec Coding。
它和你可能聽過的 Vibe Coding 不一樣，Spec Coding 會先寫好「規格」，再讓 AI 動手寫程式。
這樣做的好處是：AI 不用猜你要什麼，你也不用來回修改到崩潰。
什麼是 Vibe Coding？
在了解 Spec Coding 之前，先來看看大多數人目前怎麼用 AI 寫程式。
Vibe Coding 就是你直接跟 AI 對話，告訴它「我要做一個什麼樣的功能」，然後讓 AI 開始產生程式碼。
簡單來說，就是「憑感覺寫程式」——你不需要事先規劃，只要把想法丟給 AI，它就會幫你生出一段程式碼。
整個流程是這樣運作的：
第一步：撰寫初始 Prompt
你打開 AI 程式助手（不管是瀏覽器上的工具，還是裝在自己電腦上的 IDE 外掛），然後寫一段 prompt 給 AI。
例如：「幫我用 Python 做一個登入功能」或是「我需要一個 Java 的 REST API」。
這段 prompt 就是你跟 AI 溝通的起點。
第二步：AI 產生初版程式碼
AI 收到你的 prompt 後，會根據它在訓練過程中學到的知識，產生一段它「認為」最符合你需求的程式碼。
這時候你會拿到一份初版的樣板程式碼（boilerplate code），通常可以直接跑起來。
到這一步為止，一切看起來都很美好。
第三步：修改 Prompt，反覆調整
但問題來了——AI 產生的程式碼，很可能不是你想要的樣子。
也許它用了你不熟悉的套件，也許它的架構跟你想的不一樣，也許某個功能完全沒做到。
這時候你就要回去修改 prompt，跟 AI 說：「不對，我想要用另一個 library」或「這個部分的邏輯要改」。
然後 AI 會重新產生程式碼，你再看一次，不滿意就再改 prompt。
這個「修改 Prompt → AI 重新產生 → 再修改」的循環，就是 Vibe Coding 的核心。
第四步：達到預期的實作結果
經過幾輪來回之後，你最終會拿到一個接近你想要的結果。
聽起來很直覺，對吧？
Vibe Coding 確實很適合拿來快速做原型（prototype）或是小型實驗，因為你可以在幾分鐘內就拿到一段可以跑的程式碼，不需要從零開始慢慢寫。
但如果你要做的是一個有一定規模的專案，Vibe Coding 的來回修改成本會越來越高，有時候甚至比自己寫還花時間。
Vibe Coding 的問題在哪？
雖然 Vibe Coding 用起來像魔法一樣快，但它有兩個根本性的問題。
問題一：AI 的決策是一個黑箱
當你跟 AI 說「幫我做一個登入頁面」，AI 內部其實有非常多種方式可以實作這個功能。
它可能選擇用 Session 來管理登入狀態，也可能用 JWT Token，也可能用 OAuth 第三方登入。
它可能把密碼存在資料庫，也可能用 bcrypt 加密，也可能用其他你沒聽過的方式。
問題是：你不知道 AI 為什麼選了這個方案，而不是另一個。
更麻煩的是，你用同樣的 prompt 跑 100 次，可能每次拿到的結果都不一樣。
今天它用了 library A，明天它用了 library B，後天它可能又換了一個完全不同的架構。
這就是為什麼很多人覺得用 AI 寫程式「不穩定」——不是 AI 變笨了，而是你的指令給了它太多自由發揮的空間。
問題二：跳過了軟體開發最重要的第一步
在傳統的軟體工程裡，有一個被廣泛使用的開發框架叫做 SDLC（Software Development Lifecycle），中文叫「軟體開發生命週期」。
它定義了一個軟體從無到有、從開發到上線的完整流程。
SDLC 的五個階段分別是：
規劃與設計
這是整個流程的起點。
在寫任何一行程式碼之前，你要先搞清楚：這個專案要解決什麼問題？使用者是誰？功能有哪些？
這些需求會被整理成一份文件，通常叫做 PRD（Product Requirements Document，產品需求文件）。
PRD 就像是蓋房子之前的藍圖——沒有藍圖就開工，蓋出來的東西大概率會歪。
實作
有了需求文件之後，工程師才會根據這份文件開始寫程式。
因為大家對「要做什麼」已經有共識，所以寫出來的程式碼也會更有方向。
測試
程式寫完之後，會進入測試階段，也叫 QA（Quality Assurance，品質保證）。
這個階段要確認每個功能都能正常運作，有沒有 bug、有沒有安全性漏洞。
部署
測試通過後，程式碼會從開發環境（dev）推到測試環境（staging），最後再推到正式環境（production）讓真正的使用者使用。
維護
上線不是終點。
上線之後還要持續修 bug、根據使用者回饋改進功能、處理各種突發狀況。
Vibe Coding 跳過了哪一步？
看完 SDLC 的流程，你應該發現了——Vibe Coding 基本上跳過了第一步「規劃與設計」，直接從第二步「實作」開始。
你沒有先想清楚需求是什麼，就直接讓 AI 動手寫。
AI 不知道你的全貌，只能根據你那一句 prompt 去猜。
這在做小專案或快速原型的時候沒什麼問題，反正改一改就好。
但當你的專案有一定規模，功能之間有依賴關係，需要多人協作的時候，少了「規劃」這一步，後面的修改成本會像滾雪球一樣越來越大。
有時候來回跟 AI 修改的時間，甚至比你自己從頭寫還要久。
什麼是 Spec Driven Development（規格驅動開發）？
了解了 Vibe Coding 的問題之後，我們來看看 Spec Driven Development 是怎麼解決這些問題的。
Spec Driven Development（規格驅動開發） 的核心概念很簡單：先寫規格，再讓 AI 寫程式。
這裡的「規格（Spec）」指的是一份描述系統行為的文件，它會清楚定義：
- 這個功能的行為是什麼？（例如：使用者送出帳密後，系統要驗證並回傳 token）
- 有哪些限制條件？（例如：密碼至少 8 個字元，帳號不能重複）
- 遇到錯誤時要怎麼處理？（例如：密碼錯誤回傳 401，缺少欄位回傳 400）
- 預期的輸入和輸出分別是什麼？（例如：輸入 user + pass，成功輸出 JWT token）
規格就像一份合約
你可以把這份規格想像成你跟 AI 之間的一份合約。
在 Vibe Coding 裡，你只跟 AI 說了一句「幫我做登入功能」，剩下的全部讓 AI 自己決定。
這就像你跟裝潢師傅說「幫我弄一個漂亮的客廳」，然後就離開了——師傅可能裝了你不喜歡的風格，你回來一看只能打掉重做。
但在 Spec Coding 裡，你會先寫清楚：「客廳要北歐風格、地板用淺色木紋、沙發靠左牆、電視掛右牆、預算 30 萬以內。」
師傅拿到這份規格，做出來的東西自然會更接近你的期待。
AI 也是一樣的道理。
一份規格，同時產出四件事
Spec Coding 跟 Vibe Coding 最大的差別在於：規格不只是拿來寫程式碼用的。
你可以把規格想像成一顆種子——種下去之後，它會同時長出好幾樣東西。
同一份規格可以讓 AI 同時幫你完成四件事：
產出程式碼
因為規格已經把每個行為都寫清楚了（例如「POST /login 接受 user 和 pass 兩個參數」），AI 不需要猜你想怎麼實作，直接照著規格寫就好。
產出測試案例
規格裡面寫了「正確的帳密要回傳 200」、「密碼錯誤要回傳 401」——這些規則本身就是測試案例。
AI 可以直接根據這些規則，自動產生對應的測試程式，不用你再另外寫。
產出技術文件
規格本身就是一份可以閱讀的文件。
其他工程師看了這份規格，不用去翻程式碼，就能知道這個功能在做什麼、接受什麼參數、會回傳什麼結果。
產出驗證標準
功能做完之後，你可以拿規格逐條比對——AI 做出來的東西，有沒有符合每一條規則？
如果某一條沒通過，你馬上知道問題出在哪，不用大海撈針。
換句話說，規格變成了整個專案的唯一事實來源（Single Source of Truth）。
不管是寫程式、寫測試、寫文件、還是驗收功能，全部都是從這同一份規格展開的。
一句話總結 Vibe Coding 和 Spec Coding 的差異
Vibe Coding 是讓 AI 猜你要什麼；Spec Coding 是告訴 AI 你要什麼。
Vibe Coding 把決定權交給了 AI，你只能在事後修正；Spec Coding 把決定權留在你手上，AI 只負責執行。
Spec Coding 的完整流程
Spec Coding 的流程分成幾個階段，每個階段都有明確的產出：
第一步：寫 Prompt（但不是寫實作）
和 Vibe Coding 一樣，你還是從 prompt 開始。
但差別是，你不是在描述「怎麼做」，而是在描述「要做什麼」。
你寫的是系統的行為（behavior）和限制條件（constraints）。
第二步：產生需求規格（Requirements）
AI 根據你的描述，產生一份需求規格文件。
這份文件會定義整個專案的層級結構：功能要怎麼分、測試要怎麼做、文件要怎麼寫。
第三步：審核需求
這一步很關鍵——你要自己看過這份需求規格。
如果滿意，就進入下一步。
如果不滿意，就修改規格，而不是修改程式碼。
因為到這裡為止，AI 還沒寫任何一行程式。
在這個階段修改的成本非常低。
第四步：產生設計文件（Design Document）
需求確認後，AI 會根據規格產生一份設計文件。
這份文件會列出每個功能的具體實作方式，像是待辦清單一樣。
第五步：實作
如果你對設計文件也滿意，就讓 AI 開始動手寫程式。
因為有明確的規格和設計文件，AI 產生的程式碼會更穩定、更符合你的預期。
實際範例：用戶登入功能
來看一個具體的例子，比較 Vibe Coding 和 Spec Coding 的差異。
Vibe Coding 的做法
你直接跟 AI 說：
幫我做一個 /login 頁面，讓用戶可以登入。AI 可能用 Session、可能用 JWT、可能用 OAuth，你完全無法預期。
來回修改個五六次是家常便飯。
Spec Coding 的做法
你會先寫一份規格，像這樣：
功能：用戶認證（User Authentication）
端點：POST /login
接受參數：
- user（字串，必填）
- pass（字串，必填）
錯誤處理：
- 如果缺少 username，回傳錯誤碼
測試案例：
- 正確的帳密 → 回傳 200
- 缺少帳號 → 回傳對應錯誤
- 密碼錯誤 → 回傳 401注意到了嗎？這份規格裡面沒有任何一行程式碼。
但 AI 拿到這份規格後，它知道端點在哪、參數是什麼、錯誤要怎麼處理、測試案例有哪些。
AI 不用猜了。
而且這份規格本身就可以用來產生測試，確保 AI 寫的程式碼符合你的要求。
Spec Coding 和其他開發方式有什麼不同？
軟體開發的歷史上，出現過很多不同的開發方法論。
為了幫你更清楚理解 Spec Coding 的定位，我們來比較三種常見的開發方式。
傳統開發：先寫程式碼，再補文件
這是最早、也是最直覺的做法。
工程師拿到需求後，靠自己的直覺和經驗直接開始寫程式碼。
程式碼寫完能跑了，再回頭補上文件和註解，記錄自己做了什麼。
這個方式的好處是啟動速度快，不需要事前準備太多東西。
但缺點也很明顯：因為沒有事先規劃，程式碼的結構容易變得混亂，文件也經常寫得不完整（甚至根本忘了寫）。
而且，如果換一個工程師來接手，他只能看程式碼猜你當初在想什麼。
測試驅動開發（TDD）：先寫測試，再寫程式碼
TDD 是 2000 年代開始流行的開發方法。
它的核心概念是：在寫任何程式碼之前，先寫測試。
舉個例子，假設你要做一個「計算兩數相加」的功能。
在傳統開發裡，你會直接開始寫加法的程式碼，寫完再手動算算看答案對不對。
但在 TDD 裡，你會反過來。
你會先寫一支小程式，這支小程式不做任何功能，它唯一的工作就是「檢查」——去呼叫你還沒寫好的加法功能，然後看看結果是不是 5。
如果是 5，它會告訴你「通過」；如果不是 5，它會告訴你「失敗」。
這支專門用來檢查的小程式，就叫做「測試」。
注意，這時候你只寫了這支檢查用的小程式，真正的加法功能還沒寫。
所以你一跑測試，結果一定是「失敗」——因為加法功能根本不存在。
接下來，你才去寫真正的加法程式碼。
寫完之後再跑一次測試，如果這次顯示「通過」，就代表你的加法功能是正確的。
這就是 TDD 的邏輯：先寫檢查用的小程式，再寫真正的功能，最後用檢查程式驗證功能對不對。
通過之後，你再重構（refactor）程式碼，讓它更乾淨。
這個「寫測試 → 寫程式 → 重構」的循環，就是 TDD 的核心流程。
TDD 的好處是：你從一開始就知道程式碼「應該做什麼」，而且每次改動都有測試保護，不容易改壞東西。
但 TDD 有一個前提——寫程式碼的人是你自己。
因為是你在寫，你腦中有完整的上下文，就算測試寫得不夠詳細，你也知道該怎麼做。
規格驅動開發（Spec Driven Development）：先寫規格，再讓 AI 寫程式碼
Spec Driven Development 可以看成是 TDD 和行為驅動開發（BDD）的進階版。
BDD（Behavior Driven Development） 是 TDD 的延伸，它強調用「人類看得懂的語言」來描述系統行為，而不是用程式碼寫測試。
Spec Coding 把這個概念再往前推一步：你不只描述行為，還要把限制條件、錯誤處理、輸入輸出格式全部寫清楚，變成一份完整的規格文件。
然後把這份規格交給 AI，讓 AI 去產生程式碼、測試、和文件。
為什麼在 AI 時代，規格變得更重要？
關鍵差異在這裡：
在傳統開發和 TDD 裡，寫程式碼的人是你自己。
就算需求寫得不夠清楚，你腦中有完整的上下文，你知道這個專案的背景、技術限制、使用者是誰。
但在 Spec Coding 裡，寫程式碼的人是 AI。
AI 沒有你腦中的上下文，它只看得到你給它的那份規格。
規格寫得越清楚，AI 的產出就越穩定、越接近你的預期。
規格寫得越模糊，AI 就越容易猜錯，你就得花越多時間來回修改。
所以在 AI 時代，寫規格的能力，可能比寫程式碼的能力更重要。
小結
讓我們整理一下這篇文章的重點：
- Vibe Coding 適合快速原型和小實驗，但因為指令模糊，AI 的產出不穩定。
- Spec Driven Development 先寫規格再讓 AI 寫程式，產出更可預期、更可靠。
- Spec Coding 的核心流程是：Prompt → 需求規格 → 審核 → 設計文件 → 實作。
- 在規格階段修改的成本遠低於在程式碼階段修改。
- 規格本身就可以用來產生測試案例，形成完整的品質保證流程。
現在 AI 寫程式的能力越來越強，但「怎麼跟 AI 溝通你要什麼」才是最關鍵的技能。
寫好規格，就是跟 AI 溝通最有效的方式。