validation-mvp

name	validation-mvp
description	当需要界定MVP功能范围时使用。MVP范围自动界定工具，基于假设地图和资源约束，智能识别Must Have、MUST NOT和Nice to Have功能，并评估MVP规模占比。关键词：MVP范围、最小可行产品、功能优先级、资源约束、最小产品、核心功能。
metadata	{"module":"产品构思与设计","sub-module":"方案验证","type":"pipeline","version":"2.1","domain_tags":["互联网","软件","通用"],"trigger_examples":["MVP应该包含哪些功能","最小产品怎么做","哪些功能可以先不做"],"interaction_mode":"ai_suggest_human_approve"}
execution_depth	{"default":"standard","quick_description":"直接输出MVP范围和验证计划","deep_description":"完整方案 + MVP范围优化 + 验证指标体系 + 迭代演进路线"}

MVP范围自动界定

核心原则

1. MVP验证的是假设不是方案——MVP的目标是学习而非交付，用最小成本获取最大置信度
2. Must Have是MVP的底线——Must Have功能不可裁剪，Nice to Have功能全部可裁剪
3. 2周是MVP的时间红线——超过2周的MVP不是MVP，是完整产品
4. 验证结果只有三种——验证通过/验证失败/需更多数据，不允许模糊结论

基本信息

属性	值
Pipeline ID	11
名称	MVP范围自动界定
执行模式	🤖→👤 AI建议，人类审批
输入	方案设计 + 假设地图 + 资源约束

交互模式

🤖→👤 AI建议人类审批

输入

输入项	类型	必填	来源	说明
方案设计	JSON	是	output/pm-design/design-prototype / output/pm-design/design-userflow	完整功能列表及描述
假设地图	JSON	是	output/pm-design/validation-assumption-map/assumption_map.json	Pipeline 10输出的假设地图
资源约束	JSON	○	用户提供	时间、人力、预算限制

输入格式

{
  "solution_design": {
    "features": [
      {
        "id": "F001",
        "name": "功能名称",
        "description": "功能描述",
        "effort_estimate": "工作量估算"
      }
    ]
  },
  "assumption_map": [...],
  "resource_constraints": {
    "timeline_weeks": 8,
    "team_size": 4,
    "budget": "预算限制"
  }
}

执行步骤

Step 1: 核心假设提取与 Must Have 识别 [核心]

定义: 与最大风险假设直接相关的功能 = 必须包含

判断逻辑:

1. 找出所有 is_max_risk = true 的假设
2. 提取核心假设列表
3. 识别与这些假设关联的功能
4. 标记为 Must Have

输出格式:

{
  "core_hypothesis": [
    {
      "id": "A001",
      "description": "假设描述",
      "risk_score": 20
    }
  ],
  "must_have": [
    {
      "feature": "功能名称",
      "linked_assumption": "关联的最大风险假设",
      "effort_estimate": "工作量估算",
      "rationale": "必须包含的理由"
    }
  ]
}

Step 2: 裁剪功能识别 [核心]

定义: 干扰核心假设验证的功能 = 排除

排除标准:

排除类型	说明	示例
过于丰富	超出MVP验证需要的完整功能	MVP验证需要列表，却做完整搜索+筛选+排序
过于精美	高保真设计非MVP必要	投入大量时间在交互动效
过多配置	复杂配置项非验证必要	多个维度的自定义设置

输出格式:

{
  "cut_features": [
    {
      "feature": "功能名称",
      "rationale": "排除的理由（干扰核心假设验证）"
    }
  ]
}

Step 3: Nice to Have 归类 [核心]

定义: 既非Must Have也非裁剪功能的功能

优先级规则:

1. 关联高风险假设但非直接相关的功能 → P1
2. 关联中风险假设的功能 → P2
3. 关联低风险假设的功能 → P3

输出格式:

{
  "nice_to_have": [
    {
      "feature": "功能名称",
      "priority": "P1/P2/P3",
      "target_version": "v2.0/v3.0"
    }
  ]
}

Step 4: MVP规模评估 [核心]

计算公式:

MVP占比 = Must Have工作量 / 完整方案工作量 × 100%

工作量单位: 人天/人周/story point（根据团队习惯）

评估标准:

MVP占比	评估结果	建议
< 40%	✅ 理想	可启动MVP开发
40-60%	⚠️ 可接受	审视Nice to Have是否可精简
> 60%	🚨 需评审	升级人类判断，确认是否调整

Step 5: 时间规划 [核心]

定义: 基于MVP功能工作量与资源约束，制定时间规划

规划逻辑:

1. 汇总 Must Have 功能工作量
2. 结合资源约束中的 timeline_weeks 和 team_size
3. 确保总周数 ≤ 2（MVP时间红线）
4. 拆分里程碑节点

输出格式:

{
  "timeline": {
    "total_weeks": 2,
    "milestones": [
      {
        "name": "里程碑名称",
        "week": 1,
        "deliverables": ["交付物1", "交付物2"]
      }
    ]
  }
}

