需求规划助手

要解决的问题

需求沟通里最常见的失败模式，不是产品想得不够多，而是想法还没成形就被写成了文档。一句「我想加个批量导出」背后，缺的是谁在用、解决什么痛点、边界到哪、怎样算做完——这些信息不会凭空出现，只会在反复追问中漏掉。结果要么 PRD 写完才发现方向偏了，要么评审会上大家对验收标准各说各话。

requirement-planning 就是为这个环节设计的：当用户用自然语言抛出一个模糊或不完整的功能想法时，它负责把对话组织成几个聚焦的轮次，把散点信息收敛成一份可执行的 PRD。

核心能力

分阶段提问，而不是问卷轰炸。 每轮只围绕一个主题，控制在 3–5 个问题，通过 AskUserQuestion 给出 2–4 个常见选项加简短说明，降低作答成本；用户也能自由输入。每轮结束时先复述已知信息，让用户看到推进有形、随时可以纠偏。

轮次按维度收敛。 大致的节奏是：先确认意图与提问维度（不提问，只复述），然后依次过背景与目标（Why）、用户与场景（Who & When）、功能方案（What，含异常与边界）、验收标准与非功能要求（AC、性能、权限、Out of scope）。涉及列表、表单、审批、通知、导入导出、搜索筛选等常见模式时，会套用对应的标准问题模板。

收敛判断内置在流程里。 当「核心目标 + 目标用户 + 主流程 + 主要异常 + 验收标准」五项齐全就停止提问，直接产出；一般 3–5 轮内完成。用户答不出时给出标注为「假设」的默认建议继续推进，而不是卡住。

产出有固定落点。 PRD 写入 docs/prd/，基于 prd-template.md 结构，包含编号功能点（F-001…）、可测试的验收标准（Given/When/Then 或 Checklist）、In/Out of scope、依赖与风险，以及单独成节的待确认假设和建议下一步。写完后给出文件路径并展示给用户预览，修改时迭代同一文件，并在每日 memory 里记一条摘要。

适用边界

• 不处理完整 PRD 的润色。 用户已经给出完整文档只让 review 时，直接 review，不要重复提问。
• 不回答纯技术实现问题。 PRD 聚焦 What/Why，框架选型、表结构这类 How 不属于这里。
• 尊重用户的加速指令。 一句「不用问了，直接写」就该立刻收口，按已知信息产出并把所有推断标注为假设，而不是继续追问。
• 不做无限追问。 超过 5 轮仍未收敛时主动收口，缺口写进「待确认」而不是反复重问已答过的内容。

换句话说，它把「让 AI 帮你写需求」变成一件可控的事：每轮有聚焦、产出有结构、假设有清单，而不是一次性吐出一篇看着完整、实则没有上下文依据的文档。