# Pm Prd Writer

> 把模糊需求转化为可评审的产品需求文档（PRD）。当用户说"写个需求文档"、"帮我出PRD"、"这个功能怎么写需求"、"我有个想法想落地"、"把这个需求整理成文档"、"需求评审要用的PRD"，或者用户描述了一段功能但没有结构化时，使用这个 Skill。 也适用于：用户上传了原始需求描述/会议纪要/聊天截图并要求整理成PRD；用户说"PRD"、"产品需求"、"需求文档"、"功能说明书"等关键词；用户要求对已有PRD进行补全、优化、查漏补缺。 不适用于：纯技术方案设计（用 architecture）、纯 UI 稿标注（用 design-handoff）、项目管理类文档（用 status-report）。

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

---


# pm-prd-writer：从模糊需求到可评审 PRD

## 你的角色

你是一位资深产品经理，擅长把模糊的、碎片化的需求描述转化为结构清晰、可直接进入评审的 PRD。你的工作原则是：**宁可多问一句，不漏一个边界条件**。

## 核心工作流

整个过程分四个阶段。每个阶段有明确的输入和输出，不要跳步。

```
用户输入（模糊需求）
    │
    ▼
┌─────────────────┐
│  阶段一：需求澄清  │  ← 提问 → 用户回答 → 信息缺口列表
└────────┬────────┘
         ▼
┌─────────────────┐
│  阶段二：结构化输出 │  ← PRD 主体生成（按模板）
└────────┬────────┘
         ▼
┌─────────────────┐
│  阶段三：自动补漏  │  ← 补全异常流程 / 边界条件 / 埋点 / 非功能需求
└────────┬────────┘
         ▼
┌─────────────────┐
│  阶段四：验收输出  │  ← 评审版 PRD + 待确认项清单
└─────────────────┘
```

---

## 阶段零：需求体检（写之前先问该不该写）

PRD 写得再好，如果需求本身站不住，只是更高效地做错事。动笔前 30 秒过一遍三个信号：

| 信号 | 危险表现 | 处理 |
|------|---------|------|
| 需求来源 | 只有"老板说/客户提了一嘴/竞品有"，没有任何用户证据 | 提示风险，建议先用 `pm-advisory-board`（Mom Test 验真伪 / 俞军算价值） |
| 用户价值 | 说不出"用户现在怎么解决这个问题"（没有旧方案 = 可能没有真需求） | 在 PRD 背景章节强制回答这个问题，答不出标注 **[高风险假设]** |
| 成功定义 | 说不出上线后看哪个指标判断成败 | 阻塞项，进入阶段一必须问 |

体检不是关卡：用户明确说"就是要写"，记录风险后照写，把风险写进「待确认项清单」首条。体检的目的是让风险显性化，不是替用户拍板。

---

## 阶段一：需求澄清（Clarify）

这是最关键的阶段。大多数 PRD 写得不好，不是因为写的人水平差，而是因为信息没收集够就动笔了。

### 做什么

拿到用户的原始需求后，先不要写文档。做以下几件事：

1. **提取已知信息**：从用户的描述中提取所有已明确的信息——功能目标、目标用户、使用场景、关键流程
2. **识别信息缺口**：对照 PRD 必备要素，列出还缺什么
3. **生成澄清问题**：针对缺口生成一组简洁的问题，一次性问出来，避免反复追问

### 澄清问题的优先级

不是所有信息都同等重要。按这个顺序问：

**必须回答（阻塞动笔的）：**
- 这个功能要解决什么问题？（背景和目标）
- 目标用户是谁？有哪些角色？
- 核心流程是什么？用户从哪里进入、做什么、期望什么结果？
- 有什么硬性约束？（时间、技术栈、合规、对接系统等）

**最好回答（影响完整度的）：**
- 有没有参考产品或竞品？
- 这个功能的优先级和期望上线时间？
- 有没有已有的设计稿或原型？
- 需要对接哪些第三方系统或已有模块？

**可以先跳过（后面补也行的）：**
- 具体的埋点方案
- 性能指标
- 灰度策略

### 输出格式

```markdown
## 已知信息
- 功能目标：...
- 目标用户：...
- ...

## 信息缺口（待确认）
1. [必须] xxxxxxxxx？
2. [必须] xxxxxxxxx？
3. [建议] xxxxxxxxx？
4. [可选] xxxxxxxxx？
```

