3.2 MVP 的正确打开方式——既不简陋也不臃肿的最小可行产品

模块三：产品设计与前端实战 | 第02讲：MVP 的正确打开方式——既不简陋也不臃肿的最小可行产品

项目：VibeNote 智能笔记
本讲主线：MVP 不是「阉割版」，而是用最小成本验证最大不确定性。你将学会 MoSCoW 排优先级、范围控制对抗蔓延，并用 **「不做清单」**保护主路径。读完这一讲，你应该能自信地说：我的 VibeNote 不是做得少，而是学得快、迭代更稳、方向更专注、浪费更少。

---

一、先把概念摆正：MVP 到底验证什么

业界最常见的误读，是把 MVP 当成「很快糊出来的 demo」或「只有 CRUD 的壳」。在精益语境里，MVP 的 M 是 Minimum，V 是 Viable——可运行、可学习、可迭代。它最小化的对象是浪费，不是质量。换句话说：你可以少做功能，但不能少做「关键路径上的可靠性」与「失败后的可理解性」，否则用户根本没有机会给你反馈，你也学不到该学的东西。

对 VibeNote 而言，一个合格的 MVP 必须回答：

1. 用户能否在真实场景里完成关键任务？
2. 完成后，你是否能观测到留存或复访信号？
3. 失败时，你是否能定位是价值问题还是体验问题？

如果做不到第 3 点，你的 MVP 往往「简陋到学不到东西」：用户走了，你只知道「他们不喜欢」，却不知道卡在哪一步。

课程原文「3.2 MVP到底怎么做」强调的路径，本质是先明确价值，再定义边界，再组织实现，最后用数据校准方向。本讲把它落到可执行的优先级与范围治理上。

flowchart TB
  V["价值假设 Value"] --> S["范围 Scope"]
  S --> I["实现 Implement"]
  I --> L["学习 Learn"]
  L -->|调整| V

---

二、Viable 的三根支柱：可用、可信、可学

2.1 可用（Useful）

不是「功能存在」，而是主路径顺畅。对笔记产品，最小可用通常是：创建 → 保存 → 再次找到 → 编辑。任何阻断这条链路的缺陷，优先级都应高于「好看的空状态动画」——当然，最佳实践是两者兼顾，但当资源冲突时，先保主链路。

2.2 可信（Trustworthy）

尤其是 AI 功能：用户需要明确知道内容来自模型、可能出错、如何恢复。MVP 可以没有完美的免责声明设计，但不能没有失败可恢复（例如润色前自动本地草稿、错误可重试）。

2.3 可学（Learnable）

你必须提前设计观测点：哪些日志、哪些事件、哪些问卷问题能告诉你「为什么不用了」。没有观测点的 MVP，只是上线，不是实验。

flowchart LR
  U["用户行为"] --> E["事件埋点/日志"]
  E --> A["分析"]
  A --> H["假设更新"]
  H --> B["Backlog 调整"]

---

三、MoSCoW：把「重要」翻译成「顺序」

MoSCoW 把需求分成四类：

• Must：没有它，MVP 不成立。
• Should：没有它会很痛，但可以临时替代。
• Could：有更好，没有也能学。
• Won't：本期明确不做（这是 MVP 的灵魂）。

常见错误：把大量功能放进 Must，因为「没有它不完整」。正确做法：Must 只保留服务 H0（北极星假设） 的条目；其余默认降级。

3.1 VibeNote 示例（承接上一讲验证）

假设 H0 是「记录—回顾更快」，一版合理的 MoSCoW 可能是：

• Must：笔记创建/编辑/列表；本地或服务端可靠保存；基础搜索或按时间排序；Markdown 渲染；AI 摘要（若这是你当前验证焦点）且失败可重试。
• Should：分栏预览；标签；导出。
• Could：主题切换；快捷键大全；模板库。
• Won't：多人协作、权限体系、插件市场、离线冲突合并（除非你的赌注变了）。

