原型验证、MVP 与商业化版本

三阶段，三种完全不同的目标

阶段	核心问题	验证什么	典型周期
原型（Prototype）	能不能做到？	核心能力可行性	数天~数周
MVP	有没有人要？	价值假设：留存与付费意愿	数周~数月
商业化版本	能不能规模化赚钱？	单位经济、SLA、合规	持续迭代

最常见的失败不是技术不行，而是用错阶段的目标要求自己：在原型期纠结架构扩展性，在 MVP 期追求企业级 SLA，到了商业化期还在大改核心方向。

原型：验证想法，糙得理直气壮

目标是回答「大模型做这件事，效果到底行不行」。允许最糙的手段：手工拼 prompt、人工兜底（Wizard of Oz——用户以为在用 AI，其实是后台人工）、完全不做 UI。两条纪律：原型只看能力验证；内部 demo 的叫好不等于需求存在，别把掌声当数据。

MVP：验证价值，砍功能不砍底线

目标是找到真实用户与价值证据：

• 范围控制：只做服务核心价值主张的最小闭环，其余功能砍掉或用人工替代；
• 验收标准：预先定义北极星指标（周留存、任务完成率）与护栏指标（幻觉率、投诉率），达标才进入下一阶段；
• 诚实底线：可以糙，不可以骗——数据埋点、内容安全与失败兜底从 MVP 就要有，否则验证结论本身不可信。

商业化：从「能用」到「可承诺」

规模化阶段新增三件 MVP 不必背负的东西：SLA 承诺（可用性、延迟、赔付条款）、合规审计（数据、内容、行业资质）、成本模型（毛利为正的单位经济）。多租户、灰度体系、运维告警等重型工程，此时投入才划算。

排期与风险管理

• 里程碑倒排：从商业化窗口期（行业节奏、预算周期）倒推 MVP 与原型的时间点，防止无限打磨；
• 风险登记表：模型能力风险（效果天花板）、数据风险（拿不到数据）、合规风险，逐条列出负责人与预案；
• 预设退出条件：每阶段写清「验证失败长什么样」，失败就止损转向，避免沉没成本绑架决策。

避免过度工程

警惕这些信号：还没有留存用户就开始微调模型；为假想的百万并发设计架构；把本可人工处理的十个 case 做成自动化系统。判断原则只有一条：当前阶段验证目标之外的投入都是负债。

产品决策提示：每次评审问一句「这个投入服务于当前阶段的哪个假设？」答不上来的工作项，默认延后。

本节要点

• 三阶段目标迥异：原型验证能力可行，MVP 验证价值假设，商业化验证规模与盈利。
• 原型允许 Wizard of Oz 等糙手段；MVP 砍功能但不砍埋点、安全与兜底的诚实底线。
• 商业化新增 SLA、合规审计、成本模型三座大山，重型工程此时才值得投入。
• 里程碑倒排控节奏，风险登记表逐条配负责人与预案，每阶段预设退出条件。
• 过度工程的检验口径：不服务于当前阶段验证假设的投入，一律是负债。