requirement-planning
When to use
当用户用自然语言抛出一个模糊或不完整的产品功能想法、迭代点、优化诉求时，使用本 skill 通过分阶段问答引导用户把想法变成结构化、可落地的需求文档。
典型触发场景：
- "我想做一个 xxx 功能"、"想加个 xxx"、"xxx 要支持 xxx"
- "帮我写个需求"、"帮我整理一下 PRD"、"我有个产品想法"
- "这个功能要怎么做"、"帮我规划下需求"、"需求拆解"
- 用户描述了功能点但没说背景/用户/目标/边界/验收标准等关键信息
- 用户在产品/业务讨论中给出一段不完整的需求描述
不要触发：
- 用户已经给出完整 PRD，只让你 review 或润色（直接 review 即可，不要重复提问）
- 纯技术实现问题（"这段代码怎么写"），不涉及产品需求规划
- 用户明确说"不用问了，直接写"——尊重用户，按已知信息直接产出，并在 PRD 中标注假设
Core Principles
- 分阶段提问，不要一次抛 20 个问题。每一轮聚焦 1 个主题（3-5 个问题），让用户专注作答。
- 用 AskUserQuestion 工具收集结构化答案，每个问题给出 2-4 个常见选项 + 简短说明，降低用户作答成本；用户也可以选"其他"自由输入。
- 每一轮结束后简要复述已知信息，让用户感到推进有形，并能随时纠偏。
- 遇到用户说"你看着办"/"你帮我决定"时，给出有理由的默认建议，标注为「假设」，继续推进。
- 最终产出标准化 PRD 文档（Markdown），保存到工作区，并在末尾列出所有"待确认假设"和"建议下一步"。
- 保持节奏，不无限提问。一般 3-5 轮即可收敛；如果信息已足够，提前停止提问直接产出。
Steps
Step 1：意图复述与确认（不提问，先理解）
收到用户的初始描述后，先用 1-2 句话复述你理解的核心诉求，并用一个简短的判断告诉用户接下来会按哪几个维度提问。
示例话术：
> 我理解你想做的是「订单列表的批量导出功能」。我会先和你过一下：①谁在用、为什么用 ②场景与流程 ③范围与边界 ④验收标准。中间任何一步你觉得多余可以直接说"跳过"。
如果初始描述非常模糊（连功能主体都不清楚），用 1-2 个开放问题先把"做什么"问清楚，再进入分阶段流程。
Step 2：第一轮 —— 背景与目标（Why）
用 AskUserQuestion 一次性提 2-4 个问题，覆盖：
- 业务背景 / 痛点：当前面临的问题是什么？为什么现在要做？
- 核心目标：希望达成什么效果？有没有可量化的指标（如 DAU 提升、转化率、效率节省）？
- 优先级与时间窗口：这是 P0/P1/P2？期望什么时间上线？
提问示例：
- "这个功能要解决的核心痛点是？" → 选项：A. 现有流程效率低 / B. 用户反复反馈 / C. 竞品已有我们没有 / D. 新业务/新场景需求
- "你希望用什么指标衡量它的成功？" → 选项：A. 使用率/渗透率 / B. 转化率/留存 / C. 效率（耗时降低 X%）/ D. 暂无明确指标
Step 3：第二轮 —— 用户与场景（Who & When）
- 目标用户：是谁在用？是 C 端用户、B 端商家、内部运营、还是 API 调用方？
- 核心使用场景：在什么情境下触发？高频还是低频？
- 用户当前的替代方案：现在没有这个功能，用户怎么解决？
Step 4：第三轮 —— 功能方案（What）
- 核心流程：用户从哪里进入？关键操作步骤是什么？预期看到什么结果？
- 关键交互/字段：需要哪些输入项、哪些展示字段、哪些状态？
- 异常与边界：失败/无数据/权限不足/超出限制等情况怎么处理？
- 依赖与约束：是否依赖其他模块/数据？有没有合规、性能、成本上的硬约束？
如果用户描述的功能涉及"列表/表单/审批/通知/导入导出/搜索筛选"等常见模式，主动用对应模式的标准问题模板（见 @references/question-bank.md）。
Step 5：第四轮 —— 验收标准与非功能要求
- 验收标准（AC）：怎样算这个需求做完了？给出可测试的描述。
- 非功能要求：性能（响应时间、并发量）、权限、安全、埋点、国际化、移动端/PC 端等。
- 不做什么（Out of scope）：明确列出本期不做的内容，避免范围蔓延。
Step 6：信息充分判断 + 产出 PRD
每轮结束后判断信息是否充分：
- 「核心目标 + 目标用户 + 主流程 + 主要异常 + 验收标准」5 项齐全 → 可以产出
- 仍有缺口 → 进入下一轮针对性追问；不要重复问已经回答过的问题
- 一般 3-5 轮收敛；超过 5 轮还问不完，主动收口并在 PRD 里标注「待确认」
产出 PRD 文档到 {workspace}/docs/prd/<功能名>-PRD-<YYYY-MM-DD>.md（若 docs/prd 目录不存在，先创建）。使用 @templates/prd-template.md 作为基础结构。
PRD 必须包含：
1. 文档信息（标题、版本、作者/AI、日期、状态）
2. 背景与目标（业务背景、核心痛点、目标与衡量指标）
3. 目标用户与场景（用户画像、典型场景、使用频次）
4. 功能方案
- 核心流程（必要时用 Mermaid 流程图）
- 功能点列表（编号 F-001、F-002…，每条含描述、输入、输出、规则、异常）
- 关键字段/状态机（如适用）
- 交互与界面要点（必要时建议用 mockup 可视化）
5. 验收标准（Given/When/Then 或 Checklist 形式）
6. 非功能要求（性能、安全、权限、埋点等）
7. 范围说明（In scope / Out of scope）
8. 依赖与风险
9. 待确认假设（用户没明说、AI 替用户做出的判断，列出来供 review）
10. 建议下一步（设计稿、技术评审、排期、灰度策略等）
Step 7：交付与跟进
- 用 Write 工具落盘 PRD 文件
- 在回复中给出 PRD 文件路径，并用 open_result_view 展示
- 简要列出 3-5 个「待用户确认假设」，邀请用户 review
- 如用户确认或有修改，迭代更新同一个 PRD 文件（不要每次新建）
- 完成后追加一条记录到
{workspace}/.workbuddy/memory/YYYY-MM-DD.md，包含 PRD 路径与一句话摘要
Pitfalls
- ❌ 一次性抛 10+ 问题让用户回答 —— 改为分阶段，每轮 3-5 个聚焦问题
- ❌ 用户答了"我也不知道"还硬要问下去 —— 给出默认建议，标记为「假设」继续推进
- ❌ 把技术实现细节（用什么框架、几张表）塞进 PRD —— PRD 聚焦 What/Why，不写 How
- ❌ 把"待确认项"埋在正文里看不见 —— 单独一节"待确认假设"集中列出
- ❌ 每轮重新问一遍前面已经回答过的内容 —— 必须复述已知信息，只追问缺口
- ❌ AskUserQuestion 提供"其他"选项 —— 工具自动会有自由输入框，不要手动添加"其他"选项
- ❌ 用户说"快点直接给我 PRD" 还继续问 —— 立刻停止提问，按已知信息产出，假设全部标注
- ❌ PRD 写完不放路径不预览 —— 必须给出明确的文件路径并 open_result_view
Verification
完成时请自检：
- [ ] PRD 文件已创建在 docs/prd/ 目录下
- [ ] 包含背景、目标、用户场景、功能方案、验收标准、非功能要求、范围、风险、待确认假设、下一步 共 10 个章节
- [ ] 每个功能点有唯一编号（F-001…）
- [ ] 验收标准是可测试、可验证的（不是"系统稳定"这种空话）
- [ ] 「待确认假设」章节列出了 AI 替用户做的所有判断
- [ ] 已通过 open_result_view 把 PRD 展示给用户
- [ ] 已在 daily memory 里记一条
