07-拿著 PRD，真的把它做出來：為什麼別人 vibe coding 做到一半就崩，而你不會
還記得上一篇的結尾，我說了什麼嗎？
因為前面文件寫得夠清楚，寫 code 的過程反而是整件事裡面最輕鬆的一段。
這一篇，我就是要證明這句話。我們會拿著上次那份「呷藥了沒」的 PRD，真的把它做出來。
但在動手之前，我想先講一個你一定看過、甚至可能親身經歷過的場景。
為什麼大部分人做到一半就崩了
一個人興沖沖打開 AI，輸入：「幫我做一個用藥提醒 App。」
AI 也很配合，刷刷刷生出一大堆東西。畫面有了、按鈕有了，看起來煞有其事。他很興奮，接著說：「幫我加上會員系統。」又是一陣刷刷刷。然後是：「提醒功能好像怪怪的，幫我修。」
大概到第五、六輪，事情開始不對勁了。修好了 A 功能，B 功能壞掉；再修 B，畫面整個跑版。AI 越改越亂，他越看越慌，最後只能砍掉重練——或者直接放棄，跟朋友說「AI 還是不太行啦」。
我要很直接地說：這不是 AI 不行，是工作的方式錯了。
錯在哪？錯在他把「做一個產品」當成了「許一個願」。一句模糊的話丟出去，期待 AI 一次生出全部——沒有文件、沒有定義「做完長什麼樣」、沒有任何驗收標準。AI 手上沒有一張能照著走的地圖，只能每一輪猜你要什麼，於是越猜越歪、越補越亂。
這裡我要修正一個連我自己去年都還在教的觀念。以前我會叫你「一次只做一小塊、每塊都要能跑」，因為那時的 AI 撐不住整份產品，你一次塞太多，它就會把前面做好的東西改壞。但今天 agent 型的 AI——尤其是 Codex 這種——已經可以扛住一整份設計文件，自己一路做到底。 你的紀律不再是「幫它切小塊」，而是整個往前挪：把嚴謹全部前置到文件裡，設一個清楚的目標讓它一次跑完，最後你親手驗收。
所以這一篇的三個原則，跟一年前不一樣了：
- 動工前，把 PRD 變成一份帶驗收標準的「設計文件」——給 AI 一張能自己走到底的地圖
- 設好目標，讓它一次跑完——用 Codex 的「目標」模式，加上 SubAgent 自我檢查
- 跑完之後，親手驗收——開網站、逐一核對、遇到不對就截圖丟回去
動工前的最後一步：把 PRD 變成「設計文件」
你可能會想：我上一篇不是已經被 AI 逼問出一份 PRD 了嗎？直接開做不就好了？
還差一步。這一步是大多數教學不會告訴你的，但它是整個流程裡投資報酬率最高的一步。
PRD 回答的是「要做什麼、為誰做、做到哪為止」。但它沒有回答「每一個畫面長什麼樣、每一個按鈕按下去該發生什麼」。如果你拿著 PRD 直接叫 AI 開工，這些細節就會由 AI 自由發揮——而 AI 自由發揮的結果，通常就是那種「一看就是 AI 做的」、又醜又空的東西。
所以在寫任何一行 code 之前，我會先讓 AI 產出一份產品設計文件：把每一個畫面、每一個元件、每一個操作的體驗，全部描述到位，而且——這是關鍵——每一項都要附上驗收標準。
我實際在用的提示詞
這不是理論。下面這段提示詞的結構，是我自己最近接案子、要做一個 Demo 網站給業主看的時候，實際用的版本。我把它整理成你可以直接套用的模板：
# 背景
我正在打造一個叫「呷藥了沒」的產品的第一版 Demo，
需要一個儘可能精細的網站，把整個產品的概念與畫面邏輯完整呈現出來。
# 你的任務
打造一份完整的產品設計文件。
針對 PRD 的需求，把每一個畫面、每一個體驗、每一個操作、
每一個設計概念都精確描述出來。
# 更多想法
- 你應當作為最資深的產品設計師，成為軟體工程師最嚴厲的父親，
去指揮之後動工的工程師
- 不只是體驗，文件中也要包含每一個元件的初步設計說明：它該有什麼
- 替每一個元件、每一個畫面，都設計足夠完整的驗收標準
- 具體來說你必須想得足夠細膩，讓用戶一看就覺得驚艷，
覺得這是一套很棒的系統才行
幾個你可以偷走的細節：
第一，「最嚴厲的父親」不是玩笑。 你給 AI 什麼人設，它就用什麼標準做事。你不設定，它預設就是一個好好先生，什麼都「差不多就好」。我要它當最資深的產品設計師、當工程師最嚴厲的父親，它產出的文件就會逼死後面動工的每一步——而後面動工的也是 AI，所以嚴格是免費的，你不嚴格才是虧。
第二，驗收標準是整份文件的靈魂。 「做一個回報按鈕」是願望；「按鈕按下後 0.5 秒內顯示打勾動畫、同步更新子女端狀態、重複點擊不會重複記錄」是驗收標準。有了它，後面每做完一塊，你就有一份清單可以核對——你不用會寫 code，也能當一個很難糊弄的驗收者。
把這段丟給 AI，幾分鐘後你會拿到一份長長的設計文件。認真讀一遍，用上一篇教你的方式改它、逼問它。改到你自己看了都覺得「哇，這如果做出來真的不錯」——才准動工。
裝上 Build Web Apps，開工
進到 Codex 的外掛市集（就是我們在 Codex 那篇介紹過的「幫 AI 裝手腳」的地方），搜尋「build web」，把官方那個 Build Web Apps 裝起來。
它是官方出的網頁開發外掛，裝上之後，AI 做網站的整套流程會熟練非常多——從建專案、跑起來、到即時預覽，都更順。裝外掛這件事，本質上就是幫 AI 補上原本沒有的手腳。
這裡你可能會問：「呷藥了沒」不是要串 LINE 嗎？怎麼會是做網站？
好問題，而且這個答案本身就是一堂課：第一版，我們不串真的 LINE。 我們做一個「模擬器」——在網頁上復刻一個 LINE 對話畫面，模擬爸媽收到提醒、按下回報的完整流程；旁邊配上子女端的儀表板。整個產品的體驗一目瞭然，但你完全不用去申請 LINE 官方帳號、不用碰任何 API。
為什麼這樣做？因為現在這個階段，你要驗證的是「這個體驗成不成立」——拿給你身邊真的有這個困擾的朋友看，看他眼睛有沒有亮起來。這跟我們在驗證那篇講的邏輯一模一樣：用最小的成本，拿到最真實的信號。串接真實服務是之後的事，體驗被人買單了才值得做。
（順帶一提，這招也是我接案的祕密武器：先做一個精緻的 Demo 網站跟業主對齊想像，遠比寫十頁企劃書有效。）
核心紀律：設好目標，讓它一次跑完
設計文件有了、外掛裝了，接下來就是整篇文章最重要的一次紀律轉變。
我知道你可能還記得我以前的說法：把產品切成一小塊、一小塊，做完一塊驗一塊。那套在當時是對的——它是為了防 AI 撐不住整份產品。但今天的 Codex 已經不一樣了，你可以把整份設計文件交給它，讓它自己一路做到底。這時候真正該學會的，是 Codex 的「目標」功能。
什麼是「目標」功能
在 Codex 的輸入框，點左下角的「＋」，你會看到一個叫「目標」的選項——它的說明就寫著「設定 Codex 會持續努力達成的目標」。
差別在哪？平常你丟一句話，AI 做完那一句就停下來等你。但一旦設定了「目標」，Codex 會把你給的目標當成它要死守的終點線，自己規劃步驟、自己一步步做、每做一段自己檢查有沒有達標，不到目標不停手。這正好接上設計文件的思路：文件是地圖，目標是終點，剩下的路讓它自己走。
我實際會這樣設定目標：
幫我一步一步完成整個系統的開發，
並在開發完成後派遣 SubAgent 對系統完成邏輯檢查、測試，
最終得到一個生產級可用網站。
拆解一下這段為什麼有效：
- 「一步一步完成整個系統」——我不再自己切塊，而是把「怎麼分步驟」也交給它。它會自己把大目標拆成小步驟依序完成，這正是 agent 型 AI 比一年前強的地方。
- 「派遣 SubAgent 做邏輯檢查、測試」——還記得我們講過的分身術嗎？讓一個乾淨的 SubAgent 反過來檢查主線做出來的東西，等於它先幫你自我驗收了一輪。
- 「生產級可用網站」——把標準寫死。你不寫「生產級」，它的預設就是「能跑就好」。
再搭配輸入框旁邊那個「代我核准」模式，Codex 就不會每動一步都停下來問你「這樣可以嗎」，而是照著目標一路推進到底。你要做的，就是把設計文件 @ 進來、設好目標、按下送出，然後去泡杯咖啡。
沒文件的 one shot 是賭博，有文件加目標的 one shot 是工程。兩者的差別，不在 AI 的能力，在你動工前下的功夫。
跑完不等於做完：開網站，逐一驗收，截圖丟回去
Codex 會跟你說「完成了」。但它說完成，不代表真的完成——它只是達到了它自己認定的達標。真正的驗收，還得你親手來。
打開它做好的網站，拿出你那份設計文件裡的驗收標準，一條一條點過去：這顆按鈕按下去有沒有反應？狀態有沒有同步更新？畫面在手機上會不會跑版？你不用會寫 code，光靠這份清單，你就是一個很難被糊弄的驗收者。
遇到不對的地方，不要用文字去描述它。你打「那個卡片的顏色怪怪的、位置好像也不太對」，AI 只能靠猜，還常常猜錯。最快的方式是——直接截圖。
Codex 內建了截圖功能（設定裡叫「Appshot／應用程式快照」，快速鍵是連按兩下 ⌘），方便你跟它快速溝通。它會把你最前景的視窗連同畫面和文字一起拍下來——你把有問題的那個畫面截下來丟回去，再補一句「這裡不對，應該要是⋯⋯」。一張截圖，就是你跟 AI 之間最短的溝通路徑——它看得到你看到的東西，修起來又快又準。
這個「開網站 → 發現問題 → 截圖丟回 → 修 → 再看一次」的循環，跑個幾輪，你的產品就會從「AI 說做好了」收斂成「你自己看了也覺得可以」。這一步沒有捷徑，但它也不難——難的部分，你在前面寫設計文件的時候，就已經先做完了。
真的卡死的時候：不要吵架，開新對話丟文件
有時候截圖來回修了幾輪，AI 還是鬼打牆——越修越歪，或突然開始講一些跟你產品無關的東西。這代表這個對話已經被污染了，繼續在裡面耗只會更亂。
大多數人的反應是跟它吵：「不對！我不是這個意思！」「你怎麼又改壞了！」然後在同一個對話裡越吵越深，越吵越亂。
我的做法只有一招，但幾乎每次都有效：開一個新對話，把文件丟回去。
@PRD.md @產品設計文件.md
目前進度：第一、二、三塊已完成且正常運作。
第四塊（寬限期邏輯）的狀況是：超時之後儀表板沒有跳提醒。
請先讀完兩份文件，理解整個產品，再幫我處理這個問題。
為什麼這招有效？回到上一篇的核心觀念：AI 每開一個新對話就失憶，而你的文件不會。 舊對話裡累積的混亂、誤解、越描越黑的上下文，全部歸零；新的 AI 讀著乾淨的文件，帶著清楚的現狀說明，直接從對的地方接手。
你有沒有發現？我們上一篇花那麼多力氣寫文件，真正的回報就是在這一刻兌現的。沒有文件的人卡住了，只能從頭再講一次他的產品夢；有文件的人卡住了，換一個 AI 三十秒接手。 這就是我說「寫 code 反而是最輕鬆的一段」的底氣。
把這整套流程，存成你的技能
最後，給你一個放大這整篇價值的動作。
還記得 Codex 那篇說過的嗎——技能，就是你寫給 AI 的 SOP。這篇教你的整套流程：先產設計文件、設目標一次做完、SubAgent 自檢、開網站截圖驗收、真的卡死才丟文件……你完全可以跟 AI 說：
把我們這次開發的流程整理成一個技能：
從 PRD 產出含驗收標準的設計文件、設定目標讓 Codex 一次做完、
派 SubAgent 自檢、最後開網站逐條驗收、不對就截圖回修。
以後我說「照流程開工」就照這套做。
下一個產品，你就不用再讀這篇文章了。這才是這個系列真正想教你的事：方法論用過一次就把它固化下來，讓你的每一次經驗，都變成下一次的起點。
收尾
回顧一下這一篇：
- 動工前，先用一段嚴格的提示詞，把 PRD 變成帶驗收標準的設計文件
- 裝上 Build Web Apps，第一版做「模擬器」不串真服務——先驗體驗
- 用 Codex 的**「目標」模式設好終點、搭配 SubAgent 自檢，讓它一次跑完**
- 跑完親手驗收：開網站逐條核對，不對就截圖丟回去
- 真的卡死才開新對話、丟文件，讓 SSOT 兌現它的價值
- 最後把整套流程存成技能
照著走，你會得到一個能打開、能操作、能拿給真人看的「呷藥了沒」。做出來的那一刻真的很爽——你會忍不住想把連結丟到群組裡，讓大家看看你用 AI 做出了什麼。
先等一下。
在你把任何東西放上網路之前，有幾件 vibe coding 永遠不會主動告訴你的事。2026 年上半年，有幾十萬個像這樣做出來的網站正在網路上裸奔，其中一個還鬧出了大新聞。下一篇，我帶你看看那條看不見的線——跨過去，你的作品才算是個產品。我們下個單元見。