要用 AI 创建数据验证清单，先给模型提供经核实的 schema、业务规则登记表、数据集用途、处理阶段和失败成本。请它为结构、类型、取值范围、必填值、唯一性、引用完整性（referential integrity）、允许值、跨字段逻辑、及时性、完整性和对账起草明确的控制项，然后用合成的通过与失败样例测试每条规则。只有当每项检查都有负责人、严重度、阻断（blocking）政策、证据路径和失败分流路径（failure route）时，清单才可运行。

安全输入和审批边界见通用的 AI 使用指南。如果源数据已经出错、任务是修复它，请改用脏数据清理流程；验证只定义和发现失败，不会悄悄修正。

关键要点

定义数据集、用途、阶段、负责人、使用方和失败成本。

使用权威的 schema 和业务规则；不要根据列名推断规则。

为每项控制分配稳定的 Check ID 和确定性的测试方法。

覆盖行、表、关系、批次和汇总各个层级。

区分阻断性失败、警告和仅供参考的观察。

用合成的正例、反例和边界样例验证清单本身。

把失败交给负责的人处理；AI 不批准例外，也不放行数据。

什么才是可执行的验证？

含糊的清单会写“检查日期”“去除重复”或“确保合计看起来没问题”。可执行的清单则写明确切的字段或关系、允许的条件、如何测试该条件、哪些记录在范围内、保存什么证据，以及测试失败后怎么办。

验证不等于真实。一个有效的日期仍可能描述了错误的事件，一个对上账的合计仍可能包含分类错误的行。清单能发现已定义的违规，并暴露尚未解决的语义问题；它无法保证每个数值都准确反映现实。

把验证与清洗、审批分开。发现问题应产生证据；更正应遵循获授权、可追溯的流程；放行则应由人或受管控的系统依据既定政策决定。

第 1 步：定义用途、阶段与失败成本

从一份数据契约开始。记录数据集代表什么、谁生成和使用它、它支持哪项决定或流程、验证在生命周期的哪个环节运行，以及缺陷漏过时可能出什么问题。

英国政府数据质量框架把质量视为“适合用途”，并描述了贯穿数据生命周期的质量管理。［1］接入时重要的规则，可能不同于报告、模型训练、迁移或发布前所需的规则。

契约字段	记录内容
数据集 ID/版本	稳定名称和 schema 修订版
用途	所支持的决定、服务、报告、迁移或分析
阶段	接入、转换、存储、导出或发布
生产方/使用方	系统和负责的团队
单位与粒度	一行代表什么
刷新	预期频率、截止点和延迟
敏感度	分级和访问限制
失败成本	对客户、财务、法律、安全或运营的影响
负责人/批准人	对规则和放行政策负责的人

同一数据集服务多个用途时，分别记录规则配置。某个字段在探索性分析中可以选填，在开具发票时却可能必填。

第 2 步：收集权威规则

不要让 AI 根据一个样本文件编造清单。收集 schema 定义、数据字典、源系统契约、业务政策、参考表、转换规范、使用方要求和已知的事故记录，并记录每个来源的负责人和版本。

当定义缺失或相互冲突时，为数据负责人创建一个待办问题。使用 unknown rule，而不是根据字段名或观察到的分布去猜测。现有数据只证明发生过什么，不证明什么被允许。

如果还没有可靠的数据字典，先使用数据字典流程。如果规则用 SQL 实现，SQL 核验流程可以帮助审查语法和查询风险，而执行过程仍保持只读和受控。

第 3 步：用 AI 创建数据验证清单的统一控制记录

为每项验证分配稳定的 Check ID，并把定义保存为可审核的格式，例如有版本号的表格或配置文件。

控制字段	必填内容
Check ID	稳定标识，例如 `VAL-023`
规则来源	有版本号的 schema、政策或负责人决定
范围	数据集、表、行、字段和排除项
规则	确切的通过条件
测试方法	查询、断言、解析器或对账程序
预期结果	布尔值、计数、容差或获批集合
严重度	严重、高、中、低或仅供参考
执行方式	阻断、警告、隔离或观察
负责人	对规则负责的人
证据路径	输入版本和结果的存放位置
失败分流	队列、团队、响应时间和升级路径
例外	获批范围、理由、到期日和批准人
复核触发条件	schema、政策、事故或使用方的变化

把严重度和执行方式分开。在迁移期间，严重缺陷可能在获批例外下暂时只被观察；而一个看似很小的格式违规，却可能阻断某个机器接口。由政策负责人决定；模型只起草选项。

第 4 步：检查结构与类型

结构检查确认预期的对象存在并可被解析。核实文件类型、编码、分隔符、表头名称、表和列是否存在、合同约定的字段顺序、记录形态和 schema 版本。多出的字段带来泄露或兼容性风险时，予以拒绝。

