SDD 定骨架、RDD 問到位、TDD 驗到死：我用 AI 做原型的三段式工作流

接案做原型，最貴的成本從來不是寫 code。

是猜錯需求之後，把做好的東西砍掉重來。

我自己踩過好幾次：客戶說「做一個報名系統」，我覺得聽懂了，花三天做出來。客戶看完說「不是，我要的是⋯⋯」。又花兩天改。改完再看，又冒出新的「其實我當初的意思是⋯⋯」。

code 本身沒 bug，但時間全花在猜和重做上面。

後來我發現一件事：問題不是出在寫 code 的時候，是出在寫 code 之前。

需求沒問清楚，後面做再快都是在賭。

用蓋房子來比喻

我現在做原型，會走三個步驟。用蓋房子來比喻最好懂：

步驟 蓋房子的比喻 軟體開發裡做什麼
① SDD
畫藍圖		 建築師先畫設計圖：幾層樓、幾間房、大門朝哪 寫出規格文件，把架構骨幹定下來
② RDD
跟屋主確認		 拿藍圖跟屋主逐間確認：「廚房要開放式還是封閉式？」「浴室要乾濕分離嗎？」 用 README 跟客戶反覆對焦，把每個模糊的地方問到沒有疑問
③ TDD
請驗屋師		 蓋之前就先列好驗收清單：「水龍頭要出熱水」「插座要有接地」，蓋完逐項檢查 先寫測試，定義每個功能「什麼叫做對」，再寫程式讓測試通過

三步各自擋住一種失敗：

  • 沒有藍圖就動工 → 蓋出來的房子格局亂七八糟
  • 沒有跟屋主確認 → 蓋完才發現「我以為你要的是⋯⋯」
  • 沒有驗屋 → 交屋後才發現漏水，修起來比重蓋還貴

軟體開發一模一樣。

① SDD：先畫藍圖，再動工

SDD 的全名是 Spec-Driven Development，直翻就是「規格驅動開發」。

白話講：動手之前，先把「要做什麼」寫下來。

這不是寫一份沒人看的文件。而是強迫自己（和客戶）回答這些問題：

  • 這個東西要解決什麼問題？
  • 誰會用？怎麼用？
  • 一定要做的功能有哪些？先做什麼、後做什麼？
  • 資料長什麼樣？（比如報名系統：一筆報名要存什麼？姓名、Email、報名時間⋯⋯）
  • 這次不做什麼？

最後一個問題特別重要。很多案子會膨脹，都是因為沒講清楚邊界。開發到一半，客戶說「那順便加一個⋯⋯」。如果一開始就寫清楚「這次不做 X、不做 Y」，後面要加就是另一個報價。

混亂的需求經過這一步，會被整理成結構清楚的規格文件

實際產出長什麼樣

我會寫一份 SPEC.md，大概像這樣：

# 活動報名系統

## 解決什麼問題
主辦方需要一個線上報名頁面，取代現在用 Google 表單 + 人工統計的做法。

## 誰會用
- 報名者：填表報名、收到確認信
- 管理員：看報名清單、匯出 Excel、關閉報名

## 一定要做的功能
1. 報名表單（姓名、Email、電話、備註）
2. 報名成功後寄確認信
3. 後台可以看清單、匯出
4. 可以設定報名截止時間

## 這次不做
- 付款功能
- 多場活動管理（只做單場）
- 手機 App

搭配 AI 怎麼做

我不會從零開始寫 Spec。流程是：

  1. 把客戶講的需求整理好（可能是一段 Line 訊息、一份簡報）
  2. 丟給 AI，讓它產出初版 Spec
  3. 我看過、修掉 AI 自己加的東西（它很愛擅自加功能）
  4. 拿去跟客戶確認

AI 在這一步的角色是幫你整理結構，但最終哪些該做、哪些不做，是你跟客戶決定的。

② RDD：拿著藍圖，跟屋主一間一間確認

RDD 的全名是 README-Driven Development，直翻是「README 驅動開發」。

白話講：把 README 當成你跟客戶的對話記錄，一直更新，直到雙方對每個細節都沒有歧義。

每一輪對話，文件從模糊變清晰——這是一個不斷收斂的過程

為什麼需要這一步？

因為 Spec 寫完之後，一定還有很多「看起來清楚，其實不清楚」的地方。

舉例，Spec 寫了：

「報名成功後寄確認信。」

看起來很明確吧？但你真的要做的時候，會發現至少有五個問題沒回答：

  • 信的標題是什麼？
  • 信裡面要放什麼內容？活動時間？地點？地圖連結？
  • 用什麼寄？Gmail？SendGrid？
  • 如果信寄失敗怎麼辦？要重寄嗎？
  • 客戶要看到「誰收到信、誰沒收到」嗎？

這些問題如果你沒問，就會自己猜。猜對了沒事，猜錯了就要重做。

怎麼操作

我會把 Spec 轉成一份 README，然後開始列問題：

## 待確認

### Q1：確認信的內容誰提供？
A) 客戶給我一份信件範本
B) 我寫一個通用版，客戶再改
→ 客戶回覆：________

### Q2：報名額滿怎麼處理？
A) 顯示「已額滿」，不能再報
B) 改成候補，額滿後排隊
C) 不限人數
→ 客戶回覆：________

### Q3：管理員可以手動幫人報名嗎？
→ 客戶回覆：________

客戶回答之後，我更新 README，再問下一輪更細的問題。一直問到 README 裡面沒有任何「待確認」的項目為止。

