PRD数据字典怎么写？字段、取值与校验规则

更新时间： 2026年10月15日

PRD数据字典是产品团队对字段含义和使用规则的共同约定。它不仅解释“这个输入框叫什么”，还应说明数据来自哪里、允许什么值、什么时候必填、谁能修改、无效时如何反馈。写字典的目的，是让同一个字段在页面、接口和测试中表示同一件事，而不是把数据库字段重新抄一遍。

以订单基本资料为例，可以先用墨刀原型搭建订单表单与查看页面，再逐项补齐订单编号、联系人和联系电话的规则。可见页面帮助团队发现遗漏，数据字典则让页面背后的业务口径可以被讨论和复核。

哪些内容放进PRD，哪些交给接口和数据库设计

PRD应明确用户和业务关心的规则：联系人是不是下单人、一个订单能否有多个联系人、电话是否可以修改，以及保存后的改动会影响哪些通知。接口文档再表达参数名称、请求格式与错误返回；数据库设计解决存储类型、索引和关系。三份资料应能对应，但不必完全相同。

例如“订单金额”在界面显示为元，接口可能用分传输，数据库可能采用另一种明确的存储方案。PRD至少要写明业务币种、显示精度、四舍五入与计算口径，不能因为看见界面有两位小数，就擅自认定后台传输的单位。

字段英文名可作为关联标识，尚未与研发确定时先标记待确认，不为填满表格临时编一个名字。在业务名称稳定的前提下，可以用F-01这类字段编号关联页面与讨论记录。

并非每个字段都需要长篇说明。固定展示的系统编号可以很短；会影响金额、权限、审批或通知的字段则值得写细。用业务风险决定说明深度，比给所有字段套相同长度更容易维护。

本例约定编号由系统在正式创建订单后生成，唯一标识订单，用户不能修改；草稿阶段显示“提交后生成”，不展示看似正式的占位编号。列表、详情和导出使用同一编号。若还存在内部流水号，需分清哪个编号用于客服查询，不能把两者混写成“ID”。

原型中可以填入明确的样例编号，字段说明记录“展示样例，实际由系统生成”。这是解释业务数据来源，不要求团队在原型里实现编号算法。

本例从所选收货地址带入联系人，允许用户在当前订单内修改。保存订单不反向覆盖地址簿；如要同步更新地址，应提供独立选项并解释影响。否则一次临时收货人变更，可能悄悄改掉用户下次下单的默认信息。

校验可约定去除首尾空格，但不能随意删除姓名中间空格或标点。若系统确有限制，应由服务场景和后端能力共同确定，并在界面中给出相应提示。“真实姓名”不等于“只允许二至四个汉字”。

电话号码应作为文本处理，保留国家或地区代码、前导零以及业务允许的分机信息。格式校验只说明输入符合约定，不能保证号码有效或属于当前用户。需要验证持有关系时，应另设计验证流程，不能把一个正则表达式写成“验证手机号真实性”。

本例若只服务中国大陆移动电话号码，可以明确当前支持范围；若服务范围包含座机或海外号码，应分别定义输入方式，而不是让用户反复尝试一个不支持其号码的框。客服展示是否脱敏、谁能查看完整号码，也应和使用权限一起说明。

枚举不能只写“状态：待处理、处理中、完成”。还应说明每个状态的进入条件、展示名称，以及哪些操作使它改变。若接口用数字编码，业务名称与编码的对应关系由双方确认后记录，不能让数字顺序决定业务含义。

空值也需要区别：用户尚未填写、当前不适用、读取失败、没有权限查看，可能都显示成横线，但系统含义完全不同。对用户可以简化呈现，对规则不能合并。否则导出或统计时，团队会把未知值当成零，把无权查看当成确实没有。

对于计算字段，应给出业务公式和至少一组可核对的输入输出。例如本例的“应付金额”若由商品金额、优惠与运费构成，需要说明优惠叠加顺序和计价精度；不要把每一步各自四舍五入与最后统一处理混为一谈。具体方案应由业务与研发确认，字典负责把约定写清。

例如联系人规则从“所有订单可修改”变为“仅发货前可修改”，变化不只在详情页：编辑按钮、提交校验、客服入口、历史记录与测试用例都可能受影响。可结合PRD与原型的需求追踪方法，让一条规则能找到对应的页面和验收依据。

给评审者几个容易产生分歧的输入：联系人前后带空格、联系电话以零开头、草稿缺少电话、发货后修改联系人、无权限查看完整号码。请产品、设计与研发分别说明预期结果，再对照字典。出现不同答案，就修正具体定义。

一份写好的数据字典，应让新加入的同事不靠口头补充，也能判断字段从哪里来、什么情况下有效、改动会影响哪里。可以从当前最重要的一张表单开始，把三个字段讲透，再扩展到其他页面。