Preamble (run first)
bash# 检查是否有优先级排序报告 if [ ! -f "docs/01-需求调研/优先级排序报告.md" ]; then echo "⚠️ 未找到优先级排序报告" echo "" echo "建议先执行 /pm-priority 排序需求" echo "" echo "您可以选择:" echo "A) 执行 /pm-priority 先排序需求(推荐)" echo "B) 手动选择MVP功能(快速模式)" fi
写入时边界
只讨论时不写文件,启动检查不创建目录。用户要求保存产物时,先确认当前产品、精确输出路径及已有文件的覆盖/追加选择;确认后仅在实际 Write 前创建该输出文件的父目录。完整安装可参见 skills/_shared/artifact-policy.md,单独安装本 skill 也按本段执行。
跨 Agent 交互规则
当流程要求与用户交互时:
- 如果当前环境支持 AskUserQuestion,使用 AskUserQuestion(最佳体验)。
- 如果当前环境不支持 AskUserQuestion,必须用普通聊天消息提出同样问题。
- 一次只问一个问题。
- 提问后必须停止当前回合,等待用户回答(STOP and WAIT)。
- 不得在用户回答前生成文档、写入 docs。
- 已有 docs 文件不能替代本轮用户回答。
执行流程
步骤 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:
markdown# 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
步骤 6: 输出完成提示
使用 AskUserQuestion:
✅ MVP方案完成!
📄 MVP方案已生成:
docs/01-需求调研/MVP方案.md🎯 建议下一步:
A) 执行 /pm-docs - 生成PRD文档(推荐) B) 执行 /pm-proto - 原型设计 C) 执行 /pm-tech - 技术对接方案 D) 查看MVP方案
兜底机制
场景 1: 无优先级报告
提供快速模式,手动选择MVP功能。
场景 2: 功能过多
提醒用户精简功能,聚焦核心。
注意事项
- 聚焦核心验证:MVP要验证核心假设
- 控制范围:避免范围蔓延
- 快速迭代:尽快上线获取反馈
- 风险评估:提前识别风险并制定应对方案
- Markdown存储:MVP方案人类可读可编辑
输出质量对比
✅ Good 示例:
- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」 - 有验证来源:「数据来源:Google Analytics, 2025-12-01」 - 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例:
- 模糊结论:「数据表明留存率有所下降」 - 无来源:「根据经验,这个功能很重要」 - 没有行动建议:「留存是个问题」
常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯:
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证,再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
产出质量检查 / Verification Checklist
- 前置依赖已满足(输入文档/数据已收集)
- 核心步骤已全部执行
- 输出文档已生成到
docs/目录 - 每个判断都有数据/证据支撑
- 已推荐 2-3 个后续 skill
⚠️ 任何一项未通过 → 补全后再标记完成。


