想象你是一家数据餐厅的主厨，每天要为上百位“下游顾客”上菜。这里的“菜”是数据表，“顾客”是报表、算法模型和业务人员。如果一份订单表缺了支付金额，就像汉堡少了肉饼；如果同一客户在订单表和会员表里名字对不上，就像同一道菜换个门店就换了个味道。数据质量框架，就是贴在后厨墙上那套“质量手册”：定义五道质检关卡（准确性、完整性、一致性、及时性、唯一性），写明每道关卡怎么查、谁来查、多久查一次；发现坏菜立即亮红灯；向客人承诺“30分钟内上菜”（SLA）；出问题菜马上撤下、追根因、重做、复盘。这套体系不是一次性的突击检查，而是米其林餐厅每天都在做的日常。本篇我们就跟着这位主厨，从五维标准讲到监控告警、SLA和整改闭环，学会为数据平台搭建一套可度量的质量保障体系。

岗位关联

对 AI 从业者的价值：数据质量是 AI 决策的地基，脏数据会让模型和报表全面翻车。掌握这套框架，你就能从“跑数的人”成长为“数据可信度的守门人”。

目录
  1. 可视化演示
  2. 准确性校验
  3. 完整性保证
  4. 一致性对齐
  5. 及时性保障
  6. 唯一性控制
  7. 监控告警体系
  8. SLA与闭环
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

可视化展示数据质量六大维度评估、四类规则自动检测与监控告警SLA管理的核心流程，交互切换观察质量保障体系全貌。

本节配有交互动效（进入视口后自动加载，约 3KB）。

质量六维度评估 六维度雷达图展示准确性、完整性等质量指标 维度得分动态变化反映数据质量状态 Q = \u03a3(wi \u00d7 di) / n 点击切换查看规则检测

准确性校验

主厨每天早上都要验收“安格斯牛肋排”：先看产地证明，再称重量是否在标准区间，最后切开看纹理。如果挂羊头卖狗肉，后面再好的菜谱也白搭。数据准确性就是这个道理——它回答的是“这条记录的值是否真实反映了客观事实”。

落到数据表里，准确性规则表现为三类检查：范围检查（订单金额必须大于 0）、格式校验（日期必须符合 YYYY-MM-DD）、枚举值校验（性别只能是男、女或未知）。这些规则写清楚后，由检测任务逐条扫描数据，统计“合格记录”占比。

就像主厨在验收单上盖下“检验合格”章，只有准确率达到阈值的数据表，才有资格进入下游报表和模型。准确性是数据质量的第一道门，这道门守不住，后面所有环节都会跟着将错就错。

Accuracy=NpassNtotal\displaystyle \text{Accuracy} = \frac{N_{\text{pass}}}{N_{\text{total}}}
准确率 = 通过全部准确性规则的记录数 ÷ 记录总数。
  1. 分子的含义N_pass 表示这张表中通过所有准确性检查的记录数量，相当于验收时“完全合格的菜”。
    NpassN_{\text{pass}}
  2. 分母的含义N_total 表示被抽检或全量扫描的记录总数，是计算比例的基准盘。
    NtotalN_{\text{total}}
  3. 比值的意义当结果接近 1，说明数据基本真实可信；一旦低于阈值，就要追问是哪个环节引入了坏数据。
    Accuracy=NpassNtotal\displaystyle \text{Accuracy} = \frac{N_{\text{pass}}}{N_{\text{total}}}

完整性保证

服务员下单“招牌红烧肉”，后厨一翻备料单，酱油用完、五花肉缺斤少两，菜根本没法上桌。数据的完整性，就是“这道菜该有的料一样都不能少”。订单表必须要有订单号、用户 ID、商品 ID、金额、下单时间这些必填字段，任缺一项，这条记录就无法支撑后续分析。

完整性检测的第一步是定义必填字段清单，然后统计所有必填字段全部非空的记录数。完全记录占总记录的比重就是完整率。

后厨缺料可以紧急补货，数据缺字段则要回溯源系统补齐。完整性保证的关键在于“先立规矩再查验”，并且把缺失率的变化趋势纳入日常巡检，防止表结构变更后悄悄引入大范围空值。

