MVP通常指最小可行产品：用足够小、但能提供核心价值的产品或服务，验证最重要的业务假设。做MVP不是把完整产品随意删成几页，而是先确定要学到什么，再保留完成这次验证必需的内容。想先把方案做出来讨论，可以用墨刀AI生成原型，再决定哪些部分值得进入真实试运行。
以办公园区午餐预订为例，第一轮可以只验证“员工是否愿意提前选择午餐并按时自取”，不必同时建设配送网络、会员体系和复杂推荐算法。本文的业务、数据字段和验证安排都是教学设定，不是已发生的客户案例。
MVP、原型和Demo，不是按页面多少区分
原型主要用于表达和讨论设计；Demo主要用于展示某种能力或方案；MVP则围绕关键假设提供足够的价值，并从实际使用中学习。它们可能采用相似界面，但目的不同。一套可点击页面能帮助发现流程问题，却未必能证明用户愿意持续使用或付费。
Atlassian对MVP的介绍将早期用户使用和反馈放在核心位置。选择多小的版本，要看此次假设：验证找餐流程可以先用原型；验证履约体验，则需要真实安排供餐和自取，不能只在页面上模拟成功。
午餐预订第一版，保留什么、暂时不做什么
| 保留内容 | 为什么需要 |
|---|---|
| 有限菜品与可预订时段 | 让员工能完成一次真实选择 |
| 明确价格、取餐点和截止时间 | 让用户知道承诺与约束 |
| 提交预订与查看结果 | 让需求可以被记录和履行 |
| 取消或异常联系入口 | 减少无法取餐时的信息断点 |
| 基础运营记录 | 知道有多少请求被接受、完成或取消 |
暂不做跨园区配送、积分商城、智能推荐和多层级优惠。人工整理订单可以作为早期运营方式，但不能省略食品、支付、个人信息等环节的必要保障。MVP的“最小”针对范围，不是降低应承担的责任。
如果人工工作量已经超过团队可承受范围，就应缩小试运行规模或暂停扩展。不能因为界面已经生成，就默认服务能力也会自动跟上。
先用原型确认员工能否看懂预订流程
设计园区午餐预订原型，包含菜单、餐品详情、预订确认、我的预订四页。显示菜品、价格、取餐点、取餐时段和本轮截止时间。用户可选择餐品并查看预订结果。补充菜品售完、超过截止时间、取消预订和暂无预订状态。第一版不做配送、积分和推荐，使用示例数据，不接真实支付。
生成后，先从菜单点进详情，再提交预订并查看结果。重点检查取餐时间和地点是否一路保持一致，失败状态有没有下一步。若页面缺少关键说明，可以直接要求局部修改，并在预览中重复同一任务。
找几位接近目标用户的参与者，观察他们能否理解截止时间、修改选择和找到预订记录。这里只能得到流程方面的观察，不能用一次演示的满意度推导长期购买需求。
进入小范围试运行后，记录哪些数字
试运行前先约定记录口径，而不是结束后挑有利的数字。可以记录触达且有机会预订的人数、提交预订人数、成功履约人数、取消人数和重复参与人数，同时记录试运行日期、渠道及供餐限制。
例如“提交预订人数/实际看到本轮预订入口的人数”可以帮助理解参与情况，但分母必须能够合理获得。如果只有提交记录，没有曝光记录，就不能计算可信的参与转化率。重复提交也不应被当作多个独立用户。
不要照搬别人的合格阈值。是否继续投入，应结合当前成本、容量、替代方式和目标决定。可以预先写明：“若员工主要因取餐点太远取消，先调整取餐安排；若根本不愿提前决定午餐，重新检查需求假设。”这比事后解释所有结果都成功更有价值。
反馈来了，先分清是需求不成立还是方案不好用
用户没有预订，可能是不需要提前订餐，也可能是没看见入口、菜品不合适、取餐时间冲突。访谈与行为记录要一起看。不要只根据没有点击就否定需求，也不要只根据用户口头说喜欢就继续扩大投入。
如果问题集中在找不到订单，可先改原型与入口；如果问题集中在供餐不稳定，应先处理履约；如果用户已有更方便的替代方式，则需要重新判断价值主张。每一类问题对应的下一步不同，不应都归结为“再加几个功能”。
什么时候值得把MVP做成更完整的产品
当核心使用方式相对稳定、主要问题清楚、团队能够承接后续服务，并且有足够依据支持下一阶段投入时，再扩展系统。可以逐步补自动化订单处理、账号体系、运营后台与监控，但新增内容要回应已经观察到的问题。
若需要形成更清楚的功能范围，参考AI写PRD教程；准备进入工程实现时，再看快速开发APP的实施路线。在墨刀AI做出MVP的原型方案之后，把真实使用与履约反馈接上，才有机会判断下一步是否值得做。
