MVP 設計：砍到不能再砍
本篇是「一個人做產品」系列的第 4 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
為什麼你的 side project 死在 MVP 之前？
讓我猜猜看。
你在第 2 章驗證了點子、第 3 章選好了技術棧，興奮地打開編輯器開始動手。第一個週末完成了登入功能，第二個週末做了 CRUD，第三個週末你開始覺得「應該加一個 Dashboard」……
然後你的 TODO list 開始膨脹：
- 用戶 Dashboard
- 通知系統
- 多語言支援
- 深色模式
- 匯出 CSV
- API 文件
- 管理後台
- 數據分析
- ……
三個月後，沒有一個功能是「完成」的狀態。每個功能都做了 70%，每個都差一點點。但就是沒辦法上線。
這個殺手有個名字：功能蔓延（Feature Creep）。
功能蔓延不是因為你太貪心。而是因為你太有能力——你知道怎麼做這些功能，所以你覺得「加一個也不會花多少時間」。但一個功能不只是寫完程式碼而已，它還包括測試、debug、維護、文件。每多一個功能，你的維護負擔就多一份。
對有正職的 Solo Builder 來說，功能蔓延是最致命的。因為你每週只有 5-10 小時，分散到十個功能上，每個功能一週只推進 30 分鐘。這個進度慢到你自己都受不了，然後就放棄了。
這一章的目的很簡單：教你砍功能。砍到不能再砍。
MVP 不是「爛版本」
先釐清一個超常見的誤解。
MVP（Minimum Viable Product，最小可行產品）不是「功能很少的爛版本」。不是把所有功能都做了但每個都做得很粗糙。
MVP 的定義是：用最少的功能，驗證一個最關鍵的假設。
關鍵字是「一個假設」。
你的產品一定有很多假設：用戶願意付費嗎？他們會每天使用嗎？他們能理解操作流程嗎？註冊轉換率會是多少？
但 MVP 只挑其中最重要、最不確定的那一個來驗證。
傳統做法
列出所有你想做的功能，全部一起做，然後上線看看反應。如果反應不好，你不知道是哪裡出了問題——是功能不對？價格太高？UI 太醜？行銷沒做好？因為你一次改了太多變數，無法分離原因。
AI 加持做法
用 AI 幫你釐清假設、排優先順序、設計最精簡的功能集。把「我覺得用戶需要什麼」轉變成「我要驗證用戶是否需要 X」。
「一個假設」框架
這是我自己用的框架，極其簡單：
第一步：列出你對這個產品的所有假設
打開你的 AI 助手：
我正在做一個 [產品描述]，目標用戶是 [用戶描述]。
請幫我列出這個產品的所有核心假設，包括：
1. 需求假設（用戶真的有這個問題嗎？）
2. 解決方案假設（我的方案能解決這個問題嗎？）
3. 商業假設（用戶願意為此付費嗎？）
4. 行為假設（用戶會怎麼使用？多常使用？）
5. 成長假設（用戶會推薦給別人嗎？）
每個假設請標示「確定性」（高/中/低）和「影響性」（高/中/低）。第二步：找出最高風險的假設
在 AI 的回覆中，找出「確定性低 + 影響性高」的那個假設。這就是你 MVP 要驗證的東西。
| 影響性高 | 影響性低 | |
|---|---|---|
| 確定性低 | MVP 要驗證這個 | 之後再說 |
| 確定性高 | 已驗證，安心做 | 不重要 |
第三步：設計只驗證那一個假設的功能集
然後問 AI：
我的 MVP 要驗證的核心假設是：[你的假設]
請幫我設計一個最精簡的功能集，只包含驗證這個假設所需的最少功能。
每個功能請標示：
- 必要（沒有這個就無法驗證假設）
- 有用（讓驗證更可靠，但不是必須）
- 多餘（不影響假設驗證）
「多餘」的功能全部砍掉。「有用」的功能存起來，MVP 之後再做。
只保留「必要」的功能。這就是你的 MVP 功能清單。通常只會有 3-5 個功能。是的，就這麼少。
AI 輔助的功能優先排序
如果你發現你的「必要」功能還是太多，或者你不確定哪個該先做，可以用兩個經典的排序方法。AI 特別擅長幫你跑這些框架。
方法 1：RICE 評分
RICE 是 Intercom 發明的優先排序框架，四個維度都用數字評分：
| 維度 | 說明 | 評分方式 |
|---|---|---|
| Reach（觸及） | 這個功能會影響多少用戶？ | 預估人數 |
| Impact（影響） | 對單個用戶的影響有多大？ | 0.25 / 0.5 / 1 / 2 / 3 |
| Confidence（信心） | 你對以上估計有多少信心？ | 50% / 80% / 100% |
| Effort（工時） | 需要花多少人月？ | 對 Solo Builder 用「小時」更實際 |
RICE 分數 = (R × I × C) / E
分數越高，優先順序越高。
用 AI 跑 RICE 的 prompt：
以下是我的產品功能清單：
1. [功能 A]
2. [功能 B]
3. [功能 C]
4. [功能 D]
5. [功能 E]
產品描述：[簡短描述]
目標用戶：[描述]
我的時間預算：每週 8 小時
請幫每個功能做 RICE 評分，考量以下背景：
- 這是一個人的 side project，不是公司產品
- 開發時間用「小時」而非「人月」
- Reach 用「前 100 個用戶中有多少人會用到」
最後按 RICE 分數排序，並給出你的建議。方法 2：MoSCoW 分類
如果你覺得 RICE 太數字化，MoSCoW 更直覺：
| 分類 | 含義 | MVP 處理方式 |
|---|---|---|
| Must have | 沒有就不能上線 | 一定做 |
| Should have | 很重要但可以後補 | MVP 後第一輪加上 |
| Could have | 有了更好，沒有也行 | 放到 backlog |
| Won’t have (this time) | 這次不做 | 直接刪掉 |
重點在那個 “Won’t have”。你的 Won’t have 清單應該比 Must have 清單長至少三倍。
如果你發現自己什麼都分到 Must have，那你還不夠狠。回去重新分類，問自己：「如果這個功能沒有，真的不能上線嗎？還是只是我覺得不完整？」
功能砍殺清單
這是我的經驗法則。以下功能在 MVP 階段幾乎都不需要：
| 功能 | 為什麼不需要 | 替代方案 |
|---|---|---|
| 使用者註冊/登入 | 用 magic link 或第三方登入 | Clerk / Better Auth |
| 管理後台 | 直接改資料庫 | 用 Drizzle Studio 或 D1 Console |
| 通知系統 | 手動發 email | 先不做，或用 Resend |
| 多語言 | MVP 只需要一種語言 | 只做你的目標市場語言 |
| 深色模式 | 不影響核心價值驗證 | 上線後再加 |
| 付費功能 | 先驗證需求，再談收錢 | 先全部免費 |
| 數據分析 Dashboard | 你自己看 GA 就夠了 | Google Analytics |
| 匯出/匯入 | MVP 階段資料量不大 | 手動處理 |
| API | 除非你的產品就是 API | 先不對外開放 |
| 完美的 Error Handling | 用戶量小，你手動處理 | console.log + 手動修 |
看到這個清單，你可能會覺得：「那 MVP 也太陽春了吧？」
沒錯。MVP 就是要很陽春。它的目的不是讓用戶覺得產品好棒，而是讓你確認「有人願意用這個核心功能」。
為一個人設計 User Story
在大公司，User Story 是寫給整個開發團隊看的。但 Solo Builder 的 User Story 是寫給自己和 AI 的。
格式可以更精簡：
作為 [用戶類型]
我想要 [做某件事]
這樣我就能 [得到的好處]
驗收標準：
- [ ] [具體可測試的條件 1]
- [ ] [具體可測試的條件 2]
估計工時：X 小時讓 AI 幫你把功能清單轉成 User Story：
以下是我 MVP 的功能清單：
1. [功能 A]
2. [功能 B]
3. [功能 C]
目標用戶：[描述]
產品目的：[一句話]
請幫我把每個功能寫成 User Story，格式如下：
- 作為 / 我想要 / 這樣我就能
- 驗收標準（2-3 條，具體可測試）
- 估計工時（假設使用 AI 輔助開發，熟練的開發者）
注意：這是一個人的 side project，User Story 要精簡實用，
不需要企業級的詳細度。User Story 的好處是，它讓你清楚知道「做完」長什麼樣。沒有 User Story 的時候，一個功能可以無限延伸。有了驗收標準，你可以明確地說：「OK，這個功能做完了，下一個。」
真實案例：cloud-on-academy 的 MVP
讓我用自己的真實案例來示範這套方法。
我想做 cloud-on-academy，一個 GCP 認證的中文課程平台。在第 2 章我已經驗證了市場存在。現在要設計 MVP。
我的假設清單：
- 繁中市場的工程師願意為 GCP 認證課程付費（需求假設）
- 文字 + 圖文教學的形式就夠用，不需要影片（解決方案假設）
- 用戶會從頭到尾看完一個系列（行為假設）
- 考過認證的用戶會推薦給同事（成長假設）
最高風險的假設：
假設 2——文字教學就夠用嗎？這個最不確定。如果用戶一定要影片，我一個人做影片的時間成本會高很多。
MVP 要驗證的就是這件事。
砍功能的過程：
| 功能 | MoSCoW | 理由 |
|---|---|---|
| 課程文章展示 | Must have | 沒有內容就沒有產品 |
| 章節導覽 | Must have | 用戶需要知道在哪裡 |
| 閱讀進度追蹤 | Should have | 有用但不影響核心驗證 |
| 用戶註冊 | Should have | 先不需要，開放閱讀 |
| 付費牆 | Won’t have | 先驗證需求，再談收錢 |
| 討論區 | Won’t have | 用 Discord 或 GitHub Issues 替代 |
| 認證模擬題 | Won’t have | 第二階段再加 |
| 管理後台 | Won’t have | 用 Git + Markdown 管理 |
| 深色模式 | Could have | 不影響核心體驗 |
| 搜尋功能 | Could have | 初期內容少，不需要搜尋 |
最終 MVP 功能：2 個 Must have。
就這樣。一個能展示課程文章的網站，加上章節導覽。用 Astro 做靜態網站、Markdown 寫內容、部署到 Cloudflare Pages。
整個 MVP，兩個週末就完成了。
上線之後，我觀察到用戶確實會從頭到尾讀完一個系列，而且在 Discord 頻道上的回饋是「文字教學比影片更好搜尋、更好重看」。假設 2 驗證通過。
然後我才開始加其他功能。
時間預算：2-3 個週末完成 MVP
上班族的時間預算很明確。假設每個週末能投入 8 小時，2-3 個週末就是 16-24 小時。
這是你的 MVP 開發時間上限。如果估出來超過 24 小時，代表你的功能還太多，回去繼續砍。
AI 加持的時間估算
以下是我 MVP 的 User Story（附工時估計）：
[貼上前一步生成的 User Story]
我的開發環境：
- 技術棧：[你的選擇]
- AI 工具：Claude Code + Copilot
- 開發經驗：[你的程度]
- 每週可用時間：8 小時（週末）
請幫我：
1. 檢查工時估計是否合理（考慮 AI 輔助）
2. 安排到 2-3 個週末的開發計畫
3. 每個週末的目標和交付物
4. 如果超過 24 小時，建議砍掉哪些功能一個典型的 2 週末計畫長這樣：
| 週末 | 目標 | 產出 | 預估工時 |
|---|---|---|---|
| 週末 1（Day 1） | 專案初始化 + 核心功能 A | 可以跑的 prototype | 8 小時 |
| 週末 1（Day 2） | 核心功能 B + 基本 UI | 可以用的 MVP | 8 小時 |
| 週末 2（Day 1） | 部署 + 修 bug | 上線的產品 | 6 小時 |
| 週末 2（Day 2） | 寫 Landing Page + 分享 | 第一批用戶 | 2 小時 |
注意最後一天只留 2 小時——因為你需要預留 buffer。開發永遠比預期慢，但 deadline 不會等你。
如果超時怎麼辦？
如果週末 1 結束時進度落後了，不要加班趕工。停下來問自己：
- 是哪個功能花的時間比預期多？
- 那個功能可以簡化嗎？
- 有沒有哪個「必要」功能其實可以降級為「有用」？
然後繼續砍。永遠是砍功能，不是加時間。
常見的 MVP 設計陷阱
陷阱 1：「這個功能很簡單，加一下不會怎樣」
每個功能都很簡單。但十個簡單的功能加在一起就不簡單了。
每次你想加功能的時候，問自己：「如果這個功能不做，用戶是完全不能用這個產品，還是只是不太方便？」
如果答案是「不太方便」，那就不做。
陷阱 2：把 MVP 做成 Demo
MVP 是要給真實用戶用的，不是 demo。Demo 可以用假資料、hardcode 的流程。MVP 不行——它必須能讓用戶完成一個完整的使用流程，即使這個流程很簡陋。
陷阱 3：「等我加完這個就上線」
這句話你已經說了三次了。
設一個死線。不是「功能做完的時候上線」，而是「這個日期不管如何一定上線」。到了那天，不管功能完成度如何，push to production。
如果你的 MVP 設計得夠精簡，你會發現：即使有些功能只完成 80%，產品依然能用。而那 20% 的差距，你可以在上線後根據用戶回饋來補。
陷阱 4：不好意思讓別人看到不完美的產品
Reid Hoffman（LinkedIn 創辦人）說過一句經典的話：
If you’re not embarrassed by the first version of your product, you’ve launched too late. 如果你的第一版產品沒有讓你覺得丟臉，那你上線得太晚了。
你的 MVP 應該讓你有點不好意思。那代表你沒有過度打磨，把時間花在了正確的地方——驗證假設。
本章重點回顧
- 🎯 MVP 不是爛版本，而是「用最少功能驗證最關鍵假設」
- 🔪 用「一個假設」框架：列出假設 → 找最高風險的 → 只為那一個設計功能
- 📊 RICE 評分和 MoSCoW 分類，配合 AI 可以在 30 分鐘內完成功能排序
- 📋 你的 Won’t have 清單應該比 Must have 長三倍
- ⏱️ MVP 開發時間上限：2-3 個週末（16-24 小時），超過就砍功能
- 🚀 設定死線，不管如何到日期就上線
下一步
功能砍好了，MVP 設計好了。
下一章，我們進入這本書最核心的部分：怎麼用 AI 來開發。
不是那種「叫 AI 幫你寫一段 code」的用法——而是建造一整套 AI 開發系統，讓 AI 成為你的開發團隊。從 Vibe Coding 到 Agentic Workflow，一個人也能有三人團隊的產出。
