在短週期驗證（Prototype）流程中，重點不是把所有功能一次過做齊，而是識別出「最小可行實驗」（MVP）能否證明核心商業假設。對於以網站、WhatsApp 或實體掃碼為入口，並以 AI 自動化處理查詢與後續跟進的系統，建議先把驗證範圍限定為幾個可量化指標與代表性使用場景，並設定明確的判定標準，避免在 Demo 階段投入過多開發成本。
文章重點
本文按型態拆解 MVP 功能清單、關鍵商業指標（KBI）、每項測試的最小樣本量與接受門檻，並列出常見樣本場景與注意事項，方便產品經理、業務線負責人與技術團隊在決策會議時快速判斷是否擴充或終止專案。
Prototype 最小可行測試清單（示例）
| 項目 | 建議做法 | 注意事項 |
|---|---|---|
| 入口事件追蹤 | 設定並追蹤網站表單、WhatsApp 點擊、QR/NFC 掃碼等三類入口的事件紀錄。 | 確保事件含來源標籤與時間戳。 |
| 查詢到跟進率 | 紀錄被視為有效線索的判定標準（如填寫聯絡資料或要求報價），計算比率。 | 需先定義『有效線索』的條件，避免標準變動。 |
| NLU/意圖辨識準確度 | 以混淆矩陣計算意圖分類的精確度、召回率與 F1。 | 樣本需涵蓋常見錯誤表述與方言變體。 |
| 首次回應時間（First Response Time） | 量測從用戶觸發到系統回應的中位數與 95 百分位。 | 含第三方 API 延遲與系統排隊情況。 |
| 推薦/轉換效果（若有推薦引擎） | A/B 測試推薦版本，觀察點擊率與最終轉換率差異。 | 樣本分配需隨機且樣本量足以檢測差異。 |
| 客戶滿意度（簡短 NPS/CSAT） | 在互動結束後彈出一問卷，收集簡短評分與關鍵回饋。 | 避免過度打擾，回收率可能影響代表性。 |
常見問題
Prototype 測試要持續多久才有意義？
依指標不同而異。對於轉換率或查詢到跟進率等行為類指標，建議至少收集 200—500 次入口事件；對於語音或 NLU 準確度則以 200 個多樣化樣本為基準。若流量不足，可採分階段延長或以模擬流量輔助驗證，但需在報告中註明限制。
如何設定「可接受」的 KBI 門檻？
先回到商業目標：如每月需新增 50 個有效線索，反推所需的查詢量與轉換率。可把門檻分為「保守可接受」「目標」與「理想」，並結合單位經濟（CAC、ARPU）做決策。門檻數值若無既有資料，建議以行業或內部類似專案做參考，否則標記為待補資料並以敏感性分析判斷風險。
Demo 階段能否直接用人工輔助（Wizard of Oz）？
可以。人工輔助能在早期快速驗證用戶流程與商業假設，尤其在語音理解或推薦邏輯尚未穩定時。但需在實驗設計中明確標註哪些回應為人工處理，並在後續評估中分離人工與自動結果的效能數據。