如何构建 MVP（How to Build MVP）

使用场景

YC 核心原则

  1. 先证明需求，再构建完整产品：DoorDash 四位斯坦福工程师用一个下午搭建原型（Google Form + Find My Friends）就验证了需求。最难证明的不是技术，而是人们到底想不想要这个。（来源：20240530-Startup-Experts-Discuss-Doing-Things-That-Dont-Scale）

  2. 构建的是「最小可演化产品」而非传统 MVP：第一版产品不应只是最小可行产品，而应是最小可演化产品（Minimum Evolvable Product）——足够简单以应对市场压力，并能根据早期用户的推动快速适应和演化为更成熟产品。知道产品会改变很多是一种解脱——它不需要从一开始就完美。（来源：20260114-How-To-Get-Your-First-Users）

  3. 做不可扩展的事——先杀掉眼前的龙：在任何一个时刻，担心你最大的问题。对大多数创业公司而言，最大的问题是从零到一：获得第一个客户，构建第一个产品。如果幸运到有足够多人想要你的产品，那时才有资格担心扩展性。创始人面对面时间是小公司对抗大公司的终极武器。（来源：20240530）

  4. 学习速度 > 产品完整性：Fleek 三人团队扛箱子在伦敦街头卖二手服装四个月来学习定价和需求弹性。任何能优化学习的事都值得做。做不可扩展的事，主要目标是——今天能学到多少，而不是等到开发完一切之后。（来源：20240530）

  5. AI 正在降低 MVP 构建门槛：Vibe Coding 让非技术创始人也能快速构建可工作原型。核心原则是让 LLM 遵循专业软件工程师的工作流程——从写计划、版本控制、测试驱动到模块化架构、频繁重构。（来源：20250425-How-To-Get-The-Most-Out-Of-Vibe-Coding）

  6. 尽早交付、快速迭代、不怕流失：快速实验定价、落地页、引导流程、功能——不怕流失，因为「你对抗的是无关紧要，而非头条新闻。」创业公司的优势是运行糟糕实验时没有人写文章报道。（来源：20260114）

分步骤做法

第一步：确定「最小可演化产品」的核心

核心问题不是「能构建什么」，而是「需要验证什么」。你的第一版产品只需做一件事：在与一小群可能真正尝试它的人接触后存活下来。

产品演化是路径依赖的——早期用户的选择会决定产品的最终形态。因此慎重选择第一批用户，并理解他们真正在乎什么。

第二步：选择构建路径

路径 A：极简非技术原型（0-2 天）

如果你需要验证的是「人们是否想要这个」，而非「技术是否可行」：

（来源：20240530）

路径 B：Vibe Coding——AI 辅助编程（适合有/无编程经验）

第一步是写计划，而非写代码：
1. 与 LLM 协作撰写详尽的项目计划，保存为 Markdown 文件
2. 审核计划：删除不想要的、标记「不做」的过度复杂功能、把后续想法归入「待定」区
3. 按章节逐步实施——明确告诉 AI「现在只做第二节」，完成后检查、测试、提交

工具选择：
- 新手：Replit 或 Lovable（可视界面）
- 有经验者：Windsurf、Cursor 或 Claude Code
- 选择成熟框架：Rails 等 20 年历史的框架因有大量一致训练数据，AI 表现惊艳

Git 是最可靠的朋友：
- 每次新功能前确保 Git 干净
- 出问题果断 git reset --hard——如果不对就重掷骰子
- 更好的做法：经多轮尝试找到解决方案后，git reset 回到干净代码库，把方案作为清晰指令重新喂给 AI

测试驱动：
- 先手写测试用例（不依赖 LLM）
- 优先写集成测试（端到端验证），而非低层级单元测试
- 让 LLM 在测试的护栏下自由生成代码

（来源：20250425-How-To-Get-The-Most-Out-Of-Vibe-Coding）

第三步：测试原型

将原型交给用户后：不教操作，观察真实行为。

（来源：20221201-How-To-Talk-To-Users）

第四步：尽早发布并收费

（来源：20260114；20230419-Change-the-way-you-think-about-launching）

第五步：从原型过渡到可演化产品

（来源：20240530）

第六步：持续迭代——Vibe Coding 的最佳实践

Bug 修复策略：
1. 第一反应：直接把错误信息粘贴回 LLM
2. 更复杂的 Bug：让 LLM 先思考三四种可能原因再写代码
3. 每次修复失败后先 git reset 再重新开始——不要在失败基础上累积层级
4. 如果搞不定：添加日志
5. 如果依然不行：换模型（Claude Sonnet 3.7、OpenAI 系列、Gemini）

保持代码质量：
- 保持文件小而模块化，趋向服务化架构
- 代码跑通、测试就位后，可放心重构——测试会捕获回归
- 为 LLM 编写指令文件（Cursor Rules / CLAUDE.md）——有创始人写了数百行指令，效果显著提升
- 把相关 API 文档全部下载到项目目录子文件夹中，让 LLM 读本地文档比在线访问准确得多

