第五步：快速制作最小版本（MVP）

先说结论

MVP 的目标只有一个：验证这个方案在真实业务里行不行。一切不能帮助回答这个问题的功能，都先不做。

企业工作示例

销售报价助手的 MVP：一个网页表单，销售输入客户和配置，AI 生成报价草稿，销售检查后导出。没有权限系统、没有对接 CRM、没有漂亮的报表——但核心流程能跑通，销售愿意试。

两周后数据证明方向可行，才逐步补上权限和系统对接。

操作步骤

1. 只保留核心流程：从目标流程图里挑出"没有它就没有价值"的那 2-3 步。
2. 选最轻的工具组合：自动化平台 + 表格数据库 + AI 生成的简单界面，能拼就不从零写。
3. 人工替代未做的部分：MVP 阶段可以用人工补位（比如手动导数据），先验证流程再自动化。
4. 设定短周期验证目标：简单内部场景可以尝试 1-2 周；复杂集成和受监管场景应根据风险单独估算。判断 MVP 的标准是“最小且能验证假设”，不是固定天数。
5. 能演示、能试用：让用户能真的点、真的用，而不是看你放的录屏。

MVP 里可以先不做的

• 精细的权限体系（先用小范围人群控制）
• 和核心系统的正式对接（先用导入导出代替）
• 完善的界面设计（够用、清楚就行）
• 各种边界情况处理（先记着要人兜底）

常见错误

• 把 MVP 做成小号正式版：功能砍不下来，周期拖到一两个月。
• 先搞架构：微服务、容器编排和 MVP 无关。
• 闭门造车：做完才给用户看。做到一半就该让用户点一点。
• 忽略兜底：MVP 可以简陋，但不能没有人工兜底。

检查清单

• MVP 只包含核心流程的 2-3 个关键步骤
• 已按复杂度设定最短合理验证周期，并记录延期原因
• 真实用户可以亲手操作
• 未自动化的部分有明确的人工补位
• 有明确的人工兜底

下一步

第六步：使用真实样本评测