项目课 —— 写一份完整的 PRD

本课导读

8 个部分全部学完，本课把它们装配成一份真实可用的 PRD。最顺的路径是接着第一单元项目课的成果走：那份五层设计文档已经想清了"为什么、做什么、怎么组织"，本课把它升级成能直接交给执行的正式文档——如果你没做过那个项目，也可以直接从工作里挑一个新需求，从头走一遍。写完后有一道冷读测试等着你的文档。预计 50 分钟起。

开工前：定文档的"格"

三个开工决定，一分钟做完：

• 粒度：本课写功能级 PRD（一个功能或一次迭代），不是产品级大部头——8 部分俱全，总篇幅控制在 2-4 页。记住第 1 课的话：敌人是歧义不是篇幅
• 格式:就用你日常的笔记工具（LearnPath 笔记栏、或团队的文档平台）。文档头部留三行：版本号、日期、变更记录——活文档的最低配置
• 选题：优先选你有权推动、且两个月内可能真做的需求。写一份注定进抽屉的 PRD，练习价值减半——文档的终极测试是真的有人拿它开工

装配线：8 步写完

分步操作

1. 产品概述：三句话 + 冷读自测

   现状（可引数据）→ 方案（行为不是实现）→ 挂钩（点名它推进的产品级目标）。写完念给一个不了解背景的人听，问"我们为什么做这个"——答错就重写。

2. 用户角色：主角色 + 次角色 + 系统角色

   每个角色写与本功能的关系：使用频率、情境、目的、熟练度。特别检查系统角色——这一行漏了，第 6 步的依赖必漏。

3. 问题场景：至少一个带将就方案的三段式

   情境 → 卡点（用户现在怎么将就的，写实）→ 期望（结果不是功能）。如果发现找不到将就方案，停下来重新评估这个需求——这本身就是重大发现。

4. 功能需求：story 帽子 + FR 条目

   每条 FR：编号、MoSCoW 标注、正面/具体/客观、可检验。Won't 栏必须非空。写完逐条自问：测试能对着它直接写用例吗？

5. 工作流与边界：主流程 + 六问过筛

   主流程用编号步骤写清；然后空了呢/爆了呢/断了呢/重了呢/没权呢/悔了呢逐一过筛，每个边界写"触发条件 + 系统行为"，处理方案用三级预案裁决（预防 > 撤销 > 说人话）。

6. 依赖：从系统角色开始排查

   系统/时序/团队三类，每条标"依赖什么 + 影响哪些 FR + 不就位的后果"。想不出依赖时，把系统角色清单再读一遍——功能很少真是孤岛。

7. 验收标准:每条 Must 需求至少一条 GWT

   Given-When-Then，挂在 FR 编号下；重要边界情况各配一条；每个 Then 做"是/否一眼定"检查，杀掉所有"合理""正常""友好"。

8. 成功指标：四件套 + 反指标 + 预约复盘

   指标/基线/目标/时间窗写全（基线现在就去取数或标注埋点需求）；写一个 guardrail；最后一行写"上线后第 X 周对照本节出一页复盘"。回翻第 1 步的挂钩句，确认指标量的正是概述承诺的价值。

终检：冷读测试 + 交叉一致性

写完不算完，过两道检：

第一道 · 冷读测试：把文档发给一个没参与讨论的人（同事最好；没有就隔一天自己冷读），请他标出所有"读到这里我有疑问"的地方。每个疑问都是文档的洞——洞在哪个部分，就回哪课补。工程师问"这个字段能空吗"是第 4-5 部分的洞；问"为什么做这个"是第 1-3 部分的洞。

第二道 · 交叉一致性（PRD 版的垂直终检）：

• 每条 FR 都能回指到某个问题场景吗？（回指不了的，是谁塞进来的私货？）
• 每条 Must 都有验收标准吗？每个重要边界都有 AC 吗？
• 依赖清单和系统角色对得上吗？
• 成功指标量的是概述承诺的价值吗？反指标护住试点核心指标了吗？

交付物清单

• 一份 8 部分俱全的功能级 PRD（2-4 页，带版本头）
• 一份冷读测试的疑问清单及修补记录
• 存进笔记。如果这个需求后来真的开工了：上线后把预约的复盘写完——那一页纸会教你比整个单元更多的东西

📝 随堂测验

随堂测验0 / 4 题正确

1. 功能级 PRD 的合理篇幅与理由是？

A越长越显得专业B8 部分俱全、2-4 页——PRD 的敌人是歧义和缺漏，不是短；一页说清胜过三十页正确的废话C必须一页纸，多了就是失败D没有标准，随意发挥

2. 冷读测试中，读者的每个疑问意味着？

A读者水平不行B文档的一个洞——疑问落在哪个部分，就回哪一课的方法补哪里C需要开会当面解释D正常现象，不用处理

3. 交叉一致性检查里“每条 FR 都能回指到某个问题场景”防的是什么？

A文档格式错误B私货需求——回指不了场景的功能，往往是没有证据支撑的“我觉得该有”，正是范围蔓延的入口C工程师偷懒D场景写得太多

4. 评审会后对 PRD 的正确动作是？

A会都开完了，文档使命结束B当场把补充的边界、砍掉的条目、变化的依赖更新进文档并记录变更——与现实脱节的 PRD 是带权威性的误导C另写一份会议纪要，PRD 保持原样D口头同步即可

本课小结 · 单元结课

• 完整 PRD 装配线：概述 → 角色 → 场景 → 需求 → 工作流边界 → 依赖 → 验收 → 指标，每步都有前四课给的格式和自查
• 两道终检：冷读测试（每个疑问是一个洞）+ 交叉一致性（FR 回指场景、Must 配 AC、依赖对角色、指标对承诺）
• PRD 是活文档：评审后当场更新，上线后写完预约的复盘

两个单元到此连成一条完整的链：五层模型教你按正确顺序把产品想清楚，PRD 教你把想清楚的东西写成别人能开工的文档。下次工作里接到一个模糊的需求，你知道该做的两件事了：先问"我们在聊哪一层"，再说"我来写个 PRD"——前者让讨论回到正轨，后者让你成为那个推动事情发生的人。