3.1 需求验证三步法——功能做了一堆却没人用的根本原因

少林码僧
3 阅读17分钟

模块三：产品设计与前端实战 | 第01讲：需求验证三步法——功能做了一堆却没人用的根本原因

项目：VibeNote 智能笔记（Next.js 14 + React + TypeScript + Tailwind + shadcn/ui）
本讲主线：先验证「问题是否真实」，再验证「方案是否对症」，最后用 MVP 验证「用户是否愿意用」。功能堆得多，往往只是用忙碌掩盖了不确定性。

一、为什么「没人用」比「做不出来」更伤

很多 Vibe Coding 初学者最容易踩的坑，是把 AI 的产出速度误当成产品进度：一晚上能生成十几个页面，一周能换三套 UI，但上线后日活始终是个位数。课程原文在「3.1 功能做了一堆却没人用」里点破了一个朴素事实：真正拉开差距的往往不是语法，而是方法的顺序——先明确价值，再定义边界，再组织实现，最后用数据校准方向。

对 VibeNote 来说，典型幻觉包括：

  • 「用户需要 AI 润色」——这可能是假设，不是事实；也许用户更需要的是快速检索或结构化模板。
  • 「笔记应用要有标签、文件夹、双向链接」——这是竞品清单，不是你的用户在特定场景下的唯一痛点。
  • 「先做全功能再推广」——这会把验证推迟到成本最高的阶段；Lean 的核心是尽早用低成本实验把假设变成证据。

本讲给你一套可复制的需求验证三步法：问题验证 → 方案验证 → MVP 验证。它不要求你立刻成为资深产品经理，但要求你建立证据意识：每一个关键判断，都要能指向「我如何知道我是对的」。

二、三步法的骨架：先问「是不是真问题」

把验证拆成三步，不是为了写文档好看，而是为了降低同时犯错的维度。一维一维地排除不确定性，返工会指数级下降。

flowchart LR
  subgraph Step1["第一步：问题验证"]
    P1["痛点是否高频"]
    P2["现有替代是否够差"]
    P3["付费或留存动机"]
  end
  subgraph Step2["第二步：方案验证"]
    S1["概念是否可理解"]
    S2["关键路径是否更短"]
    S3["风险是否可接受"]
  end
  subgraph Step3["第三步：MVP验证"]
    M1["最小功能闭环"]
    M2["可观测指标"]
    M3["学习预算与迭代"]
  end
  Step1 --> Step2 --> Step3

2.1 第一步：问题验证（Problem）

目标：证明「有一群人，在某个场景下，被某个阻碍反复折磨」。
反面：只证明「我觉得这个 idea 很酷」。

对 VibeNote，你可以用一页纸回答：

  • Who：谁是第一期用户？（例如：用 Markdown 写技术笔记的独立开发者；用碎片化时间整理会议纪要的职场人——只能选一个作为主画像。）
  • When：什么时候最痛？（通勤路上？深夜复盘？会议刚结束？）
  • Why now：为什么旧办法不够？（系统备忘录搜索弱、Notion 太重、本地文件难同步——要落到可观察行为，而不是形容词。）

2.2 第二步：方案验证（Solution）

目标：证明「你的解法让用户的关键路径变短」，而不是「功能列表更长」。
方法：用低保真原型、可点击 Demo、甚至手动服务（Concierge MVP）去验证概念。

对 VibeNote，方案验证要聚焦一条主路径，例如：

  • 「打开 → 记录 → 下次能秒找到」
    而不是同时验证「协作」「知识图谱」「插件市场」。

2.3 第三步：MVP 验证（Product）

目标：证明「用户真的会用，而且会回来用」。
指标：不要一上来就追求虚荣指标；先追求行为证据：7 日回访、单次会话完成率、核心按钮点击率。

三、User Research Lite：没时间做重研究时怎么搞

你不需要雇用研团队，但需要最小剂量的用户接触，否则你只是在和 AI 对话里「自我确认」。

推荐组合：5 次深度访谈 + 10 份结构化问卷 + 7 天行为日志（你自己的也行）。

3.1 访谈提纲（30 分钟版）

  1. 上次你为了解决「记录/查找笔记」花了多久？最后怎么做的？
  2. 哪一步最想骂人？能回忆一个具体例子吗？
  3. 如果有一个魔法按钮，你希望它帮你做什么？（禁止引导到「AI」）
  4. 你用过哪些工具？为什么没继续用？
  5. 如果明天要付费，你愿意为什么付？付多少量级？