Completeness=NcompleteNtotal\displaystyle \text{Completeness} = \frac{N_{\text{complete}}}{N_{\text{total}}}
完整率 = 关键字段全部有值的记录数 ÷ 记录总数。
  1. 完整的定义N_complete 统计的是每一行记录中，预定义必填字段都不为空的行数，缺一个字段都算“不完整”。
    NcompleteN_{\text{complete}}
  2. 分母的含义N_total 是当前数据表的全部记录数，它是判断缺量程度的参照系。
    NtotalN_{\text{total}}
  3. 比值的意义完整率越低，说明这张表越“营养不良”，下游做汇总时会悄悄漏掉大量业务事实。
    Completeness=NcompleteNtotal\displaystyle \text{Completeness} = \frac{N_{\text{complete}}}{N_{\text{total}}}

一致性对齐

同一道“招牌红烧肉”，总店是咸鲜口，分店却偏甜；顾客换家店吃，味道就对不上了。数据一致性讲的就是“同一件事，在每个地方必须是一个说法”。比如用户“张三”在 CRM 系统里是“张三”，到了订单库却变成“张 三”；又比如订单明细求和是 100 万，订单汇总表却是 99 万。

一致性检测通常通过三种方式实现：跨表比对（对账两张表的同名字段）、单位换算（一张表用“元”，另一张用“万元”）、汇总核对（明细汇总与总表一致）。设不一致记录数为 N_inconsistent，则一致性率可以这样表达。

中央厨房靠统一菜谱让各门店口味一致，数据平台则靠统一口径标准和定期交叉比对来消除“一物多码、一名多写”的混乱。一致性不是一次性对齐，而是每次表结构变更后都要重新校准的长期约定。

Consistency=1−NinconsistentNtotal\displaystyle \text{Consistency} = 1 - \frac{N_{\text{inconsistent}}}{N_{\text{total}}}
一致性率 = 1 − 与其他参照表冲突的记录占比。
  1. 不一致记录N_inconsistent 是本表与参照口径比对后产生冲突的记录数，冲突越多说明数据间“各说各话”越严重。
    NinconsistentN_{\text{inconsistent}}
  2. 减法的位置用 1 减去冲突占比，得到的是和谐一致的比例，这种方法让指标与直觉一致——越大越好。
    1−NinconsistentNtotal\displaystyle 1 - \frac{N_{\text{inconsistent}}}{N_{\text{total}}}
  3. 比值的意义当一致性率低于阈值，下游做关联分析时会产出互相矛盾的结论，必须优先整改。
    Consistency=1−NinconsistentNtotal\displaystyle \text{Consistency} = 1 - \frac{N_{\text{inconsistent}}}{N_{\text{total}}}

及时性保障

客人在等菜，菜做得再精致，迟到 40 分钟端上来，体验也已经崩塌。数据的及时性同理：一份每天早晨 8 点就要送达的运营报表，如果拖到 10 点才产出，决策就已经失去了意义。

及时性保障的核心指标是“数据就绪时间”与“SLA 承诺时间”的对比。平台会为每张核心表定义时间窗口，例如“T+1 早上 8 点前完成写入”，然后统计在窗口内按时就绪的数据批次。

厨房有“出菜窗口时间”，数据平台有“交付时间承诺”。一旦延迟，不仅要对客道歉，更要在监控面板上亮起超时标记，驱动调度团队优化资源，避免坏味道从“迟到”演变成“缺席”。

Timeliness=NontimeNbatch\displaystyle \text{Timeliness} = \frac{N_{\text{ontime}}}{N_{\text{batch}}}
及时率 = 按时到达就绪状态的数据批次数量 ÷ 总批次数。
  1. 按时批次N_ontime 是在时间窗口内完成写入并可供下游使用的批次数量，“可用”意味着数据和元数据都已就绪。
    NontimeN_{\text{ontime}}
  2. 总批次数N_batch 是调度周期内应交付的全部批次数，例如每天调度一次的订单任务，一个月就是 30 个批次。
    NbatchN_{\text{batch}}
  3. 比值的意义及时率低于 90% 就说明调度链路存在积压，需要检查上游抽取耗时、队列拥堵与资源竞争。
    Timeliness=NontimeNbatch\displaystyle \text{Timeliness} = \frac{N_{\text{ontime}}}{N_{\text{batch}}}

唯一性控制

