你有一個產品想法，最想知道的只有一件事：到底有沒有人要。這個問題用嘴巴問幾乎得不到答案——你得到的會是客氣的形容詞。只有一個能點、能輸入、能存資料的東西擺在目標使用者面前，你才可能看到接近真實的行為。過去「做個能看的東西」這件事本身的成本高到足以擋住驗證，現在有一類 AI 生成工具，讓不寫程式的人也能在一個週末做出可操作的原型。這篇是操作配方：照著做，從一個模糊的想法，走到一條可分享的連結加一批真實使用者回饋。
這個場景解決什麼
先定義清楚這個週末要產出什麼，不然會做成四不像。
痛點是三段式的：想法停在「說不清楚」的階段，別人聽完只能禮貌點頭；直接開發正式版，成本與時間高到驗錯方向也來不及回頭；而沒有可操作的東西，所有討論都發生在形容詞層面（「我覺得使用者會喜歡」），無法被反駁也無法被證實。
「能用的原型」的定義，四條全滿足才算數：
- 有一條核心流程跑得通（使用者從進來到完成一件事）
- 別人在自己的裝置上打得開、用得了
- 輸入的資料會被存下來，重新整理不會消失
- 全程不需要你在旁邊解說
同時明確原型不是什麼：不是正式產品。它沒有備份、沒有監控、安全性未經加固，它的任務是驗證，不是營運。把這句話記著，後面好幾個踩坑都從忘記它開始。
時間預算：總預算一個週末（兩天的可投入時間）。每個步驟都有該停的節點，時間到就砍範圍，不砍品質關卡——寧可少做一個功能，不可跳過一次驗收。
工具組合與前置準備
這類工具的能力邊界迭代很快，以下描述的是角色分工而非功能清單；實際能力、定價與免費額度一律以各家官網與文件為準。
| 工具 | 常見角色 | 什麼時候優先選它 |
|---|---|---|
| v0 | 偏介面與前端頁面生成，快速產出可看的畫面 | 你要驗證的是「畫面與流程說不說得通」，從頁面切入 |
| Lovable | 偏完整應用生成，通常能直接接資料庫與登入 | 原型需要存資料、需要區分使用者 |
| Bolt | 在瀏覽器裡跑完整專案，邊改邊預覽、可取得程式碼 | 你想拿到程式碼，之後自己或找工程師接手 |
三者能力高度重疊，彼此之間的差異，遠小於「你有沒有把規格寫清楚」造成的差異。選擇建議只有一條：你手上哪個已經有帳號、跑得起來，就用哪個。不要花週末的一半時間橫向評比三個工具——那是拖延，不是選型。系統性的選型方法見選 AI 工具的判斷框架。
前置準備清單（開工前全部完成）：
- 帳號：選定的生成工具、常用 email；打算匯出程式碼的話，準備好程式碼託管帳號
- 素材：想法的一句話描述；一兩個你喜歡的參考網站（可選，但能省很多輪對話）
- 資料規則：原型全程用假資料，不放任何真實個資與公司機密。涉及公司資料時，先確認資料分級允許你做什麼，見企業資料安全基本盤
一、把想法收斂成一頁規格
生成工具對輸入品質極度敏感。「幫我做一個電商網站」和一頁規格，產出的東西差的不是一點，是方向。一頁規格照這個模板填：
產品一句話：給（什麼人），解決（什麼問題）。
核心流程：使用者從進來 →（步驟）→（步驟）→ 完成（什麼事）。
把涉及的畫面依序列出，最多五個。
第一版必須有：最多三項。
第一版明確不做：寫出來（之後用來擋住自己）。
資料：原型需要存什麼；每筆資料有哪些欄位。
成功的樣子：使用者完成（什麼動作），原型就算達成任務。
填完做兩個自我判斷：
- 寫不出「成功的樣子」：想法還沒收斂，先別開生成工具。回去跟對話式 AI 聊：把你的想法丟給它，請它扮演一個挑剔的目標使用者連續追問你（「我為什麼不用現有的做法」「這件事現在怎麼解決」），通常問到第三、四輪，你就知道自己真正要驗證的是什麼。
- 「必須有」超過三項：砍到三項為止。一個週末只裝得下一條核心流程，多塞的每一項都在稀釋它。
二、第一輪產出——先要骨架，不要細節
第一則指令把一頁規格整段貼給工具，外加一句話：「請先做出核心流程跑得通的版本，清單內容用假資料，先不要做登入與付款。」
拿到第一版之後，按順序做三件事：
- 把核心流程自己點一遍，先不要看美醜——流程通不通是唯一重要的事
- 列出最重要的三個修改點，寫下來，這一輪只改這三個
- 方向整個錯了就重來：回滾到上一個版本或重開專案，不要在錯的結構上硬改
之後每一輪迭代都遵守兩條紀律：
- 指令要指向具體位置與期望行為。「訂單頁按儲存沒有反應，我期望儲存後出現在下方清單」是可以執行的；「感覺不太行，再優化一下」會得到一次抽獎。
- 一輪只改一類事情：這一輪修流程，下一輪調資料，再下一輪才碰外觀。混在一起改，壞掉時你不會知道是哪句指令造成的。
三、接資料庫與登入
順序是先資料、後登入。
資料表：把規格裡「資料」那段直接給工具，讓它建立資料表（哪幾張表、每張表哪些欄位、表與表怎麼關聯）。建好後手動新增兩筆假資料，重新整理頁面，確認資料真的被讀出來顯示。
登入：優先用生成平台內建或整合的登入機制（email 驗證或第三方登入）。不要讓工具手寫帳號密碼系統——密碼儲存、工作階段管理、權限檢查，每一環都是安全黑洞，原型不該自己扛這些。
這一步的驗收只有兩條：重新整理不掉資料；兩個不同帳號登入，互相看不到對方的資料。
如果平台的資料庫功能需要付費或有限制而你想先跳過：可以退而用「單一使用者、資料存本機」的模式先跑，但要在一頁規格上記一筆「多使用者未驗證」——不要讓這個缺口隱形。
四、部署成可分享連結
用平台內建的發佈機制取得公開連結；若要匯出程式碼自行部署，選能完整匯出原始碼的平台，照其文件接上託管服務。
發佈前檢查三件事：
- 資料庫裡只有假資料——沒有你自己的真實姓名、電話、任何客戶資訊
- 金鑰沒有寫死在前端——直接問工具：「列出前端程式碼裡出現的所有金鑰與 API 端點」，逐一確認哪些不該公開
- 頁面上有原型標注——加一行「這是驗證用原型，請勿輸入真實個人資料」
把連結給別人時，附上一句話說明（這是做什麼的、請你試什麼），不要只丟一條裸連結——對方打開不知道要幹嘛，你收到的回饋就會是「看不懂」。
五、找真實使用者試用
這是整個週末最值錢的一步，也是最常被跳過的一步。做出連結就覺得完成了，等於做了考卷不對答案。
找誰：符合目標使用者輪廓的人。朋友與同事會對你客氣，他們的稱讚沒有資訊量。找幾位就好，一直約到新使用者的回饋開始重複前面的人，就夠了。
怎麼測（比找誰更重要）：
- 給任務，不給導覽：「請用它完成某某事」，然後閉嘴。他卡在哪裡，哪裡就是你的設計問題；你一開口解釋，這次觀察就作廢了。
- 請他邊用邊說出想法：他在找什麼、他以為點了之後會發生什麼。
- 記錄他的原話，不是你的轉譯。「使用者覺得不好用」沒有價值；「我以為按這裡會存檔」才是修改依據。
- 最後問一題：「用一句話說說你覺得這是做什麼的？」答案跟你的「產品一句話」對不上，問題在表達層，不在功能層。
回饋怎麼分類：分成「核心假設問題」（使用者根本不懂、不想要、流程方向錯了）與「體驗細節問題」（文案、顏色、速度）。只有前者值得回去改原型；後者記下來，留給正式版。
六、知道什麼時候該停——哪些需求這類工具做不好
生成工具的能力邊界是這個配方裡最需要誠實面對的部分。下表是「停損訊號」：當你要驗證的核心假設正好落在表裡，原型這條路本身就是錯的，應該改用人工模擬（先用人肉把服務流程跑一遍驗證需求）或直接找專業的人。
| 需求類型 | 為什麼這類工具做不好 | 該怎麼辦 |
|---|---|---|
| 複雜權限與審批（多角色可見性、多級簽核） | 畫面生得出來，權限模型很容易錯，而且錯得看不出來 | 核心需求就找工程師評估；原型只示範單一角色 |
| 金流與真實付款 | 涉及資金安全與法規遵循，原型級實作不可信 | 絕不接真實付款；用假流程表達意圖即可 |
| 與既有內部系統整合 | 需要憑證、網路權限與介面規格，超出生成工具範圍 | 見把既有 SaaS 用 n8n 串成一條流程 |
| 高度客製化互動與品牌視覺 | 做得出來，但反覆迭代的時間成本高於找人做 | 視覺本身是核心假設時，找設計師做高傳真稿 |
| 真實個資與受監管場景（醫療、理財建議等） | 合規問題不是原型工具能解決的 | 直接停，見什麼時候不該用 AI |
| 高併發與效能 | 原型架構根本不為負載設計 | 「撐不撐得住」是核心假設時，需要專業壓測 |
判斷原則一句話：原型回答「有沒有人的問題」，不回答「系統行不行的問題」。你要驗證的問題屬於後者時，別為難原型，也別為難自己。
成果與驗收標準
| 檢查點 | 通過標準 | 沒通過怎麼辦 |
|---|---|---|
| 一頁規格 | 別人讀完能說出產品給誰、做什麼、明確不做什麼 | 回到第一節；先不要開生成工具 |
| 核心流程 | 陌生人無人引導能完成一次核心動作 | 砍掉次要畫面，只修主流程 |
| 資料與登入 | 重新整理不掉資料；兩個帳號互看不到對方資料 | 請工具檢查資料表關聯與登入設定 |
| 可分享連結 | 別人的裝置與瀏覽器打得開；頁面有原型標注、無真實資料 | 檢查發佈設定，清掉敏感內容再發 |
| 使用者試用 | 有任務觀察紀錄，含使用者原話與卡點位置 | 約不到目標使用者時，先驗證「使用者是誰」這個更根本的假設 |
| 停損判斷 | 你說得出原型驗證了什麼、沒驗證什麼、下一步是什麼 | 把這三句話寫下來——它們才是週末真正的產出 |
常見踩坑
- 第一輪就想塞進全部願景：工具會產出一個樣樣都有的四不像，之後改一處壞三處。規格裡「必須有最多三項」就是為了擋這件事。
- 無盡調整視覺：原型驗證的是價值，不是美感。每次想調顏色時，把衝動寫進「明確不做」清單，週末結束前不準碰。
- 捨不得重來：結構錯掉時，重開一個專案通常比修補快。沉沒成本是原型週末最大的敵人。
- 拿原型當正式產品營運：讓真實使用者存真實資料、不做備份與安全加固，出事只是時間問題。驗證結束就讓它功成身退。
- 只聽好話：客氣的稱讚沒有資訊量，有價值的是卡點與原話。聽到「還不錯」要追問「你剛剛卡在哪裡」。
- 規格沒寫就直接生成：等於把產品決策外包給模型的訓練資料，產出的是「平均同類產品」，不是你的想法。
下一步
- 原型驗證出價值，下一步讓業務流程真正跑起來：把既有 SaaS 用 n8n 串成一條流程
- 想系統性地比較這類工具：選 AI 工具的判斷框架
- 原型要長成正式程式碼、由 AI 輔助維護時：Claude Code 完全指南
- 要估正式版的預算：AI 成本怎麼算
- 第一次接觸 AI 工作流，從這裡起手：不寫程式做出你的第一個 AI 工作流