近年軟體圈開始流行一個新名詞 —— SDD（Spec-Driven Development）。
顧名思義，它是一種「由規格驅動開發」的方式：
開發人員不再從零寫程式，而是讓 AI 根據需求規格（spec）自動生成架構、介面與部分邏輯。
這種做法聽起來令人振奮，但它的前提卻是——規格真的寫得夠好。
而在現實中，規格這件事，從來就沒那麼簡單。
在多數團隊裡，規格往往模糊不清、描述不全、甚至充滿誤解。
這時候若直接交給 AI 去生成程式碼，可能只會讓錯誤更快、影響更大。
🚧 為什麼單靠 SDD 不夠
想像你是一位開發者，接到這樣一份來自 PM 的 spec：
「乘客可預約早鳥票。若出發日距離今日超過 20 天，則顯示早鳥優惠選項。優惠依剩餘座位與時段自動計算。」
看起來清楚嗎？
對人類而言或許還行，但對 AI 來說，這份 spec 充滿灰色地帶。
它不會知道：
- 「超過 20 天」是否包含當天？
- 「剩餘座位」要少於多少才算「過少」？
- 「優惠選項」是折扣百分比還是固定票種？
AI 不會猜，也不懂業界默契。
它會照字面實作出「完全正確但毫無業務價值」的程式。
這就揭示了 SDD 的三大限制 —— 模糊語言、規格不全、與缺乏業務知識。
我們來一一拆解這三個陷阱。
⚠️ SDD 的三大限制與風險
一、語言的模糊性 —— AI 讀得懂字，但不懂語氣
SDD 的前提是「規格能被明確表達」，
但自然語言的特性恰好相反，它充滿模糊與隱喻。
例如「若訂票超過五張就需要審核」這句話，
AI 會照字面理解為「任何人訂超過五張都要審核」，
而實際上業務邏輯可能是「只有公司帳號才需要主管審核」。
結果？AI 完美執行錯誤的邏輯。
這種錯誤往往不會在測試時被立即發現，
因為在規格層面它是「正確的」，但在商業層面卻「離題了」。
二、規格不可能寫全 —— 現實永遠比文件複雜
任何專案的 spec 都只是「冰山一角」。
人們在撰寫需求時，往往只記下顯而易見的行為。
但實際的產品邏輯往往複雜得多。
以高鐵早鳥票為例：「出發日超過 20 天可顯示早鳥優惠」只是表層邏輯。
實際上還包含：
- 若該班次座位剩不到 10%，是否仍顯示？
- 若用戶登入公司帳號，是否適用不同折扣？
- 若同時使用優惠碼，優先順序是什麼？
這些未被寫出的細節，AI 不會幫你補齊。
結果就是「程式沒 bug，但功能不對」。
SDD 的本質，是把明確規格轉成明確程式。
它不會自動發現遺漏，反而會放大遺漏的後果。
三、Domain Know-how 無法自動推斷 —— AI 沒有「行業常識」
AI 雖然會寫程式，但它不理解文化與業界潛規則。
例如在台灣高鐵的早鳥票邏輯裡，有一條「付款後不得改期」的默契。
這是所有內部人員都知道的事，但若沒被寫進 spec，AI 完全不會考慮。
這不是 AI 的錯，而是因為「上下文」屬於人類知識的一部分。
AI 只看字面意思，不懂「隱含的業務意圖」。
因此，若希望 SDD 生成的程式具備商業正確性，就必須有專業人士補足這一層 domain knowledge。
🧩 解法：讓 SBE / BDD 來補足 SDD 的缺口
這時候，SBE（Specification by Example） 和 BDD（Behavior-Driven Development） 的價值就浮現了。
這兩種方法的核心精神是一樣的：
用「具體範例」把模糊需求轉化為「可驗證的行為」。
SBE 不取代規格，而是讓規格更具體。
換句話說，它幫助團隊在「原始 spec」的基礎上，
用範例補上那些人類以為 AI 會懂，但實際上它不會懂的細節。
🧠 真實對話：當團隊用 SBE 釐清「早鳥票」需求
在高鐵專案的會議室裡，PM、QA、RD 與 AI 工具並肩坐著。
PM 一開口就說：
「早鳥票要在出發日 20 天前顯示，這樣使用者比較容易看到折扣。」
開發人員皺眉問：「那如果是今天 3 月 1 日訂 3 月 21 日的票，是 20 天剛好，要顯示還是不顯示？」
PM 想了想：「嗯…那應該是顯示吧。」
QA 補充：「那如果是凌晨 00:30 查詢呢？時間算哪一天？」
全場一陣靜默。
這時 QA 打開一份 SBE 模板，開始把「原始規格」具體化：
Scenario: 出發日超過 20 天時顯示早鳥選項
Given 今天是 3 月 1 日中午 12:00
And 使用者選擇 3 月 25 日出發
When 使用者查詢可售車次
Then 系統應顯示「早鳥優惠」標籤
PM 看了點頭：「對，這樣寫就清楚多了。」
RD 接著問：「那剩餘座位如果很少，是不是要取消早鳥？」
PM：「對，不能剩太少。」
QA：「那要怎麼定義太少？」
經過討論後，大家補上第二個範例：
Scenario: 剩餘座位過少時不顯示早鳥優惠
Given 今天是 3 月 1 日
And 使用者選擇 3 月 25 日出發
And 該班次剩餘座位小於 10%
When 使用者查詢可售車次
Then 不應顯示「早鳥優惠」
這時，整個團隊終於對齊了理解：
不是只交「文字規格」給 AI，而是交「規格＋經過釐清的範例」。
這樣的結構同時保留了設計意圖（What & Why）與實際行為（How & When）。
AI 不再只是「生成程式的機器」，而能根據具體行為與上下文做出合理的實作。
🤖 接棒：AI 如何從「規格＋範例」生成程式（SDD 階段）
討論結束後，團隊把整理好的內容丟給 AI 工具（如 Kiro 或 Cursor）。
輸入的不是單一範例，而是一份完整的輸入包，包含：
- 原始需求規格
- 經過討論的範例（BDD 格式）
- API / domain 背景說明
Prompt 內容可能像這樣：
「根據以下需求與範例，使用 TypeScript 與 NestJS 實作早鳥票查詢功能，
包含座位查詢、折扣判斷與對應的測試案例。」
AI 立刻生成：
- TicketService：判斷距離出發日天數、查詢座位餘量、計算折扣範圍
- TicketController：提供
/tickets/searchAPI - 測試檔：依據範例自動驗證行為
這時的 AI 並不是在「猜」程式邏輯，而是在「執行共識」。
而這份共識的基礎，就是「spec + example」。
這正是現代開發轉變的關鍵：
AI 不取代人，而是放大規格與範例的準確性。
發表迴響