MVP Builder

MVP 构建器

1-2 周内交付 MVP，而不是几个月。

核心原则

从最小的着手，用它来验证或推翻你风险最高的假设。

MVP = 最小化可行产品，而不是最小化精美产品。

MVP 功能矩阵

使用此矩阵对每个功能想法进行分类：

类别	定义	操作
P0	核心价值主张必不可少的功能	立即构建
P1	很重要，但可以等到 v1.1	验证后发布
P2	锦上添花、能带来惊喜的功能	v2+ 发布
范围外	验证时不需要	无限期延期

示例：任务管理 MVP

P0（第 1 周）：

• 创建带标题/描述的任务
• 标记任务为已完成
• 查看任务列表
• 基本身份验证

P1（验证后）：

• 截止日期、优先级、提醒

P2（未来）：

• 团队协作、文件附件、移动应用

范围外：

• 甘特图、时间跟踪、集成

5 种 MVP 模式

1. 礼宾式 MVP

定义： 在构建自动化功能前，手动交付服务

适用场景： 核心价值在于服务交付，而非技术

示例：

• 外卖 → 通过 WhatsApp 接单，亲自配送
• AI 文案工具 → 手动为客户撰写文案
• 日程安排工具 → 通过电子邮件协调会议

时间： 1-3 天 | 验证： 人们是否需要这项服务

---

2. 绿野仙踪式 MVP

定义： 界面看起来是自动化的，但幕后由人工操作

适用场景： 自动化功能的构建成本高或复杂

示例：

• Zapier 早期 → 手动创建集成
• AI 聊天机器人 → 由真人回答，客户以为是 AI

时间： 1 周 | 验证： 用户是否会与界面互动

---

3. 落地页 MVP

定义： 介绍产品 + 收集电子邮件（产品尚未开发）

适用场景： 在开发任何东西之前测试需求

示例：

• Dropbox → 用视频展示概念
• Buffer → 代码尚不存在时先推出落地页

时间： 1-2 天 | 验证： 人们是否会注册加入候补名单

---

4. 单功能 MVP

定义： 用一个功能解决一个问题

适用场景： 一个功能就能提供 80% 的价值

示例：

• Twitter → 只发布 140 个字符的动态
• Instagram → 只分享带滤镜的照片
• Stripe → 只接受信用卡付款

时间： 1-2 周 | 验证： 人们是否会使用核心功能

---

5. 拼凑式 MVP

定义： 组合现有工具，而不是定制开发

适用场景： 可以用现有工具拼凑出解决方案

示例：

• Typeform + Airtable + Zapier + Stripe
• 无代码工具：Webflow、Bubble、Retool

时间： 2-5 天 | 验证： 工作流能否端到端运行

技术栈决策树

Is this a web app?
├─ YES
│  ├─ Need real-time?
│  │  ├─ YES → Next.js + Supabase + WebSockets
│  │  └─ NO → Remix + PostgreSQL
│  └─ Simple CRUD? → Supabase + React
└─ NO
   ├─ Mobile app? → React Native + Expo
   ├─ API only? → Express + PostgreSQL
   ├─ Chrome extension? → Vanilla JS + Chrome APIs
   └─ CLI tool? → Node.js or Python

推荐的 MVP 技术栈：

• 前端： React + Vite 或 Next.js
• 后端： Supabase（Postgres + Auth + Storage）或 Express.js
• 样式： Tailwind CSS + shadcn/ui
• 托管： Vercel/Netlify（前端）+ Railway/Fly.io（后端）
• 身份验证： Clerk 或 Supabase Auth
• 支付： Stripe Checkout

注重速度的工具：

• Supabase（10 分钟搭建后端）
• Vercel v0（生成 UI）
• Clerk（5 分钟完成身份验证）
• Stripe Checkout（20 分钟接入支付）

应避免的反模式

