pm-mvp

Preamble (run first)

bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 创建需求调研目录
mkdir -p docs/01-需求调研

# 检查是否有优先级排序报告
if [ ! -f "docs/01-需求调研/优先级排序报告.md" ]; then
  echo "⚠️  未找到优先级排序报告"
  echo ""
  echo "建议先执行 /pm-priority 排序需求"
  echo ""
  echo "您可以选择："
  echo "A) 执行 /pm-priority 先排序需求（推荐）"
  echo "B) 手动选择MVP功能（快速模式）"
fi

执行流程

digraph pm_mvp {
    rankdir=TB;
    node [shape=box, style=filled, fillcolor="#e3f2fd"];

    subgraph cluster_input {
        label="前置数据";
        style=filled;
        fillcolor="#f5f5f5";
        "读取优先级排序报告" [shape=box];
        "读取需求调研报告" [shape=box];
        "快速模式手动选择" [shape=box, fillcolor="#fff9c4"];
    }

    subgraph cluster_mode {
        label="MVP模式选择";
        style=filled;
        fillcolor="#fff3e0";
        "选择MVP模式" [shape=diamond];
        "最小MVP\n（2-4周）" [shape=box, fillcolor="#c8e6c9"];
        "标准MVP\n（1-2月）" [shape=box, fillcolor="#bbdefb"];
        "全链路MVP\n（2-3月）" [shape=box, fillcolor="#fff9c4"];
        "自定义MVP" [shape=box, fillcolor="#f8bbd0"];
    }

    subgraph cluster_decide {
        label="功能集确定";
        style=filled;
        fillcolor="#e8f5e9";
        "选取核心3-5个P0功能" [shape=box];
        "选取全部P0功能" [shape=box];
        "选取P0+部分P1功能" [shape=box];
        "逐个询问纳入MVP" [shape=box];
    }

    subgraph cluster_risk {
        label="风险评估";
        style=filled;
        fillcolor="#fce4ec";
        "技术风险评估" [shape=box];
        "业务风险评估" [shape=box, fillcolor="#f8bbd0"];
        "资源风险评估" [shape=box];
    }

    "生成MVP方案" [shape=box, fillcolor="#ffccbc"];

    "读取优先级排序报告" -> "选择MVP模式";
    "读取需求调研报告" -> "选择MVP模式";
    "快速模式手动选择" -> "选择MVP模式";

    "选择MVP模式" -> "最小MVP\n（2-4周）" [label="快速验证"];
    "选择MVP模式" -> "标准MVP\n（1-2月）" [label="平衡方案"];
    "选择MVP模式" -> "全链路MVP\n（2-3月）" [label="完整流程"];
    "选择MVP模式" -> "自定义MVP" [label="用户选择"];

    "最小MVP\n（2-4周）" -> "选取核心3-5个P0功能";
    "标准MVP\n（1-2月）" -> "选取全部P0功能";
    "全链路MVP\n（2-3月）" -> "选取P0+部分P1功能";
    "自定义MVP" -> "逐个询问纳入MVP";

    "选取核心3-5个P0功能" -> "技术风险评估";
    "选取全部P0功能" -> "技术风险评估";
    "选取P0+部分P1功能" -> "技术风险评估";
    "逐个询问纳入MVP" -> "技术风险评估";

    "技术风险评估" -> "业务风险评估";
    "业务风险评估" -> "资源风险评估";
    "资源风险评估" -> "生成MVP方案";
}

步骤 1: 读取前置数据

使用 Read 工具读取：

• docs/01-需求调研/优先级排序报告.md（提取P0需求）
• docs/01-需求调研/需求调研报告.md（提取痛点）

步骤 2: 选择MVP模式

使用 AskUserQuestion：

🎯 选择MVP模式：

A) 最小MVP - 仅核心功能，快速验证（2-4周）

B) 标准MVP - 核心功能+基础体验（1-2月）

C) 全链路MVP - 完整用户流程（2-3月）

D) 自定义MVP - 我来选择功能

步骤 3: 确定核心功能集

如果是最小MVP：

选择P0级需求中最核心的3-5个功能。

如果是标准MVP：

选择全部P0级需求。

如果是全链路MVP：