同一筐菜被粗心的仓管记了两次账，月底一盘点，库存怎么都对不上。数据表里的“重复记录”就是这么隐蔽的麻烦：订单表的主键“订单 ID”本该唯一，但因为重复抽取或 join 扇出，同一笔订单出现了两行，汇总金额瞬间虚高。

唯一性检测通常对主键字段做分组统计，找出出现次数大于 1 的记录，并计算重复记录占比。设重复记录数为 N_dup，则唯一率可以表示为：

给每筐菜贴一张唯一的标签，账本就不会打架；给每条数据建立可靠的主键和去重策略，指标才不会虚胖。唯一性控制表面上是在“消重”，实际上是在维护整个数据资产的记账底账。

Uniqueness=1−NdupNtotal\displaystyle \text{Uniqueness} = 1 - \frac{N_{\text{dup}}}{N_{\text{total}}}
唯一率 = 1 − 重复记录数 ÷ 记录总数。
  1. 重复记录数N_dup 是通过主键分组后出现次数超过一次的行数，它直接反映“一物多记”的严重程度。
    NdupN_{\text{dup}}
  2. 减法的意义用 1 减去重复占比，得到的是去重后真实唯一的比例，数值越接近 1 越健康。
    1−NdupNtotal\displaystyle 1 - \frac{N_{\text{dup}}}{N_{\text{total}}}
  3. 比值的意义唯一率骤降通常意味着抽取任务重复执行或关联表 fan-out，需要立刻排查调度逻辑。
    Uniqueness=1−NdupNtotal\displaystyle \text{Uniqueness} = 1 - \frac{N_{\text{dup}}}{N_{\text{total}}}

监控告警体系

厨房里装了烟雾报警器和监控探头，但最怕的就是“狼来了”——报警器三天两头误报，厨师们渐渐麻木，真出事时反而没人当回事。数据平台的监控告警体系也是这样：不仅要全天候设防，还要让每一条告警都精准、有分量。

监控告警由三部分构成：质量看板（实时展示各表各维度的健康分）、告警分级（P0 核心链路故障到 P3 低优提示）、值班响应（告警后自动拉群通知并指派负责人）。其中，衡量告警系统本身好坏的关键指标是精确率：

报警器要调灵敏度，告警规则也要反复校准。监控告警的终极目标不是“响个不停”，而是让每次响声都值得起身处理，把值班人员的注意力留给真正会烧掉厨房的问题。

Precision=TPTP+FP\displaystyle \text{Precision} = \frac{TP}{TP + FP}
告警精确率 = 真实问题告警数 ÷（真实问题告警数 + 误报告警数）。
  1. TP 真实告警TP 是“确实存在质量问题”且被正确抓出来的告警数，相当于真的着了火报警器响了。
    TPTP
  2. FP 误报告警FP 是“其实没问题”却报了警的次数，例如规则阈值设置不当导致的频繁误报。
    FPFP
  3. 精确率的权衡精确率越高，说明值班人越愿意相信告警；但过度收紧条件又会提高漏报风险，需要与召回率平衡。
    Precision=TPTP+FP\displaystyle \text{Precision} = \frac{TP}{TP + FP}

SLA与闭环

餐厅门口写着“30 分钟上齐所有菜品，超时免单”，这就是对顾客的服务承诺。数据团队的 SLA（服务等级协议）同样是一份契约：约定核心数据的交付时间、可用时长和质量最低分。一旦违约，要有明确的响应时限和补救措施。

但 SLA 只是承诺，真正让质量治理转动起来的是整改闭环。发现问题后，不能只发一封告警邮件就结束，必须走完“发现 → 派单 → 修复 → 验证 → 沉淀”的完整流程。衡量闭环管理水平的核心指标是闭环率：

米其林餐厅每季度都要复盘做菜事故，把教训写进新菜谱；数据团队也要把每一次质量事故的根因与解法沉淀为知识库。当 SLA 定义了下限、闭环驱动了自我进化，数据质量的治理才算真正形成了可以持续迭代的体系。

Closure=NfixedNissue\displaystyle \text{Closure} = \frac{N_{\text{fixed}}}{N_{\text{issue}}}
闭环率 = 已完成修复并通过验证的问题数量 ÷ 已发现的问题总数。
  1. 已发现问题N_issue 包括监控告警、人工上报和例行巡检发现的全部质量问题，它是治理工作的总任务池。
    NissueN_{\text{issue}}
  2. 已修复问题N_fixed 只统计那些真正修复完成并通过复检的问题，草草补个值不算修复。
    NfixedN_{\text{fixed}}
  3. 闭环的意义闭环率长期低于 80%，说明团队“只体检不治病”，质量问题会像滚雪球一样堆积成技术债。
    Closure=NfixedNissue\displaystyle \text{Closure} = \frac{N_{\text{fixed}}}{N_{\text{issue}}}

