要用 AI 起草数据字典，先盘点实际存在的字段，收集关于其含义和约束的证据，再只把这些已核实的输入交给模型。让 AI 统一措辞并指出缺口，然后在发布某个版本之前，由数据负责人验证每一项定义、类型、单位、允许值、缺失值规则、敏感度标签和数据血缘说明。

这是一套文档流程，不是根据列名反推真相的方法。更通用的负责任使用 AI 指南解释了为什么来源证据和人工复核必须始终占据主导。

关键要点

记录字段之前，先冻结数据资产、系统、环境和版本。

根据结构定义、导出文件、代码和负责人访谈建立字段清单，而不是依赖模型记忆。

把物理类型与业务含义、格式、单位和允许值分开。

为缺失值赋予明确含义，不要把每个空白都当作同一种状态。

用 AI 统一和质疑草稿，绝不让它编造定义或数据血缘。

发布版本之前，用合成样例和责任负责人进行验证。

一份可用的数据字典应包含什么？

数据字典是一份受治理的数据元素目录，包含解释这些元素所需的规则。它把 order_status_cd 这样的技术字段，与精确的业务含义、有效的表示方式、问责负责人和变更历史联系起来。结构定义可能只说明某列是可为空的字符串；数据字典则解释字符串代表什么、允许哪些值、为何可能为空及谁能批准变更。

NIH 的元数据指南把元数据视为让数据可理解、可复用的信息，NIDDK 的指南则强调要准备好定义和编码值，让另一个人也能解读数据集。［1］［2］NIMH 数据档案提供了一个具体模型：其元素列表区分名称、数据类型、大小、是否必填、条件、说明、取值范围、备注和别名。［3］

使用稳定的行结构，而不是只有文字说明的术语表：

字段	应记录的内容
字典 ID 和版本	稳定身份和发布编号
资产和字段	系统、数据集、表或文件，以及准确的物理名称
业务定义	单一含义，不用循环措辞
物理及逻辑类型	存储类型，加上日期、货币或代码等概念类型
格式和单位	格式模式、时区、币种、比例或计量单位
允许值	枚举、范围、代码集版本和大小写规则
缺失值含义	空白表示未知、未收集、不适用还是无效
来源和数据血缘	权威来源和获批的转换
责任归属	数据负责人、数据管理员和技术保管人
敏感度和用途	分类、访问限制和获批用途
质量规则	可测试的有效性、完整性、唯一性或勾稽规则
状态和复审	草稿、已批准或已停用，复审人、日期和变更说明

这张表刻意比“列说明清单”更详细，因为团队常在边界处丢失含义：没有时区的时间戳、没有分母的百分比、没有代码集版本的代码。

步骤 1：冻结资产和文档范围

写明要记录的确切对象：源系统、环境、数据集或接口、表或文件、提取日期、结构定义版本和字典负责人。确定字典描述的是源字段、转换后的模型、接口载荷，还是跨系统的规范概念。不要在不展示映射的情况下把这些层级混在同一行。

排除项也要写明。例如，客户订单字典可能排除派生的财务指标和事件遥测数据。这能防止 AI 用看似合理却无关的字段填满草稿。

建立一个简单的范围表头：

范围字段	合成示例
字典 ID	`DD-ORDERS-07`
资产	`analytics.orders_curated`
来源版本	`schema-2026-09-01`
环境	已批准的生产定义，不含数据行
纳入对象	只含订单表头字段
排除对象	支付令牌和事件日志
数据负责人	商务运营角色
复审触发条件	结构定义、政策或代码集变化

资产在此期间仍在变化时，记录截止点并另开变更项。悄悄混用两个结构定义版本的字典无法可靠复核。

步骤 2：从权威证据盘点真实字段

从获批来源收集字段名和结构事实：数据库目录导出、接口规范、文件表头、转换代码、验证规则、代码集存储库、现有治理记录，以及对数据责任人的访谈。为每个来源保存引用，而不是粘贴敏感数据行。

如果你从一份电子表格开始，先清理表格而不丢失证据。清理重复表头或不一致格式，与定义字段含义是两回事。

对每个字段，区分四类证据：

**观察到的结构：**准确名称、存储类型、可否为空、长度或位置。
**强制执行的规则：**数据库约束、验证代码或获批代码集。
**负责人陈述：**经复核的业务含义、用途和问责归属。
**工作假设：**尚未解决、必须标为 VERIFY 的解读。

