vibe-vibe 第三章实战：想法验证三步法——灵魂三问、MVP 思维与真实访谈法

• 文档
• 教程
• Vibe Coding
• 示例工程

本文是 vibe-vibe 开源教程"第三章：产品思维与文档驱动"中 3.1 节的完整展开。它聚焦一个所有开发者都会遇到的问题：如何在投入写 PRD、写代码之前，用最低成本判断一个产品想法是否值得做。读完本文，你将掌握"产品验证三步法"（灵魂三问、MVP 思维、快速验证）的完整操作细节，学会用真实访谈法从目标用户那里获取可信数据，识别"赞美、承诺、功能建议"三类虚假信号，并理解从"用户存在"到"有人付费"的逐层假设验证路径。文中所有结论均可在 vibe-vibe 仓库的教程文档与演示项目中找到对应证据。

本节适用说明：先想清楚"要不要做"，再想"怎么做"

在 vibe-vibe 的第三章序言中，老师傅强调了一个核心主张：写代码之前，先写文档；写文档之前，先做产品验证（见 docs/Advanced/03-prd-doc-driven/index.md）。3.1 节正是这条链路的起点。

如果你已经有一个明确想实现的产品想法，可以跳过本节直接开干；本节主要服务于还没有明确方向的读者——教你如何从零开始找到值得做的想法，并在动手前完成验证。当然，即便已有想法，快速浏览本节也能帮你发现验证流程中的盲点，避免常见陷阱。

前置知识：MVP 与 PMF

• MVP（Minimum Viable Product，最小可行产品）：用最少资源验证核心假设的产品版本。它的目标不是"完美"，而是"足够验证"。
• PMF（Product-Market Fit，产品市场匹配）：指产品与市场需求的匹配程度。当产品满足市场需求时，用户会主动拉新、留存曲线变平，即达到 PMF。

这两个概念贯穿全文：MVP 是验证的手段，PMF 是验证要逼近的终点。

为什么要验证想法

在投入时间写 PRD 和开发之前，必须确认一件事：这个想法值得做吗？

跳过验证直接开发的代价是惨痛的。文档指出，创业公司失败的第一大原因是"没有市场需求"，占比高达 42%。这背后是无数个"我觉得用户需要"的假设，未经任何验证就被当成了事实。创业者对想法充满热情，这种热情既是动力也是盲区——人一旦全身心投入某个想法，就容易陷入确认偏误，只看见支持自己的证据，忽略危险信号。

验证的本质是风险管理，核心逻辑是"失败得越早，成本越低"：

验证的目的不是证明想法正确，而是尽早发现致命缺陷。最好的结果恰恰是发现想法行不通——这能节省数月的开发时间。验证过程可能令人沮丧，因为很多"好主意"经不起推敲，但这种沮丧是健康的：它意味着你在用真实世界的标准检验想法，而不是在幻想中自我陶醉。

灵魂三问

在开始任何验证之前，先问自己三个问题。它们的价值不在于得到答案，而在于迫使你从自我陶醉中清醒过来，用市场视角重新审视想法。这是产品验证三步法的第一步（docs/Advanced/03-prd-doc-driven/index.md 将其概括为"用户是谁？痛点在哪？为何用你？"）。

问题一：用户是谁？

模糊的回答等于没有回答。"所有人"不是用户，"年轻人"不是用户，"需要这个功能的人"也不是用户。

具体的回答指向可触达的人群：

• 职场人士中每天需要处理 5-10 个任务的人；
• 每周五需要花 2 小时汇总周报的销售团队；
• 只会用微信、不会复杂操作的父母。

为什么具体用户重要？因为不同用户群体的痛点、使用场景、支付意愿完全不同。为"所有人"设计的产品，最终谁也服务不好。当你说"所有人"时，实际上是在逃避选择——选择意味着放弃，放弃不合适的用户，才能为真正合适的用户提供更好的服务。具体用户画像的价值在于让你能够想象出一个真实的人在真实情境中使用产品，这种具象化想象是做出正确产品决策的基础。

问题二：痛点在哪？

"我觉得需要"不是真痛点。"应该会有人用"也不是。真痛点是：用户现在有解决方案，但那个方案很痛苦。

