# Requirement To Prd

> 把一句话的产品想法、老板的灵感、会议纪要或用户反馈，写成一份结构化、可评审、研发能直接接的 PRD。当用户说"帮我写个 PRD"、"把这个需求写成文档"、"出一份产品需求文档"、"这个想法整理成 PRD"，或者丢来一段粗糙的需求描述希望落地成正式文档时使用。

- Skill: `chenpianzhou/requirement-to-prd` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add chenpianzhou/requirement-to-prd`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chenpianzhou/requirement-to-prd/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: chenpianzhou (https://skillmd.com/u/chenpianzhou)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chenpianzhou/requirement-to-prd

---


# 需求转 PRD

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

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

## 工作流

### 第 1 步：判断信息够不够

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

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

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

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

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

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

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

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

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

### 第 4 步：产出 PRD

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

### 第 5 步：自检

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

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

## 关于"假设"

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

## 输出

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

## 会被打回的写法（红线）

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