绝不要只为帮助模型识别模式就提供生产记录。使用仅含结构的导出和合成样例。如果确实需要逼真的样例，就删除或泛化标识符，并确认生成的样例已获准用于所选工具。

步骤 3：为每个字段写一份可测试的契约

好的定义会说明概念、范围，以及决定该值的事件或规则。“客户类型”是循环定义；“开户时由已批准的开户规则赋予的分类”更有用，前提是引用了该开户规则并由负责人确认。

可以使用这样的行模板：

属性	合成值
字段	`delivery_window_start`
业务定义	客户已确认配送时段的开始时间
物理类型	时间戳
格式及时区	ISO 8601，以 UTC 存储
可为空	是
缺失值含义	尚未选择配送时段
来源	排期服务事件 `window_confirmed`
数据血缘	不做时间运算，直接复制到整理后的订单表
负责人/数据管理员	履约 / 数据治理角色
敏感度	内部运营数据
质量规则	两者都存在时必须早于 `delivery_window_end`
状态	草稿——需负责人复核

不要根据列名推断定义。名称可能是历史遗留、缩写、被重复使用或具有误导性的。字段 active 可能描述账户、订阅、流程或设备的最后已知状态；只有证据才能确定其含义。

步骤 4：用 AI 起草数据字典，把它限定为有边界的整理任务

提供范围表头、获批的字段证据、输出列和明确的禁止编造规则。要求逐行转换并附上问题，而不是一份掩盖不确定性的精美文档。

把所提供的字段证据整理到指定的数据字典列中。
只使用所提供的来源，并保留每个来源 ID。
不得根据字段名推断定义、类型、单位、允许值、负责人、敏感度、
数据血缘、默认值或缺失值含义。
缺乏支持的单元格写 [VERIFY]，并说明缺少什么证据。
相互冲突的陈述分开保留。返回一份验证问题清单。
不得包含或索取生产数据行或个人信息。

要求模型原样保留标识符。只有在已提供缩写全称时，它才可以在说明文字中展开缩写。这种有边界的用法比让模型“为这个数据库创建一份字典”更安全，后者容易引出虚构字段和泛泛的含义。NIST 把虚构内容、隐私、信息完整性和人机协作配置列为生成式 AI 的重要风险。［4］

步骤 5：处理单位、代码集与缺失值

复核那些技术上有效、语义上却仍可能出错的地方。

单位与格式

记录币种、比例、时区、区域设置、精度，以及区间是否包含边界。0.15 可能表示比率、15%、税率或某个测量值。没有历法说明的日期、没有时区规则的时间戳，都可能导致分析结果不一致。

枚举与范围

准确列出允许值，包括大小写、保留值、生效版本和已弃用代码。如果清单由其他地方维护，就链接权威的代码集 ID，而不是复制一份没有版本的快照。

缺失值含义

区分未知、未收集、不适用、尚不可用、已删减和无效。如果来源把它们全都折叠成空值，就如实写明。不要让 AI 制造来源本身并未保留的区分。

默认值

区分数据库默认值、业务默认值和显示回退值。界面在值缺失时显示“标准”，并不能证明存储字段的默认值就是它。

步骤 6：映射负责人、敏感度与数据血缘

指派一名能批准含义和允许用途的数据负责人、一名维护文档的数据管理员，以及一名能核实实现情况的技术保管人。一个角色可以承担多项职能，但职责必须明确。

敏感度标签必须来自组织的分类政策。不要让模型根据字段名决定它是公开还是机密。一个看似无害的标识符，与另一个数据集关联后可能变得敏感。

数据血缘应在复核所需的层级上写明权威来源、转换和目标。避免“来自数据仓库”这类含糊说法。如果数据血缘由代码生成，要与已部署的转换和负责人的认知核对。证据冲突时，列出两条路径并发起决策，而不是挑选更顺畅的说法。

在探索性工作中，用 AI 分析表格可以帮助发现格式不一致，但它不能确立语义上的负责人或真源层面的数据血缘。

步骤 7：由负责人和合成样例验证草稿

进行三轮复核：

**结构复核：**每个真实字段恰好出现一次，标识符一致，已停用字段有标记。
**语义复核：**数据负责人确认定义、业务规则、允许用途和缺失值含义。
**技术复核：**技术保管人把类型、约束、格式、代码集和数据血缘与已实现的资产比对。