• 便签纸容易丢、手机备忘录打开太麻烦——这是真痛点，因为用户每天都在经历；
• "没有这样的工具"不是真痛点，因为用户可能根本不在意这个问题。

判断痛点真实性的两个标准：

1. 看用户是否已经尝试解决。如果用户没主动搜索过解决方案、没花钱或花时间尝试替代方案，这个"痛点"可能只是你的想象。
2. 看用户是否已经付出代价。代价可以是金钱（购买昂贵软件或服务）、时间（每天花大量精力处理繁琐流程）、情绪负担（焦虑、沮丧、尴尬）。当用户已经为解决问题付出代价，说明这个问题对他们真实且重要；如果用户只是口头说"这确实是个问题"却从未行动，那这个"痛点"优先级很低。

需求的三个层次

在定义产品需求时，用户需求有三个层次，理解它们能帮你更精准地定位产品价值。这也是 PRD 编写中"核心问题"部分的理论根基（对应 docs/Advanced/03-prd-doc-driven/00-prd-template.md 中 1.2 节"目标用户画像 / 用户场景 / 核心痛点"的拆解方式）：

编写 PRD 时，分别列出这三个层次能让产品定位更精准：先确保痛点被解决，再逐步加入痒点，最后用爽点打造差异化。MVP 应专注于解决痛点——只有痛点才能让用户真正愿意使用你的产品。

问题三：为何用你？

"因为我们技术最好"用户不在乎。"因为界面好看"用户不买账。"因为 AI 做的"这不是卖点。

真实优势源于三个方面：

1. 更好解决痛点：更快、更便宜、更简单；
2. 独特的获客渠道：你能触达而别人不能；
3. 独特的数据或资源：别人没有。

这个问题迫使你面对竞争现实。大多数市场都不是空白——你的竞争对手可能不是另一家创业公司，而是 Excel 表格、纸质笔记本，或是"什么都不做"这个默认选项。用户切换解决方案是有成本的：学习新工具的时间、迁移数据的麻烦、适应新流程的不适。如果你的优势不足以抵消这些成本，用户就不会切换。很多时候答案不是"为何用你"而是"根本不需要你"，能接受这个答案，就节省了后续所有投入。

真实访谈法：三条原则

真实访谈法的核心原则是：通过好问题获取真实数据，避免虚假信号。其理念是——如果问题设计得当，即使是亲近的人也无法给出违心的回答。

原则一：谈论他们的生活，而非你的想法

当谈论自己的想法时，人们出于礼貌会给出正面反馈，这种反馈毫无价值，因为它不反映真实行为。正确方式是谈论对方的生活：最近在忙什么？遇到了什么问题？怎么解决的？如果问题与你的想法相关，自然会有深入了解的机会。

这个原则的核心是避免"推销陷阱"。当你开始描述想法时，对方会立即进入社交礼仪模式——点头、微笑、说"听起来不错"，这不是恶意欺骗，而是社交本能。你需要的是关于用户真实处境的信息，而不是礼貌的赞同。只有把话题集中在对方身上，他们才会放下戒备，分享真正有价值的细节。

原则二：询问过去的具体行为，而非未来的假设

"你会用吗"会得到虚假肯定。"多少钱愿意买"会得到不真实的数字。人们对自己未来行为的预测极不准确——当被问到"你会用吗"时，人们倾向于想象一个理想化的自己，那个更有条理、更愿意尝试新事物的自己。

正确方式是询问过去：

• 上一次遇到这个问题是什么时候？
• 当时怎么处理的？
• 试过哪些方法？
• 花了多少时间和金钱？

过去的行为是已经发生的事实，无法被理想化的自我形象扭曲。当用户描述上次遇到问题的具体情境时，你会了解到问题的真实频率、严重程度和实际采取的解决措施——这些信息远比任何关于未来意愿的声明更有价值。

原则三：多听少说

对话中说得越多，获得的真实数据越少。当对方开始表达观点或提出问题时，往往透露出他们的真实想法和关注点。不要打断，不要急于"纠正"或"补充"。