3.2 问卷里更有信息量的不是选择题

让用户排序：速度 / 可靠 / 隐私 / 美观 / 协作 / 价格。
再给一个开放题：「请描述一次失败的笔记经历」——你会得到大量真实语料，后面写 PRD 与提示词都更准。

3.3 把访谈变成「假设登记簿」

每访谈 1 人，记录三条：

  • 假设（我们相信……）
  • 证据（因为对方说/做了……）
  • 下一步验证（我们要用哪个实验确认/证伪）

四、假设 vs 事实：团队里最容易混为一谈的两件事

flowchart TB
  H["假设 Hypothesis"] -->|"需要实验"| E["事实 Evidence"]
  E -->|"可复盘"| D["决策 Decision"]
  D -->|"落地"| B["Backlog"]
  B -->|"交付"| R["Release"]
  R -->|"观测"| M["Metrics"]
  M -->|"反馈"| H

假设示例（VibeNote）：

  • 「用户愿意为本地优先 + AI 摘要付费」
  • 「分栏 Markdown 比单栏更适合手机用户」

事实示例：

  • 「10 个目标用户里 7 个在手机上只写不超过 200 字」
  • 「他们 80% 的查找动作发生在记录后 24 小时内」

纪律：任何进入 Sprint 的功能，都要挂在一个可被证伪的假设上；否则它就是「兴趣开发」。

五、Lean Validation：低成本实验菜单（从便宜到贵）

  1. Landing Page + Waitlist：测「兴趣」，不测「留存」。适合冷启动。
  2. 可点击 Figma / v0 原型：测「理解成本」与「主路径」。
  3. Wizard of Oz：后台人工处理「AI 摘要」，前台只测流程是否顺滑。
  4. 单功能发布：例如只做「极速搜索」，其他全砍。
  5. 付费墙小流量实验：最贵，但最有信息量。

对 AI-native 产品，额外注意：模型成本与延迟也是需求的一部分；验证阶段就要记录「用户可接受的等待时间」，否则你会做出「很好看但没人等得起」的体验。

六、把三步法映射到 VibeNote：一页纸模板（可直接复制）

问题陈述：
「谁在什么场景下，因为什么阻碍，导致什么后果？」

当前替代方案：
「他们现在用什么？最大不爽点是什么？」

我们的赌注（单一焦点）：
「本期只证明：______ 比旧办法更快/更可靠。」

成功标准（7 天）：
「例如：70% 用户完成首条笔记；50% 次日回访。」

本期不做：
「例如：协作、插件、复杂权限。」

这张纸就是你后续给 AI 的最高优先级上下文：没有它，AI 只会帮你「更快地做错」。

七、可运行代码：假设登记与验证状态机（TypeScript）

下面脚本不依赖框架，Node 直接可跑：帮你把「假设—证据—状态」从口头搬到数据结构上，后续可演进为 JSON 文件或数据库表。

// scripts/validation-tracker.ts
// 运行：npx tsx scripts/validation-tracker.ts

type HypothesisStatus = "untested" | "supported" | "rejected" | "inconclusive";

type Hypothesis = {
  id: string;
  statement: string;
  targetSignal: string; // 你要观察什么信号
  status: HypothesisStatus;
  evidenceNotes: string[];
};

const vibenoteV1: Hypothesis[] = [
  {
    id: "H1",
    statement: "目标用户的核心痛点是记录后难以快速找回",
    targetSignal: "10 人中有 ≥6 人提到检索/查找困难",
    status: "untested",
    evidenceNotes: [],
  },
  {
    id: "H2",
    statement: "用户愿意接受 AI 摘要以换取更短的信息回顾时间",
    targetSignal: "试用后 ≥50% 用户每周使用摘要 ≥2 次",
    status: "untested",
    evidenceNotes: [],
  },
];

function updateHypothesis(
  items: Hypothesis[],
  id: string,
  note: string,
  next: HypothesisStatus
): Hypothesis[] {
  return items.map((h) =>
    h.id === id
      ? { ...h, status: next, evidenceNotes: [...h.evidenceNotes, note] }
      : h
  );
}

