技能介绍

要解决什么问题

产品讨论里常见的情况是：用户只说「想做一个 xxx」「帮我写个需求」，背景、目标用户、边界和验收标准都没说清楚。若助手一次性抛出十几个问题，回答成本高；若直接猜着写 PRD，又容易把未确认的判断写进正文，后续评审扯皮。

本技能面向模糊或不完整的自然语言需求描述，用分阶段对话把信息补齐，最终落盘为结构化 PRD，而不是替代已有完整文档的润色流程。

技能如何工作

核心原则是每轮只聚焦一个主题（通常 3～5 个问题），通过 AskUserQuestion 给出常见选项以降低作答成本；每轮结束后会简要复述已知信息，便于纠偏。

典型推进路径：

意图确认：先复述诉求，说明接下来会从背景、场景、方案、验收等维度提问；极模糊时先用开放问题锁定「做什么」。
背景与目标（Why）：痛点、可量化目标、优先级与时间窗口。
用户与场景（Who & When）：角色、触发情境、频次、当前替代方案。
功能方案（What）：主流程、关键字段/状态、异常与边界、依赖与约束；列表/审批/导入导出等模式可对齐问题库模板。
验收与非功能：可测试的 AC、Out of scope、性能/权限/埋点等。

当「核心目标 + 目标用户 + 主流程 + 主要异常 + 验收标准」齐备，或经历约 3～5 轮后，会按模板写出 PRD 到 docs/prd/，包含功能点编号（如 F-001）、Mermaid 流程（必要时）、待确认假设与建议下一步，并用 open_result_view 展示路径。

用户说「你看着办」或「直接写」时：前者给出带理由的默认并标为假设；后者停止追问，在 PRD 中集中列出假设。

适用边界

适合：功能想法、迭代点、优化诉求的需求拆解与 PRD 初稿。
不适合：已有完整 PRD 仅需 review/润色；纯技术实现问答（不涉及产品规划）。
注意：PRD 写 What/Why，不把表结构、框架选型等实现细节塞进去；避免重复已答问题；AskUserQuestion 勿手动加「其他」选项（工具自带自由输入）。