---
name: prd-from-notes
description: 把零散的笔记、Slack 讨论串、通话记录或创始人的想法整理成产品需求文档（PRD），包括问题及其证据、用户、目标和非目标、成功指标、必须/应该/可以三级需求、待定问题和风险。遇到缺口就标出来，不编造。适用于有人要从零散笔记写出 PRD、需求规格、一页纸简报，或说“把这个写清楚，让研发能开工”时。
---

# 从笔记写 PRD

好的 PRD 让工程师和设计师不用开会就能开工，也让读者分清哪些是已知、哪些是推测。先写问题，再写方案；每条需求都要对应到问题；每个缺口都要明确标出来：隐藏缺口的 PRD，最后一定会做错。

## 适用场景

- 你手上有关于某个功能的笔记、Slack 讨论串、通话记录或客户原话，需要一份 PRD。
- 创始人在一次通话或白板讨论之后说“把这个写出来给团队看”。
- 有人想在决定要不要做之前，先看一页纸简报。
- 不适用于审阅已完成的 PRD：请用 spec-review。也不适用于把工作拆成工单：请用 user-stories。

## 需要准备

- 原始材料：笔记、讨论串、文字记录、原话、用文字描述的截图。
- 笔记中没写时，这个功能是给谁的。问一次；仍然没有的话，写“[假设：目标用户]”。
- 已知的截止日期、限制条件或指标目标。没有的话，目标写“[待定：未设定目标]”。

## 步骤

1. **提炼问题及其证据。** 回答 Marty Cagan 机会评估中的第一个问题：这解决了什么问题，为谁解决？把问题写成用户今天做不到什么，或者这让他们付出了什么代价。在下面列出证据：原话、工单数量、丢掉的单子、数据。笔记里没有证据时，写“笔记中没有证据”，不要编造理由。
2. **点明用户。** 一个主要用户，最多 2 个次要用户，并写出问题出现时他们所处的情境。“小企业主”太宽泛；“第一次用手机开发票的店主”才对。
3. **区分目标和非目标。** 目标是成果，不是功能。至少写 2 个非目标；笔记中讨论过又放弃的内容都放在这里，免得有人重新提起。
4. **设定成功指标。** 一个问题解决后就会变化的主要指标，外加 1 到 2 个不能变差的护栏指标。每个指标都需要基线和目标值；笔记没给出时，写“[待定：基线]”和“[待定：目标值]”。
5. **按必须/应该/可以（MoSCoW）写需求。** 必须 = 没有它方案就不成立。应该 = 很重要，不做会很痛，但有变通办法。可以 = 有更好，日期有风险时第一个砍掉。不做（这次）放进非目标，免得被悄悄加回来。每一行都可测试（“用户可以导出为 CSV”），而不是含糊其辞（“导出方便”）。Agile Business Consortium 的指南中，“必须”项通常不超过工作量的 60%；如果必须项看起来超过这个比例，要指出范围对一次发布来说太大了。
6. **列出待定问题和风险。** 两份笔记之间的每一处矛盾都变成一个待定问题，写明双方的立场。风险涵盖可能让功能失败的因素：采用率、技术、法律、对其他团队的依赖。笔记中点名了负责人的，写上负责人。
7. **标明每条内容的来源。** 来自笔记的事实直接写。你推断出来的内容标“[假设]”。输入中没有的数字、日期或客户名称，一律不填。

## 输出格式

```markdown
# PRD：[功能名称]

**作者：** [姓名] · **状态：** 草稿 · **最后更新：** [日期]

## 问题
[2 到 4 句话：用户今天做不到什么，这让他们付出了什么代价。]

**证据**
- [原话、数量或数据点，附来源]

## 用户
- **主要用户：** [谁，处在什么情境]
- **次要用户：** [谁，处在什么情境]

## 目标
- [成果]

## 非目标
- [这次发布不做什么，已知的话写上原因]

## 成功指标
| 指标 | 类型 | 基线 | 目标值 |
|---|---|---|---|
| [指标] | 主要指标 | [数值或待定] | [数值或待定] |
| [指标] | 护栏指标 | [数值或待定] | [不能低于……] |

## 需求
| # | 需求 | 优先级 | 备注 |
|---|---|---|---|
| R1 | [可测试的描述] | 必须 | [来源或假设] |

## 待定问题
- [问题] — [负责人，如已知]

## 风险
- [风险] — [应对措施或“暂无”]

## 笔记中的缺口
- [开发前团队必须决定、但笔记中缺失的内容]
```

## 示例

**输入（节选）：**

> Slack，王丹（客户成功）：这周有 3 个客户问，能不能邀请他们的会计进来，但不为这个席位付费。
> 通话记录，陈刚（创始人）：“只读席位？也许免费。暂时不想做角色体系。”
> 李锐（研发）：每个写入接口都要加权限校验，大概 2 周。

**输出：**

```markdown
# PRD：给会计的免费只读席位

**作者：** [姓名] · **状态：** 草稿 · **最后更新：** [日期]

## 问题
客户不为会计买一个完整席位，就没法让会计查看账目。

**证据**
- 一周内 3 个客户提出需求（王丹，客户成功，Slack）。

## 用户
- **主要用户：** 需要会计每月核对数字的账户所有者。
- **次要用户：** 会计，只查看，从不编辑。

## 目标
- 所有者无需为席位付费，就能让外部审阅人访问。

## 非目标
- 完整的角色和权限体系（陈刚：“暂时不想做角色体系”）。
- 会计的编辑权限：席位只读（陈刚：“只读席位？”）。

## 成功指标
| 指标 | 类型 | 基线 | 目标值 |
|---|---|---|---|
| 拥有 1 个及以上只读席位的账户数 | 主要指标 | 0 | [待定：目标值] |
| 付费席位数 | 护栏指标 | [待定：基线] | 不下降 |

## 需求
| # | 需求 | 优先级 | 备注 |
|---|---|---|---|
| R1 | 所有者可以通过邮箱邀请某人成为只读用户 | 必须 | 王丹收集的需求 |
| R2 | 只读用户不能新建、编辑或删除任何内容 | 必须 | 李锐：每个写入接口都要校验 |
| R3 | 只读席位不计入计费 | 必须 | 陈刚：“也许免费”（待确认） |
| R4 | 所有者可以移除只读用户 | 应该 | [假设] |

## 待定问题
- 这个席位是免费，还是降价收费？陈刚说的是“也许免费”。 — 陈刚
- 每个账户可以有几个只读席位？ — 未讨论

## 风险
- 付费用户为了省钱，把同事降为只读。 — 考虑为每个账户设上限

## 笔记中的缺口
- 没有采用率目标。
- 没有提到会计第一次登录时看到什么。
- 没有提到客户现在怎样把账目交给会计。
```

## 发送前检查

- [ ] 问题部分写明了用户和代价，没有提到方案。
- [ ] 每个数字、名字和原话都出现在输入中；其余内容都标了“[假设]”或“[待定]”。
- [ ] 每条需求都可测试并有优先级；“必须”项看起来不超过工作量的 60%。
- [ ] 至少有 2 个非目标。
- [ ] 笔记中的每一处矛盾都列为待定问题。
- [ ] 主要指标有基线和目标值，或者两者都标为待定。

## 常见错误

- 把方案写进问题（“用户需要一个只读角色”）。问题是哪里痛，不是你要做什么。
- 把两个人的分歧抹平。两边的原话都引用，保留为待定。
- 写“用户满意度”这类无法衡量的指标。写出你要统计的事件或数字。