注意：Must 不是越多越好；Must 越多，学习速度越慢，因为你同时验证太多变量。

---

四、范围控制：范围蔓延不是「需求变更」，而是纪律失守

范围蔓延（Scope Creep）在 AI 时代会加速：你和模型对话时，它很乐意「顺手加上」。因此需要工程化的护栏：

1. 范围文档一页纸：写清 Must/Should/Won't。
2. 变更门禁：新增 Must 必须删除同等复杂度的 Must，或推迟发布。
3. 双周回顾：把「临时加一下」打回原形：它到底服务哪条假设？

flowchart TD
  R["范围变更请求"] --> Q{"服务 H0?"}
  Q -->|否| X["拒绝或延后"]
  Q -->|是| T{"有同等移除?"}
  T -->|否| Y["重新排期"]
  T -->|是| A["批准并入本迭代"]

---

五、「不做清单」：伟大产品往往是减出来的

不做清单（Not Now List）与 backlog 同等重要。它解决的是心理账户：你不是「永远不做」，而是「现在不做，以免干扰学习」。一份写得好的不做清单，会让你在深夜冲动加需求时有一个地方「把愿望寄存起来」：先写下来，不等于现在做，从而显著降低范围蔓延的概率。

建议你公开写出来（README 或 PRD），例如 VibeNote：

• 本期不做实时协同光标
• 本期不做富文本所见即所得
• 本期不做全站全文搜索引擎（若你用简单 filter 已够验证）
• 本期不做账号体系的 OAuth 全家桶

写作技巧：每条「不做」都补一句「我们用 X 代替验证」，否则会被误解为偷懒。

---

六、MVP 的两种失败：简陋失败 vs 臃肿失败

6.1 简陋失败

症状：主路径断、数据丢、错误不可理解。用户不会给你第二次机会。
对策：把 Must 里的「可靠性」写进 DoD（Definition of Done）：保存成功提示、失败重试、关键操作可撤销或备份。

6.2 臃肿失败

症状：功能很多，但不知道哪个驱动留存；开发很慢；每次改都牵连巨大。
对策：砍 Won't 比加功能更重要；用 MoSCoW 强制聚焦。

---

七、可运行代码：MoSCoW 打分器（Node / TypeScript）

把需求条目结构化，避免「口头优先级」在 AI 协作里漂移。

// scripts/moscow-prioritizer.ts
// 运行：npx tsx scripts/moscow-prioritizer.ts

type Bucket = "Must" | "Should" | "Could" | "Wont";

type Item = {
  name: string;
  bucket: Bucket;
  risk: 1 | 2 | 3; // 1低 2中 3高
  learnValue: 1 | 2 | 3; // 对学习目标的价值
};

const backlog: Item[] = [
  { name: "笔记保存与列表", bucket: "Must", risk: 2, learnValue: 3 },
  { name: "Markdown 预览", bucket: "Must", risk: 2, learnValue: 3 },
  { name: "AI 摘要", bucket: "Must", risk: 3, learnValue: 3 },
  { name: "标签系统", bucket: "Should", risk: 2, learnValue: 2 },
  { name: "深色主题", bucket: "Could", risk: 1, learnValue: 1 },
  { name: "多人协作", bucket: "Wont", risk: 3, learnValue: 1 },
];

function score(i: Item): number {
  const bucketWeight: Record<Bucket, number> = {
    Must: 100,
    Should: 10,
    Could: 1,
    Wont: -999,
  };
  if (i.bucket === "Wont") return -999;
  return bucketWeight[i.bucket] + i.learnValue * 5 - i.risk * 4;
}

const ranked = [...backlog].sort((a, b) => score(b) - score(a));
console.log("排序（越高越应先做）：");
for (const i of ranked) {
  console.log(`${i.name} | ${i.bucket} | score=${score(i)}`);
}

这段代码的价值是：把「讨论」变成「可重复计算」。你可以在评审会上现场改 learnValue，让团队对齐「我们到底要学什么」。

---

八、MVP 与 AI 协作：给模型的不是「愿望」，而是「边界」