AI 应用场景

电商订单数据质量监控台

阶段：数据接入与特征工程前的质量把关

解决的问题：电商大促期间订单表频繁出现金额为负、用户 ID 为空、上下行重复等问题，传统方式是业务方投诉后人工查数，效率低且难追溯。利用数据质量框架，平台为订单表配置准确性、完整性、唯一性规则，每分钟自动巡检并生成质量分。

具体案例：某电商平台在大促期间订单量暴涨 10 倍，质量监控台在凌晨 2 点捕获到“订单金额超出正常区间”的告警，值班人员顺藤摸瓜定位到新接入的优惠券系统把金额单位从“元”传成了“分”，在影响核心报表前完成拦截。

数据服务 SLA 保障

阶段：数据服务化与下游消费环节

解决的问题：数据团队经常被业务方质疑“报表怎么又没准时出”，缺乏量化承诺与违约机制。通过 SLA 管理平台，将核心数据表的交付时间写成契约，并自动统计准时率。

具体案例：某银行的数据团队与风控部门签订 SLA，承诺每日 7 点前完成风险指标计算。某次上游源系统故障导致批处理延迟，SLA 监控自动发出 P0 告警并同步启动重试机制，最终 7 点 20 分钟补齐数据，事后按约定完成违约赔偿流程和责任复盘。

数据质量整改闭环工单

阶段：数据运维与质量持续改进

解决的问题：质量问题被发现后常常无人认领、修完不验证，导致同一问题反复出现。通过建立整改闭环机制，将每次质量问题转为工单，明确责任人和修复时限。

具体案例：某互联网公司发现用户画像表的一致性率跌至 82%，系统自动创建 P1 工单并指派给对应数仓团队。团队定位到两个业务系统对“用户等级”的编码口径不一致，修复后执行复检，一致性率回升至 97%，相关经验被写入质量规则库，后续同类问题自动拦截。

Python 演示

