Preamble (run first)
bash# 检查是否有确认需求清单 if [ ! -f "docs/01-需求调研/确认需求清单.md" ]; then echo "⚠️ 未找到确认需求清单" echo "" echo "建议先执行 /pm-clarify 细化需求" echo "" echo "您可以选择:" echo "A) 执行 /pm-clarify 先细化需求(推荐)" echo "B) 手动输入需求列表(快速模式)" echo "C) 从需求池导入(执行过 /pm-pool)" fi
写入时边界
只讨论时不写文件,启动检查不创建目录。用户要求保存产物时,先确认当前产品、精确输出路径及已有文件的覆盖/追加选择;确认后仅在实际 Write 前创建该输出文件的父目录。完整安装可参见 skills/_shared/artifact-policy.md,单独安装本 skill 也按本段执行。
跨 Agent 交互规则
当流程要求与用户交互时:
- 如果当前环境支持 AskUserQuestion,使用 AskUserQuestion(最佳体验)。
- 如果当前环境不支持 AskUserQuestion,必须用普通聊天消息提出同样问题。
- 一次只问一个问题。
- 提问后必须停止当前回合,等待用户回答(STOP and WAIT)。
- 不得在用户回答前生成文档、写入 docs。
- 已有 docs 文件不能替代本轮用户回答。
产出要求:每项排序保留需求标识、证据来源及日期、评分依据和置信度;缺失数据标为假设,不以估算冒充事实。将最终取舍及责任人传递给 MVP 方案。
缺数据的 RICE 门禁:如果需求只有 A/B/C 之类占位代号,且缺少 Reach(覆盖人数)或 Effort(工作量)估计,不得替 A/B/C 填任何精确数值或计算示例分数;即使写“假设”“仅示例”也会让占位符看起来已有排序。只给空白输入表、公式、待补的数据和一个关键澄清问题,STOP and WAIT。获得各需求含义和同口径的估计后,才可计算或展示标注假设的区间。
执行流程
步骤 1: 读取前置数据(主 agent)
如果有确认需求清单:
使用 Read 工具读取 docs/01-需求调研/确认需求清单.md
提取需求列表。
如果有需求调研报告:
使用 Read 工具读取 docs/01-需求调研/需求调研报告.md
提取初步需求列表和背景信息。
如果有市场调研报告:
使用 Read 工具读取 docs/01-需求调研/市场调研报告.md(如存在)
提取市场数据、竞品信息,为后续评分提供数据支撑。
如果没有前置文档:
进入快速模式,使用 AskUserQuestion 收集需求列表。
步骤 2: 选择排序模型(主 agent - 用户交互)
使用 AskUserQuestion 询问:
🎯 选择需求优先级排序模型:
A) RICE评分 - 综合Reach、Impact、Confidence、Effort(推荐) B) KANO模型 - 基于用户满意度分类需求 C) MoSCoW法则 - Must/Should/Could/Won't分类 D) 自定义权重 - 自定义评分维度
用户选择后,记录到变量 PRIORITY_MODEL
步骤 3: Subagent 并行预分析(v2.0 核心优化)
优化说明:
- 每个需求派发一个 subagent,读取所有前置文档,基于数据和所选模型生成初始评分建议
- 多个需求并行分析,总耗时等于单个需求分析时间
- 预分析结果包含评分 + 数据依据,用户只需确认或微调
- 大幅减少逐维度询问的交互轮次
3.1 构建预分析任务
对每个需求,构建一个 subagent 任务:
json[ { "task_id": "prescore_req_1", "requirement": "{需求1名称}", "model": "{PRIORITY_MODEL}", "docs": ["docs/01-需求调研/确认需求清单.md", "docs/01-需求调研/需求调研报告.md"] }, { "task_id": "prescore_req_2", "requirement": "{需求2名称}", "model": "{PRIORITY_MODEL}", "docs": ["docs/01-需求调研/确认需求清单.md", "docs/01-需求调研/需求调研报告.md"] } ]
如果需求数量 > 10,提示用户:
⚠️ 需求数量较多({N}个),预分析可能需要较长时间
您可以选择: A) 全部预分析 B) 仅对核心需求预分析(前10个) C) 跳过预分析,直接手动评分
3.2 并行派发 subagent
同时派发所有 subagent:
# 并行派发 N 个 subagent Agent 1: 预分析-{需求1} Agent 2: 预分析-{需求2} ... Agent N: 预分析-{需求N}
每个 subagent 的 prompt 模板:
Tool: Agent Parameters: subagent_type: "general-purpose" description: "预分析-{需求名称}" prompt: | 你是一个产品优先级分析专家。请基于前置文档,为指定需求生成评分建议。 **需求名称**: {需求名称} **排序模型**: {PRIORITY_MODEL} **前置文档路径**: - docs/01-需求调研/确认需求清单.md - docs/01-需求调研/需求调研报告.md - docs/01-需求调研/市场调研报告.md(如存在) **任务**: 1. 使用 Read 工具读取上述前置文档 2. 根据排序模型,分析该需求的评分维度 3. 给出每个维度的建议评分和依据 --- #### 如果选择 RICE 评分: 对指定需求,分析以下 4 个维度: **Reach(覆盖人数)**: - 10分: 全部用户 - 7分: 大部分用户(50-80%) - 5分: 部分用户(20-50%) - 3分: 少量用户(<20%) **Impact(影响程度)**: - 10分: 极大影响 - 直接影响核心指标 - 7分: 较大影响 - 显著提升指标 - 5分: 中等影响 - 有一定提升 - 3分: 较小影响 - 影响有限 **Confidence(信心度)**: - 10分: 非常有信心 - 有数据或调研支持 - 7分: 较有信心 - 有一定依据 - 5分: 中等信心 - 基于假设 - 3分: 信心不足 - 猜测或不确定 **Effort(投入成本)**: - 10分: 很小 - 1-2人天 - 8分: 较小 - 3-5人天 - 5分: 中等 - 1-2人周 - 3分: 较大 - 2-4人周 - 1分: 很大 - >1人月 --- #### 如果选择 KANO 模型: 分析该需求属于哪类: - 基本型需求 - 必须有,没有用户会很不满意 - 期望型需求 - 越完善用户越满意 - 魅力型需求 - 没有没关系,有了会惊喜 - 无差异需求 - 有没有都无所谓 - 反向型需求 - 有了反而用户不满 --- #### 如果选择 MoSCoW 法则: 分析该需求的优先级: - Must have - 必须有,否则产品无法使用 - Should have - 应该有,重要但非紧急 - Could have - 可以有,锦上添花 - Won't have - 本期不做,后续考虑 --- #### 如果选择自定义权重: 分析该需求在以下维度的表现(1-10分): - 用户价值 - 商业价值 - 技术可行性 - 战略契合度 --- **输出格式**(JSON): ```json { "requirement": "{需求名称}", "model": "{PRIORITY_MODEL}", "scores": { "reach": {"score": 7, "reasoning": "依据文档中的用户规模数据..."}, "impact": {"score": 8, "reasoning": "该需求直接解决文档中提到的核心痛点..."}, "confidence": {"score": 7, "reasoning": "市场调研报告中有相关数据支撑..."}, "effort": {"score": 5, "reasoning": "基于需求复杂度评估..."} }, "rice_score": "(自动计算: Reach × Impact × Confidence / Effort)", "key_evidence": ["支撑依据1", "支撑依据2"], "risk_flag": "如有数据矛盾或不确定性,在此标注" } ``` **重要**: - 评分必须有前置文档中的数据支撑,不能凭空猜测 - 如果文档中没有足够信息,在 risk_flag 中标明不确定性 - 用中文返回 reasoning 和 key_evidence
主 agent 等待所有 subagent 完成,收集 JSON 结果。
步骤 4: 用户确认/调整评分(主 agent)
主 agent 汇总所有 subagent 的预分析结果,以表格形式展示:
markdown## 📊 预分析评分结果({PRIORITY_MODEL}) | 需求 | Reach | Impact | Confidence | Effort | RICE得分 | 预分级 | |------|-------|--------|------------|--------|----------|--------| | {需求1} | 7 | 8 | 7 | 5 | 78.4 | P0 | | {需求2} | 5 | 7 | 6 | 8 | 26.3 | P1 | | {需求3} | 3 | 5 | 5 | 3 | 25.0 | P2 | **关键依据**: - {需求1}:{subagent 返回的 key_evidence} - {需求2}:{subagent 返回的 key_evidence} **风险提示**: - {如有 risk_flag,在此展示}
使用 AskUserQuestion 逐需求确认:
📝 确认"{需求名称}"的评分:
当前预评分:Reach={R} Impact={I} Confidence={C} Effort={E} → RICE={得分}
A) 确认,无需调整 B) 调整 Reach C) 调整 Impact D) 调整 Confidence E) 调整 Effort F) 重新评估此需求
💡 依据:{subagent key_evidence}
快速确认模式(需求数量 ≤ 5):
✅ 以上预评分结果是否认可?
A) 全部确认,直接生成报告(推荐) B) 逐个调整 C) 全部重新评估
步骤 5: Subagent 生成优先级排序报告(v2.0 优化)
优化说明:报告生成交给 subagent,主 agent 上下文保持清爽
使用 Agent 工具派发 subagent 生成报告:
Tool: Agent Parameters: subagent_type: "general-purpose" description: "生成优先级排序报告" prompt: | 你是一个产品文档专家。请根据以下数据生成优先级排序报告。 **排序模型**: {PRIORITY_MODEL} **需求评分数据**: ```json {所有需求的最终评分 JSON} ``` **报告要求**: 1. 使用 Write 工具保存到 `docs/01-需求调研/优先级排序报告.md` 2. 严格按照以下模板格式 3. P0/P1/P2/P3 分级规则: - P0: RICE ≥ 50 或 Must have / 基本型 - P1: RICE 20-49 或 Should have / 期望型 - P2: RICE 5-19 或 Could have / 魅力型 - P3: RICE < 5 或 Won't have / 无差异/反向型 **报告模板**: ```markdown # 优先级排序报告 ## 一、基础信息 - **排序模型**: {PRIORITY_MODEL} - **需求数量**: {N}个 - **生成时间**: {当前时间} --- ## 二、排序结果 ### 2.1 需求优先级列表 | 排名 | 需求名称 | {模型对应列头} | 优先级 | |------|----------|{列头}|--------| | 1 | {需求1} | {得分} | P0 | | 2 | {需求2} | {得分} | P0 | | 3 | {需求3} | {得分} | P1 | | ... | ... | ... | ... | ### 2.2 优先级分组 **P0 - 核心需求(必须做)**: 1. {需求1} - {得分详情} 2. {需求2} - {得分详情} **P1 - 重要需求(应该做)**: 1. {需求3} - {得分详情} **P2 - 次要需求(可以做)**: 1. {需求4} - {得分详情} **P3 - 待定需求(暂缓)**: 1. {需求5} - {得分详情} --- ## 三、评分详情 逐需求展开评分依据: ### {需求1} | 维度 | 评分 | 依据 | |------|------|------| | Reach | {R} | {reasoning} | | Impact | {I} | {reasoning} | | Confidence | {C} | {reasoning} | | Effort | {E} | {reasoning} | | **RICE** | **{得分}** | = {R}×{I}×{C}/{E} | ... --- ## 四、排序依据 ### {模型评分说明} (根据实际使用的模型展开评分规则说明) --- ## 五、实施建议 ### 5.1 MVP范围建议 建议第一版(MVP)包含 P0 级需求,共 {N} 个需求: 1. {需求1} 2. {需求2} ... 预计工作量: {估算} ### 5.2 后续迭代 **第二版(V1.1)**: P1级需求 **第三版(V1.2)**: P2级需求 --- ## 六、下一步建议 建议执行: 1. **/pm-mvp** - MVP规划,确定第一版具体方案(推荐) 2. **/pm-docs** - 生成PRD文档 3. **/pm-pool** - 需求池管理,长期跟踪需求 --- **项目状态**: 优先级排序完成 **生成时间**: {时间戳} **生成工具**: super-pm ``` **注意**: - 如果模型是 KANO 或 MoSCoW,调整列头和评分显示格式 - 评分依据来自步骤3 subagent 返回的 reasoning - 确保 Markdown 格式正确、表格对齐
主 agent 等待 subagent 完成报告生成。
步骤 6: 输出完成提示(主 agent)
使用 AskUserQuestion 提供下一步选项:
✅ 优先级排序完成!
📄 优先级排序报告已生成:
docs/01-需求调研/优先级排序报告.md🎯 建议下一步:
A) 执行 /pm-mvp - MVP规划,确定第一版方案(推荐) B) 执行 /pm-docs - 生成PRD文档 C) 执行 /pm-pool - 需求池管理 D) 查看优先级排序报告
对比:优化前 vs 优化后
优化前(pm-priority v1.1.0)
主 agent 执行流程: 1. 读取前置数据(50 tokens) 2. 询问排序模型(10 tokens) 3. 对需求1逐维度询问(4轮交互,每轮 ~200 tokens) 4. 对需求2逐维度询问(4轮交互,每轮 ~200 tokens) 5. 对需求N逐维度询问... 6. 汇总计算(50 tokens) 7. 生成报告(~800 tokens 写入) 总计(以5个需求为例): - 交互轮次:1 + 1 + 5×4 = 22 轮 - 上下文消耗:~5,000 tokens(报告模板占用大头) - 耗时:约 5-8 分钟(串行交互)
优化后(pm-priority v2.0.0)
主 agent 执行流程: 1. 读取前置数据(50 tokens) 2. 询问排序模型(10 tokens) 3. 并行派发 subagent 预分析(20 tokens × N个任务) └─ 每个 Subagent 读取文档 + 分析(不占用主 agent 上下文) 4. 展示预评分 + 确认(200 tokens,1-2轮交互) 5. 派发 subagent 生成报告(20 tokens) └─ Subagent 生成报告(不占用主 agent 上下文) 6. 输出完成提示(10 tokens) 总计(以5个需求为例): - 交互轮次:1 + 1 + 1-2 + 1 = 4-5 轮 - 主 agent 上下文消耗:~400 tokens(减少 90%+) - 耗时:约 1.5-3 分钟(并行分析 + 快速确认) - 效率提升:4x 交互减少,5x+ token 节省
Token 使用对比
| 指标 | v1.1.0 | v2.0.0 | 改善 |
|---|---|---|---|
| 主 agent token | ~5,000 | ~400 | -92% |
| Subagent token | 0 | ~2,500 | N/A |
| 交互轮次 | 22 | 4-5 | -80% |
| 总耗时 | 5-8 min | 1.5-3 min | 2.5-3x |
关键优化点
1. 上下文节省
- ✅ 逐维度评分对话不占用主 agent 上下文
- ✅ 报告生成模板不占用主 agent 上下文
- ✅ 主 agent 只处理结构化评分数据
- ✅ Token 使用减少 90%+
2. 执行效率
- ✅ 多个需求并行预分析
- ✅ 用户只需确认而非逐维度回答
- ✅ 交互轮次从 22 轮降至 4-5 轮
- ✅ 总耗时减少 60-70%
3. 评分质量
- ✅ 预分析基于前置文档数据,减少主观猜测
- ✅ 每个评分都有明确依据(key_evidence)
- ✅ 数据不确定性在 risk_flag 中标注
- ✅ 用户保留最终决策权
兜底机制
场景 1: 无需求清单
提供快速模式,允许手动输入需求列表。
场景 2: 需求数量过多
如果需求数量 > 15,询问用户:
⚠️ 需求数量较多({N}个),评分可能需要较长时间
您可以选择: A) 全部评分 B) 仅对核心需求评分(前10个) C) 我来选择要评分的需求
场景 3: Subagent 预分析失败
如果某个 subagent 执行失败:
- 主 agent 检测到错误
- 标记该需求为"需手动评分"
- 对其余需求继续确认流程
- 对失败的需求,降级为手动逐维度询问
场景 4: 无前置文档(快速模式)
如果无前置文档可供 subagent 分析:
- 跳过步骤 3(预分析)
- 直接进入手动评分模式(原 v1.1.0 流程)
- 仍然使用 subagent 生成报告(步骤 5)
异常处理
如果 subagent 执行失败:
- 主 agent 检测到错误
- 提供降级方案:手动逐需求评分(原 v1.1.0 模式)
- 记录错误信息供用户排查
版本说明
v2.0.0 - Subagent 架构重构
- 新增 Agent 工具支持
- 需求预分析并行化(Subagent 读取文档 + 评分建议)
- 报告生成 Subagent 化
- 交互轮次减少 80%
- Token 节省 90%+
- 评分增加数据依据追溯
v1.1.0 - 功能增强
- 新增自定义权重评分模型
- 需求数量 > 15 的分批处理
v1.0.0 - 初始版本
- RICE/KANO/MoSCoW 三种排序模型
- 逐需求交互评分
- 优先级排序报告生成
注意事项
- 一次一个需求确认:避免用户负担过重
- 评分标准明确:每个选项对应明确分数
- RICE计算自动:AI自动计算得分
- 优先级分组:P0/P1/P2/P3便于后续决策
- Markdown存储:排序报告人类可读可编辑
- Subagent 预分析:基于文档数据的评分建议,用户拥有最终决定权
输出质量对比
✅ Good 示例:
- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」 - 有验证来源:「数据来源:Google Analytics, 2025-12-01」 - 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例:
- 模糊结论:「数据表明留存率有所下降」 - 无来源:「根据经验,这个功能很重要」 - 没有行动建议:「留存是个问题」
常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯:
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证,再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
产出质量检查 / Verification Checklist
- 前置依赖已满足(输入文档/数据已收集)
- 核心步骤已全部执行
- 输出文档已生成到
docs/目录 - 每个评分都有数据/证据支撑
- 已推荐 2-3 个后续 skill
⚠️ 任何一项未通过 → 补全后再标记完成。