let board = vibenoteV1;
board = updateHypothesis(
  board,
  "H1",
  "访谈#03：用户描述上周找会议笔记花了 20 分钟",
  "supported"
);

console.log(JSON.stringify(board, null, 2));

你怎么用它：每周五把新证据追加进去；任何 untested 超过两周的假设，要么做实验，要么从路线图剔除。

八、与 AI 协作的硬规则：先验证，再扩写代码

结合课程原文的提醒：AI 不会自动理解你的业务上下文。三步法应写进 AGENTS.md 或团队规则：

  • 没有「问题陈述 + 非目标 + 成功指标」，不允许开新功能分支。
  • 任何 UI 大改，必须说明它服务哪条已验证假设。
  • 三连跪时不要加功能；回到第一步检查是不是伪需求。

九、常见反例：看起来很努力，其实在逃避验证

  1. 用功能堆叠掩盖焦点缺失：标签、颜色、主题、模板一起上，结果核心路径仍卡顿。
  2. 把「竞品有」当「用户要」：竞品功能往往是历史包袱。
  3. 把个人偏好当用户偏好：独立开发者最常犯；要用外样本纠偏。
  4. 把一次热情反馈当 PMF：「朋友都说好」是最危险的信号之一。

十、复盘清单（学完本讲你应该能回答）

  • 你能用两句话描述 VibeNote 第一期要验证的唯一问题吗？
  • 你的三个关键假设分别是什么？对应证据长什么样？
  • 你能否列出「本期不做」清单，并解释节省了什么成本？
  • 你是否能把验证结果翻译成下一版的指标与非目标？

十一、深入案例：VibeNote 如何从「功能清单」收敛到「单一赌注」

假设你在模块二结束时已经做出 V2.0：Markdown 分栏 + AI 写作助手。此时最常见的冲动是继续堆功能：标签系统、全文搜索、附件、模板市场、团队空间……三步法在这里的作用，是把冲动翻译成「赌注管理」。

错误路径：先列 20 个功能，让 AI 按周产出。你会得到看起来很专业的 backlog，但每个条目都缺少「服务哪条假设」。
正确路径：先写清 H0（北极星假设）：「用户会持续回来，是因为 VibeNote 让『记录—回顾』这条路径显著更快」。接下来所有功能都要么直接缩短路径，要么先搁置。

把 VibeNote 的主路径拆成可观测步骤（漏斗）：

  1. 打开编辑器并成功保存第一条笔记
  2. 24 小时内再次打开
  3. 使用「找笔记」相关能力（搜索/列表/摘要）完成一次定位
  4. 7 日内重复第 2 步 ≥3 次

验证动作举例：

  • 若漏斗卡在步骤 1：问题不在 AI，而在「首启成本」或「保存可靠性」。
  • 若卡在步骤 3：你可能高估了「写」的价值、低估了「取回」的价值——这时应优先验证检索，而不是再加写作花样。

再补一张「决策树」，帮助你在复盘会快速定责：

flowchart TD
  A["新增功能提案"] --> B{"是否缩短主路径?"}
  B -->|是| C{"能否用更低成本实验验证?"}
  B -->|否| D["进入冷宫 Backlog"]
  C -->|是| E["排入本迭代"]
  C -->|否| F["拆分为验证实验 + 实现两卡"]

十二、指标设计：North Star 与 Guardrail（没有指标就别谈验证）

北极星指标要回答「用户获得价值了吗」，而不是「我们多忙」。对笔记类工具，常见候选包括：

  • 每周活跃创作天数（WACD）：比 DAU 更贴近「真的在用」。
  • 核心任务完成率：例如「创建并成功再次打开同一条笔记」的比例。
  • 时间到价值（TTV）：从注册/首进到完成第一条有效笔记的中位时间。

护栏指标防止你「用伤害换增长」：

  • AI 调用失败率、P95 延迟
  • 崩溃率、数据丢失相关工单关键词
  • 用户主动删除账号/清空数据的行为（若可观测）

把指标写进验证文档的好处是：AI 写代码时也有验收标准。你可以在 PRD 里明确「P95 延迟 < 3s」之类约束，让实现阶段不被「能跑」糊弄。

十三、竞品拆解的正确姿势：抄功能不如抄约束