这个原则对技术人员尤其困难：听到用户描述问题时，大脑会立即开始构建解决方案，你想说"其实你可以这样做"或"我们的产品正好能解决这个"。但这种冲动必须克制——每一次你开口解释，都是一次学习机会的丧失。用户的描述中往往包含他们自己都没意识到的深层信息：工作流程、优先级排序、组织内部的权力结构。这些信息只有在他们用自己的语言、按照自己的逻辑讲述时才会浮现。

好问题 vs 坏问题

好问题引向具体行为和真实动机，坏问题引向观点和承诺。

坏问题类型

好问题类型

虚假信号的陷阱

访谈中最危险的并不是沉默，而是听起来积极、实则毫无价值的"数据"。

赞美不是数据

"想法很棒""保持联系"——这些话听起来积极，但毫无价值。识别虚假赞美的方法：看对方是否做出实质性付出——是否愿意花更多时间深入讨论？是否愿意引荐相关人士？是否愿意预付或做出其他承诺？如果都没有，这只是礼貌的拒绝。

一个真正感兴趣的人会主动询问细节、想了解更多、提出具体建议或介绍，他们会投入自己的社会资本（时间、人脉、声誉）来表达支持。如果对话结束后对方只是礼貌地说"保持联系"然后杳无音信，请把它当作负面信号，而不是未来的希望。

"我会用"的真相

"我会用"有三层含义：真会、客套、拖延。区分方法同样是看对方是否已经为这个问题付出过代价（时间、金钱、努力）。如果对方从未主动搜索过解决方案，那么"我会用"只是客套。

功能建议的陷阱

访谈中对方提出"如果能加个 XXX 功能就好了"——这看起来是需求，但直接实现可能浪费时间。正确方式是深挖动机：为什么需要这个功能？没有它时怎么处理的？这个功能带来什么价值？很多时候，表面需求背后有更简单、更本质的解决方案。

MVP 验证思维

MVP 不是"残缺版产品"，而是"能验证假设的最简版本"。这是产品验证三步法的第二步（docs/Advanced/03-prd-doc-driven/index.md）。

这个定义纠正了一个常见误解：很多人听到 MVP 想到的是"先做个简陋的版本上线，以后再完善"。这种理解有两个问题：一是"简陋"往往意味着用户体验糟糕，会让潜在用户过早放弃；二是"以后再完善"往往永远不会到来，因为产品上线后，新需求和 bug 会占据所有时间。

正确理解是：MVP 是一个实验工具，目的是以最小成本验证最核心的假设。假设被验证就继续投入，被证伪就及时止损。MVP 的"最小"不是指功能少到无法使用，而是只包含验证假设所必需的功能——一个优秀的 MVP 应该让用户完成核心价值主张承诺的体验，即使这个体验由手工流程在后台支撑。

MVP 的形式

MVP 不一定是代码：

选择 MVP 形式时问自己：这个假设能否用更简单的方式验证？

验证假设的层次

假设有多个层次，从"用户存在"到"用户愿意付费"，每层都需要验证，不要跳过：

快速验证方法

这是产品验证三步法的第三步：用最小成本验证假设，失败得越早、成本越低。

手工验证

在写代码之前，先用手工方式服务用户，这能最快验证需求是否真实。比如想做外卖 App，先建个微信群接单——如果一周都没几个订单，App 做出来也不会有用户。

落地页测试

做一个简单页面，描述产品功能，收集邮箱或预订单。如果没人留下联系方式，说明需求不成立。

访谈技巧

找到目标用户，进行 15-30 分钟对话。不要推销、不要展示产品，专注了解对方的生活和问题。每次访谈前准备好 3 个最想验证的问题，确保每次对话都能推动认知前进。

常见问题

Q1：需要访谈多少人？目标不是几百次，而是5-10 次有效访谈。当 3 次连续访谈没有新信息时，基本可以停止。

Q2：找不到目标用户怎么办？这是风险信号。如果找不到用户访谈，可能用户群体不存在或无法触达——这两个都是致命问题。

Q3：访谈得到的都是正面反馈怎么办？检查是否提到了自己的想法、是否问了未来行为而非过去行为。重新设计问题，聚焦具体行为和真实代价。