然后用合成样例测试字典。复核人应能只依靠书面规则，判断每个样例值是有效、无效、缺失还是超出范围。样例要包含边界情况，例如闰日、零、空字符串、已停用代码、最大长度，以及带有已声明含义的空值。

检查失败时，修正定义或上报底层数据规则，不要反复改写样例直到它恰好符合含糊的文档。如果某项说法仍缺乏证据，就对 AI 辅助草稿做事实核查，并保留 VERIFY，直到负责人提供来源。

步骤 8：版本化、发布与维护

发布一个已批准的只读版本，附上范围、证据引用、复核人、批准日期和变更日志。给使用者一个稳定的标识，让报告、转换和质量检查能够声明自己使用的是哪一版定义。

定义复审触发条件，而不是只依赖日历：

结构定义迁移、接口版本或文件布局变化；
代码集新增或停用代码；
业务政策、计算方法或保留规则变化；
数据血缘中出现新的来源或转换；
发生质量事件或使用者反复提出同一问题；
分类、访问规则或问责负责人变化。

归档旧版本，而不是覆盖历史。沟通某个字段的变更时，说明变化的是物理表示、业务含义，还是两者都变了。这一区分帮助下游评估影响，也防止文档修改被误当作数据迁移。

哪些检查最容易发现常见问题？

使用发布检查清单：

如果字典要为图表或报告提供数据，请在定义稳定之后再做数据可视化。精美的图表无法修复含糊的分母或代码。

总结

从冻结的资产和经核实的字段清单开始。
把存储事实与业务含义和治理决定分开。
用 AI 做整理、一致性检查和提问，而不是推断。
记录单位、代码集、空值语义、负责人、敏感度和数据血缘。
与负责人一起用合成边界样例验证。
发布有版本的成果，并在其输入变化时触发复审。

常见问题

数据字典和数据库结构定义是一回事吗？

不是。结构定义描述已实现的结构，例如表、字段名、类型、约束和关系。数据字典还加入了人能理解的含义、单位、允许值、缺失值语义、负责人、敏感度、数据血缘、质量规则和变更背景。

数据字典最少应包含哪些字段？

至少记录资产、准确字段名、定义、类型、格式或单位、允许值、空值规则、权威来源、负责人、状态和版本。当使用者需要它们来解读或控制用途时，再补充敏感度、数据血缘、质量规则、别名和示例。

起草数据字典时，AI 可以安全地做什么？

AI 可以统一已提供的措辞，把证据映射到固定模板，找出不一致的术语，提出验证问题，并比较各行是否缺少属性。它不能确立组织特有的含义，也不能证明文档与已实现的系统一致。

可以上传样例数据来改进草稿吗？

优先使用仅含结构的元数据和合成样例。即使删除了明显的标识符，真实数据行仍可能包含个人、机密、受监管或类似凭据的数据。只有在获批环境中、目的有记录且有访问控制时才使用真实数据。

没有人知道某个字段的定义时怎么办？

把定义标为未解决，记录相互竞争的解释和证据，并指派数据负责人作出决定。不要挑选看似最合理的措辞，也不要让下游的反复使用把假设变成已批准的定义。

枚举和缺失值应如何记录？

记录准确的允许值、大小写规则、代码集版本、保留代码和已停用代码，以及空值、空白和哨兵值的含义。如果来源无法区分不同的缺失状态，就记录这一限制，而不是编造分类。

合成样例如何验证数据字典？

它们检验书面契约是否足够具体，能在不暴露真实记录的前提下判定边界值。样例应包括有效、无效、缺失、最大长度、已弃用代码、日期和跨字段一致性等情况，然后请技术和业务复核人解释结果。

数据字典应多久更新一次？

同时采用定期复审和事件触发。当结构定义、代码集、政策、转换、分类、负责人或质量表现变化时进行复审；归档上一版本，并让使用者看到生效日期。

来源

NIDDK Central Repository, Preparing Data Dictionaries — https://repository.niddk.nih.gov/static/webinar_media/pdf/NIDDKCR_Office%20Hours_Data%20Dictionaries_20240112.pdf
NIH, Workbook of Metadata Fundamentals — https://datascience.nih.gov/sites/g/files/mnhszr336/files/2025-06/workbook_of_metadata_fundamentals_v1.1_10-25-2024_508.pdf
NIMH Data Archive, Data Dictionary — https://nda.nih.gov/ndar_data_dictionary.html?short_name=ldps01
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

如何用 AI 起草数据字典：从字段证据到负责人验证与版本发布