AI原生 APP 的 MVP，不是“把传统 APP 缩小一圈”，而是用最少的产品能力验证一个核心假设：用户是否愿意用自然语言提出意图，系统能否稳定完成关键任务，并形成可持续的业务闭环。边界划错，产品要么退化成普通功能堆砌，要么陷入模型、知识库和智能体工程，迟迟无法上线。
先锁定一条核心闭环
划定范围时，先回答三个问题：核心用户是谁，最迫切的任务是什么，完成任务后产生什么可验证的价值。电商场景中，MVP不必同时建设直播、分销、虚拟试穿和复杂推荐；只需围绕“描述需求—匹配商品—解释选择—完成下单”打通一条链路。企业办公产品也不宜把所有部门需求都纳入一期，应优先选择少数高频场景，例如文档问答或流程辅助。
“功能数量”不是MVP标准，“核心闭环是否成立”才是。凡是不能帮助用户完成主任务、不能验证产品假设、上线后暂时不影响安全与合规的功能，都应进入迭代池，而不是一期范围。
AI能力要小而关键
AI原生并不等于一期必须搭建私有知识库、复杂智能体或自研模型。接入现成模型完成智能客服、语义搜索、内容生成等能力，通常比建设完整的RAG或多工具工作流更适合早期验证。选择AI亮点时，应优先考虑它能否减少操作步骤、改善决策质量，或直接推动转化，而不是追逐技术名词。
较稳妥的范围是“3个核心场景＋1个AI亮点”：业务底座负责账户、数据和交易等必要能力，AI只介入最能体现差异化的环节。模型输出还必须具备失败兜底、人工接管和结果校验，否则演示效果可能很好，真实使用却无法形成信任。
用验证结果推动扩张
需求冻结前，应把每项功能写成可验收的用户任务，并明确成功条件、异常处理、数据归属和后续迭代入口。需求验证期可先用1至2周收敛范围，再通过敏捷开发交付可内测版本。上线后观察用户是否持续使用核心功能、是否愿意完成关键动作，以及AI输出是否真正减少了人工成本或决策负担。
MVP的终点不是“功能做完”，而是获得下一轮产品决策所需的证据。只有核心闭环被验证，新增功能才有资格进入路线图；否则，越早扩张，越可能把技术复杂度误当成产品价值。
