AI Product Management · Prototyping
PM 的最小 prototype 流程
「PPT 看完工程師說：好，我們先估個 2 個月。」
「但給他看一個能跑的 demo，他說：噢，這個其實一週就能做。」
過去半年我教身邊的 PM 做 prototype，最大的感觸就是上面這句。PPT prototype 跟「能跑的 demo」是兩個世界。
PPT 解釋不清楚的設計細節，丟給工程師時會被各種反問。
能跑的 demo 一秒讓對方意會：「啊，你說的這個體驗是長這樣。」
下面用一個我前幾週剛做完的 demo 當主線：「FAQ 摘要小工具」。需求：使用者貼上一段客服對話，工具自動摘要成 FAQ 候選項。半天做完。
今天想聊的，是 PM 自己 ship demo 的最短路徑：
① PM 不寫 code，半天能 ship 一個能跑的 demo 嗎？
② v0、Cursor、Vercel 怎麼搭配，才是最短路徑？
③ Demo 做完，怎麼把接力棒交給工程團隊？
從這個 FAQ 摘要小工具看完整流程
場景：你想驗證一個假設：「客服對話可以自動轉成 FAQ 草稿，減少 IT 部門每月寫 FAQ 的時間」。半天時間，從零做到 ship。
五個步驟的最小流程
| 步驟 | 工具 | 產出 | 大約時間 |
|---|---|---|---|
| 1. 概念寫清楚 | Claude（純對話） | 一份 1 頁的 spec | 20 分鐘 |
| 2. 用 AI 畫 UI 草稿 | v0 / Lovable / Bolt | 可互動的單頁 | 30 分鐘 |
| 3. 接真 AI 邏輯 | Cursor + Claude API | 後端 API 串接 | 1.5 小時 |
| 4. 部署 | Vercel | 公開連結 | 15 分鐘 |
| 5. 驗證 + 截圖 | 自己 + 3 個朋友 | feedback 清單 | 1 小時 |
總時間：3.5 至 4 小時。一個下午就能從零做出能投給朋友試用的東西。
Step 1：概念寫清楚
打開 Claude，用對話把這個 FAQ 摘要小工具要驗證的問題講清楚。
給 Claude 的 Prompt 範例
我想做一個 prototype 驗證一個假設：「客服對話可以自動轉成 FAQ 草稿。」
>
請扮演產品經理教練，問我下面這些問題，逐題回答： 1. 這個 prototype 要解決什麼具體痛點？ 2. 第一次打開的使用者，第一眼會看到什麼？ 3. 「成功」長什麼樣？使用者做完哪個動作，我會覺得驗證成功？ 4. 必須有什麼功能？什麼功能可以先假裝（hardcode）？ 5. 失敗時要怎麼接？
>
問完後請濃縮成一份 1 頁 spec。
為什麼這步不能省
v0 和 Lovable 的產出品質，95% 取決於 Prompt 品質。Prompt 模糊，產出就模糊。
我看過太多人跳過這步，直接打開 v0 開始 prompt，做出來的東西既不像 prototype 也不像產品。20 分鐘的對話可以省下 2 小時的迭代地獄。
Step 1 的產出
一份 1 頁 spec，包含：
- 假設（這個 FAQ 摘要工具要驗證的事）
- 第一畫面（一個大文字框 + 「摘要」按鈕）
- 成功定義（使用者貼上對話、按下按鈕、看到三個 FAQ 候選項並標記哪個有用）
- 必須項 vs 可假裝項（摘要邏輯必須真、登入可假裝、儲存可省略）
- 失敗策略（如果 AI 摘要不出東西，顯示「請貼上更長的對話」）
這份 spec 等下會貼進 v0 當 Prompt 用。
Step 2：用 AI 畫 UI
打開 v0，把 Step 1 的 spec 貼進去，加一句：
請產出一個現代、簡潔的單頁應用，使用 Tailwind CSS。色系：低彩度暖色。風格參考：Linear 的設計感。
第一次產出大概 70 分。接下來用對話迭代
| 想改 | 怎麼說 |
|---|---|
| 文字框太小 | 「主輸入框請放大兩倍，加 placeholder：『把客服對話貼進來』」 |
| 缺 loading | 「點擊『摘要』按鈕後請顯示 loading 狀態 3 秒」 |
| 三個候選項排版不對 | 「候選 FAQ 請用 card layout，每張卡片右上角加一個『有用』按鈕」 |
| 配色不對 | 「請換成低彩度暖色系，主色 #C5A55A」 |
工具選擇對照
| 工具 | 強項 | 適合場景 |
|---|---|---|
| v0（Vercel） | UI 美感、React 產出 | 想直接接後端的 demo |
| Lovable | 全棧、含資料庫 | 需要登入、資料保存的 demo |
| Bolt | 速度快 | 純前端驗證概念 |
| Claude Artifacts | 對話內即可預覽 | 最小最快的快速驗證 |
我自己 80% 時間用 v0，因為它的產出最容易接續到 Cursor。
Step 2 的產出
一個「可點擊但邏輯是假的」demo。所有摘要結果都用 mock data，但 UX flow 完整。
Step 3：接真 AI 邏輯
把 v0 產出的程式碼匯出到本機，用 Cursor 打開。
給 Cursor 的指令
我要把點擊「摘要」按鈕的邏輯，改成呼叫 Claude API。使用者貼上的客服對話送到 API、回傳的三個 FAQ 候選項顯示在卡片區。請： 1. 建立/api/summarize路由 2. 加入錯誤處理（API key 錯誤、超時、空輸入） 3. 加上 loading 狀態與骨架屏 4. API key 從.env.local讀取，不要 hardcode
Cursor 會幫你產出 API 路由、處理錯誤、加 loading 狀態。你的工作不是寫 code，是看懂並驗收。
驗收清單
- [ ] API key 沒有寫死在 code 裡
- [ ] 錯誤情境（網路斷、空輸入、API 限額）有 fallback
- [ ] Loading 狀態看起來不像當掉
- [ ] 沒有 console.log 留在 production code 裡
一個值得記下的學習
第一次做 demo 我把 API key 寫進 React 元件，結果 deploy 之後任何人打開 devtools 都能看到我的 key。API key 一定要走後端 route，前端永遠不該看到。Cursor 通常會幫你做對，但你還是要驗收。
Step 4：部署
Cursor 裡 git push 到 GitHub，然後 Vercel 連 repo，幾分鐘內就有公開連結。
部署 checklist
| 項目 | 怎麼做 |
|---|---|
| 環境變數 | Vercel dashboard 設定，不要寫進 code |
| 自訂網域 | 用 demo.yourname.com 之類的，比 vercel.app 專業 |
| 訪問權限 | 如果是內部 demo，加 Vercel password 保護 |
| 監控 | 開 Vercel Analytics（免費版就夠用） |
一個小技巧
在頁面右下角加一個小小的 feedback widget（用 Cal.com 或 Tally 都行），讓試用的人直接留 comment。比 Email / Slack 傳訊息可愛得多，回收率高 3 倍。
Step 5：丟給 3 個朋友驗證
公開連結傳給三個目標 user（這次的 FAQ 摘要工具，我傳給三個我認識的客服主管），請他們：
- 不要問你問題，直接點點看
- 你在旁邊默默看（用 Loom 錄屏更好）
- 結束後問他們：「你以為這是要做什麼的？」
三個關鍵問題
- 你第一眼覺得這是要做什麼？（驗證初印象）
- 你第一個想點的東西是什麼？（驗證視覺動線）
- 你最困惑的一刻是哪一刻？（找痛點）
怎麼判斷
| 觀察 | 含義 |
|---|---|
| 三個人講出來的「以為」一致 | 概念清楚，可以往下做 |
| 三個人講出來的「以為」都不同 | 回到 Step 1 重來，概念還不夠收斂 |
| 點對動線、做對流程 | UX 設計成立 |
| 卡在某個固定畫面 | 那一畫面要重新設計 |
反過來看：能 ship 的 PM 也有要留意的地方
到這裡你大概看到一個流程：spec、UI、邏輯、部署、驗證。半天 ship 一個 demo。
但我觀察到一些 PM 學會這套之後，反而變得「什麼都自己做」，把 demo 做到接近產品的程度，工程師完全沒參與。後來真正要 ship 時，工程師覺得這不是他的孩子，maintain 起來綁手綁腳。
| 該自己 ship 的 | 該交回工程師的 |
|---|---|
| 驗證概念的 prototype | 進入 GA 前的工程化重寫 |
| 給目標 user 試用的 demo | 接公司 infra、登入、權限的版本 |
| 跟設計師討論用的視覺草稿 | 上 production 前的安全審查 |
自己 ship 是為了讓需求變具體，不是為了取代工程團隊。 概念驗證完，要把接力棒交給工程師，並且坦白告訴他們「這只是 prototype，不是 production-ready code」。
漂亮的 AI PM 不是那個「自己做完所有東西」的人，是那個讓工程師覺得『跟這個 PM 合作好做產品』的人。
寫在最後
過去十年，PM 跟工程師最大的張力是：「PM 講的需求，工程師覺得 PM 自己根本不知道要做什麼。」
現在你有了一個低成本的方式（半天時間、自己 ship 一個能跑的 demo）把「我要做什麼」從抽象變具體。
工程師討厭的不是改需求，是「需求本身想不清楚」。這個工具鏈，就是 PM 把需求想清楚的最短路徑。
挑一個你最近想驗證的假設，週末撥 4 小時試試看。從 PPT PM 變 demo PM 的距離，比你想像中近得多。
你最近一個月有沒有遇到「跟工程師講不清楚」的需求？如果有，那就是你下一個 demo 的素材。
如果這篇對你有幫助，歡迎追蹤這份 Newsletter。每兩週一篇 AI PM 實戰筆記，主題涵蓋產品策略、跨職能合作、與 AI 導入的真實節奏。
#AIPM #ProductManagement #Prototyping #AI工具 #ProductStrategy #v0 #Cursor