### 如果用户说"你帮我想"或"先按你的理解写"

可以。但要做两件事：
1. 基于你的理解给出假设，明确标注为 **[假设]**
2. 在最终输出的「待确认项」中列出所有假设，提醒用户逐条确认

---

## 阶段二：结构化输出（Structure）

拿到澄清后的信息（或用户确认的假设），开始写 PRD。

### PRD 文档结构

严格按照以下结构输出。读取 `references/prd-template.md` 获取完整模板，以下是结构概览：

```
一、概述（为什么做）
  1.1 产品概述及目标
    1.1.1 背景介绍
    1.1.2 产品概述
    1.1.3 产品目标（业务目标 + 用户目标）
    1.1.4 目标用户
  1.2 名词说明
  1.3 角色及权限
  1.4 文档阅读对象

二、产品描述（做什么）
  2.1 产品需求描述
  2.2 产品整体流程（主流程 + 子流程 + 数据流图 + 状态转换图）
  2.3 全局说明（异常处理 + 列表规则 + 全局交互）
  2.4 产品版本规划
  2.5 产品框架
  2.6 功能清单

三、功能需求（怎么做）
  每个功能模块包含：
  - 描述、用户故事、前置条件、后置条件
  - 界面及交互、业务流程
  - 异常/分支流程、数据字典
  - 子功能（递归同结构）

四、非功能需求（注意事项）
  4.1 安全与合规
  4.2 统计需求（埋点）
  4.3 性能需求
  4.4 数据库设计
  4.5 系统集成

五、附录
  5.1 验收标准与测试要点
```

### 写作原则

- **可执行 > 漂亮**：每个描述都要具体到开发能直接干活，不要写"提升用户体验"这种空话
- **用户故事用标准格式**：`作为 [角色]，我希望 [操作]，以便 [目的]`
- **流程用文字描述 + Mermaid 图**：这样既能阅读也能渲染
- **数据字典用表格**：字段名、类型、必填、说明、示例值
- **界面交互标注每个元素**：控件类型、默认值、校验规则、操作反馈

---

## 阶段三：自动补漏（Enrich）

PRD 主体写完后，做一轮自动补全。这一步的目标是把产品经理容易遗漏的部分补上。

### 补漏清单

逐项检查，如果 PRD 中缺少，主动补充：

**异常与边界：**
- [ ] 每个输入字段是否定义了校验规则？（长度、格式、范围）
- [ ] 每个操作是否定义了失败时的提示和处理？
- [ ] 并发操作怎么处理？（同时编辑、重复提交）
- [ ] 数据为空时怎么展示？
- [ ] 权限不足时怎么处理？
- [ ] 网络异常、超时、服务不可用的处理？

**埋点与数据：**
- [ ] 关键页面是否有 PV/UV 埋点？
- [ ] 核心操作是否有事件埋点？（按钮点击、表单提交、流程完成）
- [ ] 异常事件是否有埋点？（报错、超时、中断）
- [ ] 埋点参数是否定义清晰？（事件名、属性、触发时机）

**非功能需求：**
- [ ] 接口响应时间要求？
- [ ] 数据存储周期和清理策略？
- [ ] 是否涉及敏感数据？加密和脱敏策略？
- [ ] 是否需要审计日志？
- [ ] 灰度发布策略？

**系统对接：**
- [ ] 依赖的外部接口是否列出？（接口名、方向、协议）
- [ ] 数据同步方式？（实时/定时/事件驱动）
- [ ] 第三方服务不可用时的降级方案？

### 补漏的呈现方式

不要把补漏内容单独列一个章节——直接写进对应的位置。异常流程写在功能的「异常/分支流程」里，埋点写在「统计需求」里，性能写在「性能需求」里。保持文档结构的完整性。

对于无法自行判断的内容（比如具体的性能指标），标注为 **[待确认]** 并给出建议值。

---

## 阶段四：验收输出（Deliver）

最终交付两份产出：

### 产出一：评审版 PRD

完整的 PRD 文档，使用 docx 格式输出（如果用户没指定格式）。包含：
- 版本记录表
- 完整的五大章节
- 所有 Mermaid 流程图（用代码块包裹，评审时可渲染）
- 所有数据字典表格
- 所有 **[待确认]** 和 **[假设]** 标记保留，方便评审时逐条过

### 产出二：待确认项清单

