3. 字段名称与ID规范：命名原则与唯一标识

在需求文档（PRD）中，字段名称与ID是需求的“身份证”。命名混乱、ID冲突、版本无追溯会导致研发与测试在实现时反复核对，严重拖慢交付节奏。本章聚焦如何建立一套可执行、可审计的字段与ID规范。

3.1 用户场景与业务痛点

• 场景1：跨版本需求追溯——产品经理在V2.3版本中修改了“订单状态”字段，却找不到V2.2版本中该字段的历史映射关系，导致数据迁移遗漏。
• 场景2：多系统字段对齐——上游CRM系统使用“isVipMember”，下游订单系统却用“vip_flag”，每次联调都需要人工翻译字典。
• 场景3：同名不同义——两个需求模块都出现了“用户ID”，但一个指注册用户ID，另一个指匿名访客指纹，测试用例覆盖不全。

3.2 需求拆解：四大核心维度

1. 命名原则：统一语种、风格、含义，避免歧义。
2. 唯一标识：每个字段拥有全局唯一的ID，不因版本刷新而改变。
3. 版本号：明确字段变更的生命周期，支持逐版本回溯。
4. 关联需求追溯号：每个字段必须绑定顶层需求或用户故事的编号。

3.3 方案表达：字段规范表与验收清单

3.3.1 字段命名原则对比

原则	推荐做法	不推荐做法
语种	全英文小写 + 下划线（snake_case）	中文拼音、大小写混用、驼峰
词序	业务域 + 含义 + 属性，如 order_status_current	含义 + 无业务域前缀，如 status
长度	不超过32个字符，英文单词完整	缩写得无法理解，如 ord_sts_cur
特殊字符	仅允许字母、数字、下划线	包含空格、连字符、点号

3.3.2 唯一标识分配规则

• ID结构：模块_序号_子序号，例如 order_00342_01。
• 序号机制：使用递增数字，不重用已删除的ID号。
• 集中登记：所有字段ID必须列入PRD的“字段总览表”，不允许产生“孤儿字段”。

3.3.3 版本号迭代策略

版本号示例	变更类型	触发条件
v1.0	初始创建	新需求纳入
v1.1	小小修改	字段说明、枚举值增减、默认值调整
v2.0	重大变更	字段含义改变、数据类型变化、字段废弃

版本号记录在每个字段的元数据中，独立于PRD整体版本。每次变更需在字段后追加变更日志。

3.3.4 关联需求追溯号定义

• 追溯号格式：[需求模块]-[需求编号]，例如 LOGIN-042。
• 一对一关联：一个字段必须归属于且仅归属于一个需求条目。
• 显式声明：在字段总览表中，将“关联需求号”作为必填列。

3.4 指标验证

• 字段唯一率：同一PRD中字段ID重复数为0。
• 版本覆盖率：每个版本变更的字段，100%记录新版本号与变更原因。
• 追溯命中率：字段总览表中的每个字段均能通过关联需求号找到对应的需求条目。

3.5 验收标准

验收项	通过条件
命名规范检查	所有字段名均为英文小写+下划线，长度≤32，无保留字
唯一标识检查	字段ID在整份PRD中不重复，ID格式符合 模块_序号 规则
版本号完整性	每个字段均有版本号字段，且最新版本号与PRD总版本对应
追溯号完整性	每个字段均填写 [需求模块]-[编号]，且对应需求条目存在

3.6 字段与ID分配流程图

3.7 交付物模板示例

字段总览表（PRD附件）

字段ID	字段名称	版本号	关联需求号	字段说明
order_00342_01	order_status_current	v1.1	ORDER-0342	当前订单生命周期状态码
user_00112_02	user_registration_time	v1.0	USER-0112	用户首次注册时间戳

以上表格为每个字段提供了完整溯源能力，开发与测试人员可以根据字段ID快速定位变更历史，无需翻阅整篇PRD。