MVP 验证的不是功能
AI 项目的第一个版本，最常见的失败不是技术做不到，而是做了一大堆功能，却没有验证最关键的假设：用户是否愿意为这个问题的解决付钱或花时间。
因此第一版只保留一条完整链路：输入、处理、输出，中间不做配置中心，不做权限系统，不做报表。
用一句话写下假设
把项目假设写成：「我们相信，[某类用户] 在 [某场景] 下，会因为 [AI 能力] 而获得 [可衡量的结果]。」如果这句话里有一个词无法验证，第一版就要围绕它设计。
- 用户是谁：越具体越好，不要写「所有企业」
- 场景是什么：一次真实发生的任务，而不是虚构流程
- 结果怎么衡量：时间、成本、满意度、转化率，选一个
四到八周的时间盒
带 AI 能力的产品原型，我们通常建议 4-8 周。第一周做需求梳理与数据准备，中间四周做核心链路，最后一周做真实用户测试。
如果两个月还没有一个真实用户用上，说明范围仍然太大，需要再切一刀。
上线后只看三个数
使用次数、完成率和用户原话。使用次数说明是否有人回来，完成率说明链路是否真的通，用户原话则告诉你下一步该修哪里。
MVP 的终点不是「功能做完」，而是「假设被验证或推翻」。
第一版最容易踩的三个坑
第一个坑是功能太多：为了显得完整，把配置、权限、报表都塞进第一版，结果核心链路反而没做深。第二个坑是数据太晚接入：用假数据验证出来的产品，接入真实数据后往往完全不成立。
第三个坑是验证指标选错：只测「有没有人用」，不测「用完之后有没有价值」。把这三个坑避掉，MVP 才算真正完成使命。
MVP 之后怎么办
假设被验证后，下一步不是立刻堆功能，而是把验证过的核心链路做深：提升稳定性和性能，补齐权限与安全，再谈扩展。
假设被推翻时，也要诚实地停下来。很多团队因为已经投入了时间，舍不得推翻，结果在一个错误方向上越走越远。
MVP 的真正产出不是代码，而是「继续做、调整做、还是不做」的决策依据。
给 MVP 一个结束仪式
MVP 验证结束那天，开一场简短的决策会，而不是直接进入下一轮开发。会上回答三个问题：假设成立了吗、证据是什么、下一步是继续、调整还是停止。
把决策和证据写成一份一页纸记录，存档到项目资料里。三个月后再看，这份记录会比任何复盘都有价值。
给 MVP 一个明确的结束仪式，团队才能从「验证模式」干净地切换到「建设模式」，不会带着没有结论的假设继续开发。