很多同学习惯做竞品矩阵：A 有协作、B 有白板、C 有 AI——然后得出「我们都要」。更有效的拆解是三层：

  1. 用户任务层：竞品帮助用户完成的关键任务是什么？最短路径几步？
  2. 约束层：它为什么做成这样？（性能、合规、生态、历史债务）
  3. 失效层：用户在什么场景会抛弃它？（太重、太贵、太慢、不信任）

对 VibeNote，若你对比「巨笔记」与「本地编辑器」，你会发现竞品往往在「协作」或「插件」上叠复杂度；而你的赌注如果是「个人知识工作者的极速回顾」，你应该选择性地无视它们的长板，否则你会被拖进无限功能战。

十四、笔记类产品的隐私与信任：验证阶段就要谈清

验证不是只有「喜不喜欢」，还包括「敢不敢用」。在早期访谈里加入两组问题：

  • 你是否介意笔记内容经过云端模型处理？可接受的匿名化/离线方案是什么？
  • 如果发生一次「AI 生成了错误摘要」导致你误判，你希望得到怎样的产品回应？

这类答案会直接影响你是否把某些 AI 能力放进 MVP，以及默认开关策略（opt-in / opt-out）。

十五、工作坊：两小时「验证冲刺」脚本（可团队共创）

  1. 0–15 分钟：每人写 3 条「我们相信」的假设，贴墙。
  2. 15–35 分钟：合并同类项，选出赌注最大的 1 条作为 H0。
  3. 35–60 分钟：为 H0 设计一个本周能完成的实验（原型/访谈/数据）。
  4. 60–90 分钟：写出 MVP 的非目标清单（至少 10 条「不做」）。
  5. 90–120 分钟：把成功标准改成可数字化的句子，并指定负责人。

结束时你应产出三张纸：H0、实验计划、非目标清单。这就是模块三后续 PRD 的「母文档」。

十六、与模块二衔接：把验证写进 Workflow，而不是写在 PPT

模块二强调 Plan → Review → Implement → Verify。本讲把 Verify 提前到「动手写大功能之前」：

  • Plan 阶段多一张「验证计划」卡片
  • Review 阶段红灯问题：「这功能对应哪条假设？证伪了怎么办？」
  • Implement 阶段只允许实现与当前实验直接相关的路径
  • Verify 阶段对照指标，不通过则 禁止合并下一批范围

这样 AI 再快，也只能在正确轨道上加速。

十七、答疑与纠偏：你可能还在心里反驳的四个问题

Q1：我只有一个人，也要搞「用户研究」吗？
要，但可以极简：每周找 1 个真实用户聊 20 分钟，胜过你和 AI 闭门造车 20 小时。独立开发者的优势是决策快，劣势是样本偏差大；研究的目的不是写报告，而是防止你把个人习惯当成市场真相。

Q2：验证会不会拖慢开发？
恰恰相反：验证便宜，返工昂贵。你用三天验证砍掉一个错误方向，通常能省下三周的无意义开发。Vibe Coding 让「写代码」变便宜了，于是更多人会在错误方向上高速前进——这才是真正拖慢你的东西。

Q3：我已经有种子用户了，还需要三步法吗？
更需要。种子用户往往对你更宽容，他们的反馈会系统性偏正；你要主动寻找「不那么喜欢你的人」或「用过一次就消失的人」，才能补齐证据。

Q4：AI 能不能帮我做验证？
能，但只能做助理：帮你整理访谈纪要、生成问卷草稿、把假设写成实验计划。它不能替代你与真实用户的对话，也不能替代你对业务场景的判断——否则你会得到「看起来很专业的幻觉文档」。

十八、场景演练：把同一需求写成「未验证版」与「已验证版」

以 VibeNote 的「AI 摘要」为例。

未验证版（危险）：
「我们要做 AI 摘要，因为 AI 很火，而且竞品都有。」
这句话里没有用户、没有场景、没有成功标准。

已验证版（可用）：
「目标用户是每周写 ≥3 篇技术复盘笔记的开发者；痛点是周末回顾一周内容耗时；我们假设『一键生成不超过 120 字的要点摘要』能把回顾时间从 30 分钟降到 10 分钟以内；本周用 5 次访谈 + 手工摘要模拟验证；若少于 3 人愿意连续三天使用，则暂停该方向。」

你会发现：已验证版几乎可以直接粘进 PRD，而未验证版只能粘进「愿望清单」。