选择P0+部分P1需求，覆盖完整用户流程。

如果是自定义：

逐个询问每个需求是否纳入MVP。

步骤 4: 风险评估

AI评估MVP方案的风险：

技术风险：

• 是否有技术难点？
• 是否需要新技术栈？

业务风险：

• 市场窗口是否足够？
• 竞品是否会抢先？

资源风险：

• 团队是否有足够人力？
• 预算是否充足？

步骤 5: 生成MVP方案

使用 Write 工具创建 docs/01-需求调研/MVP方案.md：

# MVP方案

## 一、MVP概述

- **MVP模式**: {模式名称}
- **目标上线时间**: {时间}
- **核心验证目标**: {验证什么}
- **生成时间**: {当前时间}

---

## 二、核心功能集

| 序号 | 功能名称 | 优先级 | 工作量 | 负责人 |
|------|----------|--------|--------|--------|
| 1 | {功能1} | P0 | {工作量} | 待定 |
| 2 | {功能2} | P0 | {工作量} | 待定 |
| 3 | {功能3} | P0 | {工作量} | 待定 |

---

## 三、用户流程

### 3.1 核心用户旅程

用户进入 → {步骤1} → {步骤2} → {步骤3} → 完成

### 3.2 关键触点

- 触点1: {描述}
- 触点2: {描述}

---

## 四、技术方案

### 4.1 技术栈

- 前端: {技术}
- 后端: {技术}
- 数据库: {技术}

### 4.2 关键技术点

1. {技术点1}
2. {技术点2}

---

## 五、风险评估

### 5.1 技术风险

**风险**: {描述}
**应对**: {方案}

### 5.2 业务风险

**风险**: {描述}
**应对**: {方案}

### 5.3 资源风险

**风险**: {描述}
**应对**: {方案}

---

## 六、里程碑规划

| 里程碑 | 时间 | 交付物 |
|--------|------|--------|
| 设计完成 | Week 1 | 设计稿、原型 |
| 开发完成 | Week 2-3 | 功能代码 |
| 测试完成 | Week 4 | 测试报告 |
| 上线 | Week 5 | 产品上线 |

---

## 七、成功标准

### 7.1 业务指标

- 用户数: {目标}
- 留存率: {目标}
- 核心行为: {目标}

### 7.2 技术指标

- 性能: {目标}
- 稳定性: {目标}

---

## 八、下一步建议

建议执行：

1. **/pm-docs** - 生成PRD文档（推荐）
2. **/pm-proto** - 原型设计
3. **/pm-tech** - 技术对接方案

---

**项目状态**: MVP规划完成
**生成时间**: {时间戳}
**生成工具**: super-pm v1.0.0

步骤 6: 输出完成提示

使用 AskUserQuestion：

✅ MVP方案完成！

📄 MVP方案已生成：docs/01-需求调研/MVP方案.md

🎯 建议下一步：

A) 执行 /pm-docs - 生成PRD文档（推荐）

B) 执行 /pm-proto - 原型设计

C) 执行 /pm-tech - 技术对接方案

D) 查看MVP方案

兜底机制

场景 1: 无优先级报告

提供快速模式，手动选择MVP功能。

场景 2: 功能过多

提醒用户精简功能，聚焦核心。

注意事项

1. 聚焦核心验证：MVP要验证核心假设
2. 控制范围：避免范围蔓延
3. 快速迭代：尽快上线获取反馈
4. 风险评估：提前识别风险并制定应对方案
5. Markdown存储：MVP方案人类可读可编辑

输出质量对比

✅ Good 示例：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad 示例：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

| 误区 | 正确做法 | |------|---------| | 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 | | 未运行检查就声称已完成 | 先验证，再陈述 | | 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 | | "这次应该没问题"的想法 | 每次都要重新验证 |

产出质量检查 / Verification Checklist

• [ ] 前置依赖已满足（输入文档/数据已收集）
• [ ] 核心步骤已全部执行
• [ ] 输出文档已生成到 docs/ 目录
• [ ] 每个判断都有数据/证据支撑
• [ ] 已推荐 2-3 个后续 skill

⚠️ 任何一项未通过 → 补全后再标记完成。