类型检查应测试实际的契约，而不只是软件能否强制转换某个值。要决定 "0012" 是标识符还是数字、空字符串是否不同于 null、小数精度如何处理、时间戳使用哪个时区，以及布尔值是否只接受一种既定的表示方式。

明确记录类型转换。静默转换可能删掉前导零，或用错误的时区解读时间戳。解析成功并不够；要把结果与预期的语义类型进行比较。

第 5 步：检查字段

字段检查通常包括：

必填： 在规定的记录类型中，该值必须存在。
范围： 数值或日期落在获批的闭区间或开区间内。
长度与格式： 标识符、代码或文本符合约定的模式。
允许值： 该值存在于有版本号的参考集合中。
唯一性： 该值或复合键在规定范围内只出现一次。
精度： 货币、计量值或百分比保持允许的小数位数。
条件必填： 只有在另一种状态成立时，该字段才必填。

纳入边界样例。如果年龄范围是 18 到 120，就测试 17、18、120、121、null、文本和小数。如果时间戳不得晚于批次截止点，就测试恰好等于截止点的情况和时区切换。

不要让 AI 根据当前的最小值和最大值推导允许范围。历史数值可能含有错误，也可能没有覆盖合法的极端值。使用权威规则，或询问负责人。

第 6 步：验证键与关系

唯一性和引用完整性跨越多行或多张表。定义候选键、主键、复合键、父子关系、基数和删除行为。检查重复的业务键、孤立的子记录、意外的多对多连接，以及子记录状态不可能成立的父记录。

PostgreSQL 文档区分了检查约束、非空约束、唯一约束、主键约束和外键约束，并解释外键用于维护相关表之间的引用完整性。［3］数据库约束很有价值，但清单可能还需要加载前检查、跨系统关系、时间规则，或无法安全编码为简单约束的条件。

对每一种关系，写明快照和键的规范化方式。分别报告匹配、未匹配、多重匹配和被排除的数量。

如果主要任务是比较两个数据集并解决未匹配的记录，请使用专门的表格对账流程。验证清单可以引用其结果，而不必吞并整个对账过程。

第 7 步：跨字段与时间规则

跨字段规则体现业务含义。例如 end_date >= start_date、退款金额不超过已收款金额、国家与邮编格式相互匹配，或已关闭的记录必须填写关闭原因。把每条规则写成明确的谓词，并规定 null 的处理方式。

时间检查应区分事件时间、接入时间、更新时间和批次截止点。测试到达过晚的事件、未来的时间戳、不可能的先后顺序、重叠的生效期、必需区间中的空档，以及过时的参考数据。

避免编码偏见或未经批准的代理变量的规则。在旧数据中观察到的相关性并不是业务约束。如果某条拟议规则会影响资格、访问、定价、雇佣或其他有后果的结果，就要按情况进行相应的领域、法律、隐私和公平性审查。

第 8 步：完整性与及时性

完整性不只是字段非空。要定义预期记录数、预期分区、必需的实体、覆盖时段和强制关系。有权威控制总数时，把接收到的记录与之比较。

及时性检查应定义预期到达时间、允许的延迟、时区、节假日、重试窗口，以及什么算一个完整批次。把“迟到”与“缺失”分开：一个批次可能按时到达，却只包含预期总体的一部分。

W3C 的数据质量词汇表（Data Quality Vocabulary）提供了一种方式，用于表达数据集的质量测量、指标、注释和相关溯源信息。［2］你不必采用这套词汇表也能运用其原则：保存测量了什么、用哪个指标、针对哪个数据集版本、何时测量，以及由谁或哪个流程完成。

第 9 步：汇总与不变量

增加跨层级的检查：行值应能汇总为分组合计；分组合计应与批次控制数一致；在领域定义了这一不变量的情况下，期初余额加上变动应等于期末余额。写明四舍五入、货币换算、容差和被排除的状态。

对账规则绝不能写成“合计差不多”。要定义绝对容差和相对容差、设定的理由，以及该规则是阻断还是警告。同时报告差额及其组成，便于审核人调查。

尽可能使用独立的控制总数。同一有缺陷转换的两份输出可能彼此吻合，所以要记录它们共享的依赖。

第 10 步：设计失败处理

每一项失败的控制都需要失败分流路径。决定是阻断批次、隔离受影响的记录、向使用方发出警告、在获批例外下继续，还是停止下游流程。写明负责人、响应时间、所需证据和升级路径。

失败字段	必填内容
运行 ID/Check ID	确切的验证执行和规则
数据集版本	输入快照和流水线修订版
失败数量	受影响的行数和百分比
样本证据	最少量、受访问控制的示例
严重度/执行方式	对这次失败适用的政策
负责人	负责分流处理的人或团队
控制措施	阻断、隔离、警告或隔开
解决方式	修复、源头更正、接受例外或修改规则
批准	具名的获授权审核人和时间戳
重跑证据	更正或例外之后的结果