❌ “以防万一”而构建功能 → 等到有 3 位以上用户提出需求时再构建
❌ 发布前追求完美设计 → 先交付可用版本，界面不美观也没关系
❌ 过度设计架构 → MVP 使用单体架构即可
❌ 自定义身份验证 → 使用 Clerk、Auth0 或 Supabase Auth
❌ 优先构建管理面板 → 使用数据库 GUI（Retool/Supabase）
❌ 先做移动应用再做 Web → 始终先做 Web
❌ 按 100 万用户的规模设计 → 先服务 10 位用户，按需扩展

MVP 质量标准

必须具备 ✅

• 核心功能可端到端运行
• 基本身份验证（登录／注册）
• 部署后不会崩溃
• 适配移动设备（不必精美）
• 基本错误处理

可以跳过 ⏸️

• 完美的 UI／UX
• 电子邮件通知
• 高级功能
• 分析仪表板
• 错误监控（验证后再添加）
• 测试（产品市场契合后再添加）

构建流程

第 1 周：构建核心功能

第 1–2 天：设计 + 设置

• 绘制 3 个页面草图（纸上／Figma）
• 设置代码仓库 + 数据库（最多 3–5 张表）
• 部署基础设施

第 3–4 天：构建

• 身份验证（使用库，不要自己开发）
• 核心功能（仅 1 条用户流程）
• 基本 UI（使用组件库）

第 5 天：完善 + 部署

• 修复严重错误
• 部署到生产环境
• 分享给 5 位朋友以征求反馈

第 2 周：验证

第 1–2 天：迭代

• 修复第 1 周反馈中提到的问题
• 添加 1–2 个缺失的关键功能

第 3–4 天：获取用户

• 在社交媒体上分享
• 在相关社群中发布
• 亲自给 20 个人发电子邮件

第 5 天：分析并决定

• 是否有 10 人以上注册？
• 是否有 3 人以上使用了 3 次以上？
• 是否有 1–2 人愿意付费？

决策点：

• ✅ 符合上述条件 → 构建 P1 功能
• ❌ 不符合 → 转型或终止项目

发布清单

发布前（1 小时）：

• 核心用户流程可端到端运行
• 注册 + 登录可正常使用
• 已通过 HTTPS 部署
• 隐私政策 + 服务条款（使用生成器）

发布当天：

• 在 Twitter／LinkedIn 上发布并附上截图
• 在 3–5 个相关社群中分享
• 亲自给 20 个人发电子邮件

发布后第 1 周：

• 回复每一条反馈
• 在 24 小时内修复严重错误
• 采访 3–5 位早期用户

成功指标

MVP 验证标准：

• 首周注册人数超过 10 人
• 3 人以上使用了 3 次以上
• 1–2 人愿意付费

**如果达到这些标准：**说明可能有发展潜力。构建 P1 功能。

**如果没有达到：**转型或继续寻找其他方向。不要在没人需要的东西上投入数月时间。

真实的 MVP 示例

成功的精简起步案例：

• **Airbnb：**公寓照片 + PayPal 链接
• **Stripe：**仅用一个表单收集银行卡信息
• **Dropbox：**先发布演示视频，再构建产品
• **Uber：**仅在旧金山推出 iPhone 应用
• **Facebook：**仅面向哈佛学生，提供基本个人资料

它们的起步规模都比你想象的要小得多。

相关资源

相关技能：

• product-strategist - 用于验证产品市场契合
• frontend-builder - 用于构建 UI
• api-designer - 用于后端 API 设计
• deployment-advisor - 用于部署决策
• go-to-market-planner - 用于制定发布策略

相关模式：

• META/DECISION-FRAMEWORK.md - 平台选择决策树

相关操作手册：

• PLAYBOOKS/build-mvp.md - 分步 MVP 构建流程（创建后提供）

快速参考

适用于有经验的用户：

• 找出风险最高的假设
• 选择 MVP 模式（礼宾式／向导式／落地页／单一功能／分阶段）
• 对功能分类（P0／P1／P2／范围外）
• 仅构建 P0（最多 1–2 周）
• 先发布外观粗糙但可用的产品
• 与 10 位以上用户验证
• 决定：构建 P1 还是转型