研发数据质量校验规则清单模板：空白表与填写规范

2026年11月11日

研发数据质量校验要长期运转，需要把规则、执行配置和异常处理分别沉淀成可复用的表。本文提供三张可直接复制填写的空白模板：规则清单表、校验配置表和问题记录表，并说明每个字段的填写口径、必填最小集、一条规则的完整填写示例以及后续维护方法。三张表共用同一套规则编号，先登记规则，再配置执行，最后跟踪问题闭环。

Table of Contents

要点总览（TL;DR）

研发数据质量校验可沉淀三张表：规则清单登记校验对象、判定条件与责任人，校验配置说明执行位置与频率，问题记录跟踪异常发现到复核关闭。
三张表用同一套规则编号串联：规则清单是主键，校验配置按编号落地执行，问题记录按编号回溯来源规则。
最小可用集先填满：规则清单至少填规则编号、校验对象、字段、规则类型、判定条件、严重级别和责任人；校验配置至少填规则编号、数据源、执行频率和启停状态。
模板上线后按增、停、调、审四类动作维护，建议每季度复核一次规则有效性、阈值匹配度和未闭环问题进度。
规则清单与问题记录保留版本留痕，追溯历史报表时可还原当时生效的规则和阈值。

可复制空白模板：规则清单、校验配置与问题记录

三张表的分工是：规则清单回答“校验什么、怎么判定、出了问题谁处理”；校验配置回答“这条规则在哪里执行、多久跑一次、结果发到哪里”；问题记录回答“某次校验发现了什么异常、怎么修、复核结果如何”。建议把三张表放在同一份文档或同一套表格工具中，用规则编号作为唯一关联键。

表一：规则清单

规则编号	校验对象	字段	规则类型	判定条件	阈值	严重级别	责任人	处置动作
DQ-001
DQ-002
DQ-003

表二：校验配置

规则编号	数据源	执行频率	告警渠道	生效范围	启停状态
DQ-001
DQ-002
DQ-003

表三：问题记录

问题编号	关联规则编号	发现时间	异常样本	原因	修复动作	复核结论
ISS-001
ISS-002
ISS-003

三张表的关联方式：规则清单中的“规则编号”是主键，校验配置以同一编号说明该规则如何执行，问题记录以“关联规则编号”指回来源规则。一条规则可以对应多条问题记录，一条配置只对应一条规则。规则编号建议采用“DQ-序号”格式，问题编号采用“ISS-序号”格式，便于在文档中检索和引用。

字段说明：每个字段填什么、怎么判定

字段口径统一，不同角色填写时才能对得上。下面按表逐字段说明，重点区分容易混淆的几组概念。

规则清单字段

字段	填写口径
规则编号	全表唯一，格式建议 DQ-三位序号，创建后不随规则内容修改而变更。
校验对象	被校验的数据集合，如“需求工作项表”“迭代交付记录”“缺陷记录表”，写到可定位的表或数据集层级。
字段	校验对象中的具体列，如“需求负责人”“关闭时间”“迭代编号”。一条规则涉及多个字段时逐字段列出或拆成多条规则。
规则类型	从完整性、唯一性、有效性、一致性、及时性、准确性六类中选择一类，含义见下文。
判定条件	描述“什么情况算不通过”的逻辑表达式，如“字段为空”“同一迭代内编号重复”“关闭时间早于创建时间”。
阈值	判定条件成立的数量或比例界限，如“不通过记录数大于 0”“空值率超过 5%”。阈值是判定条件的量化边界，两者配合使用。
严重级别	按对度量结论的影响分三级：高（直接导致指标失真，需当日处理）、中（影响局部统计，本迭代内处理）、低（展示瑕疵，排期处理）。
责任人	填写规则的维护人，负责规则口径解释与调整；数据修复人另在问题记录中指定，两者可以不同。
处置动作	校验不通过时的标准动作，如“阻断数据入仓”“标记异常并通知责任人”“自动回填默认值”。

六类规则类型的判定含义：完整性关注必填字段是否缺失；唯一性关注主键或业务编号是否重复；有效性关注取值是否落在允许范围或格式内；一致性关注跨表、跨字段的对应关系是否成立，如工作项所属迭代在迭代表中存在；及时性关注数据是否在约定时间内更新到位；准确性关注数值与真实业务结果是否吻合，通常需要抽样比对。

