夜雨聆风
AI产品的MVP设计:先收窄边界,再想别的
AI产品的MVP不是”功能最少的版本”，而是”用最小成本验证AI能力边界的版本”。核心就三件事：划定边界、设计兜底、灰度验证。
上一篇聊了需求验证的三把尺——数据、场景、成本。
三把尺全过了，需求可以立项。立项之后第一个要面对的问题就是：MVP怎么做？
传统软件的MVP思路很简单——砍功能，砍到最核心，先上线看反馈。AI产品的MVP不一样。砍功能不解决核心问题，因为AI产品最大的不确定性不是”功能够不够”，而是“AI能不能做好这件事”。同一个功能，换一批数据、换一个场景，效果可能天差地别。所以AI产品MVP的核心目标不是验证功能需求，而是验证能力边界。
这篇文章聊的就是怎么设计一个能验证能力边界的AI MVP。
AI MVP vs 传统MVP：区别在哪？
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
一句话：传统MVP验证”该不该做”，AI MVP验证”AI能不能做好”。
第一件事：划定能力边界
能力边界是AI产品MVP最核心的东西。很多AI产品失败，不是技术不行，是PM把边界画得太宽——既想让AI干这个，又想干那个，结果哪个都没干好。
好的AI产品PM会主动收窄能力边界，在窄边界内做到极致。
能力边界三要素
1. 输入边界：AI能吃什么？
定义AI接受什么输入、拒绝什么输入。
-
支持什么格式（文字/图片/语音/混合） -
支持什么话题（商品咨询可以，竞品对比不行） -
支持多长内容（超过500字截断处理） -
支持什么语种
2. 输出边界：AI能说什么？
定义AI能输出什么、不能输出什么。
-
能给信息但不能给承诺（”建议您联系售后”可以，”保证三天退款”不行） -
能推荐但不能决策（”这个产品评分较高”可以，”您应该买这个”不行） -
涉及专业领域的话术要限定范围
3. 场景边界：AI在什么情况下用？
定义AI的适用场景和不适用场景。
-
辅助场景 vs 决策场景（辅助可以，决策不行） -
高峰期 vs 低谷期（先用低峰期试，稳了再扩） -
新用户 vs 老用户（先给老用户用，反馈更真实）
一个真实案例：智能客服AI的边界设计
┌─────────────────────────┐
│ 智能客服AI 能力边界 │
├────────────┬──────────────┤
│ 能做 │ 不能做 │
├────────────┼───────────────┤
│ 商品咨询问答 │ 涉及账户安全操作 │
│ 订单状态查询 │ 退款金额协商 │
│ 商品图片识别 │ 复杂投诉（需要情绪安抚） │
│ 退换货流程引导│ 评价竞品 │
│ 3轮以内对话 │ 承诺具体退款时间 │
└──────────┴──────────────────┘
注意一个设计原则：先定义”不能做什么”，再定义”能做什么”。“不能做”的清单决定了你的风险上限，”能做”的清单决定了你的价值下限。
第二件事：设计Fallback（兜底机制）
AI不可能100%准确。问题是，当AI答错的时候，怎么办？
这就是Fallback机制要解决的事。
四种兜底策略
策略一：规则兜底
AI置信度低的时候，不走AI，直接走规则。典型场景：用户说”我要退款”，AI不需要理解退款原因，直接调退款流程API。用户说”我要投诉”，直接转人工。
适用：有明确规则可处理的场景（退款、改地址、查物流）
策略二：人机协作兜底
AI先处理，人再审核或补充。
典型场景：AI生成文案，人审核后再发布。AI回答问题，用户觉得不满意可以一键转人工。
适用：AI效果不太稳定但人工成本可控的场景
策略三：多模型兜底
主模型搞不定的，换一个更强的模型来处理。
典型场景：日常问题用便宜模型（DeepSeek），复杂问题自动切到贵模型（GPT-4）。
适用：对效果要求高、有多个模型可选的场景
策略四：预设回复兜底
AI完全理解不了的时候，返回标准话术。
典型：”抱歉，我不太理解您的问题。您可以：1. 转人工客服 2. 查看帮助中心 3. 换个方式描述您的问题”
适用：冷启动阶段或AI能力有限时
Fallback触发条件表
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PM设计Fallback时要问自己三个问题
-
最坏情况是什么？ AI最离谱的错误会导致什么后果？是用户多等了5秒，还是用户损失了钱？ -
用户能自救吗？ 当AI出错时，用户有没有办法绕过AI、找到人或者找到正确答案？ -
兜底成本是多少？ 转人工的客服成本、规则维护成本、多模型调用的额外费用——这些都得算进ROI。
第三件事：灰度发布
传统产品上线是”开或者关”。AI产品上线必须是”开一点点，看看，再开多一点”。因为AI在测试环境里的表现，和真实用户场景里的表现，差距可以非常大。
三种灰度策略
策略一：用户分桶灰度
按用户ID分批开放，逐步扩大比例。
Day 1-3 → 5%用户（约1万人） → 验证基础功能
Day 4-7 → 20%用户（约4万人） → 收集Bad Case
Day 8-14 → 50%用户（约10万人） → 验证稳定性
Day 15+ → 100%全量 → 正式上线
策略二：场景灰度
先在简单场景开放，稳了再扩展到复杂场景。
阶段一：标准问答（商品咨询、订单查询）
阶段二：中等复杂（退换货引导）
阶段三：全场景（含投诉处理）
策略三：功能灰度
先开放低风险能力，再逐步开放高风险能力。
阶段一：AI推荐（只推荐，不决策）
阶段二：AI自动回复（中等风险）
阶段三：AI自主操作（高风险，需用户授权）
灰度期必须盯的指标
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
灰度决策流程
灰度启动 → 每日盯数据 → 周度评估
如果指标全达标 → 扩大灰度比例
如果某个指标不达标 → 分析原因 → 优化后继续
如果出现严重Bad Case → 立即回滚，不等全量
一个关键原则：宁可灰度慢一点，不要全量翻车。灰度阶段是发现问题的最佳时机，发现越多，全量后的坑越少。
拿一张模板走：AI MVP设计卡
每做一个AI功能的MVP，建议填这张卡：
三个最容易犯的错
错 1：MVP功能堆太多
不是功能越多越好验证，是越少越好验证。一个MVP只验证一个核心假设。你想验证AI客服能不能替代人工，就只做一个场景——商品咨询。不要一上来就加投诉、加售后、加推荐。
错 2：没有Fallback直接上线
没有兜底机制的AI产品，就像没有刹车的车。上线第一天的Bad Case就会毁掉用户信任。Fallback不是”后期优化项”，是”必须第一版就有”。
错 3：灰度周期太短
很多团队灰度两三天就全量了。两三天能发现什么？只能发现明显的Bug，发现不了效果波动、长尾Bad Case、用户信任度变化。灰度至少跑两周，数据才够做判断。
回到开头那句话
AI产品MVP的核心目标不是”功能最少的版本”，而是”用最小成本验证AI能力边界的版本”。
怎么做？三步走：
划定边界
——先想清楚AI不能做什么，再想能做什么。边界越窄，越容易在边界内做到极致。
设计兜底
——AI一定会犯错，犯错的时候用户怎么自救？这个机制必须在MVP第一版就有。
灰度验证
——不要一口气全量上线。从5%开始，盯数据，发现问题，修好再扩。
边界定清楚了，兜底设计好了，灰度跑稳了，这个AI功能才算真正”活了”。