chenpianzhou 需求转 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，通篇是脑补的需求
- 把待确认的假设当成事实陈述，不做任何标注
- 罗列一堆功能，但没有优先级、没有"非目标"
- 只写理想主流程，不写异常流和边界条件
- 成功指标写成"提升用户体验""增强用户粘性"这种没法衡量的空话
- 用户故事写成功能清单的复述（"作为用户，我想要一个按钮"），没有动机和价值