当你用 Cursor / Copilot 生成前端时，务必在提示词里贴：

• Must/Should/Won't
• 主路径用户故事（Given/When/Then）
• 非目标

否则模型会默认「做一个看起来很完整的笔记应用」，你将得到臃肿 MVP。

推荐提示词骨架：

• 角色：Next.js 14 + TS + Tailwind + shadcn/ui
• 目标：只实现 Must 列表
• 约束：不要引入新后端框架；不要加协作；组件拆分在 components/
• 验收：列出可手工走通的步骤

---

九、从 V2.0 到「可学习 MVP」：检查清单

如果你已按模块二做出 V2.0（分栏 + AI 工具栏），在进模块三 UI 升级前，先回答：

• 你是否能用一句话描述 H0？
• Must 列表是否 ≤7 条？
• Won't 列表是否 ≥5 条？
• 你是否记录过三次真实用户的完整操作路径？
• 你是否知道「用户放弃」发生在哪一步？

任何一条为否，优先补课，而不是继续加皮肤。

---

十、里程碑拆分：MVP 也要分段合并（像模块二 PR-A/B/C）

即使 MVP 很小，也建议 分段 PR：

• PR-1：主路径 + 样式最小集
• PR-2：AI 能力 + 错误处理
• PR-3：观测（日志/事件）+ 文案

这能避免「一次大合并后不知道哪里坏了」。

---

十一、数据与指标：MVP 也要最小埋点

你不需要复杂分析平台，初期可以用：

• 服务端日志：AI 调用失败率、延迟分位
• 前端事件：note_created、note_reopened、ai_summary_used
• 每周一次人工复盘：把事件漏斗画在笔记本上

关键：埋点服务于假设，不是为了报表好看。

---

十二、心理建设：MVP 是「学习装置」，不是「作品完美度」

独立开发者常把 MVP 当作品展示，导致迟迟不发。正确心态是：MVP 是实验仪器，仪器的标准是信噪比，不是雕花。

---

十三、对照表：优秀 MVP vs 自欺欺人版

维度	自欺欺人	优秀实践
Must 数量	15+	少而硬，通常 ≤7
Won't	没有写	明确写，且对外可见
学习指标	只有 DAU	有关键漏斗与失败信号
AI 功能	炫技堆参数	失败可恢复、提示清晰
发布节奏	等大功能齐	每段 PR 可回滚可验证

---

十四、延伸：当你必须加需求时，如何「等价交换」

若业务方说「这个必须加」，你应问：删掉哪个 Must？或推迟到哪一周？
没有交换的范围扩张，必然稀释学习速度。对 solo 开发者，「业务方」通常就是明天的你自己——更要无情一点。

---

十五、复盘清单

• 已为 VibeNote 写出 MoSCoW 表
• Won't 清单已能说服「未来的你」
• 运行了 moscow-prioritizer.ts 并调整过一次参数
• 主路径 DoD 已写成可勾选条目

---

十六、深度拆解：「最小」到底最小到什么粒度？

很多人把「最小」理解成「少做页面」，但更精确的定义是：最小化同时验证的未知数。一次迭代最好只动一个主要变量：例如本轮只验证「AI 摘要是否提升回顾效率」，那就不要让「全新编辑器交互」同台竞技，否则失败时你无法归因。

对 VibeNote，推荐的粒度是「一条用户故事 + 一组观测指标 + 一组 Won't」。用户故事越短越好，例如：「作为复盘用户，我希望在笔记列表看到一段摘要，以便我不用点开全文就能定位会议记录。」这句话天然约束了 UI：列表需要摘要字段，而不是整个工作台重做。

再补一张「范围分层图」，帮助你在架构讨论里对齐语言：

