📚 课程目录第1章理解场景化PRD的核心理念

第1章理解场景化PRD的核心理念：场景定义、用户故事、需求条目与场景的关系

场景化PRD的核心逻辑是：需求从来不是凭空产生的，它诞生于特定的用户场景之中。脱离场景谈论功能，往往导致需求模糊、验收困难、交付物与用户预期错位。本章从三个基本概念——场景、用户故事、需求条目——出发，厘清它们之间的内在联系，为后续的场景化编写打下认知基础。

用户场景描述了谁在什么时间、什么地点，因为什么原因，想要完成什么任务，以及期望获得什么结果。它是需求最原始的“土壤”。

一个完整的用户场景包含六个核心要素：

避坑提示：很多PRD只写“用户点击按钮进入详情页”，却忽略了用户为什么要点这个按钮、在什么情境下点击。缺少情境的动作描述不是场景，而是操作步骤。

用户故事是场景到需求的中间桥梁。它用一句话浓缩角色、功能和价值，格式固定为：

案例对比如下（非正确 vs 正确）：

❌ 缺少场景的故事	✅ 带有场景感的故事
As a 用户, I want 搜索商品, So that 找到想买的东西。	As a 上班通勤族, I want 在早高峰用关键词快速搜索地铁沿线便利店商品, So that 到站前就能完成下单、下车直接取走。

第二个版本之所以好，是因为它隐含了时间（早高峰）、环境（地铁）、约束（到站前完成），这些信息直接决定了后续功能的优先级和设计取舍。

需求条目是可验证的功能描述。它把用户故事中的“I want”拆解为具体、可量化、可测试的陈述。一个合格的需求条目通常包含：

下面是一个PRD片段示例（表格形式）：

条目编号	功能概述	业务规则	验收标准
REQ-001	用户可在地铁线路图上点击站点查看该站周边便利店列表。	仅显示当前营业中的门店；列表按距离从近到远排序。	点击站点后3秒内返回门店列表；列表首店距离误差≤50米。
REQ-002	用户可设置“通勤模式”，系统自动识别早/晚高峰并推荐沿途门店。	通勤时段为07:00-09:00和18:00-20:00；支持手动编辑常驻路线。	开启通勤模式后，首页推荐栏切换为“沿途顺路”门店；切换延迟＜1秒。

常见误区：需求条目只写“系统支持商品搜索”，不写“搜索范围是全网还是门店库存”“搜索结果排序规则是什么”“无结果时如何提示”。验收标准一旦缺失，测试和开发就会按照各自理解执行，导致返工。

场景、故事、需求条目三者构成一个逐层收敛的漏斗：场景提供上下文，用户故事提炼角色与价值，需求条目落地为可执行的功能规格。同时，需求条目也可以反过来验证场景假设是否成立。

下面这张关系图展示了三层的核心要素以及它们之间的映射路径：

  核心记忆点：“场景给故事以温度，故事给需求以方向，需求给交付以标尺。” 编写PRD时，始终从场景出发，用故事描述价值，用条目锁定规格，三者缺一不可。

第1章 理解场景化PRD的核心理念：场景定义、用户故事、需求条目与场景的关系