1. PRD 与数据原型的关系：数据原型定义、PRD 核心要素、两者衔接点
1.1 数据原型定义
数据原型（Data Prototype）是在产品需求文档（PRD）落地过程中，将抽象的业务需求转化为可执行的数据结构雏形。它不是高保真 UI 原型，而是以字段、类型、关系、示例数据为核心的数据逻辑示意。
核心特征：
- 结构化：字段名称、数据类型、长度、主外键
- 逻辑性：业务规则在数据层面的映射（如枚举值、范围校验、关联约束）
- 可验证：能从原型中推导出验收指标（如字段覆盖率、数据完整性）
产品经理视角：数据原型是 PRD 与开发/测试之间的“翻译器”。当需求描述为“用户可设置工作台布局”时，数据原型需要明确 layout_config 字段为 JSON 对象，含 panelOrder、visibleModules 等子结构。
1.2 PRD 核心要素架构
一份可驱动数据原型的 PRD 必须包含以下五层要素：
| 层级 | 要素名 | 数据原型关联内容 |
|---|---|---|
| L1 | 用户场景 | 触发原型中数据录入/展示的条件 |
| L2 | 业务问题 | 数据模型需要解决的问题域（如库存超卖） |
| L3 | 用户访谈摘要 | 字段粒度的需求来源（如“需要记录取消原因”） |
| L4 | 需求拆解 & 规则 | 枚举值、必填条件、业务计算公式 |
| L5 | 验收标准 | 原型中字段的量化阈值（如“取消原因字段需覆盖 95% 场景”） |
1.3 PRD 与数据原型的衔接点
衔接点出现在需求拆解后的“字段定义”阶段。此时产品经理需将文本性需求转译为数据字段清单，典型映射如下表：
| PRD 原文示例 | 数据原型字段 | 类型/约束 | 验证方式 |
|---|---|---|---|
| “用户可一键退货” | return_flag | Boolean (default 0) | 边界测试：True/False |
| “订单金额超过 5000 需主管审批” | approval_status | Enum [pending, approved, rejected] | 用例检查：金额＞5000 时字段变化 |
| “按区域查看库存” | region_id | FK → region_dim | 关联完整性测试 |
常见断点：PRD 中出现“用户可自定义通知时间”等模糊表述，未定义时间格式（UTC vs 本地）、重复规则（每周/单次）、最大数量限制。这样的需求无法直接落地数据原型，必须通过结构化追问补全。
1.4 衔接流程（内联 SVG）
1.5 从 PRD 到数据原型的步骤清单
- 提取字段源泉：遍历 PRD 中的用户故事、业务规则、异常处理，列出所有可能的数据项
- 分层归类：按实体（订单、用户、商品）将散落字段分组，标注主外键关系
- 添加元数据：为每个字段填入数据类型、长度、默认值、枚举范围、必填性
- 设计示例数据：针对核心规则构造 boundary case（如金额为 0、多语言字符串、并发时间戳）
- 映射验收标准：将 PRD 中的验收条件拆解为数据层面的检查点（如“字段 X 在条件 Y 下为 null”）
1.6 交付物模板
每章节结束时都会产出以下模板的一部分，本章对应“字段定义矩阵”：
| 字段名 | 类型 | 来源（PRD 章节） | 业务规则 | 验收检查点 |
|---|---|---|---|---|
| order_status | ENUM | 2.3 订单生命周期 | 初始 pending，支付后 paid，发货后 shipped | 状态流转不允许跳过阶段 |
| shipping_cost | DECIMAL(10,2) | 2.4 费用计算 | 满 99 免运费，否则收 8 元 | 金额＞=99 时字段应为 0.00 |
| remark | VARCHAR(500) | 3.1 用户备注 | 支持 emoji，最长 500 字符 | 插入 501 字符应截断或报错 |