flowchart TB
  subgraph Core["核心层 Core"]
    C1["主路径"]
    C2["数据可靠性"]
    C3["关键 AI 能力"]
  end
  subgraph Support["支撑层 Support"]
    S1["可观测性"]
    S2["错误处理"]
    S3["基础无障碍"]
  end
  subgraph Polish["抛光层 Polish"]
    P1["动效"]
    P2["皮肤主题"]
    P3["锦上添花功能"]
  end
  Core --> Support --> Polish

纪律：Polish 层再诱人，也不能牺牲 Core 层的学习信号。你可以把抛光层全部丢进 Could，等核心假设被支持后再开闸。

---

十七、时间盒与「学习预算」：MVP 必须有截止日期

没有截止日期的 MVP 会变成产品：你会无限打磨。建议给 MVP 实验设 2 周时间盒（solo 可放宽到 3 周），并写清：

• 截止前必须可观测的信号是什么（例如 20 次摘要调用、5 次复访）
• 到期未达标怎么办（换假设 / 换人群 / 换主路径）

时间盒不是粗暴，而是对抗完美主义与范围蔓延的唯一可靠工具。

---

十八、VibeNote 的「非目标」范文（可直接粘进 PRD）

本期非目标（Won't）

1. 不支持多人同时编辑同一笔记。
2. 不提供插件与第三方小程序容器。
3. 不提供复杂的文件夹层级权限。
4. 不提供离线优先与冲突合并（除非出现明确付费客户）。
5. 不提供全量 OCR 与图片手写识别。

替代验证手段

• 用「导出 Markdown」验证用户是否要迁移；
• 用「只读分享链接」验证协作需求是否为只读即可；
• 用「标签 + 搜索」验证组织需求是否可被更简单结构满足。

你会发现：非目标写得越具体，AI 越不会替你「好心加戏」。

---

十九、MoSCoW 与 Roadmap 的映射：避免「列表无限增长」

实践上你可以维护两张表：

1. Learning Roadmap：只含假设与实验，按时间排序。
2. Delivery Roadmap：只含 Must/Should，严格受 Learning Roadmap 门禁。

flowchart LR
  L["Learning Roadmap"] -->|门禁| D["Delivery Roadmap"]
  D -->|实现| R["Release"]
  R -->|数据| L

当有人提议加功能，先问它属于哪条学习实验；对不上就别进 Delivery。

---

二十、从「功能」切换到「任务」：写用户故事的高级技巧

差的故事写功能：「做一个标签系统」。
好的故事写任务：「当我积累了 30+ 笔记，我希望能用两个关键词缩小范围，以便我在会议前 1 分钟找到那份记录。」

差别在于：后者自带场景、频率、时限，因此你能判断 Must 真伪。AI 也能据此生成更贴近交互细节的界面，而不是生成「数据库里多一张表」。

---

二十一、MVP 评审会：solo 也要做的 15 分钟「自我质询」

1. 我现在最想加的功能，服务哪条假设？
2. 如果砍掉它，我还能验证吗？
3. 本周结束我能否用数据说话，而不是用感觉？
4. 我是否在用「工程成就感」替代「用户学习」？
5. Won't 列表是否被我偷偷撕掉了一页？

这套质询很痛，但比上线后无人使用更痛。

---

二十二、与模块二 Workflow 的对齐：MVP 也要分段验证

模块二强调 Plan/Review/Implement/Verify。对 MVP：

• Plan：输出 MoSCoW + 主路径故事 + 指标
• Review：只砍需求，不加需求（加需求走变更流程）
• Implement：严格按 Must
• Verify：对照指标，写下「学到的一句话」

---

二十三、常见问答：MVP 与「技术债」怎么共处？

MVP 允许技术债，但只允许 可追踪、可偿还 的债：写下 ADR（Architecture Decision Record）或 TODO 注释，标明「为何现在妥协」与「何时偿还」。不允许的债是：数据丢失风险与安全红线——它们不属于学习成本，属于事故成本。

---

二十四、对照表：VibeNote 功能在三轮迭代中的漂移示例

功能	探索期 MVP	增长期	商业化期
AI 摘要	Must（验证学习）	Should（优化质量/成本）	Must（差异化）
深色模式	Won't	Could	Should
协作	Won't	Won't/Should	视细分人群
搜索	Must（极简）	Should（增强）	Must

