什么是 MVP 减法思维
从"加法思维"到"减法思维"的转变
传统产品开发中，我们习惯做加法：
- 用户可能需要这个功能，加上
- 竞品有这个功能，我们也得有
- 这个功能很酷，加上去会更吸引人
- 万一用户需要呢？先加上再说
结果产品越做越臃肿，开发周期越来越长，最后偏离了用户真正的核心需求。
MVP 减法思维是逆向思考：不是"我要加什么"，而是"我能砍掉什么"。
MVP 减法思维的核心理念
MVP（Minimum Viable Product，最小可行产品）减法思维可以用一句话概括：
用最少的功能，验证最核心的假设。
三个关键原则
| 原则 | 含义 | 实践要点 |
|---|---|---|
| 最小化 | 只做必不可少的功能 | 问自己：没有这个功能，产品还能用吗？ |
| 可验证 | 每个功能都要能验证假设 | 问自己：这个功能能帮我验证核心假设吗？ |
| 快速迭代 | 尽快交付，快速学习 | 问自己：用户第一次使用就需要这个功能吗？ |
为什么要做减法？
1. 资源永远是有限的
时间、人力、资金总是不够用。减法思维帮我们把资源集中在最重要的事情上。
❌ 错误做法：10个功能各做50分
✅ 正确做法：3个功能做到90分
2. 用户注意力有限
功能越多，用户学习成本越高，核心价值的传达就越模糊。
❌ 错误做法：给用户20个选择
✅ 正确做法：给用户3个最好的选择
3. 假设需要验证
产品早期，所有想法都只是假设。减法思维让我们用最小成本快速验证。
❌ 错误做法：花3个月做完整产品，发现没人要
✅ 正确做法：花1周做MVP，快速验证需求
减法思维 vs 加法思维
| 维度 | 加法思维 | 减法思维 |
|---|---|---|
| 关注点 | 功能数量 | 核心价值 |
| 决策依据 | "万一需要呢？" | "没有它能用吗？" |
| 开发周期 | 长（追求完美） | 短（快速验证） |
| 风险 | 高（投入大，反馈晚） | 低（投入小，反馈快） |
| 用户反馈 | 复杂（功能太多，不知道哪个重要） | 清晰（聚焦核心，反馈明确） |
减法思维在 AI 编程中的优势
AI 编程工具大幅提升开发效率，但这更需要减法思维：
- 生成容易，删减难：AI 可以快速生成大量代码，但没有清晰边界，项目会迅速膨胀
- 快速原型：利用 AI 的快速生成能力，几小时内就能完成多个 MVP 版本迭代
- 聚焦验证：把省下来的时间用于验证假设，而不是堆砌功能
AI 编程 + 减法思维 = 快速验证，精准迭代
AI 编程 + 加法思维 = 快速堆砌，方向迷失
减法思维的常见误区
❓ 误区 1：减法 = 偷工减料
错误理解：做减法就是降低质量标准。
正确理解：减法是在功能数量上做减法，在核心价值上做加法。P0 功能的质量必须保证。
❓ 误区 2：MVP = 半成品
错误理解：MVP 是一个残缺的产品。
正确理解：MVP 是一个完整的最小价值单元，它能独立完成核心任务。
❓ 误区 3：减法是一次性的
错误理解：前期做减法，后期就可以一直做加法。
正确理解：减法是一种持续思维，每个版本都要重新审视功能的必要性。
实践指南：减法思维的完整应用流程
把本节所学应用到你自己的项目上。这个实践指南将带你完成从想法到 MVP 的完整减法流程。
实践流程概览
本实践指南包含以下步骤：
- 明确核心假设 - 定义你要验证什么
- 列出所有功能 - 不设限地头脑风暴
- 应用筛选框架 - 用三个问题分类功能
- 确定P0功能集 - 你的MVP范围
- 制定不做清单 - 明确项目边界
- 执行验证计划 - 快速验证假设
- 分析结果决策 - 基于数据做决定
Step 1：明确你的核心假设
在做任何减法之前，先明确你在验证什么。
核心假设模板
## 我的核心假设
---
我假设：
[某类用户] 存在 [某个问题/需求]，
他们愿意使用 [我的解决方案] 来 [完成某个任务]，
因为它比现有方案 [更快/更简单/更便宜/更有效]。
我的填写：
[ ]
验证标准模板
## 验证标准
---
如果：
- [ ] 个用户
- 在 [ ] 天/周内
- 完成了 [ ]
则说明假设成立，值得继续投入。
我的填写：
如果：
- [ ] 个用户
- 在 [ ] 天/周内
- 完成了 [ ]
则说明假设成立。
实际应用示例
待办清单项目：
## 我的核心假设
---
我假设：
职场人士 存在 「怕遗漏重要事项」的问题，
他们愿意使用 一个极简待办工具 来 管理每日任务，
因为它比 便签纸/手机备忘录 更容易坚持使用。
## 验证标准
---
如果：
- 10 个用户
- 在 2 周内
- 平均每周使用 3 天以上
则说明假设成立。
Step 2：列出所有想做的功能
不要自我审查，把你能想到的所有功能都列出来。
## 功能清单（不设限）
---
1.
2.
3.
（继续添加...）
头脑风暴技巧
- 不设限制：暂时不考虑技术难度、时间、成本
- 参考竞品：看看类似产品都有什么功能
- 用户需求：想象不同用户可能的需求
- 扩展思维：考虑相关的、延伸的功能
- 记录所有想法：即使看起来不靠谱也先记下
功能分类示例
对于待办清单项目，可能的功能清单：
- 添加任务
- 完成任务
- 编辑任务
- 删除任务
- 任务分类
- 优先级标签
- 截止日期
- 提醒功能
- 重复任务
- 子任务
- 标签系统
- 搜索功能
- 任务统计
- 完成历史
- 数据导出
- 多设备同步
- 分享功能
- 协作功能
- 评论系统
- 暗黑模式
- 自定义主题
- 小组件
- 语音输入
- 图片附件
- 位置提醒
Step 3：用三个问题筛选
对每个功能问三个筛选问题：
| 功能 | Q1：没有能用？ | Q2：验证假设？ | Q3：首次需要？ | 优先级 |
|---|---|---|---|---|
| 1. | 能/不能 | 能/不能 | 是/否 | P0/P1/P2 |
| 2. | ||||
| 3. | ||||
| 4. | ||||
| 5. | ||||
| ... |
判断规则
- P0：Q1=不能 且 Q2=能 且 Q3=是
- P1：Q1=能 但 (Q2=能 或 Q3=是)
- P2：其他所有功能
应用示例
基于待办清单项目的筛选：
| 功能 | Q1：没有能用？ | Q2：验证假设？ | Q3：首次需要？ | 优先级 |
|---|---|---|---|---|
| 添加任务 | 不能 | 能 | 是 | P0 |
| 完成任务 | 不能 | 能 | 是 | P0 |
| 任务列表 | 不能 | 能 | 是 | P0 |
| 任务分类 | 能 | 部分能 | 否 | P1 |
| 提醒功能 | 能 | 部分能 | 否 | P1 |
| 数据统计 | 能 | 不能 | 否 | P2 |
| 协作功能 | 能 | 不能 | 否 | P2 |
| 暗黑模式 | 能 | 不能 | 否 | P2 |
Step 4：确认你的P0功能
从上面的筛选中，提取P0功能。
## 我的P0功能（最多3-5个）
---
### P0功能1：[功能名称]
- **为什么不砍**：[说明]
- **验证价值**：[说明]
---
### P0功能2：[功能名称]
- **为什么不砍**：[说明]
- **验证价值**：[说明]
---
### P0功能3：[功能名称]
- **为什么不砍**：[说明]
- **验证价值**：[说明]
P0功能验证标准
每个P0功能都要能回答：
- 没有这个功能，核心价值还存在吗？
- 这个功能直接验证核心假设吗？
- 用户第一次使用就需要这个功能吗？
如果任何一个问题的答案是"否"，那么这个功能可能不是真正的P0。
Step 5：制定不做清单
# 不做清单（V1版本）
## 一、不做的功能
---
| 功能 | 不做的理由 | 何时重新考虑 |
|-----|----------|-------------|
| [P1功能] | [理由] | [条件] |
| [P2功能] | [理由] | [条件] |
## 二、不考虑的用户群
---
| 用户群 | 不考虑的理由 |
|-------|-------------|
| [用户描述] | [理由] |
## 三、不追求的指标
---
| 指标 | 不追求的理由 | 替代关注点 |
|-----|-------------|----------|
| [指标名称] | [理由] | [替代指标] |
Step 6：执行验证计划
MVP实施时间表
## MVP实施计划
---
### 第1周：核心功能开发
- [ ] 功能1开发
- [ ] 功能2开发
- [ ] 功能3开发
---
### 第2周：内部测试
- [ ] 自己使用测试
- [ ] 找2-3个朋友试用
- [ ] 收集初步反馈
---
### 第3-4周：用户验证
- [ ] 找目标用户试用
- [ ] 收集使用数据
- [ ] 分析验证结果
---
### 第4周末：决策点
- [ ] 评估验证结果
- [ ] 决定继续/调整/放弃
- [ ] 规划下一步行动
数据收集方法
- 使用频率：用户多久用一次
- 功能使用率：哪些P0功能实际被使用
- 用户反馈：定性反馈和建议
- 完成率：验证标准达成情况
- 留存率：用户是否持续使用
Step 7：分析结果决策
验证结果分析框架
## 验证结果分析
---
### 假设验证情况
- [ ] 假设成立：达到验证标准
- [ ] 假设部分成立：部分达到标准
- [ ] 假设不成立：未达到标准
---
### 关键学习点
1.
2.
3.
---
### 下一步决策
- [ ] 继续迭代：基于反馈改进P0功能
- [ ] 调整方向：修改核心假设
- [ ] 暂停项目：假设不成立，重新考虑
- [ ] 扩展功能：P0验证成功，开始P1功能
AI辅助工具和提示词
让AI帮你砍功能
我正在做一个[项目类型]，核心假设是[核心假设]。
以下是我想实现的功能列表：
[功能列表]
请帮我分析哪些功能是P0（必须立即做的），哪些是P1（下个版本做），哪些是P2（有时间再做）。
分析标准：
1. 没有这个功能，产品还能用吗？
2. 这个功能能验证核心假设吗？
3. 用户第一次使用就需要这个功能吗？
请按以下格式回答：
P0功能：
- 功能1：[理由]
- 功能2：[理由]
P1功能：
- 功能1：[理由]
- 功能2：[理由]
P2功能：
- 功能1：[理由]
- 功能2：[理由]
让AI帮你验证假设
我有一个项目的核心假设：[核心假设]
验证标准是：[验证标准]
现在收集到的数据是：
[数据和结果]
请帮我分析：
1. 假设是否成立？
2. 哪些数据支持/反对假设？
3. 还需要收集什么数据？
4. 基于现有数据，建议下一步怎么走？
实践练习模板
练习1：完整应用减法流程
选择一个你想要做的项目（可以是真实的，也可以是练习用的），完成以下工作：
- 填写核心假设模板
- 列出至少15个功能
- 用三个问题筛选，确定P0/P1/P2
- 制定不做清单
- 设计验证计划
练习2：分析现有项目
找一个你正在做或曾经做过的项目：
- 当时的核心假设是什么？（如果没有，现在补上）
- 当时的功能清单是怎样的？
- 用现在的知识重新筛选功能
- 如果当时有不做清单，会是什么样子？
- 从中学到了什么？
练习3：快速MVP挑战
选择一个想法，尝试在1周内做出MVP：
- 限制时间：1周
- 限制功能：最多3个P0功能
- 限制资源：只能用现有工具和技能
- 目标：验证核心假设，不是做完美产品
- 记录过程：每天写简短日志
常见问题解答
❓ Q1：如果我的P0功能还是太多怎么办？
答案：
- 检查核心假设是否过于宽泛
- 考虑把项目分成多个阶段
- 重新审视每个P0功能，看是否能进一步简化
- 可能需要分阶段验证不同的假设
❓ Q2：验证结果不理想怎么办？
答案：
- 不要立即放弃，先分析具体原因
- 可能是假设错了，需要调整
- 可能是MVP不够好，需要改进
- 可能是验证方法有问题，需要调整
❓ Q3：用户要求P1/P2功能怎么办？
答案：
- 对照不做清单，如果在不做清单里，礼貌说明理由
- 如果不在不做清单里，考虑是否需要调整清单
- 记录用户需求，作为未来规划的参考
- 优先处理影响核心价值验证的反馈
❓ Q4：如何平衡快速验证和质量？
答案：
- P0功能要保证质量，但不追求完美
- 核心是能验证假设，不是展示技术水平
- 质量底线：不严重影响验证结果
- 用手动方式处理边缘情况，节省时间
核心要点总结
三条核心原则
MVP是实验，不是产品。它的目的是验证假设，而不是取悦用户。
做减法比做加法更难，但更重要。功能多不等于价值高。
「不做清单」和「要做清单」同样重要。明确边界才能聚焦核心。
可复用的模板清单
本节提供了以下可直接使用的模板：
- 核心假设模板：明确你在验证什么
- 验证标准模板：定义成功/失败的判断标准
- 功能筛选表格：用三个问题快速分类
- 不做清单模板：三个维度的完整格式
- AI辅助Prompt：让AI帮你砍功能和验证判断
常见错误vs正确做法
| 常见错误 | 正确做法 |
|---|---|
| 列了14个功能就开始做 | 先明确核心假设，再确定P0 |
| MVP=功能最少 | MVP=投入最小且能验证假设 |
| 做完再给用户看 | 尽早让用户参与验证 |
| 竞品有什么我也做什么 | 只做验证假设必须的功能 |
| 不做清单放脑子里 | 写下来，形成正式的决策记录 |
检查清单
在开始动手开发之前，确认以下事项：
- [ ] 我有明确的核心假设（一句话能说清楚）
- [ ] 我有可衡量的验证标准（X个用户在Y时间内做了Z）
- [ ] 我的P0功能不超过5个
- [ ] 我写下了「不做清单」
- [ ] 我知道这个MVP要验证什么，不验证什么
"完美不是无以复加，而是无可删减。"
减法思维不是偷懒，而是聚焦；不是放弃，而是智慧；不是限制，而是效率。