最小可行产品

MVP (Minimum Viable Product)

也常被叫作：最小可用版第一版能跑起来的最简版先做个丑的

产品与需求通常止于「主路径」约 1 分钟读完

你可能会这么说

「别一上来就做完整版，先做个最丑但能用的，拿去让人用起来。」

最小可行产品 MVP (Minimum Viable Product)

砍到只剩能验证核心价值的最小版本，先上线让真人用，而不是把功能做全。

MVP 不是「少做功能的半成品」，而是「刚好够验证核心假设的最小版本」。要验证的核心假设通常只有一个：有没有真人愿意为这件事花时间、再回来一次、甚至掏钱。所以第一版的功能不是「能少则少」，而是「砍到只剩那个非用不可的理由」——删掉它，产品就没有存在的意义了。

对用 AI 做东西的人，MVP 的坑恰恰不是做少了，而是做多了。AI 生成功能的成本几乎是零，它会顺手给你加上登录、后台、排行榜、多语言……每多一个功能，上线就多拖几天，而你要验证的核心问题一个都没多验证。范围每大一点，出问题的地方就多一片。

怎么定第一版做什么：写一句话「用户遇到什么问题 → 我给他什么 → 他怎么算用上了」，然后砍到一个场景、一个动作、一个结果，剩下的全部写进「以后再说」。第一版丑没关系，能用、能被真人用起来才算数。

长什么样真实可交互，不是截图

✕ 第一版就做全套注册 + 登录 + 排行榜 + 积分 + 后台 + 多语言，两个月后上线

✓ 第一版只做一件事上传照片 → 出对比图 → 拿到分享链接，两周后有人真的在用

左边不是「需求丰富」，是验证被无限推迟；右边每一个功能都能回答一个问题：上传能不能出图、别人能不能点开。

拆开看，里面有这几块

1
核心价值 Core value
用户非用不可的那一件事。删掉它产品就没有意义。
2
最小范围 Minimum scope
只服务一个场景、一个动作、一个结果，其余不碰。
3
验证目标 Validation goal
第一版要回答的问题：有没有真人愿意用起来、用第二次。
4
砍掉清单 Cut list
明确写下「这版不做」的功能，防止它偷偷回来。

常见的有哪几种

只有核心Bare core

只留一个功能闭环，丑但能验证。

用在：想法还没被任何人验证过

核心 + 证据Core + evidence

核心功能之外加最小收集手段：一个反馈按钮、一条使用记录。

用在：想判断「有没有人真的在用」

人工代跑版Concierge

后台用人工操作冒充自动化，先验证需求值不值得做。

用在：不确定该不该做这个功能时

容易搞混？这样区分

最小可行产品 ≠ 半成品 Unfinished product

半成品是「做着做着停了」，MVP 是「有意识地砍到刚好能验证」。判断方法：MVP 的每个功能都能回答一个验证问题；半成品只是没做完，回答不了任何问题。

最小可行产品 ≠ 原型 Prototype

原型是拿来试的假界面，点完就扔，数据可以是假的；MVP 是真能用的，会有人真的在上面完成目标。原型验证「好不好用」，MVP 验证「有没有人愿意用」。

什么时候用得上

想法刚冒出来时

先写一句话「给谁解决什么问题」，再砍到最小场景，别急着列功能。

AI 给你加功能时

每多一个功能问一句「它帮我验证核心问题吗」，不是就砍或写进以后再说。

第一版上线后

只看一件事：有没有真人主动用第二次，别急着加功能。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【范围】做一个能验证核心假设的最简版本，只实现［上传照片 → 生成对比图 → 得到可分享链接］这一条路径
【目标】这版要回答的问题：有没有真人愿意上传照片并拿到结果。为此需要：
  - 一个上传入口 + 一个结果页
  - 一个别人能打开看到结果的分享链接
  - 最少的使用痕迹：至少记录「上传了多少次、成功了多少次」
【边界】这版不做：注册登录（不做账号体系）、排行榜、积分、后台管理、多语言。我上面没提的功能一律不要做，你想到什么先写进「以后再说」清单发我
【交付】改完告诉我：我打开哪个地址、上传什么照片、点哪几步能看到结果；「上传 → 出图 → 打开分享链接」这条路径你自己实际走过没有；使用次数你打算怎么统计，统计结果我看得见吗

这段的关键是「边界」和「交付」：边界挡住了 AI 顺手加的登录和后台，交付里的三个问题逼它交出可验证的证据，而不是一句「做好了」。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「主路径」这层：真实用户的正常操作能走通，不靠特殊参数。

要亲眼看到这些，才算数