这张表提醒你：同一功能在不同阶段的优先级会变，所以 MoSCoW 要随假设迭代重排，而不是一次定终身。

---

二十五、复盘清单（加强版）

• 你能用用户故事格式写出 3 条 Must 吗？
• 你的 Won't 是否包含「你最想做的功能」？若没有，可能不够诚实。
• 你是否给 MVP 设了时间盒与到期决策？
• 你是否能把学习指标讲给非技术听众听？

---

二十六、实战演练：把「想法风暴」收敛成一张 MoSCoW 表（含反面案例）

反面案例：团队在白板上写了 30 个功能，最后说「都是核心」。这不是 MoSCoW，这是购物清单。
正面流程：先静默脑暴 5 分钟 → 合并同类项 → 每条需求必须映射到用户任务 → 只能有 1 个「本轮最大赌注」 → 其余降级。

下面给你一张可直接复制的 Markdown 表头：

需求	用户任务	MoSCoW	风险	学习价值	依赖	备注

填表时强制规则：Wont 行数不得少于 Must 行数。这听起来武断，但能防止你被「全能笔记」诱惑。

---

二十七、VibeNote 与 AI 成本的现实约束：把「能跑」写进 Must 的隐藏项

很多团队把 AI 功能放进 Must，却忘了把 成本控制 与 超时策略 写进去，结果 MVP 在演示时漂亮，真实用时账单爆炸或延迟劝退。建议在 Must 增补两条「工程 Must」：

• 超时：超过 N 秒自动中断并提示重试（N 由你根据目标用户耐心设定）。
• 配额：开发/测试环境使用独立 key 与限额，防止一次调试把预算烧光。

这不是「运维细节」，而是 Viable 的一部分：用户不会把「慢且贵」当作可用产品。

---

二十八、从「功能完备」到「故事完备」：用三张卡片描述 MVP

1. 触发：用户为什么现在打开 VibeNote？
2. 行动：用户点击/输入的最短序列是什么？
3. 回报：用户在 30 秒内得到什么可感知收益？

如果第三张卡片答不出来，你的 MVP 可能还在「工具层面」而不是「价值层面」。AI 写作助手尤其容易掉进这个坑：用户要的不是「模型很厉害」，而是「我少花了时间」。

---

二十九、范围蔓延的「五种借口」与拆穿话术

1. 「顺便做一下」——拆穿：顺便的代价是验证信号被污染。
2. 「不加这个不完整」——拆穿：不完整是策略，不是事故；学习优先。
3. 「竞品都有」——拆穿：竞品可能服务不同赌注；抄功能不抄假设很危险。
4. 「AI 一行代码的事」——拆穿：维护、测试、交互、失败恢复都不是一行。
5. 「上线后再说」——拆穿：上线后你更不敢删，债务利滚利。

把这张清单贴在 AGENTS.md，让 AI 助手也遵守范围纪律。

---

三十、延伸阅读：精益思想在 Vibe Coding 里的新含义

传统精益强调「尽快接触用户」。在 Vibe Coding 时代，你还要强调「尽快接触真实运行环境」：本地很快、线上很慢；模型很快、审核与合规很慢。MVP 的 Definition of Done 建议包含：至少一次预发布环境走查，否则你会把「开发机上的 MVP」当成「世界的 MVP」。

---

三十一、术语对照（方便你写英文 PRD 或与国际客户沟通）

• MVP：Minimum Viable Product，最小可行产品
• Scope：范围；Scope creep：范围蔓延
• MoSCoW：Must / Should / Could / Won't
• H0：本轮最大赌注假设
• DoD：Definition of Done，完成定义

---

三十二、再给一个可运行脚本：从 Markdown 清单生成 MoSCoW 统计（Python）

适合你把 PRD 里的条目复制到文本文件后快速统计比例，检查是否「Must 过多」。

