什麼是 MVP？最小可行產品淺白解說
MVP，即最小可行產品，係真正嘅人可以用嚟獲得真正價值嘅最細版本產品，而且建造出嚟，係為咗了解呢個構思值唔值得繼續。「最小」代表你剔除所有對核心工作並非必要嘅嘢；「可行」代表剩低嘅嘢對真正用戶嚟講確實可以用。重點唔係推出一樣便宜嘅嘢，而係喺你花幾個月去建造錯嘅嘢之前，先搞清楚人哋要咩。
呢個詞嘅來源同點解重要
呢個詞係由 Eric Ries 嘅《The Lean Startup》同更廣泛嘅精益創業運動推廣嘅。佢將建造產品視為一連串嘅實驗：建造一個細嘅嘢，量度人點樣使用佢，學習，然後調整。
用 AI 建造嘢嘅時候，MVP 嘅概念會變得更容易，亦都更重要。
- 更容易，因為而家建造一個可以運作嘅第一版，只需要幾日而唔係幾個月，成本亦低好多。
- 更重要，因為而家好容易想加更多功能。當每個新功能都只係一句提示之遙，懂得剔除嘢嘅紀律，先會令你嘅應用程式保持焦點，並令首批用戶嘅回饋清晰。
日常比喻
想像你想開一間餐廳。喺簽十年租約同裝修廚房之前，你先喺週末嘅街市擺一個有三款菜式嘅小食攤。
呢個攤檔好細，但並唔係假嘅。人哋畀真錢、食真嘅食物。經過幾個週末，你就會知道邊款菜會賣清、人哋願意俾幾多錢，以及佢哋會唔會再返嚟。噉就係 MVP。
一張你從未煮過嘅菜嘅相片就係原型。開幕之夜嘅完整餐廳就係成品。食物攤位就介乎兩者之間：夠真實，可以教曉你真正嘅嘢；夠細，錯咗都唔會災難性。
MVP、原型同其他術語
| 術語 | 係咩 | 邊個用 | 需唔需要真正運作？ |
|---|---|---|---|
| Mock-up（樣板圖） | 畫面可能會係點樣嘅一張圖片 | 你同你嘅團隊 | 唔需要 |
| Prototype（原型） | 可以點擊嘅模型，通常用假資料 | 你、少數測試者、投資者 | 部分需要 |
| Proof of concept（概念驗證） | 一個測試，證明某嘢喺技術上可行 | 你或者開發人員 | 只係最有風險嗰部分需要 |
| MVP | 最細、但可以提供價值嘅真實產品 | 真正嘅早期用戶或者客戶 | 需要 |
| MLP / MMP | 「最值得愛」或者「最適合推向市場」嘅產品——即係更加打磨嘅 MVP | 更廣泛嘅推廣對象 | 需要，而且要打磨過 |
| V1 | 你會廣泛推廣嘅第一個版本 | 大眾 | 需要 |
你仲會聽到嘅其他詞語：
- 核心循環（Core loop）——用戶反覆做嘅主要動作，例如「發佈職位、收到申請」。
- 最大風險假設（Riskiest assumption）——如果錯咗，就會令構思失敗嘅信念。你嘅 MVP 應該首先測試呢個。
- 驗證（Validation）——證明人哋想要並會使用（或付費）產品嘅證據。
- 反覆改進（Iteration）——根據所學，用小輪次去改善產品。
實例：一個遛狗預約應用程式嘅 MVP
你嘅構思：一個應用程式，讓本地嘅狗主可以預約經過審核嘅本地遛狗員。
你嘅最大風險假設可能係：「狗主會透過應用程式預約並付款俾一個陌生人。」而唔係「狗主想要一個即時 GPS 地圖顯示遛狗路線」。
完整願景包括：遛狗員個人檔案同評價、即時 GPS 追蹤、應用程式內聊天、訂閱、遛狗員付款、評分系統、推播通知、推薦計劃，以及遛狗員加入流程。
MVP：
| 包括 | 暫時剔除 |
|---|---|
| 一份你親自審核過嘅遛狗員清單，有相片、地區同收費 | 遛狗員自行註冊同審核流程 |
| 一個預約表格：狗隻、日期、時段、地址 | 定期訂閱 |
| 喺預約時用代管結賬付款 | 自動向遛狗員付款（你手動付） |
| 發給狗主同遛狗員嘅確認電郵 | 推播通知 |
| 一個簡單嘅管理頁面，讓你睇到所有預約 | 即時 GPS、應用程式內聊天、評價 |
你可以喺一個社區度行一個月。如果狗主重複預約，你就學到咗值得繼續發展嘅嘢。如果佢哋唔預約，你就用較低成本搵出問題，並可以問吓佢哋點解。
留意到有啲「剔除」嘅項目係用人手完成嘅。手動付款畀遛狗員，或者自己審核佢哋，唔係可以擴展嘅做法，但暫時唔需要改。喺一個簡單應用程式背後用人手做嘢，係最有效嘅 MVP 技巧之一。
常見錯誤同誤解
- 「最小」變成「壞咗」。 一個會搞丟預約或者睇落唔可信嘅 MVP，測試嘅係你嘅錯誤，而唔係你嘅構思。要保持細，但嘅嘢要做到運作。
- 為「所有人」而建造。 為「任何需要 X 嘅人」而做嘅 MVP 好難測試。要揀一個你接觸得到嘅特定用戶群。
- 加功能，而唔係同用戶傾偈。 當早期數字令人失望，解決方法很少係再加一個功能。要問用戶係乜嘢令佢哋卻步。
- 跳過真正嘅測試。 候補名單報名顯示興趣；付款或者重複使用先至顯示價值。要預先決定邊個結果先算成功。
- 將 MVP 當成用完即棄。 用 AI 建造工具，MVP 嘅代碼經常會變成真正嘅產品。要用一個正式嘅資料庫同正確嘅登入功能去建造，咁就唔使重頭開始。
- 永遠做唔完。 要定好一個上線日期，然後砍功能去趕上，而唔係反過嚟。
用 AI 去界定 MVP 範圍
- 寫一句話。「[邊個] 可以 [做咩]，令 [結果]。」例如：「利茲嘅狗主可以為聽日預約一個經過審核嘅遛狗員，好令佢哋唔使請假。」
- 列出你想到嘅每個功能。 將腦海中所有嘢都寫出嚟。
- 為每個功能標示「測試構思所需」或者「之後再做」。 要嚴格。大部分都應該放入「之後再做」。
- 決定邊啲嘢你會用人手去做。 付款、加入流程、支援。
- 定義成功。「4 星期內有 20 個付費預約」係可以測試嘅。「人哋會鍾意」就唔係。
- 建造、俾一小群人試用，然後觀察。 之後再反覆改進。
想要更深入、逐步嘅幫助，可以睇點樣驗證應用程式構思同點樣建造 SaaS MVP。
要求你嘅 AI 建造工具做咩
- 「呢個係我嘅構思同我嘅最大風險假設。建議一個可以測試佢嘅最細版本，並列出要剔除嘅嘢。」
- 「只建造呢五個功能。未經我同意，唔好加任何其他嘢。」
- 「由一開始就用真正嘅資料庫同正式嘅登入功能，咁呢個應用程式先可以發展成真正嘅產品。」
- 「加一個簡單嘅管理頁面，讓我可以睇到每個預約，並可以手動處理嘢。」
- 「加入基本分析或者事件紀錄，讓我可以睇到有幾多人完成咗預約。」
- 「上線之前，檢查有冇明顯嘅安全問題：邊個可以睇邊啲紀錄，以及有冇任何金鑰外洩。」
用 Mythex 建造 MVP
Mythex 好適合用嚟建造 MVP：你喺聊天入面描述第一個版本，喺即時預覽入面試用，準備好就發佈去一個公開網址——需要時亦可以加入 Postgres 資料庫同檔案儲存。Plan 模式對界定範圍好有用：要求 agent 喺寫任何代碼之前，先提出一個最小版本。免費計劃包括發佈功能，所以你可以喺付費之前將 MVP 放喺用戶面前；Pro 則加入自訂網域、代碼匯出同 GitHub 同步，供構思開始見效時使用——見價格。Docs 有一個 SaaS MVP 教學；當你準備好搵用戶時，可以睇點樣推出應用程式並獲得首批用戶。
常見問題
MVP 係咩嘢嘅縮寫？
MVP 係 minimum viable product 嘅縮寫，即最小可行產品：產品最細嘅版本，真實用戶可以用嚟獲得真正嘅價值，並且被建造出嚟，等你可以了解呢個構思是否值得繼續。
MVP 同原型（prototype）有咩分別？
原型係展示某嘢可能會點樣睇落或者點樣運作，通常用假資料，用嚟喺內部或者同少數人一齊測試構思。MVP 則係俾真正客戶用嚟做真正嘅事，所以必須真正運作——要儲存資料、發送電郵、收取付款。
建造一個 MVP 應該要幾耐？
冇固定嘅規則，但係所花時間越長，就越有可能超出咗最細嘅範圍。用 AI 應用程式建造工具，一個專注嘅簡單工具 MVP 通常幾日就可以運作，而唔係幾個月。目標係盡快俾用戶試用。
MVP 應該有幾多個功能？
越少越好，只要足夠為用戶帶來他們最在乎嘅那一個結果。好多好嘅 MVP 只做一件工作，由頭做到尾。任何唔幫到測試你主要假設嘅嘢，都可以等。