| 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 上游产物文件夹约定」段）
落盘前强制步骤：
- 查
05-prd/README.md 当前活跃版本号（如 V1 / V2 / V3）
- 确认
{项目目录}/02-analysis-report/ 文件夹存在；不存在则 mkdir
- 临界点检查：如果文件夹外存在旧版
02-analysis-report.md（或 -V1.md 等 v1 后缀文件）→ 先 mv 到 02-analysis-report/V1.md 并补 V1 frontmatter
- 写入
02-analysis-report/V{当前版本}.md，frontmatter:
---
version: V{x}
status: 草稿
phase: 需求分析
upstream-from: V{x-1}.md
created: YYYY-MM-DD
---
- 同步 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. 建议与下一步
{分析结论和行动建议}
