AI时代的产品需求文档新写法
第二章：需求定义与文档 | 第 7 课
AI 时代，PRD 成为人与机器的协作协议
课前思考
小张已经想清楚了：他的简约待办清单目标用户是像自己一样的上班族，核心是“新增+标记+移除”，不做分类和云同步。他打开 AI 工具，输入：“帮我做一个待办清单应用。”
AI 做了一个带登录注册、日历视图、团队协作的复杂系统。小张花了两个小时调试，最后放弃了。
问题在哪？不是想法不清楚，而是没有用结构化的方式告诉 AI 你要什么。在 AI 时代，PRD 不再是“给开发团队看的参考文档”，而是你和 AI 之间的协作协议。
核心概念
传统 PRD 通常是几十页的正式文档，包含市场分析、竞品对比、技术架构。它的读者是开发团队和老板。AI 时代的 PRD 完全不同：
传统 PRD 阅读对象：开发团队、老板 核心目的：对齐团队认知 篇幅：几十页 格式：Word / PPT 更新频率：立项时写一次
AI 时代的 PRD 阅读对象：AI 核心目的：让 AI 准确理解意图 篇幅：20-50 行关键信息 格式：Markdown 更新频率：随对话持续迭代
AI 时代 PRD 不是给人看的“报告”，而是给 AI 的“任务书”。规范是新的源代码。一个足够清晰的 PRD 可以生成代码、文档、测试、教程——它比你生成的代码更值得被精心维护和版本管理。——Sean Grove, OpenAI
文档结构
一份好的 PRD 分为五个核心部分，对应“初稿 → 中稿 → 定稿”的迭代节奏：
第 0 部分文档信息·始终维护 这是什么版本？谁在负责？
第一部分需求背景与目标·初稿 为什么要做？为谁做？
第二部分方案概述·中稿 业务流程是什么？功能怎么走？
第三部分细节方案·定稿 每个页面具体怎么交互？边缘情况怎么处理？
第四部分上线计划·定稿 什么时候做？分几期？
迭代原则：初稿想清楚“为什么”，中稿想清楚“是什么”，定稿想清楚“怎么做”。每一步都有检查点，避免到最后才发现方向错了。
第 0 部分
记录文档版本状态，让 AI 知道这是初稿还是定稿：
当前版本：内部评审版-修订二 当前阶段：需求评审中 核心干系人：产品-小张、研发-待定 更新记录：初稿（阐述需求背景和核心价值）→ 修订一（补充业务流程和功能流程图）→ 修订二（补充边缘情况处理）
第一部分 · 初稿
这是 PRD 的灵魂。如果没有把这块写清楚，后面的所有内容都是空中楼阁。
1. 项目概述
用一句话概括产品是什么。注意好概述和差概述的差异：
好概述 一个给自己用的极简待办清单网页，只做添加和勾选
差概述 一个待办清单应用
好的概述直接设定了边界。“给自己用”= 不需要多用户；“极简”= 不需要复杂功能；“网页”= 纯前端技术栈。
2. 核心问题
回答三个问题：目标用户是谁（具体到人，不是群体）、用户场景是什么时间什么情境下用、核心痛点是现有方案有什么问题。
3. 用户故事
用标准格式从用户视角描述需求：
作为一名具体角色，我想要完成某项任务，以便于实现某个价值。
例如：“作为一名每天要处理 10 件事的产品经理，我想要一个打开就能记的极简待办工具，以便于不遗漏重要事项，晚上能安心下班。”
4. 需求范围管理
这是最容易被跳过但最关键的部分——明确 In-Scope 和 Out-of-Scope：
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
“做一个待办清单功能，用户可以添加任务、勾选完成。”
问题：没说用户是谁 → 可能做成团队版；没说核心功能 → 可能加一堆不需要的；没说 Out-of-Scope → 可能加登录和云同步；没说边缘情况 → 快速点击会重复提交；没有流程图 → AI 可能理解错业务逻辑。
✓ 好 PRD
包含了五部分结构、明确的用户画像、清晰的 In-Scope/Out-of-Scope、完整的边缘情况处理、核心业务流程图。AI 读了之后，不需要再问“这个按钮放哪”、“失败时怎么处理”这类问题。
实操技巧
你不需要从零开始写。在与 AI 确认完需求之后，可以这样说：
“请基于我们的讨论，用 PRD 模板生成文档。如果某个字段我们没讨论过，请标注 TBD（待确定）。”
AI 生成后，你的职责是：检查每个字段基于讨论而不是 AI 猜的、补充待确定部分的细节、纠正与讨论不一致的地方。
本课实践
1基于你在第一章中用灵魂三问分析的产品想法，写一份 PRD 初稿（第一部分即可）
2包含：项目概述、用户画像、用户故事、In-Scope/Out-of-Scope
3让 AI 用确认模板检查你的 PRD，看看有没有遗漏的信息
4根据 AI 的反馈完善你的 PRD
下一步：需求的可视化表达
PRD 是需求和 AI 之间的桥梁。但文字有时不够直观——下一课我们将学习如何用可视化的方式表达需求，让你的 PRD 更加精准和清晰。
写得越清楚，输出越精准。
产品思维入门课