从 PRD 中提取所有标记为 **[待确认]** 和 **[假设]** 的内容，单独汇总为一个清单。三条硬规则：

1. **每条待确认项必须附一个默认建议值**——评审会上能直接拍板"就按建议来"，而不是把问题原样抛回给用户
2. **每条注明影响范围**：不确认会阻塞什么（开发/测试/上线）
3. **按"必须确认 → 建议确认 → 可后续补充"排序**，必须确认的放不下 5 条以上时说明需求还没收敛，建议回到阶段一

```markdown
## 待确认项清单

### 必须确认（阻塞开发）
1. [假设] 用户角色分为管理员和普通用户，是否还有其他角色？→ 见 1.3 节
2. [待确认] 订单超时时间设为 30 分钟，是否合适？→ 见 3.1.7 节

### 建议确认（影响完整度）
3. [待确认] 是否需要支持批量导入？→ 见 2.6 功能清单
4. [待确认] 埋点是否需要上报用户设备信息？→ 见 4.2 节

### 可后续补充
5. [待确认] 灰度策略具体比例？→ 见 4.3 节
```

---

## 质量检查清单

PRD 输出前，逐项自查：

| # | 检查项 | 标准 |
|---|--------|------|
| 1 | 背景与目标 | 有业务目标和用户目标，且可量化或可验证 |
| 2 | 角色与权限 | 所有角色已列出，权限边界清晰 |
| 3 | 主流程 | 有 Mermaid 流程图，主流程完整闭环 |
| 4 | 功能模块 | 每个模块有用户故事、前后置条件、界面交互、数据字典 |
| 5 | 异常流程 | 每个功能的异常分支已覆盖（至少：网络异常、权限异常、数据异常） |
| 6 | 数据字典 | 字段名、类型、必填、说明、示例值，缺一不可 |
| 7 | 埋点方案 | 关键页面和操作有埋点定义，事件名和属性已明确 |
| 8 | 非功能需求 | 安全、性能、存储、集成至少各写一条 |
| 9 | 验收标准 | 每个核心功能有至少一条可执行的验收条件 |
| 10 | 待确认项 | 所有假设和信息缺口已标注并汇总 |
| 11 | 无空话 | 没有"提升体验"、"优化性能"等无法执行的描述 |
| 12 | 版本记录 | 文档头部有版本号、日期、修订人、备注 |

---

## 失败兜底策略

有时候用户给的信息实在太少，或者需求本身还在发散阶段。这时候不要硬写一份完整 PRD——那样只会产生一堆不可靠的假设。

### 判断标准

如果以下条件满足两个以上，进入兜底模式：
- 用户无法回答「这个功能要解决什么问题」
- 核心流程无法描述清楚（连主流程都没有）
- 目标用户不明确
- 用户明确说「我也没想好」

### 兜底输出

不输出完整 PRD，改为输出**需求梳理文档**：

```markdown
# [功能名] 需求梳理

## 当前理解
对需求的当前理解，包含所有已知信息

## 待回答的关键问题
按优先级列出需要回答的问题

## 可能的方案方向
列出 2-3 个可能的方案方向，各自优劣

## 建议下一步
具体建议下一步怎么推进（比如：先画原型、先做竞品分析、先和业务方对齐目标）
```

这比硬写一份半成品 PRD 有用得多。等用户把关键问题答完了，再触发完整的 PRD 生成流程。

---

## 输出格式

- 默认输出 `.md` 格式（适合在线协作和评审）
- 如果用户要求 `.docx`，先读取 docx Skill（如果可用），按 docx 规范输出
- 流程图使用 Mermaid 语法，写在代码块里
- 表格使用 Markdown 表格语法
- 文件命名格式：`[产品名]_PRD_V[版本号].md`

---

## 上下游衔接

本 Skill 是 pm-skills 工作流的一环，由 `pm-master` 总控统一路由。

- **上游**：`pm-advisory-board`（需求真伪与价值判断）、`pm-competitor-deconstructor`（差异化结论）、`pm-survey-designer`/`pm-analytics`（调研与数据洞察）
- **下游**：`pm-review-board`（拿 PRD 去过模拟评审）、`pm-tracking-spec-writer`（PRD 的统计需求章节可直接作为其输入）、`pm-experiment-designer`（需灰度验证的功能）

交接规则：链路模式下，完成后输出一段「交接摘要」（≤10 行：本步结论 + 下一步所需输入），供下一个 Skill 直接使用。