你用 Vibe Coding 做的東西，為什麼只能當 Demo？

這幾天在 X 上看到一則貼文，作者是 Meta 的 AI 資深總監 Madhu Guru，他在 Google 時期帶過 Gemini、Veo 與 Nano Banana 開發團隊。他給了一個週末練習，短到可以寫在便利貼上：

挑一個你熟到不能再熟的工作流程，工作或生活的都行，用你順手的 AI 產品，把整條流程從頭到尾自動化。你大概得試個幾種工具才會找到合用的。做完之後，把野心再往上加一階。

讀到這裡，這還只是一則鼓勵動手做的貼文。真正該停下來看的，是他接著列的四個問題。他說這個練習會逼你去想：什麼叫好的端到端體驗？MCP 與工具該怎麼用？人該留在流程的哪一段？要怎麼評估成效？他最後的意思是，這樣實作一次，勝過反覆閱讀關於 AI 產品的文章。

我看到那四個問題的時候，第一個念頭不是「說得真好」，而是：這四個問題，正好就是把 Demo 推成產品的那道門檻。

讓東西跑起來，已經變得很簡單了

自 ChatGPT 問世以來，這幾年最大的變化就是程式設計變簡單了！你用自然語言描述一個想法，二十分鐘後螢幕上就有一個能點、能填、能跑出結果的東西。這件事在三年前，至少要花掉一個工程師一整週的時間。

而現在，我只花一個早上的時間，就教會一位六十多歲的阿姨設計貓捉老鼠的小遊戲。

但有件事的成本一點都沒減少，那就是要如何讓那個東西持續可靠地被人使用。

老實說，我在課堂上看過非常多這樣的作品。網站介面做得漂亮，功能點下去有反應，展示的時候大家都很興奮。可是回家放三天再打開，資料付之闕如，流程斷在中間，或者只有作者本人知道要先做哪一步才不會壞。它不是不能用，它只能在作者手裡、在作者還記得所有前提的時候，用那麼一次。

那就是 Demo。Demo 的任務是證明「這件事有可能」，它做完就功成身退了。但產品的任務不一樣，產品要在你不在場、使用者亂點、資料長得跟你想像的不一樣時，還能給出可以信任的結果。

Madhu 那四個問題之所以有份量，是因為它們每一題都指向 Demo 不必回答、產品逃不掉的地方。

第一題：什麼叫好的端到端體驗

Demo 只顧中間那一段，也就是最精采、最好展示的那一段。

但真正的流程，有頭有尾。頭是：這個東西怎麼被啟動？誰去按？在什麼情境下想起它？資料從哪裡進來？尾是：跑完之後結果去了哪裡？誰接手？如果結果是錯的，這個人怎麼發現、怎麼退回？

大部分 Vibe Coding 作品的破綻都在頭尾。中間那段模型表現得很好，但輸入要人工貼上去，輸出跑在畫面上、關掉就沒了。這樣的東西每用一次都要作者親自伺候，它就永遠長不成產品。

端到端的意思，就是從「有人想到要用它」一路到「事情真的被完成了」。當你把這條線完整畫過一次，會立刻發現自己原來只做了中間三成。

第二題：MCP 與工具該怎麼用

模型如果不能碰到真實世界，它的用途就會受限。

它能寫出一封漂亮的信，但寄不出去；能整理出一張很好的清單，但寫不進你的資料庫；能判斷這筆訂單有問題，但不會去查金流系統確認。工具與 MCP 就是讓模型長出手腳的東西，讓它從「會講」變成「會做」。

這一個問題卡住多數人的地方，其實是選擇：哪些事該讓模型自己判斷，哪些事該寫成一支確定性的函式，讓它每次都給一樣的答案。日期換算、稅額計算、格式驗證這種有標準答案的事，交給模型去猜是在自找麻煩；需要讀懂語意、需要權衡的事，才是模型的主場。

分不清這條線，做出來的東西體質會很奇怪：大方向都對，小地方三不五時錯一次，而且每次錯的還不同。

第三題：人該留在流程的哪一段

全自動很誘人，尤其當你剛做出一個會自己跑完的流程，會很想把最後那個確認鍵也拿掉。