# scripts/moscow_count.py
# 运行：python scripts/moscow_count.py

from collections import Counter

lines = """
Must: 笔记列表
Must: 编辑器保存
Should: 标签
Could: 动效
Won't: 协作
""".strip().splitlines()

bucket = Counter()
for line in lines:
    if line.startswith("Must:"):
        bucket["Must"] += 1
    elif line.startswith("Should:"):
        bucket["Should"] += 1
    elif line.startswith("Could:"):
        bucket["Could"] += 1
    elif line.startswith("Won't:"):
        bucket["Wont"] += 1

print(bucket)
ratio_must = bucket["Must"] / max(1, sum(bucket.values()))
print(f"Must 占比: {ratio_must:.2f} （经验上建议不超过 0.45）")

你可以把这段脚本接入 CI 的「文档检查」：当 Must 占比异常升高时，直接在 PR 评论里提醒「范围可能失控」。对 VibeNote 这种迭代频繁的项目，这种自动化羞辱往往比人工提醒更有效，因为它不针对个人，只针对结构。

---

三十三、复盘清单（终检）

• 你为 AI 协作准备了「Must + Won't + 主路径故事」三件套吗？
• 你是否能解释「为什么要现在学这件事」而不是「为什么想要这个功能」？
• 你是否把时间与金钱预算写进计划，而不是默认无限？

---

三十四、写给「完美主义者」的一段狠话（但有用）

如果你迟迟不发 MVP，通常不是因为你要求高，而是因为你害怕面对评价。MoSCoW 与 Won't 清单其实是你的心理护甲：它们告诉你——现在验证的不是你的才华，而是世界的反馈。把作品当成实验仪器，你的自尊就不会绑在每一条 UI 曲线上了。VibeNote 这种个人工具型产品尤其如此：你越是早点让真实用户使用，越能早点从「自嗨式功能堆叠」里毕业。记住：用户不会在你脑子里开会，他们只会在你发布的版本里投票。

把 MVP 当成「采样器」而不是「作品终稿」，你会更敢发布：采样器的标准是样本是否有效，不是外壳是否华丽。下一讲我们要把这些采样结论固化进 PRD，让 AI 在明确的边界内高速迭代，而不是在模糊的愿望里反复横跳。

---

三十五、从表格到看板：用四列管理本周交付（Trello/Notion 通用）

四列建议命名为：Must 正在做 / Must 待验证 / Should 排队 / Won't 冰柜。规则很简单：Won't 冰柜里的卡片任何人不得拖到其他列，除非通过「变更门禁」记录原因。你会惊讶于这种幼稚规则能拯救多少深夜加戏。

再补一条「团队只有一个人」时的技巧：把 Won't 冰柜 设成公开页面（哪怕是 GitHub Issue 里的一张表）。公开承诺会显著提高你撕掉 Won't 的成本，从而保护你的迭代节奏。很多人失败不是因为技术，而是因为对自己不够无情。

---

三十六、思考题

1. 如果你砍掉 VibeNote 里一半功能，保留哪三条 Must？为什么？
2. 举一个「Should 伪装成 Must」的例子，并说明如何识破。
3. 你如何向非技术干系人解释 Won't 不是「永远不做」？
4. AI 功能失败时，你的 MVP 最小恢复策略是什么？

---

三十七、下讲预告

当你把 MVP 当作方法而不是挡箭牌，你会同时获得两种自由：对用户更诚实（不假装全都能做），对自己更温柔（不必一次做对）。这份自由，才是 Vibe Coding 时代最稀缺的工程资产。

第03讲进入 PRD 驱动开发：你会拿到一份面向 AI 的 PRD 模板，理解「文档质量 = AI 产出上限」，并把 VibeNote 的需求写成模型与人类都能执行的规格。

---

参考：课程原文 课程内容/3.2 MVP到底怎么做：既不简陋也不臃肿的实操方法.md。把本讲与上一讲连读，你会看到「验证三步法」与「MVP 边界」是同一条链路的上下半段。