十九、给 solo 开发者的「一周验证日历」（可复制）

  • 周一：写出 H0 与 3 条关键假设；列出可触达用户名单。
  • 周二：完成 2 次访谈；当晚更新假设看板。
  • 周三：做一个可点击原型（哪怕很丑），给第 3 位用户走主路径。
  • 周四：整理失败点：卡在理解、信任、性能还是价值？
  • 周五：开 30 分钟复盘会（一个人也要写复盘笔记）：决定下周是做 MVP 还是换假设。

这套节奏的意义是：让验证变成固定节拍，而不是「等项目不顺再做」的补丁。

二十、术语小抄：把「口头黑话」翻成可执行语言

  • 问题验证：证明痛点客观存在，而不是证明想法有趣。
  • 方案验证：证明你的解法比现有替代更优，而不是证明技术更难。
  • MVP 验证：证明有人持续使用，而不是证明你能做出来。
  • 假设：可被证伪的陈述；要包含「如果……那么……」结构。
  • 事实：可引用的观察结果（原话、行为、数据），而不是推断。
  • 学习预算：本轮实验最多允许消耗的时间/金钱/样本量；超出预算就必须决策转向。

把术语写进团队文档的价值在于：你和 AI 用同一套词，减少「看似聊得很投机、其实各说各话」。

二十一、附录：VibeNote 验证记录表（Markdown 模板，可直接粘贴）

## 验证记录 YYYY-MM-DD
- 实验编号：EXP-00x
- 关联假设：H1/H2/...
- 方法：访谈 / 问卷 / 原型走查 / 行为数据
- 样本：n=?（描述人群）
- 结果摘要：...
- 结论：支持 / 否定 / 不确定
- 下一步：继续 / 调整 / 停止（说明原因）
- 附件：录音纪要链接 / 截图 / 原始表格

建议你每个实验都保留「原始材料」，否则两周后你会忘记当时为什么做决策——AI 也无法在后续迭代里继承你的判断。

二十二、对照表：验证动作 vs 常见自欺（打印贴显示器旁）

你嘴上说实际在做什么更诚实的下一步
「用户会喜欢的」没有样本，只有直觉先找 5 个目标用户聊完再写 PRD
「先做出来再看」把验证推迟到高成本阶段先做原型走查或手工服务验证
「这是小细节」在主路径上反复摩擦把细节当缺陷记录进看板，优先消灭
「竞品都有」用功能清单代替策略追问竞品用户为什么仍不满意
「我这就是 MVP」功能仍然分散，没有主路径重新写 H0，删掉不服务 H0 的模块
「反馈挺好的」只听了赞美，没有追问流失原因主动回访「用过一次的人」

这张表的价值是羞辱你的侥幸心理：不是侮辱你，而是保护你的时间。

最后补一句「工程师听得进去」的话：验证并不是让你不写代码，而是让你把代码投放到更容易产生学习的地方。就像性能优化要先 profiling 一样，产品优化要先证据化；否则你只是在随机改参数，还误以为自己很忙。对 VibeNote 这种 AI-native 应用，证据化还包括模型延迟、失败重试与提示注入带来的体验风险——它们同样会决定用户愿不愿意第二次打开你的应用。把本讲的方法固化成习惯，你会少写很多「将来一定要删」的临时代码。下一讲我们会把这些证据收敛成可执行的 MVP 边界。

二十三、思考题

  1. 如果 VibeNote 只能保留一个按钮，你会保留「写」还是「搜」？用三步法论证你的选择。
  2. 举一个你会用 Wizard of Oz 方式验证的 AI 功能，并说明如何人工模拟。
  3. 你如何区分「用户想要更多功能」与「用户想要更少摩擦」？各举一例访谈追问。
  4. 若验证结果证伪了你的核心假设，你如何设计「体面退出」或「转向」而不陷入沉没成本？

二十四、下讲预告

第02讲我们将进入 MVP 的正确打开方式：用 MoSCoW 做优先级、用 Scope 控制对抗范围蔓延，并建立正式的 「不做清单」——让你在做 VibeNote 时，既不交付简陋到无法学习，也不臃肿到无法迭代。

参考：课程原文 课程内容/3.1 功能做了一堆却没人用？先用三步法验证需求.md；项目方法论可参考 reference/practice/vibe-coding-methodology.md。

avatar
文章
阅读
粉丝