判斷的方法其實不複雜：問自己這一步做錯的話，代價由誰承擔、收不收得回來。寄出去的信收不回來，刷下去的款收不回來，發布到網路上的內容就算刪掉也已經被人看過。這些地方要留人。反過來，整理格式、分類歸檔、產草稿這種做錯了重跑一次就好的事，人留在那裡只是拖慢自己。

我自己的做法是，把人放在「不可逆」的那幾個點上，其餘全部讓它跑。這樣既不會被瑣事綁住，真出事了損失也還收得住。

這一題答得好不好，決定了你敢不敢真的把這個東西交出去用。

第四題：你要怎麼評估它

這是四個問題裡最容易被跳過的，也是差距拉最開的一題。

Demo 的評估標準是現場反應，大家覺得酷，就算成功。產品不能這樣。你得先講清楚：什麼叫做對了？跑一百次裡面錯幾次是可以接受的？錯的時候是安靜給出錯誤答案，還是會停下來說我不確定？

沒有評估標準的後果，是你每次改動都在賭。改了一段提示詞，感覺好像變好了，但你不知道是真的變好，還是這次剛好抽到好結果。等到某天它在真實情境下出包，你連是哪一次改動害的都查不出來。

不必一開始就搞得很正式。準備十到二十筆你已經知道正確答案的真實案例，每次改完就整批跑一次，看錯幾筆。光是這樣，你對自己作品的掌握度就會跟以前完全不同。

為什麼一定要挑「你熟到不能再熟」的流程

Madhu 那句話裡，有個很容易被滑過去的限定：挑一個你熟悉的流程。

這個限定不是為了讓練習變簡單，而是為了讓第四個問題有辦法回答。你只有在自己熟悉的領域裡，才知道什麼叫做對了？你熟悉報價流程，才看得出來 AI 少問了一個關鍵條件；你熟悉自己的電子報，才知道那段開頭讀起來不像你的口吻。

換成一個你不熟的題目，你會失去判斷能力，只能看著輸出說「看起來還不錯」。嗯，那就回到 Demo 的評估方式了。

所以，我總是建議大家先從自己的工作下手。這些題目未必最有商業價值，但你在那個範疇中是內行人。唯有內行人做出來的東西才有分寸，才知道哪裡不能將就。

這個週末可以怎麼開始

如果你想真的動手，我會這樣安排：

先挑一件你這個月至少做過三次的事。三次是個門檻，代表它夠常發生，值得自動化，也代表你手上已經有幾筆可以拿來當評估標準的真實案例。

然後把這件事從頭到尾寫下來，包括你平常怎麼想起要做它、資料從哪裡拿、你在哪一步會停下來判斷、做完之後結果放到哪裡。先寫流程，再開始做東西。這一步很多人跳過，然後就直接做出一個只有中間段的作品。

接著才是 Vibe Coding 的部分：把它做出來，讓它真的能跑完一次。做完先別急著加功能，回頭問那四個問題，哪一題答不出來，那裡就是你的下一個工作。

最後把那十幾筆案例跑一遍，數一數錯了幾筆？然後，你就會很清楚知道自己站在哪裡。

從想法到作品，中間有一段路

我很喜歡 Madhu 的那則貼文，因為它沒有把開發 AI 產品講成一件需要天分的事，而是一件可以練習的事。挑題目、動手做、回答四個問題、把野心再加一階，如此循環。

但我也知道，對很多人來說卡住的是更前面那一步：想法有了，工具打開了，然後不知道第一行要打什麼？

這正是我寫《零基礎學 Vibe Coding：用 AI 做出網站、App 與工作自動化工具》的原因。這本書處理從零到第一個作品跑起來的那一段：怎麼把腦中的想法講成 AI 聽得懂的話、卡住時怎麼問、做出來之後怎麼讓別人也能打開來用。書裡的第 1 章與第 4 章開放免費試閱，你可以先讀完再決定要不要買。想直接入手的話，博客來、天瓏、誠品線上或金石堂都買得到。

先有第一個作品，才有東西可以拿來問那四個問題。這個週末，挑一件你做過三次的事，開始動手吧！

---

本文的起點是 Madhu Guru 這則貼文：https://x.com/realmadhuguru/status/2095907570540335174