第3章 PRD与数据原型的映射关系
3.1 映射断层：需求传递中的典型困境
在产品需求传递过程中，产品经理、开发工程师和测试人员常面临一个核心困境：PRD 中的文字需求如何准确、无歧义地转化为可运行的原型系统？这正是需求映射要解决的根本问题。
用户场景：某电商平台产品经理完成 PRD 后，开发团队根据理解搭建了原型。评审时发现：
- “订单状态流转”在原型中缺少“已取消→退款中”的中间态
- “用户手机号”字段在三个页面中分别命名为
phone、mobile、tel - “满减优惠”规则中有两条约束条件未被原型覆盖
根源在于需求条目→原型元素之间缺少结构化的映射机制。
业务问题：需求与原型之间的断层通常表现为三类问题：
- 需求条目不可追踪——PRD 中的每一条需求在原型中找不到对应元素
- 数据字段定义不一致——同一业务字段在不同页面出现命名、类型、格式的差异
- 业务规则表达遗漏——约束条件、状态流转、校验逻辑在原型中被简化或忽略
用户访谈：通过访谈 5 个已完成交付的项目团队发现，超过 70% 的需求缺陷源于映射阶段的信息丢失或变形。开发人员反映“PRD 写得很清楚，但原型里不知道该怎么放”；产品经理则困惑“原型做出来总和我想要的不一样”。
3.2 需求拆解：映射的起点
在建立映射之前，必须对 PRD 中的需求条目进行原子化拆解。每条需求应拆解为三类可映射要素：
| 需求要素类型 | 定义 | 拆解示例（订单系统） |
|---|---|---|
| 功能要素 | 用户可执行的操作或系统提供的功能 | “用户可查看订单详情” → 查看按钮、详情页、返回操作 |
| 数据要素 | 系统需采集、存储或展示的业务字段 | “订单包含收货地址” → 省份、城市、街道、邮编、收件人 |
| 规则要素 | 约束业务流程或数据行为的逻辑条件 | “已支付订单不可修改地址” → 状态判断 + 禁用编辑 |
拆解原则：一条 PRD 需求条目在拆解后，至少包含 1 个功能要素 + 1 个数据要素 + 0~N 个规则要素。若某个要素缺失，说明需求粒度不够细或存在隐含假设。
3.3 三种映射关系的表达方式
3.3.1 需求条目→原型元素
将拆解后的功能要素映射到原型中的 UI 组件与交互流程。每个功能要素至少对应一个可操作的原型元素。
- 映射原则：一对一映射（一个需求对应一个原型组件）或一对多映射（一个需求涉及多个页面状态）
- 表达工具：在 PRD 中使用“需求-组件对照表”或在原型元素上直接标注需求编号
- 常见错误：将多个需求合并到一个组件中，导致后续测试无法定位
3.3.2 数据字段映射
将拆解后的数据要素映射到原型中的字段名称、数据类型、格式约束与状态容器。每个业务字段在原型中必须有唯一的标识和一致的定义。
// 数据字段映射配置示例（JSON）
{
"mapping_id": "MAP-202",
"prd_requirement": "R-103：用户注册需填写手机号",
"field_mappings": [
{
"prd_field": "用户手机号",
"prototype_field": "phoneNumber",
"data_type": "string",
"format": "/^1[3-9]\\d{9}$/",
"max_length": 11,
"is_required": true,
"pages": ["注册页", "修改资料页", "安全中心"]
},
{
"prd_field": "手机验证码",
"prototype_field": "smsCode",
"data_type": "string",
"format": "/^\\d{6}$/",
"max_length": 6,
"is_required": true,
"pages": ["注册页", "找回密码页"]
}
]
}常见陷阱：同一业务字段在不同页面使用不同名称（如 userPhone vs phone），或在原型中遗漏了某个业务场景下该字段的展示形态。建议在 PRD 中维护一份全局字段字典作为映射基准。
3.3.3 规则嵌入方式
将拆解后的规则要素嵌入到原型的交互逻辑、校验机制与状态流转中。规则嵌入有三种典型方式：
| 嵌入方式 | 适用场景 | 原型表达形式 | 验证方法 |
|---|---|---|---|
| 前端即时校验 | 格式检查、必填项、字段关联 | 输入框失去焦点时触发提示 | 输入非法数据观察反馈 |
| 状态条件流转 | 业务状态机、审批流程、订单变更 | 页面跳转 + 按钮显隐 + 字段读写状态 | 遍历状态转换路径 |
| 后端约束模拟 | 数据唯一性、库存校验、权限控制 | Mock 接口返回错误码 + 前端错误提示 | 模拟边界条件观察行为 |
3.4 映射关系的结构化表达
三种映射关系并非独立运行，而是协同构成从 PRD 到数据原型的完整桥梁。下图展示了需求条目经过拆解后，通过三条并行映射通道汇聚到数据原型的整体流程：
图中展示了从 PRD 需求条目出发，经过需求拆解与分类后，沿着三条并行通道（原型元素映射、数据字段映射、规则嵌入方式）最终汇聚到数据原型验证的完整映射链路。三条通道缺一不可，任何一条的缺失都会导致需求与原型之间的信息断层。
3.5 指标验证与验收标准
建立映射关系后，需通过量化指标验证映射质量：
| 验证维度 | 指标名称 | 计算方式 | 验收标准 |
|---|---|---|---|
| 需求可追溯性 | 需求-元素映射覆盖率 | 已映射需求条目数 ÷ 总需求条目数 × 100% | ≥ 98% |
| 字段一致性 | 字段定义冲突率 | 存在命名/类型冲突的字段数 ÷ 总字段数 × 100% | 0% |
| 规则完整性 | 规则嵌入覆盖率 | 已嵌入原型的规则数 ÷ PRD 中规则总数 × 100% | ≥ 95% |
验收实操建议：在数据原型评审会上，逐条对照 PRD 需求与原型元素，使用“需求-映射-原型”三栏对照表进行走查。每次发现未映射或映射错误的需求，计入映射缺陷清单并标记优先级，在下一轮原型迭代中闭环。
3.6 交付物模板：需求映射矩阵
将三种映射关系整合为一份可交付的需求映射矩阵，作为 PRD 的附件与原型验收的依据：
| 需求编号 | 需求描述 | 要素类型 | 原型元素 | 数据字段 | 规则表达 | 状态 |
|---|---|---|---|---|---|---|
| R-101 | 用户可搜索商品 | 功能 | 搜索输入框 + 搜索结果列表 | — | — | 已映射 |
| R-102 | 搜索支持模糊匹配 | 规则 | 搜索输入框 + 加载状态 | — | 输入后 300ms 触发模糊查询 | 已映射 |
| R-103 | 商品展示价格与库存 | 数据 | 商品卡片组件 | price (decimal), stock (int) |
库存为 0 时显示“无货”标签 | 已映射 |
| R-104 | 加入购物车需登录 | 规则 | 加入购物车按钮 | — | 未登录状态弹出登录弹窗 | 已映射 |
矩阵使用流程：
- PRD 定稿后，产品经理逐条填写“需求编号”“需求描述”“要素类型”三列
- 开发团队在原型搭建过程中同步填写“原型元素”“数据字段”“规则表达”三列
- 测试团队根据“状态”列筛选未映射或映射错误的需求，作为测试用例补充来源
- 每一轮原型迭代后更新矩阵状态，直至全部需求标记为“已映射”
映射矩阵维护红线：禁止在原型开发过程中直接修改矩阵而不同步更新 PRD；禁止在未更新矩阵的情况下口头传递映射变更。矩阵必须作为 PRD 的一部分纳入版本管理，其变更历史可作为需求回溯的审计线索。
通过需求条目→原型元素、数据字段映射、规则嵌入方式三条映射通道的结构化协作，PRD 中的文字需求能够完整、一致、可验证地转化为数据原型的每一个组件、字段与交互行为，从根本上消除需求传递过程中的信息衰减。