📚 课程目录第1章 PRD的核心结构拆解

数据产品PRD与原型验证闭环 - 第1节

PRD 核心结构拆解：用户故事、验收条件、数据约束、业务规则、优先级标注

一份可用于数据原型验证的 PRD，其结构并非简单的功能罗列。它必须是一个“可执行的需求执行体”——每一行描述都能被直接转化为原型中的交互、数据字段或判断逻辑。本章将拆解 PRD 的五个核心构件，它们共同构成了数据原型的骨架与验证标尺。

在数据原型语境下，PRD 的五要素不再是静态文档，而是原型开发的指令集与测试用例集。它们之间的映射关系如下表所示：

用户故事提供了“谁、想做什么、为什么” 的完整场景。在数据原型中，用户故事直接转化为一条“测试剧本”。

讲师提示：在原型阶段，用户故事应优先聚焦“happy path”（快乐路径），异常路径留至后续迭代验证。避免因过早处理边缘情况而拖慢验证节奏。

验收条件将模糊的“做完了”转换为可执行的二进制判定（通过/不通过）。它们是原型演示时的评审清单。

有效的验收条件应包含：

示例对比：

❌ 弱验收条件：“用户能正常添加商品。”

✅ 强验收条件：“点击‘加入购物车’后，购物车图标右上角数字 +1，‘加入购物车’按钮文字变为‘已添加’，且按钮置灰不可再次点击。”

这是 PRD 中最容易被原型设计师忽略的部分。没有准确的数据约束和业务规则，原型只是一堆“好看的静态图”。

# 业务规则示例（自动化营销引擎）
规则：若用户标签包含“高活跃”且“最近30天未登录”，则触发弹窗“回归好礼已准备”。
涉及字段：user.tags（数组字符串）、user.last_login（datetime）
约束：弹窗每天每个 user 仅触发 1 次。

原型资源有限，必须用优先级来引导验证重点。推荐使用 P0（核心主路径） / P1（重要副路径） / P2（增强体验） / P3（未来优化） 四级分类。

在原型验证阶段，P0 的需求必须 100% 可演示，P1 可允许部分降级（如仅展示静态数据），P2/P3 仅作为信息架构参考，不投入交互开发。

下图展示了五个要素如何构成一个完整的 PRD 结构。从用户故事出发，经数据约束与业务规则定义，最终通过验收条件锁定验证标准，并由优先级标注控制版本范围。

假设我们要为某电商平台设计一个“流失用户召回”的营销引擎原型。以下是一个浓缩的 PRD 片段，展示五个要素如何协同工作：

要素	内容	原型验证点
用户故事	作为运营经理，我希望创建一条“高价值沉默用户”的召回策略，以便在 48 小时内触达他们，提升复购率。	原型中是否存在“策略创建”入口，并允许选择“高价值”与“最近X天未登录”标签。
数据约束	“高价值” = 近 90 天消费金额 > 5000 元；沉默 = 最近 7 天无登录。user_id 必填且唯一。	输入条件选择器是否准确反映了这些数值范围；是否对 user_id 做了去重校验。
业务规则	若用户同时满足“高价值”且“沉默”，则在创建策略后 48 小时内发送弹窗与短信。同一用户 30 天内只触发一次。	原型中是否展示了触发记录的“唯一性标记”；是否在弹出弹窗时限制了“上次触发日期”字段。
验收条件	1. 创建成功后，策略列表出现新条目，状态显示“待执行”。2. 在模拟沙盒中输入满足条件的用户 ID，预览弹窗内容。3. 触发后该用户 ID 被加入“已触发列表”，且“最近触发时间”刷新为当前时间。	以上三条均可通过原型截图或点击流一一验证。
优先级	P0：策略创建页面与列表展示；P1：模拟触发与预览；P2：历史触发报表；P3：A/B 测试版本对比。	P0 必须可交互，P1 允许降级为静态 mock，P2/P3 仅在原型中体现入口位置。

常见误区：很多 PRD 在“业务规则”段落只写了“根据规则触发”，却没有明确写出规则的具体判断条件。在原型验证中，这种模糊描述会导致开发者无法判断原型行为是否符合预期。规则必须可计算、可测试。