校验配置字段

字段	填写口径
规则编号	引用规则清单中的编号，不新编。
数据源	规则实际执行的位置，写到系统与表或数据集名称，如“项目管理系统-工作项同步表”。
执行频率	按数据更新节奏填写，如“每日同步后执行”“每次导入后执行”“每周一全量执行”。频率应与数据变化速度匹配。
告警渠道	校验不通过时的通知方式，如“责任人邮件”“团队群消息”“问题记录自动创建”。
生效范围	规则作用的记录范围，如“全部项目”“某产品线”“近 12 个月数据”，避免全量执行拖慢同步。
启停状态	填写“启用”或“停用”，停用时在规则清单备注停用原因。

问题记录字段

字段	填写口径
问题编号	全表唯一，格式建议 ISS-三位序号。
关联规则编号	触发该问题的规则编号，必须能在规则清单中找到。
发现时间	校验执行并判定不通过的时间，精确到日期。
异常样本	至少给出一条可复现的记录标识或截图说明，便于定位。
原因	区分数据录入错误、同步遗漏、规则口径过严等类别，写清具体原因。
修复动作	实际执行的修正操作，如“补录负责人字段”“修正迭代归属”“调整阈值”。
复核结论	取值为“通过”“不通过”“转规则调整”三种：通过表示复跑校验已无异常；不通过表示问题仍在，需继续处理；转规则调整表示原规则口径需要修改，转入规则清单维护流程。

必填与选填：哪些字段不能空

模板字段较多，落地时先保证最小可用集填满，其余字段按需补充。必填字段缺失时，该条记录视为未完成登记，不进入执行或复核环节。

表	必填字段	可后补或选填字段
规则清单	规则编号、校验对象、字段、规则类型、判定条件、严重级别、责任人	阈值（无量化界限时可空）、处置动作（默认按严重级别处理时可后补）
校验配置	规则编号、数据源、执行频率、启停状态	告警渠道（初期人工巡检时可空）、生效范围（默认全量时可空）
问题记录	问题编号、关联规则编号、发现时间、异常样本、复核结论	原因、修复动作（问题尚在定位阶段时可先留空，复核前补齐）

选填字段的典型场景：阈值在规则刚建立、历史数据不足时可以先空着，积累一两个周期后再定；告警渠道在规则试运行阶段可以只记录不通知；原因和修复动作在问题刚发现、尚未定位时可以暂缺，但复核结论为“通过”前必须补齐，否则无法判断修复是否有效。必填字段缺失时的处理约定是：规则清单缺必填项不进入配置环节；校验配置缺必填项不启用；问题记录缺必填项不计入闭环统计。

填写示例：一条规则从登记到复核的完整记录

以下示例为演示情景，展示三张表如何用同一规则编号串联。假设团队发现迭代交付记录中部分工作项缺少负责人，导致按人统计的交付效率失真。

规则清单中的记录

规则编号	校验对象	字段	规则类型	判定条件	阈值	严重级别	责任人	处置动作
DQ-007	迭代交付记录	负责人	完整性	已关闭工作项的负责人字段为空	不通过记录数大于 0	高	效能数据管理员	标记异常并通知项目负责人补录

校验配置中的记录

规则编号	数据源	执行频率	告警渠道	生效范围	启停状态
DQ-007	项目管理系统-工作项同步表	每日同步后执行	责任人邮件并自动创建问题记录	近 6 个月已关闭工作项	启用

问题记录中的记录

问题编号	关联规则编号	发现时间	异常样本	原因	修复动作	复核结论
ISS-012	DQ-007	2025-03-10	工作项 ITER-231 负责人为空，同批次共 4 条	批量导入时负责人列未映射	补录 4 条工作项负责人，修正导入模板映射	通过

这条链路中，规则清单定义了“已关闭工作项负责人不能为空”，校验配置把它落到每日同步后的执行动作，问题记录记录了 4 条异常、原因和修复结果。复核结论为“通过”表示次日复跑校验已无同类异常。若复核发现异常反复出现，可把结论改为“转规则调整”，回到规则清单评估是否需要在导入环节增加前置校验。