Step 6: 资源估算 [核心]

定义: 基于MVP功能工作量与时间规划，估算所需资源

估算逻辑:

1. 根据 Must Have 功能工作量计算人力需求
2. 结合 timeline.total_weeks 推算团队配置
3. 评估是否需要外部资源支持

输出格式:

{
  "resource_estimate": {
    "team_size": 3,
    "roles": [
      {
        "role": "角色名称",
        "count": 1,
        "rationale": "配置理由"
      }
    ],
    "external_dependencies": []
  }
}

Step 7: 成功标准与风险缓解 [核心]

定义: 定义MVP验证的成功标准，并识别风险及缓解措施

成功标准逻辑:

1. 将核心假设转化为可量化的验证指标
2. 每个核心假设至少对应1个成功标准
3. 成功标准必须可量化（含具体数值或阈值）

风险缓解逻辑:

1. 识别MVP执行过程中的关键风险
2. 为每个风险制定缓解措施
3. 评估风险影响等级

输出格式:

{
  "success_criteria": [
    {
      "criterion": "成功标准描述",
      "metric": "量化指标",
      "target_value": "目标值",
      "linked_hypothesis": "关联假设ID"
    }
  ],
  "risk_mitigation": [
    {
      "risk": "风险描述",
      "impact": "high/medium/low",
      "mitigation": "缓解措施"
    }
  ]
}

Step 8: Go/No-Go决策框架 [核心]

定义: 基于成功标准构建Go/No-Go决策框架，metrics直接引用success_criteria中的量化指标

决策逻辑:

1. 从 success_criteria 中提取关键决策指标（每个核心假设选取1个主指标）
2. 为每个指标定义 Go/No-Go 阈值（基于success_criteria.target_value上下浮动）
3. 至少包含2个 metrics 和对应 thresholds
4. metrics 不重复定义指标，通过 linked_criterion 引用 success_criteria

输出格式:

{
  "go_no_go": {
    "metrics": [
      {
        "name": "指标名称",
        "linked_criterion": "关联的success_criteria索引",
        "description": "指标描述"
      }
    ],
    "thresholds": {
      "go": "Go条件描述",
      "no_go": "No-Go条件描述",
      "needs_more_data": "需更多数据条件描述"
    }
  }
}

输出深度分级

深度级别	输出范围	说明
quick	MVP范围和验证计划	核心结论 + 最小可行产物
standard	完整产物（当前默认）	完整产物，包含全部Step输出
deep	完整方案 + MVP范围优化 + 验证指标体系 + 迭代演进路线	完整产物 + 扩展分析 + 深度推演

输出

存储路径：output/pm-design/validation-mvp/ 输出文件：mvp_definition.json

{
  "mvp_scope": {
    "core_hypothesis": [
      { "id": "A001", "description": "假设描述", "risk_score": 20 }
      // ... 同结构可扩展
    ],
    "must_have": [
      { "feature": "功能名称", "linked_assumption": "关联假设ID", "effort_estimate": 8, "rationale": "必须包含的理由" }
      // ... 同结构可扩展
    ],
    "nice_to_have": [
      { "feature": "功能名称", "priority": "P1", "target_version": "v2.0" }
      // ... 同结构可扩展
    ],
    "cut_features": [
      { "feature": "功能名称", "rationale": "排除理由" }
      // ... 同结构可扩展
    ],
    "timeline": { "total_weeks": 2, "milestones": [{ /* 同Step5结构 */ }] },
    "resource_estimate": { "team_size": 3, "roles": [{ /* 同Step6结构 */ }], "external_dependencies": [] },
    "success_criteria": [{ /* 同Step7结构 */ }],
    "risk_mitigation": [{ /* 同Step7结构 */ }],
    "effort_summary": { "mvp_total": 24, "full_solution_total": 60, "mvp_ratio": "40%" },
    "go_no_go": { "metrics": [{ /* 同Step8结构 */ }], "thresholds": { "go": "...", "no_go": "...", "needs_more_data": "..." } }
  },
  "approval_status": "pending|approved|needs_discussion",
  "recommendation": "AI建议说明"
}

输出校验规则：详见下方输出校验规则章节

决策规则

规则	条件	动作
人工审批触发	MVP占比 > 60%	升级人类判断
审批触发	Must Have无假设关联	需补充说明
审批触发	cut_features理由不充分	需补充排除依据

质量检查

P0 检查（quick/standard/deep 都必须通过）

• 核心假设（core_hypothesis非空且与must_have关联）
• 假设关联（Must Have功能都有假设关联）

P1 检查（standard/deep 必须通过）

• 排除理由（cut_features功能都有充分理由）
• 占比计算（MVP占比已计算）
• 优先级完整（Nice to Have都有优先级）
• 时间红线（timeline.total_weeks ≤ 2，超过时 human_override 必须为 true）
• 成功标准可量化（success_criteria包含量化指标和目标值）
• Go/No-Go完整（go_no_go包含至少2个metrics和对应thresholds）

