第 6 课：PRD 编写实战

模块二：需求定义与文档 | 第 6 课

课前思考

小李已经想清楚了：他的极简待办清单目标用户是像自己一样的职场人，核心是"添加+勾选+删除"，不做分类和云同步。

他打开 AI 工具，输入："帮我做一个待办清单应用。"

AI 做了一个带登录注册、日历视图、团队协作的复杂系统。小李花了两个小时调试，最后放弃了。

问题在哪？不是想法不清楚，而是没有用结构化的方式告诉 AI 你要什么。

这就是 PRD 的作用：把你想清楚的东西，用 AI 能准确理解的方式写下来。在 AI 时代，PRD 不再是"给开发团队看的参考文档"，而是你和 AI 之间的执行契约。

---

什么是 AI 时代的 PRD

传统 PRD 通常是几十页的正式文档，包含市场分析、竞品对比、技术架构。它的读者是开发团队和老板。

AI 时代的 PRD 完全不同：

维度	传统 PRD	AI 时代的 PRD
阅读对象	开发团队、老板	AI
核心目的	对齐团队认知	让 AI 准确理解意图
篇幅	几十页	20-50 行关键信息
格式	Word/PPT	Markdown
更新频率	立项时写一次	随对话持续迭代

核心洞见：AI 时代 PRD 不是给人看的"报告"，而是给 AI 的"任务书"。写得越清楚，输出越精准；写得越模糊，结果越随机。

OpenAI 的 Sean Grove 甚至说：规范是新的源代码。 一个足够清晰的 PRD 可以生成代码、文档、测试、教程——它比你生成的代码更值得被精心维护和版本管理。

---

PRD 的五部分结构

一份好的 PRD 分为五个核心部分，对应"初稿 → 中稿 → 定稿"的迭代节奏：

部分	阶段	回答的问题
第 0 部分：文档信息	始终维护	这是什么版本？谁在负责？
第一部分：需求背景与目标	初稿	为什么要做？为谁做？
第二部分：方案概述	中稿	业务流程是什么？功能怎么走？
第三部分：细节方案	定稿	每个页面具体怎么交互？边缘情况怎么处理？
第四部分：上线计划	定稿	什么时候做？分几期？

迭代原则：初稿想清楚"为什么"，中稿想清楚"是什么"，定稿想清楚"怎么做"。每一步都有检查点，避免到最后才发现方向错了。

下面我们逐部分展开。

---

第 0 部分：文档信息

记录文档版本状态，让 AI 知道这是初稿还是定稿（定稿应该更详细，初稿可以留 TBD）：

## 文档信息

- **当前版本**：内部评审版-修订二
- **当前阶段**：需求评审中
- **核心干系人**：产品-小李、研发-待定
- **更新记录**：
  | 版本 | 更新内容 |
  |------|---------|
  | 初稿 | 阐述需求背景和核心价值 |
  | 修订一 | 补充业务流程和功能流程图 |
  | 修订二 | 补充边缘情况处理 |

---

第一部分：需求背景与目标（初稿）

这是 PRD 的灵魂。如果没有把这块写清楚，后面的所有内容都是空中楼阁。

1. 项目概述

用一句话概括产品是什么。注意好概述和差概述的差异：

好概述	差概述
一个给自己用的极简待办清单网页，只做添加和勾选	一个待办清单应用

好的概述直接设定了边界。"给自己用"= 不需要多用户；"极简"= 不需要复杂功能；"网页"= 纯前端技术栈。

2. 核心问题

回答三个问题：

• 目标用户：谁用？（具体到人，不是群体）
• 用户场景：什么时间、什么情境下用？
• 核心痛点：现有方案有什么问题？

3. 用户故事

用标准格式从用户视角描述需求：

作为一名 [具体角色]，我想要 [完成某项任务]，以便于 [实现某个价值]。

例如："作为一名每天要处理 10 件事的产品经理，我想要一个打开就能记的极简待办工具，以便于不遗漏重要事项，晚上能安心下班。"

4. 需求范围管理

这是最容易被跳过但最关键的部分——明确 In-Scope 和 Out-of-Scope：

In-Scope（要做）：添加任务、查看列表、勾选完成、删除任务

Out-of-Scope（不做）：登录注册、云同步、分类标签、日历视图、团队协作

不写 Out-of-Scope 的后果：AI 可能自动加上它认为"应该有"的功能——登录、云同步、分类标签……你在不断拒绝中浪费大量时间。