例外必须范围窄、有时限且可复核。记录谁批准、为什么、覆盖哪些记录，以及何时到期。绝不让模型豁免失败的控制。

第 11 步：合成测试

为每条规则至少创建一个通过样例、一个失败样例和相关的边界样例。合成记录不应包含任何真实的个人数据或生产数据。给它们稳定的 ID 和预期结果。

示例包括：重复的复合键、孤立的子记录、结束日期早于开始日期、只对某一种记录类型必填的 null、恰好等于最大值的数值、迟到但被允许的事件，以及超出容差的批次。确认每个样例只令预定的那项检查失败；否则该测试数据可能未能隔离规则。

模型可以根据规则表建议样例，但审核人必须核实覆盖范围和预期结果。NIST 的生成式 AI 配置文件指出了虚构内容和其他需要受管控核实的风险。［4］看似合理的生成测试，不能证明控制正确。

第 12 步：试行与版本化

在非生产环境中，用合成测试数据和一份获批的历史快照运行清单。把结果与已知事故和人工审核进行比较。意外的通过与意外的失败同样要认真调查。

对数据集契约、规则来源、清单、实现、测试数据和执行政策进行版本管理。在 schema、政策、来源、使用方、转换或风险发生变化后重新审查。

不要仅仅因为 AI 生成的草稿看起来完整，就在生产环境中启用阻断。数据负责人批准语义，工程师审查实现和运行行为，安全和隐私负责人审查敏感数据的处理，放行权限方决定执行方式。

简明提示词契约

告诉模型：只使用提供的 schema、规则来源和数据集用途；每项检查输出一行，包含 Check ID、精确的谓词（predicate）、范围（scope）、null 的处理方式、测试方法、预期结果、严重度（severity）选项、执行方式（enforcement）选项、负责人（owner）、证据（evidence）、失败分流路径（failure route）和合成样例；冲突或缺失的规则标为 owner decision required；不得根据样本分布推断约束，也不得批准例外、修复或放行。

最终检查清单

已记录数据集用途、粒度、生命周期阶段、使用方、敏感度和失败成本。
每条规则都指向权威来源和负责人。
覆盖了结构、类型、字段、唯一性、引用完整性、跨字段、时间、完整性、及时性和汇总检查。
每项检查都有确定性的逻辑、null 处理方式、预期结果和证据路径。
严重度与阻断、警告、隔离或观察政策相互独立。
合成的通过、失败和边界样例都产生预期结果。
已定义失败分流、负责人、升级、例外、到期日和重跑证据。
生产环境中的执行已通过组织正常的发布流程批准。
版本和复核触发条件把 schema、规则、实现和测试数据联系在一起。

常见问题

验证和清洗有什么区别？

验证检测既定条件是否成立并记录证据；清洗会改变数据。让更正过程获得授权、可重现，并与检测结果分开。

AI 可以从样本推断规则吗？

它可以提出问题，但观察到的模式并不是权威规则。每一项约束都要通过 schema、政策、使用方要求或数据负责人加以确认。

哪些检查应该阻断流水线？

由获批的执行政策根据用途和失败成本决定。把严重度与阻断行为分开，并记录例外。

数据库约束够吗？

不够。数据库约束是支持范围内不变量的强控制，但生命周期、跨系统、及时性、汇总和加载前的检查，可能还需要额外的验证。

如何验证 null？

针对每个字段和记录类型，定义 null、空值、零、未知和不适用是否彼此不同，并测试每一种允许和禁止的情况。

什么是好的引用完整性检查？

使用来自同一既定快照、经过规范化的确切父键和子键，然后分别报告匹配、孤立、多重匹配和被排除的记录。

可以用生产行做 fixture 吗？

优先使用合成的测试数据（fixture）。如果试行确实需要一份获批的历史快照，就把它最小化、保护访问权限，并遵守保留和删除规则。

多久审核一次清单？

在 schema、政策、来源、转换、使用方、事故记录或失败成本发生变化时复核，并按既定周期定期复核。

谁批准例外？

由具名的政策或数据负责人，在必要的领域、隐私、安全、法律或发布审查支持下批准。例外应当有范围、有理由，并设有到期日。

来源

UK Government — The Government Data Quality Framework — https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework
W3C — Data on the Web Best Practices: Data Quality Vocabulary — https://www.w3.org/TR/vocab-dqv/
PostgreSQL — Constraints — https://www.postgresql.org/docs/current/ddl-constraints.html
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 创建数据验证清单：Check ID、阻断规则与失败分流