什么是 MVP？最小可行产品详解
MVP，即最小可行产品（minimum viable product），是真实的人能够使用并获得真正价值的最小版本产品，它的目的是让你了解这个想法是否值得继续投入。“最小”意味着去掉所有对核心工作并非必不可少的东西；“可行”意味着剩下的部分对真实用户确实有效。重点不是推出一个廉价的东西，而是在你花几个月构建错误的东西之前，先弄清楚人们想要什么。
这个词从哪里来，为什么重要
这个说法由埃里克·莱斯（Eric Ries）的《精益创业》以及更广泛的精益创业运动所推广，它把产品构建看作一系列实验：先做一个小的东西，衡量人们如何使用它，从中学习，然后调整。
用 AI 构建时，MVP 的理念既变得更容易，也变得更加重要。
- 更容易，因为如今构建一个可运行的第一版只需要几天而不是几个月，成本也低得多。
- 更重要，因为人们很容易想不断添加功能。当每一项新功能都只是一条提示之遥时，克制地不做某些事情，才是让应用保持聚焦、让第一批用户的反馈保持清晰的关键。
日常类比
想象你想开一家餐厅。在签下十年的租约、装修厨房之前，你先在周末的集市上摆一个只卖三道菜的小摊。
这个摊位很小，但并不是假的。人们付真钱、吃真食物。经过几个周末，你就知道哪道菜会卖光，人们愿意付多少钱，以及他们会不会回头。这就是 MVP。
一张你从未做过的菜的照片是原型。开业当晚的整个餐厅则是成品。摊位介于两者之间：足够真实，能教会你一些可靠的东西；又足够小，即使判断错误也不是灾难。
MVP、原型以及其他术语
| 术语 | 它是什么 | 谁使用它 | 是否需要真正可用？ |
|---|---|---|---|
| 线框图（Mock-up） | 屏幕可能长什么样的图片 | 你和你的团队 | 不需要 |
| 原型（Prototype） | 可点击的模型，通常使用假数据 | 你、少数测试者、投资人 | 部分需要 |
| 概念验证（Proof of concept） | 验证某件事在技术上是否可行的测试 | 你或开发人员 | 只需要有风险的那一部分 |
| MVP | 能够交付价值的最小真实产品 | 真实的早期用户或客户 | 需要 |
| MLP / MMP | “最小可爱产品”或“最小可营销产品”——打磨得更精致的 MVP | 更广泛的发布受众 | 需要，并且经过打磨 |
| V1 | 你会广泛推广的第一个版本 | 公众 | 需要 |
你还会听到其他一些词：
- 核心循环（Core loop）——用户反复做的主要事情，例如“发布职位，收到申请”。
- 最具风险的假设（Riskiest assumption）——如果它不成立就会让想法失败的那个信念。你的 MVP 应该首先验证它。
- 验证（Validation）——证明人们确实想要并会使用（或付费使用）这个产品的证据。
- 迭代（Iteration）——根据所学，以小步的方式不断改进产品。
实例：一款遛狗预约应用的 MVP
你的想法：一款应用，让养狗的人在你所在的城市预约经过审核的本地遛狗员。
你最具风险的假设可能是：“养狗的人会通过应用预约并付款给陌生人。”而不是“养狗的人希望看到遛狗过程的实时 GPS 地图”。
完整的愿景包括：遛狗员档案与评价、实时 GPS 追踪、应用内聊天、订阅、遛狗员结算、评分系统、推送通知、推荐计划，以及遛狗员入职流程。
MVP：
| 包含 | 暂时不做 |
|---|---|
| 一份你亲自审核过的遛狗员列表，含照片、服务区域和价格 | 遛狗员自助注册和审核流程 |
| 预约表单：狗狗、日期、时间段、地址 | 定期订阅 |
| 预订时通过托管结账付款 | 自动结算给遛狗员（由你手动付款） |
| 发给主人和遛狗员的确认邮件 | 推送通知 |
| 一个简单的管理页面，可以看到所有预约 | 实时 GPS、应用内聊天、评价 |
你可以在一个街区试行一个月。如果主人反复预约，你就学到了值得在此基础上继续开发的东西。如果他们不预约，你也能以很低的成本发现问题，并直接问他们为什么。
注意，有些“不做”的事项是靠人工完成的。手动支付遛狗员或亲自审核他们并不能规模化，但目前并不需要规模化。在一个简单应用背后用人工完成事情，是最有效的 MVP 技巧之一。
常见错误与误解
- “最小”变成了“坏掉”。 一个会丢失预约或看起来不可信的 MVP，测试的是你的 bug，而不是你的想法。保持小巧，但要让已有的部分真正可用。
- 为所有人而做。 一个面向“任何需要 X 的人”的 MVP 很难测试。请选择一群你能够接触到的特定用户。
- 增加功能而不是与用户交谈。 当早期数据令人失望时，解决办法很少是再加一个功能。应该问用户是什么让他们却步。
- 跳过真正的测试。 一次候补名单注册只能说明兴趣；付费或重复使用才能说明价值。请提前决定什么样的结果才算成功。
- 把 MVP 当作一次性的东西。 使用 AI 构建器时，MVP 的代码往往会成为真正的产品。请从一开始就使用真正的数据库，并把登录做好，这样就不必从头再来。
- 永远无法完成。 设定一个上线日期，然后砍掉功能以按时上线，而不是反过来。
如何借助 AI 界定 MVP 的范围
- 写一句话。 “[谁] 能够 [做什么]，以便 [获得什么结果]。”例如：“利兹的养狗人可以为明天预约一位经过审核的遛狗员，这样他们就不必请假。”
- 列出你设想的每一项功能。 把它们全部从脑子里倒出来。
- 为每一项标注“测试想法所需”或“以后再说”。 要严格。大多数应归入“以后再说”。
- 决定哪些事情由你手动完成。 结算、入职、客服。
- 定义成功。 “4 周内 20 笔付费预约”是可以测试的。“人们喜欢它”则不行。
- 构建，向一小群人上线，然后观察。 再逐步迭代。
如需更深入、分步骤的帮助，请参阅如何验证应用创意和如何构建 SaaS MVP。
向你的 AI 建站工具提出什么要求
- “这是我的想法和我最具风险的假设。请建议能够验证它的最小版本，并列出应该砍掉哪些内容。”
- “只构建这五个功能。在我同意之前，不要添加任何其他内容。”
- “从一开始就使用真正的数据库和正规的登录功能，这样它就能发展成真正的产品。”
- “添加一个简单的管理页面，让我可以看到每一笔预约，并手动处理事务。”
- “添加基础的数据分析或事件日志，让我知道有多少人完成了预约。”
- “上线前，检查明显的安全问题：谁可以看到哪些记录，以及是否有密钥暴露。”
用 Mythex 构建 MVP
Mythex 非常适合构建 MVP：你在聊天中描述第一个版本，在实时预览中试用，准备好后再发布到公开网址——需要时还会添加 Postgres 数据库和文件存储。**计划（Plan）**模式对界定范围很有用：在编写任何代码之前，让 Agent 先提出一个最小版本的方案。Free 版包含发布功能，因此你可以在付费之前就把 MVP 交到用户面前；Pro 版则在想法开始奏效时提供自定义域名、代码导出和 GitHub 同步，参见价格。文档中的 SaaS MVP 教程很有参考价值；当你准备好寻找用户时，可以阅读如何推出应用并获得第一批用户。
常见问题
MVP 是什么的缩写？
MVP 是最小可行产品（minimum viable product）的缩写：真实的人可以用来获得真正价值的最小版本产品，它的目的是让你了解这个想法是否值得继续投入。
MVP 和原型有什么区别？
原型展示的是某样东西可能的样子或工作方式，通常使用虚假数据，用于在内部或向少数人测试想法。MVP 则由真实客户为真实目的使用，因此它必须真正能用——保存数据、发送邮件、完成付款。
做一个 MVP 应该花多长时间？
没有固定的标准，但耗时越长，它就越可能已经超出了“最小”的范围。借助 AI 应用构建器，一个聚焦的简单工具型 MVP 往往几天内就能运行起来，而不是几个月。目标是尽快把它交到用户面前。
一个 MVP 应该有多少功能？
尽量少，只要能交付你的用户最关心的那一个结果即可。许多好的 MVP 只做一件事，并且完整地做完。任何无助于验证你核心假设的功能，都可以等以后再做。