📚 课程目录第1章 AI产品MVP认知

AI产品MVP需求规划与原型交付 - 第1节

1.1 AI产品MVP核心定义

AI产品MVP（Minimum Viable Product）不是“最小功能集”，而是最小可行验证单元——用最少的资源，在真实用户场景中检验核心价值假设是否成立。与传统软件MVP不同，AI产品MVP的“最小”边界必须覆盖数据、模型、交互三个维度的可行性，否则验证结果无效。

    关键认知：AI产品MVP的本质是“假设驱动”而非“功能驱动”。你需要在产品上线前就定义清楚：哪个价值假设一旦被证伪，整个产品就不该继续做下去。

AI产品MVP的“最小”不是无限缩小，而是在以下三个边界内找到可验证的最小交集：

数据边界：至少能获取 100～500 条高质量标注样本（视任务复杂度浮动），且能形成“采集 → 清洗 → 标注 → 反馈”的闭环链路。如果数据获取成本高于模型收益预期，MVP阶段就应该暴露这个矛盾。
模型边界：使用现有开源基座或 API 搭建基线系统（Baseline），不追求 SOTA。MVP 阶段模型的效果只要能让用户完成核心任务且不产生严重错误即可，重点在于验证“用户是否愿意在模型辅助下做这件事”。
交互边界：交互链路不超过 3 步（输入 → 处理 → 输出），避免在 MVP 阶段引入多轮对话、复杂配置或个性化记忆。交互设计的核心目标是降低用户对“机器输出”的信任摩擦，而非追求体验完美。

常见误区：团队常把“模型准确率从 85% 提升到 90%”作为 MVP 目标。实际上，AI 产品 MVP 的第一目标是验证“用户是否愿意接受 85% 准确率的产品”——如果用户不接受，再高的准确率也无法转化为产品价值。

每个 AI 产品 MVP 都需要同时定义两类假设，它们决定了验证方向与成功标准：

假设类型	核心问题	典型表述	验证指标示例
价值假设	用户为什么需要用 AI 做这件事？	“用 AI 生成会议纪要，能让用户节省 70% 的记录时间”	任务完成时长、用户留存率、NPS 中“是否愿意推荐”
增长假设	用户用完会叫更多人用吗？	“每个使用 AI 纪要的用户，每周会分享 2 次给同事”	邀请率、分享率、内容引用次数、自然传播系数

两类假设的关系：价值假设决定产品存亡——如果价值假设不成立，产品根本没有存在的必要；增长假设决定产品能否做大——价值假设成立但增长假设不成立，产品可以活但很难规模化。MVP 阶段应优先验证价值假设，只有当价值假设初步成立后，才开始系统验证增长假设。

实操建议：在项目启动前，用“一页纸假设清单”把价值假设和增长假设写下来，并标注“哪个假设一旦被证伪，项目立即终止”。这能帮助团队在 MVP 阶段保持决策清醒。

在定义 AI 产品 MVP 之前，必须将假设映射到具体的用户场景和业务问题上。以下是一个标准的三步映射方法：

    案例参考：某团队做“AI 会议纪要助手”MVP 时，没有直接做完整转写，而是只选取“行动项提取”这一个子场景，用 200 条历史会议记录训练一个简单的分类模型，通过微信群机器人每天推送摘要。3 周内验证了价值假设（用户阅读率 78%）和增长假设（分享率 34%），随后才扩展为完整产品。

第 1 章内容对应的验收标准是团队能够独立完成以下三项输出：

交付物	内容要求	验收标准
MVP 假设清单	写明价值假设 + 增长假设，并标注终止条件	每条假设可被单一指标证伪，无模糊表述
最小可行边界定义	数据、模型、交互三个维度的下限阈值	边界清晰可执行，团队对“什么算达标”无分歧
用户场景映射表	场景描述 → 痛点量化 → AI 介入点	介入点聚焦在一个可验证的子任务上，不 scope creep

章节自检：如果你的团队能在 30 分钟内向一名不了解项目的同事讲清楚“我们要验证什么假设、最小边界在哪里、用户凭什么用 AI 来做”，那么本章认知已经到位，可以进入第 2 章的用户访谈与需求拆解。