阅读完本节后，你将会收获：
- 理解 PRD 的五部分结构及其作用
- 掌握"初稿-中稿-定稿"迭代原则
- 学会用 Markdown 和 Mermaid 编写 AI 友好的 PRD
- 掌握边缘情况处理和范围管理的方法
序言中提到的：PRD 是 AI 的执行规范，也是问题定义能力的体现。
PRD 分为五个核心部分，对应"初稿-中稿-定稿"的迭代原则：
| 部分 | 对应阶段 | 核心内容 |
|---|---|---|
| 第0部分：文档信息 | 始终记录 | 版本、阶段、更新记录 |
| 第一部分：需求背景与目标 | 初稿 | 为什么要做、为谁做、解决什么问题 |
| 第二部分：方案概述 | 中稿 | 业务流程、功能流程、信息架构 |
| 第三部分：细节方案 | 定稿 | 交互说明、边缘情况、非功能需求 |
| 第四部分：上线计划 | 定稿 | 排期、灰度发布 |
迭代原则：初稿想清楚"为什么"，中稿想清楚"是什么"，定稿想清楚"怎么做"。每一步都有评审和修改，避免到最后才发现大问题。
这个迭代节奏有其心理学基础。人在面对复杂问题时，往往会陷入"分析瘫痪"——想要一次性想清楚所有细节，结果反而寸步难行。分阶段迭代让你在每个阶段只关注特定的维度。初稿时，你不需要担心技术实现，只需要确认方向正确；中稿时，你不需要纠结按钮的颜色，只需要确认流程合理。这种分层的思考方式，让复杂问题的处理变得可管理。
另一个容易被忽视的好处是，每个版本都是一个"可回退的检查点"。如果在中稿时发现方向有问题，你可以回到初稿重新审视；如果在定稿时发现技术方案不可行，你可以回到中稿调整流程。这种结构化的迭代，让错误可以在早期被发现和纠正，而不是累积到最后爆发。
这是 PRD 的灵魂，对应初稿阶段的核心内容。
用一两句话概括产品是什么。
| 好的概述 | 差的概述 |
|---|---|
| 一个给自己用的极简待办清单网页 | 一个待办清单应用 |
模糊的概述会导致 AI 做出复杂版本。具体的概述能快速设定边界。
概述的撰写是一门压缩的艺术。你需要在极短的篇幅内，传达产品的本质特征。"一个给自己用的极简待办清单网页"这句话包含了多个关键信息："给自己用"说明是个人工具而非团队协作工具；"极简"说明功能有限、界面简洁；"网页"说明技术形态。这些信息共同构成了一个清晰的边界，让 AI 知道什么该做、什么不该做。
回答三个问题：
| 漏写 | 后果 |
|---|---|
| 没说用户是谁 | 可能做成"所有人都能用"的复杂版 |
| 没说场景 | 可能用不适合的技术（手机端做成桌面版） |
| 没说痛点 | 可能做了"完美"功能，但解决的是伪需求 |
从用户视角描述需求：
作为一名 [角色]，我想要 [完成某项任务]，以便于 [实现某个价值]
这比"我要做一个功能"更贴近用户。用户故事格式强制从用户角度思考，而非从功能角度思考。
用户故事的价值在于它建立了一个"共情框架"。当你写下"作为一名销售经理，我想要快速生成周报，以便于节省周五下午的时间"时，你被迫想象一个具体的人，在具体的场景中，面对具体的困扰。这种想象让你脱离技术实现的角度，从用户的真实处境出发去思考解决方案。很多时候，我们以为用户需要的是某个功能，但实际上他们需要的是功能背后的价值。用户故事帮助你发现这种真正的需求。
明确"做哪些"和"不做哪些"。
In-Scope（范围内）：明确要做的功能点
Out-of-Scope（范围外）：明确不做哪些
范围管理应该在 3.2 与 AI 确认需求 时完成。这里只是把讨论结果记录下来。
| 不写 Out-of-Scope | 写了 Out-of-Scope |
|---|---|
| AI 可能自动加上"常见功能" | AI 明确知道边界 |
| 范围不断蔓延 | 保持产品聚焦 |
将宏观需求拆解为具体需求点，并标注优先级：
| 需求ID | 模块 | 描述 | 优先级 | 状态 |
|---|---|---|---|---|
| R001 | 添加任务 | 用户可以添加待办任务 | 高 | 规划中 |
| R002 | 删除任务 | 用户可以删除任务 | 高 | 规划中 |
| R003 | 历史记录 | 查看历史任务 | 低 | V2.0考虑 |
优先级让 AI 知道哪些是核心（P0）、哪些可以延后。
对应定稿阶段，是最详尽的部分，是 AI 写代码的直接依据。
描述每个页面的完整交互流程：
| 只写"用户可以添加任务" | 写完整交互逻辑 |
|---|---|
| AI 不知道加在哪、怎么显示 | AI 知道输入框位置、按钮样式、列表如何更新 |
这是新手最容易漏掉的部分。
边缘情况的遗漏往往不是因为粗心，而是因为"正常路径偏差"。当我们想象用户使用产品的场景时，大脑会自动填充最理想的流程：用户打开应用，完成操作，满意离开。但真实的用户体验充满了意外——网络波动、手滑误触、突然来电。这些异常情况不是"例外"，而是用户体验的常态组成部分。一个只处理正常情况的系统，在真实环境中会表现得非常脆弱。
| 边缘情况 | 不写会怎样 |
|---|---|
| 用户快速点击按钮两次 | 可能重复提交 |
| 网络出错时 | 用户不知道发生了什么 |
| 数据为空时 | 可能显示空白或报错 |
| 用户中途退出 | 可能数据丢失 |
常见的边缘情况处理：
| 需求类型 | 为什么重要 |
|---|---|
| 性能 | 不写 → AI 可能做很重，加载很慢 |
| 兼容性 | 不写 → 可能只支持 Chrome，Safari 用户无法使用 |
| 数据埋点 | 不写 → 上线后无法追踪使用情况 |
PRD 应该使用 Markdown 编写，并用 Mermaid 绘制流程图。
Markdown 的优势：
Mermaid 的优势：
告诉 AI "用 Mermaid 画个流程图"即可，不需要记忆语法。
# 待办清单
做一个待办清单功能，用户可以添加任务、勾选完成。问题：
# 极简待办清单
## 1.1 项目概述
一个给自己用的极简待办清单网页，只有添加和勾选功能。
## 1.2 核心问题
- **目标用户**：我自己（职场人士，每天处理 5-10 个任务）
- **用户场景**：早上打开电脑，快速看今天要做什么
- **核心痛点**：便签纸容易丢，手机备忘录打开麻烦
## 1.5 需求范围
**In-Scope**: 添加任务、查看列表、勾选完成、删除任务
**Out-of-Scope**: 登录注册、云同步、分类标签
## 2.1 核心业务流程
[Mermaid 流程图]
## 3.1 边缘情况处理
- 快速点击"添加" → 0.5秒防抖
- 列表为空 → 显示"暂无任务"
- 刷新页面 → 数据不丢失（localStorage）PRD 写好后，接下来理解 AI 如何执行它。