python92 行
class DataQualityChecker:    def __init__(self, rows, thresholds=None):        self.rows = rows        self.total_rows = len(rows)        self.field_names = list(rows[0].keys()) if rows else []        self.quality_scores = {}        self.failed_rules = []        default = {'accuracy': 0.95, 'completeness': 0.98, 'consistency': 0.95,                   'timeliness': 0.90, 'uniqueness': 0.98}        self.threshold_map = thresholds or default     def check_completeness(self):        filled = 0        for row in self.rows:            if all(row.get(f) not in (None, '', 'NULL') for f in self.field_names):                filled += 1        self.quality_scores['completeness'] = filled / self.total_rows if self.total_rows else 1.0        return self.quality_scores['completeness']     def check_uniqueness(self):        seen = set()        dup = 0        for row in self.rows:            key = tuple(row.get(f, '') for f in self.field_names)            if key in seen:                dup += 1            else:                seen.add(key)        self.quality_scores['uniqueness'] = 1 - dup / self.total_rows if self.total_rows else 1.0        return self.quality_scores['uniqueness']     def check_accuracy(self):        ok = 0        for row in self.rows:            price = row.get('price')            try:                price = float(price)                if 0 < price < 100000:                    ok += 1            except (TypeError, ValueError):                pass        self.quality_scores['accuracy'] = ok / self.total_rows if self.total_rows else 1.0        return self.quality_scores['accuracy']     def check_consistency(self):        consistent = 0        for row in self.rows:            unit = row.get('unit')            amount = row.get('amount')            if unit == 'kg' and isinstance(amount, (int, float)):                consistent += 1        self.quality_scores['consistency'] = consistent / self.total_rows if self.total_rows else 1.0        return self.quality_scores['consistency']     def check_timeliness(self):        on_time = 0        for row in self.rows:            delay = row.get('delay_hours')            if delay is not None and delay < 2:                on_time += 1        self.quality_scores['timeliness'] = on_time / self.total_rows if self.total_rows else 1.0        return self.quality_scores['timeliness']     def run_all_checks(self):        self.check_completeness()        self.check_uniqueness()        self.check_accuracy()        self.check_consistency()        self.check_timeliness()        report = {}        for dim, score in self.quality_scores.items():            threshold = self.threshold_map.get(dim, 0)            passed = score >= threshold            report[dim] = {'score': round(score, 4), 'threshold': threshold, 'passed': passed}            if not passed:                self.failed_rules.append(dim)        return report  if __name__ == '__main__':    orders = [        {'order_id': 1, 'amount': 199, 'unit': 'kg', 'delay_hours': 0.5},        {'order_id': 2, 'amount': 350, 'unit': 'kg', 'delay_hours': 1.2},        {'order_id': 3, 'amount': -5, 'unit': 'kg', 'delay_hours': 3.0},        {'order_id': 4, 'amount': None, 'unit': 'g', 'delay_hours': 0.8},        {'order_id': 5, 'amount': 88, 'unit': 'kg', 'delay_hours': 1.5},    ]    checker = DataQualityChecker(orders)    result = checker.run_all_checks()    for dim, info in result.items():        flag = 'PASS' if info['passed'] else 'FAIL'        print('{}: score={}, threshold={}, {}'.format(dim, info['score'], info['threshold'], flag))
目的：用简单的 Python 类实现数据质量五维检测，输出每张表的健康评分和是否达标。
  1. self.threshold_map = thresholds or default为每个维度设定及格线，相当于后厨的“质量标准手册”。
  2. def check_completeness(self)统计每行记录的所有字段是否都非空，缺任何一个字段都算不完整。
  3. key = tuple(row.get(f, '') for f in self.field_names)把所有字段拼成一个唯一指纹，用来发现重复记录。
  4. if 0 < price < 100000用范围规则做准确性检查，金额超过正常区间就判定为脏数据。
  5. report[dim] = {'score': round(score, 4), 'threshold': threshold, 'passed': passed}生成质量报告，每项都给出分值、阈值和是否通过，方便后续驱动告警。

常见误区

误区我觉得每天跑出几千万行数据，说明数仓很健康，质量问题自然就少了。

正解数据量大和数据质量高是两回事。就像餐厅每天采购的食材很多，但里面混着过期牛排和空壳鸡蛋，再多也没用。质量检测关注的是“每一行是否可信”，而不是“有多少行”。

为何常见：新手常把关注点放在任务是否跑完、数据量是否增长这些显性指标上，忽略了脏数据的隐形危害。

误区我把五维规则全部配置了一遍，也跑出了 98% 的质量分，以后就不用再管了。

正解数据源在变、口径在变、表结构也在变，今天的健康表明天就可能因为一次 schema 变更而崩掉。质量检测必须像厨房的例行晨检一样，按调度持续巡检，并把检测结果纳入监控看板。

为何常见：因为跑一次检测看到分数不错会产生“达标幻觉”，忽略了质量是动态变化的，而不是静态属性。

误区只要把所有规则阈值都调得很严格，告警刷得越多，团队就越重视质量。

正解告警过多会造成“狼来了”效应。比如把阈值设成 100% 准确，系统每天误报 200 次，值班人直接麻木，真正的 P0 故障反而被淹没。要用精确率（Precision）衡量告警的有效性，宁可少而准，不要多而滥。

为何常见：初学者容易把“响得勤”理解为“管得严”，忽略了告警系统本身也需要量化评估。

误区发现质量问题后，发一封邮件通知业务方就算完成工作了。

正解检测只是“体检”，闭环才是“治病”。一个质量工单必须走到修复、复检和知识沉淀才算结束。如果只报不管，闭环率长期偏低，同样的错误会换着花样反复出现。

为何常见：因为修复问题需要跨团队协作和长期跟进，比跑一个检测脚本麻烦得多，所以容易被跳过。

误区准确率和一致性都是“数据对不对”，差不多一个意思，没必要区分。

正解准确性是“数据与真实世界吻合”，比如金额是不是正确的 100 元；一致性是“多个系统对同一件事的说法统一”，比如两套系统里金额是否都记成 100 元。一个数据可能既准确又不一致，也可能一致但都不准确，两者检测的手段完全不同。

为何常见：两者日常口语里经常混用，导致配置规则时用错方向，比如用一致性比对去查本来就该不同的字段。

