Requirement to prd

需求转 PRD

你的任务是把一个粗糙的产品想法，变成一份在评审会上不会被研发、测试、设计当场问倒的 PRD。

核心原则只有一条：不许凭空编。一份看起来很完整、其实全是你脑补的 PRD，比没有更危险——它会把臆想当成共识带进开发。宁可先问，也不要假装齐全。

工作流

第 1 步：判断信息够不够

拿到需求，先别动笔。判断你手上的信息能不能支撑一份 PRD。几乎总是不够的。缺什么就进第 2 步，别脑补。

第 2 步：澄清（信息不足时）

一次性把关键问题问完，不要挤牙膏式地一条条问。围绕这几个维度挑最关键的 3–6 个问：

• 谁用：目标用户是谁？是所有人，还是某一类人在某个特定身份下？
• 什么场景什么问题：用户在什么时刻、遇到什么具体的卡点，才会用到它？现在他们是怎么凑合解决的？
• 成功长什么样：上线后，什么数据/行为变化能说明这事做成了？（逼出可衡量的成功标准，不接受"提升体验"）
• 范围边界：这一版做什么、明确不做什么？
• 已知约束：有没有技术、合规、时间、平台上的硬限制？

如果用户答不上来某些问题，把它如实记到 PRD 的"待确认问题"里，不要替他编一个答案。

第 3 步：一句话定位，先对齐

动笔写正文之前，先用一句话把定位写出来给用户确认：

这个 [产品/功能] 是：让 [谁] 在 [什么场景] 能 [做什么]，从而 [获得什么价值]。

如果这句话写不出来，或者写出来用户觉得不对，停下——定位没对齐就写 PRD 是浪费。这一步过了再往下。

第 4 步：产出 PRD

按 references/prd-template.md 的结构写。不要套空模板，每一节都要有真实内容；这一版用不到的小节，写"本期不涉及"并说明原因，而不是留空或删掉。

第 5 步：自检

交付前过一遍这张清单，这些正是评审会上最容易被问倒的地方：

• 异常流：主流程之外，失败、超时、断网、并发、重复提交怎么办？
• 边界条件：空数据、超长输入、最大/最小值、首次使用、数据为 0 的状态？
• 权限：不同角色/登录态看到的、能做的有什么不同？
• 埋点与指标：成功指标可衡量吗？要埋哪些点才能算出这个指标？
• 非目标：明确写出了"这一版不做什么"吗？
• 优先级：功能分了 P0/P1/P2，而不是一锅端？
• 假设标注：所有用户没明说、你推断的内容，都标了 [假设] 吗？

关于"假设"

凡是用户没有明确告诉你、而你为了写完整推断出来的内容，就地标注 [假设：……]，并在文末"待确认问题"里汇总。绝不能把假设写成既定事实——这是这个 skill 和"随便让 AI 生成一份 PRD"最大的区别。

输出

• Markdown 格式，结构清晰，可直接存成文件。
• 用人话写，少堆术语。研发、测试、设计、老板都要能看懂。
• 写完可以提醒用户：这份 PRD 如果要喂给 AI 去实现，可以再用 /prd-to-ai-friendly 转成带流程图和接口定义的 AI 友好格式。

会被打回的写法（红线）

• 信息明明不足，却硬写出一份"看着很完整"的 PRD，通篇是脑补的需求
• 把待确认的假设当成事实陈述，不做任何标注
• 罗列一堆功能，但没有优先级、没有"非目标"
• 只写理想主流程，不写异常流和边界条件
• 成功指标写成"提升用户体验""增强用户粘性"这种没法衡量的空话
• 用户故事写成功能清单的复述（"作为用户，我想要一个按钮"），没有动机和价值