番号库数据字典：字段、别名与状态值怎么读

数据字典不是字段名称的简单列表，而是一份对含义、类型、允许值、空值和更新责任的共同约定。目录如果只写“日期”“状态”“名称”，不同编辑很容易把收录日期当作发布日期，把未知值当作不存在，最终让同一列混入多种语义。

问题边界与核心判断

可靠的字段定义至少回答五件事：字段描述什么对象、采用什么格式、值从哪里取得、缺失时如何表达、何时需要重新核验。别名必须指向首选名称，但原始写法仍应保存在证据记录中；状态值则要列出完整值域，避免编辑临时创造相近词。

本文只讨论公开、中性的元数据整理方法。任何来源未给出的事实都不补写，任何无法回到证据的判断都保留为待确认；示例内容不对应真实人物、作品或平台。

可复现的工作流程

执行时建议为本篇主题创建独立工作单，保存输入、操作顺序、观察日期和结论强度。不要一次改变多个条件，也不要为追求整齐覆盖原始值。

1. 步骤 1：先写业务问题，再决定字段。只有能回答明确问题的属性才进入正式字典，装饰性信息放入备注。
2. 步骤 2：为每个字段声明文本、日期、枚举或标识等类型，同时记录精度、大小写和分隔符规则。
3. 步骤 3：把“未知”“不适用”“尚未核验”和真正空白分开，禁止用同一个空值承担四种含义。
4. 步骤 4：建立首选名与别名表，修订首选名时保留旧称、启用日期和迁移说明。

示例工作单

虚构示例记录中，字段“record_status”允许 draft、verified、disputed 三个值；空白不被视为第四个状态。若来源只给出模糊年份，就把日期精度记为 year，而不是补成某年一月一日。示例只用于说明结构，不对应任何真实作品、人物或平台。

record: "example-only"
method: "data-dictionary-fields-aliases-status"
source_status: "待确认"
decision: "仅演示流程，不构成事实"

常见偏差与纠正

• 把显示标签直接当稳定字段名，界面文案一变就破坏下游引用。
• 发现别名后覆盖原始值，导致以后无法解释合并依据。
• 只写正常值，不说明未知、冲突和失效记录怎样表示。

如果流程要求真实账号、下载文件、绕过权限或提交敏感资料，应立即停止。本地站点不具备真实提交、发布或核验后台，相关状态不能从页面外观推断。

结论

先定义再录入，能让番号库中的每个值都有明确语义。字段字典应与样例、来源要求和变更日志一起维护；任何无法解释的值都应停留在待确认状态，而不是被猜测补全。