如何定义 MVP，避免项目越做越重
AI 项目最常见的失控方式，不是做错，而是做太多。大家很容易在一开始就想把推荐、记忆、多轮对话、自动执行、数据分析一次做满，最后把验证阶段做成了长期工程。
MVP 的核心不是“做少”，而是“做准”。更准确地说，应该追求 Minimum Verifiable Value，也就是最小可验证价值。
MVP 的目标
graph LR
A["很多想法"] --> B["切掉非关键项"]
B --> C["保留验证核心价值的最小能力"]
C --> D["快速上线验证"]
切 MVP 的三个判断问题
- 如果只有这一版，用户还能完成核心任务吗
- 如果这版有效，我们能明确知道为什么有效吗
- 如果这版失败，我们能快速知道失败在哪里吗
P0 / P1 / P2 的实用分法
| 优先级 | 定义 | 示例 |
|---|---|---|
| P0 | 不做就无法验证核心价值 | 知识检索、回答生成、人工转接 |
| P1 | 能显著提升体验，但可延后 | 多轮上下文、个性化推荐 |
| P2 | 增强能力 | 自主规划、多工具自动执行 |
一个 MVP 范围表示例
mvp_scope = {
"P0": ["FAQ 检索", "单轮回答", "人工转接", "日志记录"],
"P1": ["多轮上下文", "推荐相关文档"],
"P2": ["自动学习知识", "复杂 Agent 编排"],
"明确不做": ["跨系统自动执行", "高风险自动审批"],
}
for level, items in mvp_scope.items():
print(f"{level}: {items}")
MVP 为什么在 AI 项目里更重要
因为 AI 系统的可变因素太多：
- Prompt 质量
- 知识质量
- 模型能力
- 错误类型
- 用户预期
如果第一版范围太大，你根本不知道最后效果好坏到底由什么造成。
常见误区
| 误区 | 表现 | 后果 |
|---|---|---|
| 把愿景直接做成第一版 | “要一步到位” | 交付慢，验证慢 |
| 把 AI 能力全塞进去 | “都能做就都做” | 系统复杂度失控 |
| 不写非目标 | 边界越来越模糊 | 项目不断膨胀 |
案例演练：AI 销售助手
第一版如果要验证价值，P0 可能只需要：
- 读取产品知识库
- 回答常见售前问题
- 收集客户需求并分类
- 对高意向客户转人工
而不是一开始就做：
- 自动报价
- 自动发邮件
- 自动生成完整提案
- 自动推进 CRM 流程
课堂案例：SaaS Copilot 第一版到底该切到哪里
案例背景
一个数据分析 SaaS 想做 AI Copilot，团队列出了十几个想法：
- 数据问答
- 自动建图表
- 自动写周报
- 自动发告警
- 自动改配置
教学拆解
如果目标是验证“AI 是否能提升分析效率”，那第一版真正需要的可能只有：
- 自然语言查指标
- 报表摘要
- 异常波动提示
其余功能可以全部先砍掉，因为它们会显著增加复杂度，却不一定增加验证价值。
练习题
- 为什么功能越多，不一定越容易验证价值
- “Minimum Verifiable Value” 比传统 MVP 多强调了什么
- 为什么写非目标很重要
标准答案提示
- 从变量控制、结果归因和交付复杂度回答
- 核心是“验证价值”而不只是“做出最少功能”
- 非目标会直接防止需求膨胀和团队误解
本章 checklist
- 我是否定义了 P0 / P1 / P2
- 我是否明确写下“这版不做什么”
- 我是否确保第一版能验证核心结果
- 我是否能解释“为什么先做这几个，不先做另外那些”
本章小结
- MVP 的重点不是精简功能，而是验证价值
- AI 项目范围越大，越难解释结果
- 非目标和边界，是切 MVP 的必要动作
下一节：02-MVP切分方法与优先级框架 — 用 P0/P1/P2 三层切分法和价值-风险矩阵确定 MVP 边界。