為什麼不用 Line 來回就好？

因為 Line 的對話會散在時間軸裡。三天後你回去翻，根本分不清哪句是最終決定、哪句只是隨口說說。

README 是一份活文件——每次確認就更新，所有決策都留在裡面。三個月後客戶問「當初為什麼這樣做？」，打開 README 就有答案。

搭配 AI 怎麼做

AI 在這一步最好用的地方：自動從 Spec 裡找出模糊的部分，幫你列出問題清單。

我會跟 AI 說：

請看這份 Spec，找出所有定義不夠明確、開發時可能會有疑問的地方。每個模糊點列一個問題，附上你的建議答案。

AI 會很認真地把每一個「使用者可以⋯⋯」後面缺少的細節都挖出來。這省掉我自己逐條看的時間，而且它常能想到我漏掉的邊界情況——比如「如果使用者填完表單但沒按送出就關掉頁面，要不要存草稿？」

但我會篩選——有些問題太瑣碎（比如「按鈕的圓角要幾 px？」），MVP 階段不用管。只問會影響功能邏輯的問題。

③ TDD：先寫驗收清單，再開始蓋

TDD 的全名是 Test-Driven Development，直翻是「測試驅動開發」。

白話講：在寫程式之前，先寫好「怎麼驗收」。然後寫程式，讓驗收全部通過。

就像驗屋師不是房子蓋好才想要驗什麼——是蓋之前就列好清單：

  • ☐ 水龍頭打開 5 秒內要出熱水
  • ☐ 每個插座都要有接地
  • ☐ 門鎖要能從裡面反鎖

蓋完之後，逐項檢查。有一項沒過，就不能交屋。

測試就像安全網——程式掉下去會被接住，不會直接摔到地上

為什麼 TDD 放最後，不是一開始就寫測試？

因為你得先知道「什麼叫做對」，才能寫出有意義的測試。

如果 Spec 還是模糊的、README 還沒跟客戶確認完，你寫的測試是基於「你猜的需求」，不是「客戶真正要的」。測試全過了，客戶一看：「不是我要的。」那些測試就白寫了。

前兩步（SDD + RDD）做完，你已經知道每個功能的具體行為。這時候寫測試，其實就是把 README 裡的規格翻譯成程式語言：

// README 寫：「一個 Email 只能報名一次」
it('同一個 Email 報名第二次，應該回傳錯誤', async () => {
  await register({ email: 'test@example.com', name: '小明' })
  const result = await register({ email: 'test@example.com', name: '小華' })
  expect(result.error).toBe('此 Email 已報名')
})

// README 寫：「超過截止時間不能報名」
it('截止日之後送出表單，應該回傳已截止', async () => {
  setMockDate('2026-09-01') // 截止日是 8/31
  const result = await register({ email: 'late@example.com', name: '遲到' })
  expect(result.error).toBe('報名已截止')
})

每一條測試都能對應到 README 裡的某一條規格。測試通過 = 這個功能做對了。

搭配 AI 怎麼做

這是 AI 最能發揮的一步。因為走到這裡，Spec 和 README 都很精確了，AI 拿到的「題目」品質很高。

  1. 把確認過的 README 餵給 AI
  2. 讓 AI 根據規格寫測試
  3. 我 review 測試，補漏掉的情況
  4. 讓 AI 寫程式，跑測試
  5. 沒過的地方，讓 AI 修

前面需求問得越清楚，這一步 AI 的命中率越高。 這就是整套流程的核心邏輯——前面花時間，後面省事。

整個流程的時間怎麼分配

以一個中型案子（比如一個報名系統 + 後台管理）為例：

步驟 花多少時間 產出什麼
① SDD — 寫規格 15% SPEC.md（藍圖）
② RDD — 跟客戶對焦 25% README.md（雙方確認的規格）
③ TDD — 寫測試 + 寫程式 50% 通過所有測試的程式碼
收尾 — 部署 + 交付 10% 客戶可以用的原型

前兩步佔了 40% 的時間，一行程式都還沒寫。看起來很浪費？

但這 40% 換來的是：後面 60% 幾乎不用猜、不用跟客戶來回確認「你是不是要這個」、不用砍掉重來。

省掉一次「做錯重來」，就把前面花的時間全部賺回來了。

什麼時候不需要這套流程

不是每個案子都要走完整三步。

幾小時就能做完的小東西 — 直接做。問問題的時間比做錯的成本還高。

純粹試水溫的原型 — 目的就是「做一個出來看看」，需求本身還在變。太早鎖定規格反而綁手綁腳。

客戶自己都不知道要什麼 — 這時候 RDD 會變成無限迴圈，問什麼都得到「你覺得呢？」。更好的做法是先做一個很粗的版本讓客戶看，看完他才知道自己不要什麼。

最適合的情境是：客戶有明確的目標（「我要一個線上報名系統」），但細節還沒定義。 這是最常見的接案狀況，也是這套流程最能幫上忙的地方。

小結

SDD 定骨架、RDD 問到位、TDD 驗到死。

先畫藍圖，再跟客戶確認每個房間怎麼用，最後列好驗收清單才動工。

AI Agent 在這裡面扮演的角色，不是替你做決定——是替你在每一步做整理和收斂的苦工：幫你產出 Spec 骨架、幫你找出模糊的地方、幫你寫測試、幫你寫程式。

但方向盤一直在你手上：哪些該做、哪些該問客戶、哪些測試有意義。

做對的東西，永遠比把東西做快更重要。