MVP、原型还是概念验证：应该先做哪一个

三者各自检验一种不同的风险。下表把它们放在一起比较。

概念验证（PoC）用来检验某件事在技术上是否可行。它通常是一小段代码，只解决一个难题，其他一概不管：没有设计，没有账号，也不做打磨。

例如，一家想从手写收据照片中提取合计金额的创业公司，应该先测试 AI 模型能否以足够的准确率识别这些收据。如果做不到，再好的设计也救不了这个产品。

大多数产品不需要概念验证。如果您的想法由账号、支付、表单和数据看板这类成熟模块组成，技术风险就很低，做概念验证只会推迟真正需要回答的问题。

概念验证的代码通常会被丢弃。写它是为了快速回答一个问题，而不是为了支撑一个产品。

原型在任何人编写正式代码之前，就展示产品将如何运作。它可以是一组草图，也可以是可点击的、逼真的界面，表现得几乎和真实产品一样。

Nielsen Norman Group 关于低保真和高保真原型的指南，把其中的取舍讲得很清楚。简单的草图做得更快，也更容易得到坦率的批评；高保真原型能展示逼真的交互，当您要测试具体流程时，这一点很重要。

原型也是让各方达成一致的最佳工具。AutoIntel 是一款面向德国二手车市场的 B2B 工具，它最初是一个基于示例车源的交互式原型。客户带着自己的团队完整走了一遍，在评估数据处理的工作量之前，就确定了哪些字段和筛选条件真正重要。

MVP 即最小可行产品，是真实用户可以真正使用的最小版本产品。它有可用的账号、真实的数据，并在必要时支持真实的支付。

它的目标是学习，而不是为了上线而上线。用精益创业（Lean Startup）的话来说，做 MVP 是为了“尽快开始学习的过程”。

MVP 能衡量原型无法衡量的东西：用户会不会回来，会不会付费。CarPixly 是一个为汽车广告服务的 AI 照片工作室，任何人都可以注册并免费体验工作室，在产生价值的那一刻，也就是生成渲染图时，才开始付费。这样的模式能清楚地显示有多少访客转化为付费用户。

大多数 MVP 根据复杂度不同，需要 6 至 14 周完成。我们关于开发 MVP 需要多长时间和 SaaS MVP 要花多少钱的文章，按层级给出了具体区间。

从风险最大的未知点开始。按顺序问自己这几个问题：

• 是否真的有可能做不出来？例如，产品依赖一个您还没测试过的 AI 模型、硬件传感器或 API。那就先做概念验证。
• 还不清楚用户是否理解这个方案，或是否需要它？那就做原型，并拿给用户测试。
• 用户理解也需要，悬而未决的是他们会不会使用或付费？那就做 MVP。

大多数创业公司都停在第二个问题上。技术通常已经成熟，尚未被证明的是：这个产品对它所服务的人来说是否有意义。

不确定您的想法中最大的风险是什么？发给我们一份简短的需求简报，我们会告诉您，如果是我们，会从哪一步开始，以及原因。

只有真实的人试用过，原型才有价值。好消息是，您需要的测试者比大多数创始人想象的要少。

Jakob Nielsen 的研究发现，对 5 名用户进行测试就能发现一个设计中的大部分可用性问题。他的建议是进行几轮小规模测试，而不是做一次大型研究。

一轮简单的测试是这样的：

• 给每个人一个真实的任务，例如“预约下周二的一项服务”。
• 观察他们的操作，不提供帮助，也不做解释。
• 记录他们在哪里犹豫、看错或放弃。
• 修复最严重的问题，再找新的人测试下一个版本。

也要问问他们现在的做法：他们目前如何解决这个问题，要付出多少成本。这比问他们“会不会使用”您的产品，更能说明真实的需求。

用草图做成的原型是学习工具，之后会重新绘制。用真实组件设计的高保真原型则不同：它的流程、界面和设计系统会成为 MVP 的起点。

这就是我们从第一个界面开始就使用可复用组件进行设计的原因。原型经过测试和确认后，开发直接基于同一套组件进行，而不是重新解读一张图片。

概念验证则正好相反。它的代码只回答一个问题，通常会在 MVP 中被认真重写，因为它从来就不是为真实用户准备的。

每一步都应该以一个明确的答案结束，而不是一种感觉。开始之前就写下“成功”意味着什么，这样结果就不会在事后被解读成您希望的样子。

• 概念验证成功，是指难点部分在真实数据上能以产品所需的准确率或速度运行。如果用户会上传成千上万个文件，“在三个测试文件上能跑通”是不够的。
• 原型成功，是指大多数测试用户无需帮助就能完成主要任务，并能用自己的话说出它解决的问题。
• MVP 成功，是指真实用户无需提醒就会回来，或者愿意付费，而且比例高到足以支撑下一笔投入。

如果某一步失败了，这同样有价值。失败的概念验证让您避免了一次昂贵的开发。让人困惑的原型提醒您趁修改成本还低的时候调整流程。

还要为每一步设定时间上限。一个打磨了好几个月的原型已经不再是测试，而是变成了一个还没有人能用的产品。

有时候可以。如果您已经验证过这个想法，比如通过人工方式提供过这项服务，您可能已经掌握了足够的信息，可以直接做 MVP。

例如，一位创始人几个月来一直用表格和消息，手动为客户匹配家教老师。这位创始人已经了解整个流程，也知道用户会问什么问题。做原型主要只是确认已经知道的事情。

在三个条件都满足时，跳过原型才有意义：技术已经成熟，您亲眼看过真实用户走完整个流程，并且您知道软件应该先接手流程中的哪一部分。只要缺少其中任何一项，原型仍然是更便宜的探索方式。

同样的错误一再出现：

• 把原型叫作 MVP。原型上的点击说明用户理解了，不代表他们会使用或付费。不要把两者混为一谈。
• 把概念验证打磨成产品。为回答一个问题而写的代码，会成为之后所有功能的脆弱基础。
• 跳过原型。在测试流程之前就开发 MVP，等于花钱请开发者去发现设计问题。
• 往 MVP 里塞太多东西。每多一个功能，都会推迟您得知核心是否可行的时间。
• 找朋友测试。喜欢您的人会称赞这个想法。请找那些确实有这个问题、也没有理由客气的人来测试。

准备好选择第一步了吗？告诉我们您的想法，我们会帮您在概念验证、原型和 MVP 之间做出选择。