MVP 定义与验证路径设计

在 https://www.zangwei.dev/prompts/product-planning/mvp-definition-validation-plan-prompt 有一个提示词指南。请提取并遵循该提示词来创建文件 /docs/handbook/planning/mvp.md

你是一名资深产品负责人，
为该产品设计【MVP（Minimum Viable Product）定义与验证路径】。

【核心定位】
- MVP 的目标不是“交付产品”，而是“验证关键假设”
- MVP 不是功能最少的版本，而是：
  用最小代价，验证最关键的不确定性
- 本文档用于连接 Planning → Execution，是资源投入前的最后一道闸门

请基于已有结论，系统性定义：
1）什么是这个产品的 MVP
2）如何通过 MVP 快速验证成败

【总体要求】
- 明确假设 → 验证方式 → 成功 / 失败判据
- 严格控制范围，避免“顺手多做一点”
- 避免技术实现细节，聚焦验证逻辑
- 若某假设无法通过 MVP 验证，请明确指出

---

【MVP 输出结构】

一、MVP 的核心目标
- MVP 要验证的最关键问题是什么？
- 如果这个问题被证明为“否”，产品是否应立即停止？
- MVP 成功后，能支持哪些进一步投入决策？

二、关键假设拆解（非常重要）
请列出 3–5 个必须被验证的核心假设，包括但不限于：
- 用户是否真的有该需求？
- 用户是否理解并认可核心价值？
- 用户是否愿意为此付费 / 采取关键行动？
- 当前解决方案是否明显优于替代方案？

并标注：
- 每个假设的重要性
- 若该假设失败的后果

三、MVP 范围定义（What to Build）
- MVP 必须包含的最小能力集合
- MVP 明确不包含的功能或场景（What NOT to build）
- 哪些能力只是“验证工具”，而非长期产品资产

四、验证路径与方法设计
针对每一个核心假设，定义：
- 验证方式（原型测试、Landing Page、内测、手动流程等）
- 样本来源与规模（定性 / 定量）
- 验证周期与所需资源
- 可能的偏差与局限

五、成功与失败判据（Go / No-Go）
- 每个假设的成功判据是什么？
- 哪些结果构成“明确失败”？
- 是否存在需要重新设计而非直接放弃的情况？

六、MVP 之后的决策路径
- 如果 MVP 成功，下一步应做什么？
- 如果部分成功，哪些假设需要二次验证？
- 如果失败，是否应：
  - 调整定位
  - 调整目标用户
  - 或直接停止项目？

---

【输出要求】
- 不输出具体技术方案或开发排期
- 避免把“愿景功能”塞进 MVP
- 明确标注“验证目的”与“产品资产”的区别
- 若无法设计有效 MVP，请明确指出该风险

请在最后用 3–5 条要点总结：
“这个 MVP 是否真的能在最小投入下，回答最关键的问题？”