MVP构建

为什么需要 MVP 构建

创业者最常见的错误不是做得不够快，而是在验证之前就把资源砸进了一个没人要的功能里。团队花六周打磨一个完整的 平台，上线后发现用户根本不在乎核心卖点。MVP 构建要解决的就是这个「先建后问」的陷阱——用最小代价拿到最真实的市场反馈，再决定下一步往哪走。

这个技能不是帮你写代码，而是帮你做决策：什么该做、什么可以砍、什么必须先验证。

它如何工作

技能扮演精益创业专家的角色，按照五个步骤推进：

1. 明确核心假设：先用预测式提问——「猜一下会发生什么」——逼你写下最关键的假设。比如「用户愿意为这个功能付费」，这句话本身就是需要验证的假设，而不是既定事实。
2. 梳理功能优先级：将候选功能分成四档——必须有、应该有、可以有、暂不需要。MVP 的核心功能不超过 5 个，这是硬约束，防止范围蔓延。
3. 推荐技术栈：优先推荐无代码和低代码工具，降低实现门槛。不是为了省事，而是让验证周期缩短到 2-4 周。
4. 制定时间表：建议开发周期 2-4 周，不是拍脑袋的数字，而是匹配「快速迭代」的节奏。
5. 设定指标与迭代计划：MVP 不是终点，是学习循环的起点。技能会帮你定义什么算「成功」，以及下一轮迭代怎么调整。

整个过程保持互动，每 2-3 步会停下来确认理解或邀请你参与决策。

适用边界

• 输出是纯文本方案，零外部依赖。它不会帮你生成代码仓库或部署流水线。
• 核心功能上限 5 个，这是设计约束，不是建议。如果你的需求天然超过这个数量，说明 MVP 的范围需要重新定义。
• 适合早期验证阶段，不适合已经找到 PMF 后的规模化迭代。
• 如果你已经有明确的技术方案和数据支撑，这个技能的指导价值会下降。它更适合「想法还没被验证」的模糊阶段。

进入和退出都有明确信号：触发关键词如 MVP、最小可行产品、原型、快速迭代；输入「方案确认」或「退出」即停止，输出「MVP 方案已就绪，开始行动吧！」