找一个真实用户（朋友就行），不教他，只看他能不能自己完成「上传 → 看到结果 → 打开分享链接」。
你本人用手机和电脑各走一遍核心路径，记下每步花了多久、卡在哪。
上线一周后看使用记录：有没有人完成第二次？重复使用比「有人点赞」更能证明价值。
对着你原来的「以后再说」清单，确认没有功能偷偷混进这一版。
自问：这个版本如果没人用，最核心的假设是什么？这条假设有没有被真实记录回答，而不是被你的感觉回答。

它常这么糊弄你

「功能我都做全了，肯定是个好产品」——功能多不等于有人用。先看使用记录，再看功能清单。
「MVP 已完成」——但你从没让一个不熟的人自己走通过。让他自己走一遍，你在旁边只看不说。
「我先加个登录，反正很快」——加登录就是加账号体系，一个「很快」能拖一周。
「等全部做完再上线」——如果「全部做完」遥遥无期，说明你砍得不够狠，回去重新砍。

第一版做到「主路径」层就算过关：真实用户的核心路径能走通。但要判断「有没有人真的愿意用」，得推到生产层——真上线、真记录、真看数据，那时候说的才算数。

考考你选一个你觉得对的

你要做一个「AI 帮家长挑兴趣班」的产品，第一版最少该做什么？

想再深挖一点靠谱出处

Minimum viable productWikipedia ↗

# 最小可行产品 (MVP (Minimum Viable Product))

> 砍到只剩能验证核心价值的最小版本，先上线让真人用，而不是把功能做全。

**你可能会这么说**：别一上来就做完整版，先做个最丑但能用的，拿去让人用起来。

MVP 不是「少做功能的半成品」，而是「刚好够验证核心假设的最小版本」。要验证的核心假设通常只有一个：有没有真人愿意为这件事花时间、再回来一次、甚至掏钱。所以第一版的功能不是「能少则少」，而是「砍到只剩那个非用不可的理由」——删掉它，产品就没有存在的意义了。 对用 AI 做东西的人，MVP 的坑恰恰不是做少了，而是做多了。AI 生成功能的成本几乎是零，它会顺手给你加上登录、后台、排行榜、多语言……每多一个功能，上线就多拖几天，而你要验证的核心问题一个都没多验证。范围每大一点，出问题的地方就多一片。 怎么定第一版做什么：写一句话「用户遇到什么问题 → 我给他什么 → 他怎么算用上了」，然后砍到一个场景、一个动作、一个结果，剩下的全部写进「以后再说」。第一版丑没关系，能用、能被真人用起来才算数。

**也叫**：最小可用版、第一版、能跑起来的最简版、先做个丑的

## 你可以这样告诉 AI

```text
【范围】做一个能验证核心假设的最简版本，只实现［上传照片 → 生成对比图 → 得到可分享链接］这一条路径
【目标】这版要回答的问题：有没有真人愿意上传照片并拿到结果。为此需要：
  - 一个上传入口 + 一个结果页
  - 一个别人能打开看到结果的分享链接
  - 最少的使用痕迹：至少记录「上传了多少次、成功了多少次」
【边界】这版不做：注册登录（不做账号体系）、排行榜、积分、后台管理、多语言。我上面没提的功能一律不要做，你想到什么先写进「以后再说」清单发我
【交付】改完告诉我：我打开哪个地址、上传什么照片、点哪几步能看到结果；「上传 → 出图 → 打开分享链接」这条路径你自己实际走过没有；使用次数你打算怎么统计，统计结果我看得见吗
```

## 怎么验证他真的做到了

通常止于层级：**主路径** — 真实用户的正常操作能走通，不靠特殊参数

- [ ] 找一个真实用户（朋友就行），不教他，只看他能不能自己完成「上传 → 看到结果 → 打开分享链接」。
- [ ] 你本人用手机和电脑各走一遍核心路径，记下每步花了多久、卡在哪。
- [ ] 上线一周后看使用记录：有没有人完成第二次？重复使用比「有人点赞」更能证明价值。
- [ ] 对着你原来的「以后再说」清单，确认没有功能偷偷混进这一版。
- [ ] 自问：这个版本如果没人用，最核心的假设是什么？这条假设有没有被真实记录回答，而不是被你的感觉回答。

常见糊弄：
- 「功能我都做全了，肯定是个好产品」——功能多不等于有人用。先看使用记录，再看功能清单。
- 「MVP 已完成」——但你从没让一个不熟的人自己走通过。让他自己走一遍，你在旁边只看不说。
- 「我先加个登录，反正很快」——加登录就是加账号体系，一个「很快」能拖一周。
- 「等全部做完再上线」——如果「全部做完」遥遥无期，说明你砍得不够狠，回去重新砍。

来源：https://mickerbook.com/reference/t/mvp/