Q4：验证通过后，还需要继续验证吗？验证不是一次性事件。随着产品发展，新的假设需要新的验证，要持续保持验证心态。

仓库实践线索：把验证结论落到代码上

vibe-vibe 仓库中的演示项目恰好为"灵魂三问 → 痛点 → MVP"这条路径提供了可运行的实现证据，可以作为你验证想法后的下一个参照物。

1. 从痛点出发的极简待办 MVP。文档中"便签纸容易丢、手机备忘录打开太麻烦"正是 demo-01-todo 要解决的痛点。这个项目的 MVP 形态是"极简清单 + CRUD"：核心数据模型只有todos一张表（id、title、completed、category、dueDate、order、createdAt），见 demos/demo-01-todo/src/db/schema.ts；C（增）与 R（查）两个操作封装在 demos/demo-01-todo/src/app/api/todos/route.ts 中。它没有登录、没有云同步、没有团队协作——这正是"只包含验证假设所必需功能"的 MVP 定义在代码层面的体现。

2. 用校验和测试守住"有效数据"的底线。访谈原则说"具体行为无法撒谎"，落到代码里就是输入校验：demo-01 用 Zod 定义了createTodoSchema（标题 1-200 字、分类枚举、截止日期可选），见 demos/demo-01-todo/src/lib/validation.ts；对应的测试用例覆盖了"正常创建返回 201""空标题返回 400""缺标题字段返回 400"等行为，见 demos/demo-01-todo/tests/todos.test.ts。这提醒你：访谈中收集到的"数据"同样需要像代码输入一样经过可信度校验。

3. 从"用户存在"到"用户体系"。当待办产品通过"用户存在"验证后，下一步通常就是引入用户体系。demo-02-todo-auth 展示了这一演进：user、session、account、verification四张表构成认证底座，todos表通过userId外键关联用户，见 demos/demo-02-todo-auth/src/db/schema.ts 与 demos/demo-02-todo-auth/src/lib/queries.ts。这与验证层次表中"用户存在 → 痛点真实 → 方案可行 → 可持续"的递进逻辑一致：先证明有人要，再证明能留住人。

4. 验证"可持续"前的数据设计。如果产品有社交属性，"可持续"层次的验证需要先想清楚关系模型。demo-03-social-schema 给出了一个完整的社交产品数据模型：用户、帖子、评论、点赞、关注、标签及帖子-标签多对多关系，全部带唯一索引约束，见 demos/demo-03-social-schema/src/db/schema.ts；其 seed.ts 在插入数据前先用 drizzle-zod 生成的校验 schema 逐个验证用户与帖子数据，validation.ts 中定义了昵称 1-50 字、内容 1-2000 字、评论 1-500 字等边界。这说明：在你决定写代码之前，先像这样把"用户是谁、产生什么内容、互相如何互动"画清楚，本身就是一次低成本的数据层验证。

验证通过后，下一步就是与 AI 确认需求，让 AI 明确说出它的理解，再基于标准模板编写 PRD——详见 3.2 与 AI 确认需求 与 3.3 PRD 编写实战（英文版见 docs/en/Advanced/03-prd-doc-driven/02-discuss-with-ai.md、docs/en/Advanced/03-prd-doc-driven/03-prd-template-guide.md）。

本节核心要点

• ✅验证的目的是尽早发现致命缺陷，而非证明想法正确——失败得越早，成本越低；
• ✅灵魂三问快速筛选想法：用户是谁、痛点在哪、为何用你；
• ✅需求三层次：痛点（Must-have）优先，痒点（Nice-to-have）迭代加入，爽点（Wow-factor）打造差异化；
• ✅真实访谈法三原则：谈生活不谈想法、问过去不问未来、多听少说；
• ✅好问题引向具体行为，坏问题引向观点和承诺；
• ✅MVP 不是残缺产品，而是能验证假设的最简版本——形式可以是非代码的手工服务、落地页或原型；
• ✅假设要分层验证：用户存在 → 痛点真实 → 方案可行 → 可持续（付费）；
• ✅赞美和承诺不是数据，真实行为和付出才是。

• 文档
• 教程
• Vibe Coding
• 示例工程