P2 检查（仅 deep 必须通过）

• 扩展分析完整（深度推演和路线图已生成）
• 决策记录完整（关键决策有依据和替代方案）

---

降级策略

缺失的上游输入	降级方案	输出影响	数据获取说明
假设地图缺失	用户描述关键假设，界定MVP	缺乏结构化假设数据，MVP范围可能不够精准	要求用户提供关键假设列表和验证优先级或上传假设地图文件
方案设计数据缺失	用户描述方案，界定MVP	缺乏方案数据，功能裁剪可能不够合理	要求用户提供功能方案描述和核心功能列表或上传ideation输出文件
资源约束数据缺失	用户描述资源约束，界定MVP	缺乏资源约束数据，时间规划可能不够合理	要求用户提供团队规模、可用工期和技术栈等资源约束信息
假设地图+方案设计+资源约束均缺失	用户描述假设和方案，界定MVP	整体置信度降低，MVP范围可能不够完整	要求用户提供关键假设、功能方案和资源约束描述
所有上游文件均缺失	提示用户先执行前序阶段，或基于用户描述界定MVP	输出仅为基本MVP框架	要求用户提供核心假设、最小功能集和资源约束

输出校验规则

字段路径	类型	必填	说明
mvp_scope	object	是	MVP范围定义
mvp_scope.core_hypothesis	array	是	核心假设列表
mvp_scope.must_have	array	是	Must Have功能列表
mvp_scope.nice_to_have	array	是	Nice to Have功能列表
mvp_scope.cut_features	array	是	裁剪功能列表
mvp_scope.timeline	object	是	时间规划
mvp_scope.timeline.total_weeks	number	是	总周数（≤2，超过时需 human_override: true）
mvp_scope.timeline.milestones	array	是	里程碑列表
mvp_scope.resource_estimate	object	是	资源估算
mvp_scope.effort_summary	object	是	工作量汇总
mvp_scope.effort_summary.mvp_total	number	是	MVP总工作量
mvp_scope.effort_summary.full_solution_total	number	是	完整方案总工作量
mvp_scope.effort_summary.mvp_ratio	string	是	MVP占比
mvp_scope.success_criteria	array	是	成功标准
mvp_scope.risk_mitigation	array	是	风险缓解措施
mvp_scope.go_no_go	object	是	Go/No-Go决策框架
mvp_scope.go_no_go.metrics	array	是	决策指标
mvp_scope.go_no_go.thresholds	object	是	阈值定义
human_override	boolean	是	人类覆盖标记（默认 false，当 total_weeks > 2 时必须为 true）

上游变更响应

上游变更影响

上游变更	影响范围	响应策略
假设地图变更（假设增删/风险评分变更）	核心假设、Must Have功能	标注受影响的假设和功能，建议人类确认是否重新界定MVP
方案设计变更	功能列表、裁剪决策	标注受影响的功能，建议人类确认是否调整MVP范围
资源约束变更	时间规划、资源估算	标注受影响的时间线，建议人类确认是否调整MVP范围
实验结果更新	核心假设验证状态	标注受影响的假设，建议人类确认是否调整MVP策略

下游通知机制

MVP范围变更类型	通知范围	通知方式
Must Have功能增删	validation-experiment、validation-usability	标记功能变更，触发实验设计和可用性测试更新
时间规划变更	validation-experiment	标记时间变更，触发实验周期调整
成功标准变更	validation-experiment	标记标准变更，触发实验指标更新
Go/No-Go决策变更	所有下游Skill	标记决策变更，触发全流程更新

---

使用示例

假设地图中的最大风险假设:

• A001: 用户认为推荐内容与兴趣匹配（风险分数: 20）

方案设计中的功能:

• F001: 智能推荐算法
• F002: 推荐结果展示
• F003: 收藏功能
• F004: 分享功能
• F005: 高保真动效

AI分析:

核心假设:
- A001: 用户认为推荐内容与兴趣匹配（风险分数: 20）

Must Have:
- F001 智能推荐算法（直接验证A001）
- F002 推荐结果展示（验证A001必需）

裁剪功能:
- F005 高保真动效（干扰核心验证，非MVP必要）

Nice to Have:
- F003 收藏功能（P2，v2.0）
- F004 分享功能（P3，v3.0）

时间规划:
- 总计2周，第1周完成核心算法，第2周完成展示与验证

资源估算:
- 3人：1后端+1前端+1数据

成功标准:
- 推荐匹配度 ≥ 60%（关联A001）

风险缓解:
- 算法精度不足（high）→ 降级为规则推荐

Go/No-Go:
- metrics: 推荐匹配度、用户点击率
- Go: 匹配度≥60%且点击率≥30%
- No-Go: 匹配度<40%或点击率<15%

MVP占比: 40% ✅ 理想