原型、Demo和MVP不能按“完成度越来越高的三个版本”简单划分。原型用来表达并验证设计；Demo是一种演示方式，可以展示原型，也可以展示已经运行的功能；MVP则围绕真实用户和具体假设，提供足够小但能被使用的价值。AI生成了可点击页面，说明你有了可供体验的产物，是否已构成MVP，还要看用户能否在明确范围内完成真实任务，以及团队是否得到可判断的反馈。
如果要先确认用户能否理解流程，使用墨刀原型组织页面与交互就很合适；如果要决定是否继续投入，则需要先写下要验证的假设和观察方式。把产物叫什么与它能证明什么分开，能避免拿一次顺畅演示替代真实需求判断。
三个词分别回答哪个问题
| 类型 | 主要目的 | 常见形态 | 不能单独证明 |
|---|---|---|---|
| 原型 | 表达方案、检查流程和交互 | 纸面草图、低保真页面、可点击高保真界面 | 真实接口、权限、稳定性及长期使用价值已经成立 |
| Demo | 向特定受众演示某项能力或体验 | 演示脚本、可操作页面、功能样机、录屏 | 演示之外的路径同样可用，或用户愿意持续使用 |
| MVP | 以小范围可用价值检验关键产品假设 | 小功能产品、限定人群的服务、部分人工完成的流程 | 已经达到完整产品规模，或商业模式已被最终验证 |
三者可以重叠。一个可点击原型可以拿来做Demo；一个MVP也可以安排Demo向新用户说明怎么使用。反过来，一个界面逼真的Demo可能只连接了少数脚本路径；一个界面朴素、后台靠人工处理的服务，也可能用于MVP验证。判断依据是使用方式与证据，不是画面是否精致。
以设备借用为例，分别应该做到哪一步
假设一个团队想改善相机、投影仪和录音设备的借还管理。当前靠群聊登记，大家常常不知道某台设备何时能借到。待验证的想法是“成员能够自己查可用时间并提交申请，管理员不必反复在群里确认”。下面三类产物各有适用场景。
原型：验证成员是否看懂并完成申请
先画设备列表、可用时段、申请确认和结果页。用固定设备与日期让参与者完成“借一台投影仪开周五会议”。观察他们是否理解可用日期、能否找到归还时间、是否知道提交后还需审批。这里不一定要有真实库存或登录服务。
有效结论可能是“日期选择让人误以为归还当天不能使用”“申请结果没有说明谁审批”。这些问题可以通过修改原型验证，不需要先开发完整库存系统。
Demo：向管理员展示一条完整处理过程
演示者可以从成员申请一路展示到管理员确认和归还提醒，解释产品如何工作。若通知、审批或库存只是预设状态，要在交接时明确它们当前的实现范围。Demo适合帮助人理解方案、讨论投入和获取反馈，不宜把观众点头直接记成“需求验证成功”。
MVP：让限定团队实际借还一类设备
可以先只面向一个小团队、一类设备和一个管理员，提供真实的查询、申请与借还记录；后台确认允许暂由人工完成，前提是服务范围和处理时段清楚。团队此时观察的是用户是否真的改用这个流程、有没有反复回到群聊、管理员能否处理实际冲突。
这不意味着MVP必须是一套完整软件，也不意味着手动操作就一定合适。涉及付款、隐私或高风险操作时，基本安全与责任要求不能以“小规模验证”为理由省略。
AI生成的可点击页面，当前属于哪一种
先检查页面中的操作究竟改变了什么。点击“提交”只是打开成功弹层，还是写入可恢复的记录；刷新后结果是否还在；换一个角色是否真有不同权限；多人同时选择同一设备时如何处理。回答这些问题，才能决定下一步工作，而不是只看有没有按钮动画。
墨刀AI生成原型支持从需求得到页面，并通过对话或局部编辑继续完善；这适合快速形成可讨论的方案。是否达到真实使用条件，需要结合实际项目补齐业务与工程工作。生成工具的产物也可能包含代码，但“有代码”和“服务已经可以交付”仍是两件需要分别确认的事。
| 当前观察到的结果 | 可以据此做的判断 | 下一步 |
|---|---|---|
| 固定样本的主流程能点击完成 | 方案可以用于流程讨论或演示 | 检查误解、遗漏状态和不合理顺序 |
| 有可运行代码，使用模拟数据 | 可以检查部分前端行为和工程结构 | 确认数据、权限、部署与异常处理范围 |
| 限定用户可以完成真实借还任务 | 具备观察真实行为的基础 | 按事先约定的问题收集反馈和失败记录 |
| 完成一次顺畅演示，暂无实际使用 | 受众理解了这条演示路径 | 不要据此推断留存、需求规模或稳定性 |
怎样决定现在需要原型、Demo还是MVP
先问“什么不确定性最可能让我们做错”。如果问题是用户看不懂流程，先做原型；如果问题是利益相关者不了解方案，准备清楚的Demo；如果问题是用户在真实情境下是否会改用产品，就设计小范围实际验证。若主要疑问是外部接口或设备能力能否实现，可以先由研发做技术验证，不必先包装成完整产品。
一个简单的决策方法是把假设写成句子，再问当前产物是否有机会观察到它。比如“用户找不到可用设备”可以通过任务观察调查；“成员愿意放弃群聊登记”则不能只靠一次被要求点击原型来确认，需要在真实借用情境里观察选择。
不要让“先做MVP”成为跳过判断的理由。如果连用户是谁、当前如何处理问题都不清楚，先访谈、观察或画流程可能更合适；也不要因产品能人工处理就无限扩大试点，把验证变成无法承受的运营负担。
在开始前，写一张真正有用的验证卡
下面是设备借用练习可用的材料。它没有预设真实效果数字；业务团队应根据可获得用户、现有基线和决策成本，再决定观察窗口与通过条件。
| 项目 | 填写示例 |
|---|---|
| 待验证假设 | 成员能在需要借设备时自行查询并提交完整申请 |
| 适用范围 | 一类设备、一个管理员、确认过的成员名单 |
| 用户得到的价值 | 看见可借时间，并得到明确的申请处理结果 |
| 观察材料 | 进入查询的人、完成申请的人、失败原因、回到群聊的原因；分母分别记录 |
| 人工工作 | 管理员确认库存与交接，记录处理时间和例外 |
| 继续条件 | 用户问题被解决，主要失败原因可改善，人工负担在可接受范围内 |
| 缩小或停止条件 | 用户没有实际需要、核心约束无法满足，或维护成本超过验证价值 |
“访问了页面”“完成了演示”“实际借到设备”应分别记录。它们处于不同阶段，不能相加成一个成功率。成员在指导下完成任务，也要与独立完成区分，否则很容易把演示者的帮助误当成产品的可用性。
下一阶段的投入，跟着问题走
如果原型暴露的是操作障碍，就先改流程；如果Demo让团队发现规则没有统一，就先确认规则；如果真实使用表明用户不需要这一服务，就应重新检查方向，而不是用更多页面掩盖问题。只有下一步投入能够减少关键不确定性时，继续建设才有明确意义。
关于如何划定首个可用范围，可以继续阅读MVP范围与验证方法。对于从AI页面起步的项目，保留原型、规则和使用反馈之间的联系：让每一轮页面修改回答一个真实问题，再决定是否扩大功能或用户范围。