5. 需求优先级

将功能按 P0/P1/P2 分类：

需求ID	功能	优先级	说明
R001	添加任务	P0	核心功能，没有就不叫待办清单
R002	勾选完成	P0	核心功能
R003	删除任务	P0	核心功能
R004	分类标签	P1	V2 再考虑
R005	统计周报	P2	锦上添花

---

第二部分：方案概述（中稿）

用可视化方式展示产品全貌。

核心业务流程图

用 Mermaid 描述用户完成核心任务的流程：

graph TD
    A[用户打开网页] --> B{有历史数据?}
    B -- 是 --> C[显示任务列表]
    B -- 否 --> D[显示空状态]
    D --> E[输入任务 + 点击添加]
    C --> E
    E --> F[任务出现]
    F --> G[点击勾选]
    G --> H[任务显示删除线]
    F --> I[点击删除]
    I --> J[任务移除]

流程图让 AI 准确理解业务逻辑——比纯文字描述清楚得多。

信息架构

列出产品有哪些页面、它们怎么组织：

• 首页
  • 顶部输入区：输入框 + 添加按钮
  • 任务列表区：待完成（上方）+ 已完成（下方）
  • 底部操作栏：清空已完成

---

第三部分：细节方案（定稿）

最详尽的部分，是 AI 写代码的直接依据。

页面交互说明

用"状态-触发-反馈"的结构描述每个页面：

以"添加任务"为例：

1. 初始状态：输入框为空，placeholder 显示"输入新任务"
2. 触发操作：用户输入文字，点击"添加"按钮
3. 加载状态：按钮短暂禁用，显示"添加中..."
4. 成功状态：任务出现在列表顶部，输入框清空
5. 失败状态：如果是空内容提交，显示提示"请输入任务内容"

边缘情况处理

这是新手最容易漏掉的部分，但恰恰决定了产品的"完成度"：

边缘情况	处理方案
用户快速点击"添加"两次	0.5 秒防抖，防止重复提交
网络请求失败	显示 Toast："网络错误，请重试"
任务列表为空	显示空状态提示："暂无任务，添加一个吧"
用户输入超长内容	限制 200 字符，超出时截断

非功能性需求

不写会导致什么：

• 没写性能要求 → AI 可能生成很重的代码，加载很慢
• 没写浏览器兼容 → 可能只支持 Chrome
• 没写埋点需求 → 上线后无法追踪使用情况

---

第四部分：上线计划

不需要写得很复杂，但至少要有：

阶段	计划时间
需求评审	第 X 周
UI/UX 设计	第 X 周
研发	第 X 周
预计上线	第 X 周

---

好 PRD vs 坏 PRD

坏 PRD

# 待办清单
做一个待办清单功能，用户可以添加任务、勾选完成。

问题：没说用户是谁 → 可能做成团队版；没说核心功能 → 可能加一堆不需要的；没说 Out-of-Scope → 可能加登录和云同步；没说边缘情况 → 快速点击会重复提交；没有流程图 → AI 可能理解错业务逻辑。

好 PRD

包含了五部分结构、明确的用户画像、清晰的 In-Scope/Out-of-Scope、完整的边缘情况处理、核心业务流程图。AI 读了之后，不需要再问"这个按钮放哪"、"失败时怎么处理"这类问题。

---

让 AI 帮你生成 PRD

你不需要从零开始写。在与 AI 确认完需求之后，可以这样说：

"请基于我们的讨论，用 PRD 模板生成文档。如果某个字段我们没讨论过，请标注 TBD（待确定）。"

AI 生成后，你的职责是：

1. 检查：确认每个字段基于讨论，不是 AI 猜的
2. 补充：对于"待确定"的部分，补充细节或明确"不需要"
3. 纠正：发现与讨论不一致的地方，立即纠正

---

本课实践

1. 基于你在模块一中用灵魂三问分析的产品想法，写一份 PRD 初稿（第一部分即可）
2. 包含：项目概述、用户画像、用户故事、In-Scope/Out-of-Scope
3. 让 AI 用确认模板检查你的 PRD，看看有没有遗漏的信息
4. 根据 AI 的反馈完善你的 PRD

---

下一步

PRD 是需求和 AI 之间的桥梁。但文字有时不够直观——下一课我们将学习如何用可视化的方式表达需求，让你的 PRD 更加精准和清晰。