（来源：20250425）

常见错误

错误 1：过度工程化——构建完整产品而非验证假设

DoorDash 团队（四位斯坦福工程师）完全有能力构建带 Google Maps 实时追踪的动态网站，但创始人非常务实——最难证明的不是技术，而是人们到底想不想要。太多创始人需要被「反教育」他们在大公司学到的那些东西——「如果你按大公司的玩法，永远赢不了。」（来源：20240530）

错误 2：在 PMF 之前担心扩展性

Paul Graham 2013 年的文章逆转了硅谷被 Google 扭曲的「可扩展性偏执」。创业公司最大的问题不是架构不够可扩展，而是无法获得用户。先杀掉眼前的龙，再去担心后面的龙。（来源：20240530）

错误 3：对咨询/手动收入上瘾

Optimizely 的教训：手动为客户搭建 A/B 测试赚钱验证了需求，但如果停留在咨询模式就永远无法构建大生意。咨询业务不可能一年增长十倍，真正的软件业务可以。（来源：20240530）

错误 4：不收费——用免费用户验证需求

不收费的客户不是真正的客户。如果用户不愿付费，你还没有验证真正的需求。（来源：20260114）

错误 5：Vibe Coding 中反复修补而不重置

反复用多个 Prompt 修补会让 LLM 积累层层垃圾代码，而非真正理解根因。出问题果断 git reset --hard，在干净代码库上给出精确修复指令。（来源：20250425）

错误 6：等产品「完美」才发布

知道产品会改变很多是一种解脱——它不需要从一开始就完美。最终它将成为什么，取决于你从哪里开始以及与谁一起开始。（来源：20260114）

诊断问题

  1. 你的第一版产品能在 48 小时内构建出一个可演示的原型吗？
  2. 你用这个原型验证的核心假设是什么？（只能有一个）
  3. 你是否已经将原型交给真实用户——不教操作，只观察行为？
  4. 你是在构建「最小可演化产品」还是「精美但不可演化的产品」？
  5. 你是否已经向用户收费？付费用户的反馈比免费用户尖锐多少？
  6. 你最近一次「做不可扩展的事」是什么？（亲自服务客户、手动完成流程等）
  7. 如果用 Vibe Coding：你是否先写了计划再写代码？Git 是否干净？
  8. 你的原型中有多少功能其实是 MVP 不需要的？（诚实回答）
  9. 你是在等产品完美再发布，还是已经发布并开始迭代？
  10. 你现在做的事情，如果在大公司会不会被开除？（如果是 Yes，那可能就是创业公司该做的事）

YC 来源案例

可直接使用的模板 / 话术

MVP 构建计划模板（Vibe Coding 用）

# [产品名] MVP 计划

## 核心假设
我们要验证的唯一假设是：[一句话]

## MVP 范围
### 必须做
- [ ] 功能 1：
- [ ] 功能 2：
- [ ] 功能 3：

### 不做（标注原因）
- 功能 A：MVP 不需要，等验证后再做
- 功能 B：过度复杂，可用手动替代

### 待定（后续评估）
- 功能 C：
- 功能 D：

## 技术栈
- 前端：
- 后端：[推荐 Rails 等成熟框架以提高 AI 编码效果]
- 数据库：
- 部署：

## 实施步骤
### 第一节： [模块名]
- 目标：
- 预计时间：
- 验证标准：

### 第二节： [模块名]
...

## MVP 成功标准
- 获得 [N] 个付费用户
- [N]% 的用户在 [时间周期] 内返回
- [定性信号：如用户主动推荐给他人]

48 小时 MVP Sprint 流程

## 小时 0-2：计划
- [ ] 写 Markdown 项目计划（与 LLM 协作）
- [ ] Git init，确保仓库干净

## 小时 2-12：核心功能
- [ ] 实现最小核心流程
- [ ] 每完成一个小节 git commit

## 小时 12-18：集成测试
- [ ] 手写关键集成测试
- [ ] 跑通所有测试 → git commit

## 小时 18-30：部署 + 手工打磨
- [ ] 部署到 Heroku / Vercel 等
- [ ] 手工测试所有流程

## 小时 30-42：用户测试
- [ ] 找 3-5 个用户，不教操作观察行为
- [ ] 记录所有卡点和困惑

## 小时 42-48：快速迭代
- [ ] 修最关键的问题
- [ ] 发布 → 开始收费

Vibe Coding Bug 修复流程

1. 粘贴错误信息给 LLM（不要手动解释）
2. 让 LLM 先列出 3-4 种可能原因
3. LLM 尝试修复
4. 如果失败 → `git reset --hard`（回到干净状态）
5. 如果还是不行 → 添加日志
6. 如果依然不行 → 换模型（Claude → OpenAI → Gemini）
7. 找到根源后 → `git reset --hard` 回到干净代码库
8. 给 LLM 精确修复指令 + 干净代码库

相关 source pages

相关 topic pages

置信度与局限