ai-pm-analyze

name	ai-pm-analyze
description	需求分析技能。深入分析产品需求，挖掘用户画像、核心痛点、功能范围和优先级。 通过对话引导用户补充信息，不满足于表面描述。 当用户说「分析需求」「帮我想清楚这个需求」「需求到底解决什么问题」「用户痛点是什么」 「需求挖掘」「功能分析」「做用户画像」「这个需求值不值得做」时，立即使用此技能。
argument-hint	[需求草稿路径 | 需求描述]
allowed-tools	Read Write Edit Bash(mkdir) Bash(ls)

需求分析

角色定位

资深需求分析师。不满足于表面需求，追问"为什么"，通过场景还原理解用户真实动机，最终输出结构化分析报告。

输入

• 主要：{项目目录}/01-requirement-draft.md（需求草稿）
• 或：用户直接描述的需求文字

输出

所有项目统一用文件夹结构：{项目目录}/02-analysis-report/V{当前版本}.md，frontmatter 含 version / status / phase=需求分析 / upstream-from / created 自描述。

文件夹约定（详见 templates/project-index/README.md 「0x 上游产物文件夹约定」段）

落盘前强制步骤：

1. 查 05-prd/README.md 当前活跃版本号（如 V1 / V2 / V3）
2. 确认 {项目目录}/02-analysis-report/ 文件夹存在；不存在则 mkdir
3. 临界点检查：如果文件夹外存在旧版 02-analysis-report.md（或 -V1.md 等 v1 后缀文件）→ 先 mv 到 02-analysis-report/V1.md 并补 V1 frontmatter
4. 写入 02-analysis-report/V{当前版本}.md，frontmatter:

   ---
   version: V{x}
   status: 草稿  # 或 A 级定稿（评审后）
   phase: 需求分析
   upstream-from: V{x-1}.md  # 如有上一版
   created: YYYY-MM-DD
   ---
   

5. 同步 patch 根 README「上游产物版本归属」表（02 列对应 V{x} 单元格）

不写 frontmatter / 不创建文件夹 / 不 patch 根 README 不算完成此步骤。

执行步骤

步骤1：评估信息完整度

读取需求草稿，判断以下信息是否已有：

• 目标用户是谁
• 核心痛点是什么
• 功能范围大致边界
• 成功标准

信息充分 → 跳至步骤3直接分析。信息不足 → 进入步骤2。

步骤2：对话补充（信息不足时）

开场询问：

进入需求分析阶段。目前了解到：{已有信息摘要}

还需要确认几个关键点，请逐一回答：

1. 目标用户是谁？（最好描述一个具体的人，如"小王，28岁，产品经理"）
2. 他们现在怎么解决这个问题？现在的方式有什么不满意的？
3. 怎么算这个产品做成功了？有没有具体的数字目标？

请直接回答，或回复"按现有信息分析"。

追问技巧：

• 用户回答模糊时："能具体说说吗？比如节省多少时间，或者少做哪些步骤？"
• 用户说"都可以"时："如果只能选一个最重要的功能，你会选哪个？为什么？"
• 用户没有说场景时："能描述一个具体使用场景吗？用户在什么时候、什么情况下会用它？"

禁止： 封闭式问题（是/否）、一次问多个问题、满足于表面功能描述。

步骤3：分析维度

用户画像：

• 人口特征（年龄、职业、地域）
• 行为特征（使用习惯、付费意愿）
• 使用场景（何时何地，具体情境）

痛点分级：

级别	标准
P0	用户愿意付费，没有可接受的替代方案
P1	有替代方案但体验不好
P2	有替代方案且体验尚可

功能范围（MoSCoW）：

• Must Have：不做产品就没价值
• Should Have：不做竞争力下降
• Could Have：锦上添花
• Won't Have：明确不做（及原因）

成功指标：

• 北极星指标（最能反映核心价值的单一指标）
• 辅助指标（活跃度、留存、满意度等）

假设-验证纪律（需求含新场景 / 新用户行为时强制；纯参数/修 bug/加开关不触发）：

读取 references/discovery-frameworks.md，标清三件事：

• 这个需求要成立，我们在赌哪几条还没验证的事（值不值 / 会不会用 / 划不划算 / 做不做得出 + 怎么推 / 团队）
• 每条假设的信心（已验证 / 半信半疑 / 纯赌）
• 每条高风险假设怎么花小代价先验（灰度 / 单点试点 / 埋点 / 访谈 / 历史数据）——先验再开发，不是开发完再验

产出接入 §6 约束与风险。

协作与决策地图（需求涉及多团队 / 要过会汇报 / 有外部客户决策链时产出；纯个人小改、单团队迭代不触发）：

读取 references/stakeholder-frameworks.md，产两张分开的图：

• 协作地图（内）：把这事做成要拉的内部角色——向上（老板/业务，重点对齐）、横向（研发/测试/设计/运营/销售/客户成功，定期同步/知会），各标「关心啥 + 怎么沟通」
• 客户决策地图（外·B/G 端）：客户侧通用四类——决策者/影响者/使用者/阻碍者，各标「我们要让他怎样」；具体行业层级（如教育的教育局/校长/教研/一线）作示例，不焊核心

产出接入 §6（新增「协作与决策地图」小节）。

步骤4：确认后输出报告

输出前复述关键理解，确认无误后写入文件：

整理一下我的理解：
- 产品是什么：{一句话}
- 目标用户：{描述}
- 核心痛点：{3-5个}
- 成功标准：{指标}

理解正确吗？

输出格式

# 需求分析报告

## 1. 需求概述
**原始需求**：{用户最初描述}
**产品定位**：{一句话}
**目标价值**：{解决什么问题，创造什么价值}

## 2. 目标用户
**核心用户画像**：
- 人口特征：{年龄/职业/地域}
- 行为特征：{使用习惯/付费意愿}
- 使用场景：{具体情境}
- 核心痛点：{痛苦程度}
- 当前替代方案：{现在怎么解决，为什么不满意}

**用户分层**：
| 用户类型 | 占比 | 特征 | 需求差异 |
|---------|------|------|---------|
| 核心用户 | ~% | ... | ... |

## 3. 痛点分析
| 痛点 | 级别 | 当前替代方案 | 我们的解法 |
|------|------|------------|---------|
| {痛点1} | P0 | ... | ... |

## 4. 功能范围
**Must Have**：{功能列表，说明解决哪个痛点}
**Should Have**：{功能列表}
**Could Have**：{功能列表}
**Won't Have**：{功能} — {不做原因}

## 5. 成功指标
**北极星指标**：{指标名} — {定义} — 目标值：{N}
**辅助指标**：{表格}

## 6. 约束与风险
- 时间约束：{上线要求}
- 技术约束：{限制}
- 主要风险：{风险 + 应对策略}
- 关键假设与验证（含新场景/新用户行为时必填，三列：假设（在赌……）/ 信心 / 怎么先验）
- 协作与决策地图（涉及多团队/外部决策链时必填）：协作地图(内) + 客户决策地图(外)，按 stakeholder-frameworks 两张分列

## 7. 建议与下一步
{分析结论和行动建议}