当规则数量和问题记录增多后，问题从发现到复核关闭的状态流转需要有承载位置。ONES 的工作项与文档能力可以承接这类登记与流转：把校验问题建成工作项，关联规则编号，按“待处理—修复中—待复核—已关闭”推进状态，复核记录留在工作项中可追溯。ONES 效能管理对交付效率、交付质量、进度情况、资源效率等效能数据进行直观展示，形成量化、实施、分析、改进的闭环，规则校验后的干净数据可以直接支撑报表与图表展示。规则清单本身适合以文档形式维护，与工作项中的问题记录通过规则编号对应。

调整与维护方法：规则增删、分级与定期复核

规则清单上线后需要持续维护，否则会出现规则过期、阈值失真、问题积压。维护动作围绕增、停、调、审四类展开。

新增规则的触发条件与登记流程

出现以下情况时新增规则：新指标上线需要配套数据校验；某类问题在问题记录中重复出现两次以上；数据源结构变更导致原有字段含义变化。登记流程为：提出人在规则清单中新增一行，填写必填字段，指定责任人；责任人确认判定条件与阈值后，在校验配置中补充执行配置；规则进入试运行，观察一个周期后再正式启用。

规则停用与归档

规则对应的指标下线、数据源废弃或连续多个周期无异常且业务不再关注时，可以停用。停用不是删除：在校验配置中把启停状态改为“停用”，在规则清单中保留原记录并注明停用日期和原因。停用满一个季度仍无恢复需求的规则移入归档区，规则编号不再复用，历史问题记录仍可通过编号回溯。

严重级别与阈值的调整依据

严重级别按规则对度量结论的实际影响调整：某规则触发后导致对外报表出现明显偏差，可从中升高；长期只影响个别记录且不影响汇总口径，可从高降为中或低。阈值调整依据历史问题记录中的异常数量和修复成本：阈值过严导致大量低价值告警时放宽，阈值过松导致问题在报表发布后才被发现时收紧。每次调整在规则清单中记录调整日期和调整人。

定期复核的周期与参与角色

建议每季度做一次规则清单复核，参与角色包括效能数据管理员、各项目数据责任人、报表使用方代表。复核内容包括：规则是否仍对应有效指标、阈值是否匹配当前数据量、问题记录中未闭环项的处理进度、停用规则是否可归档。复核结论形成简短记录，附在规则清单文档末尾。

版本留痕方式

规则清单和问题记录都建议保留版本记录：规则清单每次增删改后更新文档版本号，并在变更记录中写明规则编号、变更内容和日期；问题记录按问题编号保留完整处理历史，复核结论变更时追加记录而非覆盖原值。这样在追溯某期报表数据时，可以还原当时生效的规则和阈值。

常见问题

规则清单里的“责任人”和问题记录里的修复人可以是同一个人吗？

可以，但两个角色的职责不同。规则清单中的责任人是规则的维护人，负责解释判定口径、调整阈值和处理“转规则调整”的结论；问题记录中的修复人负责具体的数据修正。小团队里由同一人兼任很常见，规则数量增多或数据源分散后，建议把规则维护和数据修复分开，避免规则口径被个例修复需求带偏。

阈值暂时定不下来，规则可以先上线吗？

可以。阈值在规则清单中属于可后补字段，规则刚建立、历史数据不足时先留空，按判定条件执行并观察一两个周期的异常数量，再据此设定量化界限。需要注意的是，阈值留空期间严重级别的判断缺少数量依据，建议先按“高”级别试运行，等阈值确定后再按实际影响调整级别。

问题复核结论填“转规则调整”之后，流程怎么走？

“转规则调整”表示异常反复出现，根因在规则口径或前置环节，而非单条数据。处理方式是回到规则清单评估：判定条件是否过严、阈值是否过低、是否需要在数据录入或导入环节增加前置校验。调整后在规则清单中记录变更日期和调整人，原问题记录保留“转规则调整”结论不覆盖，待新规则生效后另建问题记录跟踪复跑结果。

校验配置里的执行频率怎么和数据同步节奏配合？

执行频率应与数据变化速度匹配。数据每日同步一次的，配置为“每日同步后执行”；有批量导入场景的，增加“每次导入后执行”；变化慢、数据量大的规则可改为每周全量执行。频率过高会拖慢同步并产生重复告警，频率过低则问题可能在报表发布后才暴露。生效范围同时收窄，例如只校验近 6 个月数据，可以减少单次执行的数据量。