第二章：需求定义与文档 | 第 7 课

第 7 课：PRD 编写实战

在 AI 时代，PRD 是你和 AI 之间的执行契约

课前思考

小李的困境

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

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

核心概念

什么是 AI 时代的 PRD

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

传统 PRD
阅读对象：开发团队、老板
核心目的：对齐团队认知
篇幅：几十页
格式：Word / PPT
更新频率：立项时写一次

AI 时代的 PRD
阅读对象：AI
核心目的：让 AI 准确理解意图
篇幅：20-50 行关键信息
格式：Markdown
更新频率：随对话持续迭代

文档结构

PRD 的五部分结构

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

第 0 部分 文档信息 · 始终维护
这是什么版本？谁在负责？

第一部分 需求背景与目标 · 初稿
为什么要做？为谁做？

第二部分 方案概述 · 中稿
业务流程是什么？功能怎么走？

第三部分 细节方案 · 定稿
每个页面具体怎么交互？边缘情况怎么处理？

第四部分 上线计划 · 定稿
什么时候做？分几期？

第 0 部分

文档信息

记录文档版本状态，让 AI 知道这是初稿还是定稿：

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

第一部分 · 初稿

需求背景与目标

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

1. 项目概述

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

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

差概述
一个待办清单应用

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

2. 核心问题

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

3. 用户故事

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

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

4. 需求范围管理

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

不写 Out-of-Scope 的后果：AI 可能自动加上它认为"应该有"的功能——你在不断拒绝中浪费大量时间。

5. 需求优先级

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

P0 添加任务、勾选完成、删除任务
核心功能，没有就不叫待办清单

P1 分类标签
V2 再考虑

P2 统计周报
锦上添花

第二部分 · 中稿

方案概述

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

核心业务流程图

用 Mermaid 描述用户完成核心任务的流程，让 AI 准确理解业务逻辑——比纯文字描述清楚得多：

用户打开网页
→ 有历史数据？是 → 显示任务列表 | 否 → 显示空状态 → 输入任务 + 点击添加 → 任务出现 → 点击勾选 → 任务显示删除线 | 点击删除 → 任务移除

信息架构

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

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

第三部分 · 定稿

细节方案

最详尽的部分，是 AI 写代码的直接依据。用"状态-触发-反馈"的结构描述每个页面。以"添加任务"为例：

1 初始状态：输入框为空，placeholder 显示"输入新任务"

2 触发操作：用户输入文字，点击"添加"按钮

3 加载状态：按钮短暂禁用，显示"添加中..."

4 成功状态：任务出现在列表顶部，输入框清空

5 失败状态：如果是空内容提交，显示提示"请输入任务内容"

边缘情况处理

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

用户快速点击"添加"两次
0.5 秒防抖，防止重复提交

网络请求失败
显示 Toast："网络错误，请重试"

任务列表为空
显示空状态提示："暂无任务，添加一个吧"

用户输入超长内容
限制 200 字符，超出时截断

非功能性需求

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

第四部分 · 定稿

上线计划

需求评审
第 X 周

UI/UX 设计
第 X 周

研发
第 X 周

预计上线
第 X 周

对照参考

好 PRD vs 坏 PRD

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

实操技巧

让 AI 帮你生成 PRD

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

AI 生成后，你的职责是：检查每个字段基于讨论而不是 AI 猜的、补充待确定部分的细节、纠正与讨论不一致的地方。

本课实践

本课实践

1 基于你在第一章中用灵魂三问分析的产品想法，写一份 PRD 初稿（第一部分即可）

2 包含：项目概述、用户画像、用户故事、In-Scope/Out-of-Scope

3 让 AI 用确认模板检查你的 PRD，看看有没有遗漏的信息

4 根据 AI 的反馈完善你的 PRD