⬛ 我覺得我設計的 PRD 已經很好了，但我後來又多學到一件事
最近在看幾位朋友的 vibe coding 專案分享，我突然意識到一件事：原來我所設計寫出一份會說話的 PRD 之後，或許還可以再往下一層挖。
我在《打造屬於你的 Vibe Coding 戰隊：從夢想，到可運作的系統（二）好的產品，都始於一份會說話的需求》一文裡，已經有跟大家分享我搭建 PRD 的過程，我已經靠它建構出完整的語境、角色、情境、邏輯，甚至可以直接讓 AI 生成功能框架。其實這份 PRD 拿去給各大 Agent, CLI 我覺得都已經相當足夠。
但早上發文的時候以及之前看朋友的招生文案的時候，一個名詞吸引了我的注意： SDD當下我心裡是想：蛤？什麼 SDD？不是 PRD 已經講很清楚了嗎？
我原本來天真的以為我寫的就已經是 SDD 了，還很自負的跟朋友說：哼哼，我早就有在寫了。
但後來我再度去深入的了解，發現自己漏看了一個關鍵：
PRD 是一份讓 AI「理解你」的文件，而 SDD，是一份讓 AI「開始動手」的規格。
最近我一直期待 AI ，只要它看完 PRD ，就應該要可以幫我自動整理出 todo list、自動設計功能流程，甚至分派任務。但期待越大、失望也就越大，每次都需要我額外下指令請他處理，想要自動卻又一直做不太出來的原因，也許就卡在我沒有給它 SDD。
▏所以 SDD 到底是什麼？它真的跟 PRD 不一樣嗎？
剛開始聽到 SDD 的時候我是有稍微去了解他一下，但馬上就關掉了。
因為我剛開始的時候覺得：PRD 都已經寫到有故事、有角色、有脈絡、有邏輯了，還要什麼 SDD？它又不是要拿去給工程師看，也不是要寫 API 文件。
但後來我開始回想：為什麼我那麼多次，AI 都理解了，做個小服務，可能還撐的起開發。但只要開工時間一長，他就開始放飛自我，然後我還得罵他他才會懂，我一直都覺得講得好像已經很清楚，但它還是少幫我補一段流程、漏掉一個條件、格式也常常亂掉。
過去我一直認為，都是 AI 幻覺的問題，只覺得 AI 不夠聰明，但現在回頭看，可能只是我給它的東西，只到「理解」，沒到「執行」。
SDD，全名是 Specification-Driven Development，規格驅動開發，一開始看起來像是工程師那種嚴謹寫法，但我後來發現它其實是一種補語言邊界的方法。這是一種軟體開發方法論，其核心是先產出清晰、可驗證的規格文件，再以規格為依據進行程式碼開發和自動生成。這種方法強調「規格即真相」，透過消除需求轉譯落差，讓規格文件成為開發流程中唯一的真實來源，並能藉由AI自動化產生程式碼、測試腳本、資料模型等，實現更精準且同步的開發。(source)
我認真思考了一下：如果 PRD 是在講「我要做一個什麼樣的東西，幫什麼樣的人，解決什麼問題」，那 SDD 講的就是「所以你要我怎麼做？什麼時候做？輸入是什麼？要怎麼判斷有沒有做對？」有點像是 PRD 是說明書，而 SDD 是操作手冊。一個讓 AI 感覺懂了，另一個才讓它真的動起來。
▏哪些問題其實 PRD 解不到，SDD 才會幫上忙？
有時候回頭看我的 vibe coding 過程，比如我之前常常會講：
- ⚐ 「幫我分析這份廣告的異常狀況」
- ⚐ 「給我一份更精準的 persona」
- ⚐ 「用角色式的語氣寫出吸引力更強的文案」
- ⚐ 「幫我整理功能列表」
看起來很明確，但其實你仔細想，AI 根本不知道：
- ✎ 什麼叫「異常」？是 CPM 大於平均？還是 ROAS 掉到多少？
- ✎ 「更精準」的 persona，是要加更多細節？還是濾掉不相關的？
- ✎ 「吸引力更強」是增加張力？還是說得更白話？
- ✎ 功能列表是要從使用者旅程拆？還是從任務拆？
PRD 沒有這些東西，它本來就解不到。它只負責把世界說得像一個世界，但沒有說這個世界要按照什麼規則運作。真正讓 AI 能夠穩穩持續開發的，是那些看起來「很瑣碎」的細節。
而 SDD 正在補的，就是這些你以為不重要、但 AI 缺它就會亂跑的那一塊。我甚至覺得 PRD 是讓 AI 懂「我要去哪裡」，而 SDD 是告訴它「路怎麼走、什麼路不能走、走錯要停哪裡」。
你沒有 SDD，AI 就只能靠感覺在陪跑幫你 vibe coding；你有了 SDD，它才會開始像一個隊友，不是像一個猜謎機。這可能對很多資深工程師會覺得「這不是基本的嗎」？但對剛踏入 vibe coding 世界的我們，不得不擴張的知識邊界。
▏那在 PRD 打造完之後，怎麼跟 LLM 一起寫 SDD？
前面這一大段，其實是在說服「我們自己」：光有 PRD 不夠，還得承認 SDD 這一塊是自己的知識黑洞。那接下來，就是要想辦法讓 AI 來補這個黑洞。
在 PRD 的時候，你還記得我們前文所設計過的 prompt 嗎：
我想和你協作一份 PRD。請你像專業產品經理一樣，引導我一步步建立這份文件，從黃金圈理論的『Why』開始，透過一問一答的方式幫我釐清邏輯，直到最後我們能整理出清楚的架構。
這一段的核心，其實是把 LLM 當成「會問問題的 PM」，而不是「幫我寫文件的文書機器」。
我不是叫它一次幫我產出一份 PRD，而是請它用問題把我腦袋裡沒講清楚的東西都翻出來。
那 SDD 要不要用同一個 prompt？以邏輯來說一定要拆開來做。因為 PRD 和 SDD 的生成出的氣氛跟場景完全不一樣。
- ☑ 寫 PRD 的時候，我是在講人、講場景、講故事。
- ☑ 寫 SDD 的時候，我要開始講欄位、講條件、講錯誤處理、講格式。
如果你硬要用同一段 prompt，通常會變成兩邊都不夠深：故事沒講透，規格也講不清楚。與其這樣，不如乾脆承認，我們需要兩種不同的「合作模式」。
一種，是請 AI 當「產品經理」，陪你把 PRD 問出來；另一種，是請 AI 當「系統設計師」，陪你把 SDD 問出來。
所以在 PRD 打造完之後，我現在會開一個新的對話線，然後丟進去剛剛那份 PRD，接著用這種方式開場，以下是我現在會用的 SDD prompt：
「接下來，我想和你協作一份 SDD（Specification-Driven Development）的規格文件。我已經有一份 PRD（產品需求文件），裡面講清楚了使用者、情境與產品目標。請你暫時不要重寫 PRD，而是扮演一位系統設計師＋後端工程師＋產品經理的綜合角色，幫我做下面這件事：
先讀完這份 PRD，幫我整理出這個系統裡的「關鍵名詞」（Domain）有哪些。
接著用一問一答的方式，幫我把這些名詞背後的規則和判斷邏輯（Behavior）問清楚。
當我們把邏輯說清楚之後，再一起設計這個系統的輸入與輸出格式（Interface），用 JSON 或表格都可以。
最後，請你根據我們整理好的 Domain／Behavior／Interface，幫我彙整成一份 SDD 草稿，並列出你覺得還有模糊、需要我決定的地方。在整個過程裡，請你優先用「問問題」來引導我，而不是自己腦補答案；任何你需要假設的地方，都先問過我再寫進文件裡。」
這裡有幾個小小的刻意安排：
- ☐ 我先明說：「PRD 已經有了，你不要重寫。」避免它又回去幫我重講故事。
- ☐ 然後直接把三件事講出來：Domain／Behavior／Interface，引導它用這三個視角來追問。
- ☐ 強調「用問題引導」，是為了避免它自己假裝很懂，結果規格都是憑空長出來的。
- ☐ 最後讓它幫我「整理一版草稿＋標出還沒決定的東西」，這樣我下一輪就有東西可以接著改。
PRD 的 prompt 重點是：幫我釐清 Why / Who / How / What；
SDD 的 prompt 重點變成：幫我釐清 Domain / Behavior / Interface。
兩套都靠 LLM 共創，但節奏完全不同。一個是在幫你補「人與故事」的模糊，一個是在幫你補「規則與邊界」的模糊。
▏所以我們現在要怎麼開始新的 vibe coding 旅程呢？
寫完這篇，我其實沒打算讓你立刻去寫什麼 SDD 模板，也不是叫你今天就得有一套完美的語法。
我真正想說的是這個：
如果你覺得 AI 怎麼說都不太對、怎麼做都差一點，其實不一定是模型的問題，而是我們語言裡的規則還沒長好。
PRD 幫你釐清你要什麼，SDD 才能讓你知道「你說的，AI真的能怎麼做」。
vibe coding 到後來，其實就是一種語言層級的工程：不是你有想法它就能做，而是你有語法，它才跟得上。
下一步你要做的，不是去複製誰的 SDD 寫法，而是試著在自己的工作裡，找到那個 「你以為 AI 懂你，但其實你還沒講清楚的地方」， 然後補上去。
補的方式不用完美，但要持續。 因為系統不是一次寫完的，是一次次對話修出來的。這就是我最近 vibe 出來的新一層節奏，也留給你。