面试题

Q1. 同一客户在 CRM 系统中叫“张三”，在订单库中叫“张 三”，这属于哪个数据质量维度的问题？

单选题 · easy

  • A.准确性问题
  • B.一致性问题← 正确答案
  • C.完整性问题
  • D.及时性问题

答案：B。这是典型的“同一实体在不同系统里说法不一致”，归为一致性问题。准确性关注是否真实，完整性关注是否缺失，及时性关注是否准时，都不符合本题场景。

Q2. 完整性检测主要考察数据的哪个方面？

单选题 · easy

  • A.数据是否包含空值和缺失← 正确答案
  • B.数据是否准时交付
  • C.数据是否重复出现
  • D.数据格式是否合法

答案：A。完整性衡量的是“该有的字段有没有”。空值和缺失记录是完整性下降的典型表现。准时交付是及时性，重复记录是唯一性，格式合法是准确性。

Q3. 一条订单记录的金额为 -50 元，最可能触发了哪种准确性规则？

单选题 · easy

  • A.范围检查规则← 正确答案
  • B.主键唯一规则
  • C.跨表汇总规则
  • D.时间窗口规则

答案：A。金额为负超出正常取值范围，属于范围检查规则的管辖范围。主键唯一规则管重复，跨表汇总规则管口径，时间窗口规则管时效。

Q4. SLA 中的“数据就绪时间”指标主要衡量什么？

单选题 · mid

  • A.数据量是否足够大
  • B.数据是否按时交付← 正确答案
  • C.数据存储是否安全
  • D.数据成本是否超标

答案：B。SLA 约定的数据就绪时间，就是承诺“什么时刻数据可用”。它直接评估及时性维度，与数据量、安全性、成本无关。

Q5. 告警精确率（Precision）偏低，最可能说明什么问题？

单选题 · mid

  • A.告警全部都不该发生
  • B.真实问题全部被漏掉
  • C.大量告警其实是误报← 正确答案
  • D.告警通知速度太慢

答案：C。Precision = TP/(TP+FP)，精确率低意味着 FP（误报）占比高，也就是“狼来了”太多。漏报由召回率反映，与速度无关。

Q6. 某张订单表每天全量覆盖写入，要定位“重复下单”导致汇总虚高的问题，最合适的做法是？

单选题 · hard

  • A.对订单 ID 做唯一性校验← 正确答案
  • B.检查下单时间的格式
  • C.核对两个系统的编码
  • D.延长调度重试等待时间

答案：A。重复下单本质是同一订单出现多行，唯一性校验按主键分组统计重复数可直接定位。格式问题归准确性，系统编码差异归一致性，重试时间归及时性。

Q7. 为什么质量工单修复后必须执行“验证复检”？

单选题 · hard

  • A.为了增加检测任务运行次数
  • B.确认修复达标且没引入新问题← 正确答案
  • C.为了让平台产生更多告警
  • D.为了替换掉原有数据源

答案：B。复检是闭环的关键一环，防止“假修复”和“修 A 坏 B”。增加检测次数、制造告警、换数据源都不是复检的目的。

Q8. 数据质量监控告警分级时，通常需要考虑哪些因素？

多选题 · mid

  • A.影响下游报表范围← 正确答案
  • B.告警邮件的措辞
  • C.是否涉及核心 KPI← 正确答案
  • D.值班人员的星座

答案：AC。影响范围越大、越靠近核心 KPI，告警级别就越高。邮件措辞只是展示形式，星座更是无关因素。

Q9. 以下哪些方法属于完整性校验的常见手段？

多选题 · mid

  • A.非空检测← 正确答案
  • B.填充率统计← 正确答案
  • C.重复记录计数
  • D.跨表汇总核对

答案：AB。非空检测和填充率统计直接刻画“缺了多少”。重复记录计数属于唯一性校验，跨表汇总核对属于一致性校验。

Q10. 关于数据质量整改闭环机制，下列说法正确的有？

多选题 · hard

  • A.问题修复后无需复核
  • B.需要记录根本原因← 正确答案
  • C.修复后应做回归验证← 正确答案
  • D.质量问题无需沉淀归档

答案：BC。闭环强调“发现→派单→修复→验证→沉淀”。记录根因和回归验证是防止问题复发的基础；不复核、不归档则会让治理流于形式。