## 1、数据治理规划和实施服务（3.2.6.1）

数据治理在本项目中要达成两重目标。一重是把天地奔牛的数据管理能力提升到数据管理能力成熟度（Data Management Capability Maturity Assessment Model，DCMM）三级所要求的水平：九大能力域的管理过程被定义、被执行，执行留有可供检查的记录。另一重是为四类高质量数据集的加工生产提供口径、规则与证据，使每一个数据子集都能回答它从哪里来、按什么标准加工、由谁批准发布。两重目标共用一套制度、一个平台与一套记录（b1218）。

建设范围分三部分。治理体系部分，覆盖九大能力域的现状诊断、规划与制度建设，输出三十七项规划成果（b1219—b1223）。治理平台部分，建设承载元数据、数据标准、质量规则、安全分级、资产目录与指标卡的管控平台，九项治理内容在平台上落地（b1224、b1336）。治理实施部分，以十七套外围应用系统为数据来源、以九个业务域为落地对象，把标准、分级与规则加载到数据汇聚与加工的各个环节上运行，同步构建决策数据指标体系（b1225、b1226）。

运行组织按三层设置。决策层是数据治理委员会，决议数据战略目标、跨部门口径争议、资源投入与考核结果。管理层是数据管理办公室与按能力域设置的九个数据治理工作组，办公室负责规划落地、制度起草、流程运行与指标采集，工作组负责本域规则的细化与会签。执行层是各业务域的数据专责、源系统的系统管理岗与我方项目组。三层之间有一条固定界线：制度与口径的审批权在甲方，规则起草、平台实现与数据加工由我方承办，业务口径由业务归口部门会签确认。

交付责任按主体分清。我方交付现状诊断报告与高质量数据集验证场景数据需求清单两份评估成果、三十七项规划成果、三份配套细则、十份标注规范、四类标准验证成果，以及一套治理平台及其运行记录。甲方承担治理组织的正式发文、业务口径的会签、源系统的授权开放与贯标评估的申报。贯标结论由具备资质的认定机构作出。治理部分的验收以三件事为准：成果物齐备、平台功能可用、执行记录可被抽查核对。

### 1.1 治理目标与建设范围

#### 1.1.1 贯标与数据集建设对治理的要求不同

招标文件把治理目标写成一句话：以通过 DCMM 三级认证为目标，以满足 11 个智能化应用场景的高质量数据集建设为业务导向，构建全域数据治理体系，配套落地数据治理平台（b1218）。这句话里有两个目标。贯标认证关心的是能力域有没有被规范地管起来、管的过程有没有记录可查；数据集建设关心的是某一张图纸、某一个热处理炉次、某一段振动波形今天能不能被稳定地取到、对齐、标注并交付。

两个目标的工作量落点不同。贯标的落点在制度、流程与组织，数据集建设的落点在字段、口径与可用率。本项目的处理方式是以后者为主线组织工作，把前者所需的制度与执行记录作为主线工作的自然产物：每一条标准发布时同时留下评审记录，每一次质量稽核运行时同时留下稽核台账，每一次数据服务授权时同时留下审批留痕。这样做的理由很直接——为贯标单独攒一套文档，文档与现场脱节，评审时问到执行记录就露底；而把记录长在业务动作上，记录是跑出来的，不是补出来的。

本包承担的是数据加工生产服务。治理体系的建设、治理平台的落地、治理文档的交付与数据治理实施均在本包范围内（b1224、b1226）。11 个智能化应用场景所需的数据集与场景验证服务由本包提供，场景本身的建设由甲方另行安排。

#### 1.1.2 治理在七项服务中的落点

招标文件 3.2.1 服务采购清单列明七项服务（b0803、b0804r01）。七项之间不是并列的七块工程，而是一条生产线上的不同工位：第 1 项把数据取进来，第 2 项提供加工手段，第 5 项是加工实施的主体并把治理作为横向管控层贯穿，第 3 项把成品挂出去运营，第 4 项把软硬件装起来，第 6、7 两项由具备资质的机构从外部核验。治理不是其中的第八项，而是落在每一项上的约束与留痕要求。表 1-1 逐项给出治理在该项服务中的具体落点。

表 1-1　治理在七项服务中的落点

| 序号 | 服务名称 | 服务内容要点 | 治理在该项中的落点 | 详述位置 | 单元 |
|---|---|---|---|---|---|
| 1 | 数据资源建设服务 | 17 套外围应用系统的多源异构集成采集；多格式多模态数据接入与离线非结构化数据解析录入 | 接入前完成元数据登记、数据元映射与安全分级判定，三项齐备方可汇聚；离线解析件按来源方式登记，与自动采集分开统计 | 「数据资源采集接入」；解析方法见「数据加工生产（一）」 | b0804r02 |
| 2 | 数据集加工生产专项智能工具链建设服务 | 9 类 25 个工具链，不限许可节点数 | 工具链的输入输出字段引用数据元标准，运行日志回写字段级血缘；工具替换不改变治理侧的字段定义与分级 | 「专项智能工具链总述」及其三个分节 | b0804r03 |
| 3 | 数据集运营服务管理平台建设服务 | 16 个功能模块，不限许可节点数 | 资源目录、权属登记与安全级别以治理侧为单一来源，运营侧按此展示与校验，不另建一套台账 | 「数据集运营平台」 | b0804r04 |
| 4 | 系统集成服务 | 通用服务器、接入连接器、服务密码机国密调试、硬件网络适配 | 国密调用与权限策略按安全分级标准配置，集成测试与调试记录纳入贯标证据包 | 「系统集成方案」；硬件选型见「硬件选型与配置」 | b0804r05 |
| 5 | 数据集加工生产实施服务 | 含数据治理规划和实施服务在内的全流程实施，另含技术标准验证、专家库、标注规范、软建设、内部管理制度、安全合规、知识产权七项配套 | 治理规划与实施是本项的第 1 条子要求，由本节与两个治理子节承载；技术标准验证与标注规范的依据同为治理侧标准体系，在第 2 章与第 3 章论述 | 加工主线见「四大数据集加工生产总述」；专家库、软建设与知识产权见「技术创新与机制创新」；内部管理制度见服务方案「项目管理措施」 | b0804r06 |
| 6 | 信息安全风险评估服务 | 等级保护测评与商用密码应用安全性评估 | 安全分级标准与权限策略作为测评输入，测评发现项回流为数据安全域的整改项并进台账 | 「安全方案」第三方测评安排一节 | b0804r07 |
| 7 | 数据集质量测评服务 | 首轮全量评测、缺陷整改复测、盖章评测报告与数据质量档案 | 评测指标与治理侧质量规则库同源，评测的错样归因结论回流为规则修订线索 | 服务方案「数据集质量评测方案」 | b0804r08 |

清单第 5 项列了八条子要求。第 1 条数据治理规划和实施服务是本节与两个治理子节的主体内容。第 2 条技术标准验证与第 4 条数据标注规范，其依据都是治理侧的标准体系，因此与治理一并论述，分别在第 2 章与第 3 章。其余五条——数据标准专家库、约 30＋项软建设配套措施、不少于 7 份项目内部管理制度、安全合规核查与去标识化、知识产权指标——按上表所列位置论述（b0804r06）。

#### 1.1.3 运行组织与审批权限

治理动作能不能落地，取决于每一件事有没有确定的起草方、会签方与批准方。本项目把这三者在项目启动阶段一次定清，写入数据治理组织架构与各项管理办法，不留「由相关部门协商确定」这类无主语的条款。

权限按三级分配。单域规则的发布、工作包排期、一般偏差的处理在数据管理办公室一级；跨域口径的裁定、安全分级中最高两级数据的授权、资源投入与考核结果在数据治理委员会一级；本域数据的口径确认、权属归属与对外共享范围在业务归口部门一级。三级之上有一条上报规则：办公室协调不成的事项上报委员会，委员会按季度例会或专题会裁定，裁定结论形成决议并更新到对应的制度条款中。

我方在这套组织里的位置是承办方。规则草案、平台配置、数据加工与证据归集由我方承担；审批、会签与口径确认由甲方相应层级作出。在甲方治理组织正式发文之前，各项成果物只出送审稿，以项目联合工作组形式临时议事，决议在组织设立后追认，避免因组织未定而使前期工作全部停摆。

表 1-2　治理事项的起草、会签、批准与留痕

| 治理事项 | 起草／承办 | 会签 | 批准 | 平台留痕 |
|---|---|---|---|---|
| 数据战略与实施路线图 | 我方项目组 | 九个工作组 | 数据治理委员会 | 战略任务与度量指标配置、评估结论 |
| 顶层管理制度与各域管理办法 | 我方项目组 | 对口工作组、业务归口部门 | 数据治理委员会 | 制度库条目、发布与修订记录 |
| 业务术语标准、数据元标准 | 我方项目组与数据管理办公室标准岗 | 对口工作组 | 数据管理办公室 | 标准版本、下发回执 |
| 参考数据码表 | 业务归口部门提出，标准岗整理 | 对口工作组 | 数据管理办公室 | 码表版本、变更记录 |
| 数据质量校验规则与阈值 | 质量岗与业务数据专责 | 对口工作组 | 数据管理办公室 | 规则上线记录、稽核台账 |
| 数据安全分级结论 | 业务归口部门判定，安全岗复核 | — | 数据管理办公室备案；争议由委员会裁定 | 分级审批单、标签变更记录 |
| L4、L5 数据的访问授权 | 使用方申请 | 数据责任部门 | 数据治理委员会 | 授权记录、访问审计日志 |
| 资产目录条目与权属登记 | 元数据与资产岗 | 业务归口部门 | 数据管理办公室 | 目录上下架记录、权属确认单 |
| 指标卡与计算口径 | 我方项目组 | 业务归口部门逐项会签 | 数据管理办公室 | 指标卡会签记录、口径变更记录 |
| 数据集发布与对外共享范围 | 我方项目组 | 数据责任部门 | 对外开放由委员会批准 | 服务授权记录、挂牌记录 |

#### 1.1.4 治理口径的单一来源

同一个口径在两处定义，迟早会出现两个值。治理涉及的口径大多跨环节使用：一个安全分级结论既决定平台上的标签与访问权限，也决定数据集发布时的脱敏要求；一份质量规则既是业务数据稽核的判据，也是数据集质检门控的来源。这类口径若由各自使用的环节分别写一遍，差异往往要等到某次统计对不上才暴露出来，那时已经波及按旧口径产出的成果。本项目的做法是每一类口径只在一处定义，其余各处引用；凡需要修改口径的，一律回到定义处修改，不在使用处就地调整。

表 1-3 所列十类，是本项目中跨环节使用最频繁、也最容易各写一套的口径。它们的归属不按文档的先后或篇幅划分，而按规则责任：现状评估结论、组织制度、数据架构与资产的口径归两份数据治理规划，评测指标归数据集质量评测方案，分级标签的技术管控与测评归安全方案，目录与确权的功能实现归数据集运营平台，标注的实施方法归加工生产与工具链，各类报告模板归附录佐证卷——谁负责制定这件事的规则，谁所在的成果就是它的定义处。

读表时，中间一列是判据，指明该口径唯一可被修改的地方；右侧一列是用法，说明本节对它的引用方式，只作引用不另立口径。其中三十七项治理文档清单与分级标签两行最为关键，它们被引用的环节最多，也最容易在各节分头细化时走样。据此可以给出一致性的控制口径：首次交付前对表内十类口径逐项核对一次定义处与各引用处的取值，作为基线；此后随制度与成果的修订，逐步做到口径一经变更即触发各引用处的同步核对；若核对中发现同一口径出现两个取值，以定义处为准，使用处当次作废并回溯更新受影响的成果，变更过程进制度修订记录留痕。

表 1-3　治理口径的单一来源与引用关系

| 治理事项 | 口径的定义处 | 其他环节的用法 |
|---|---|---|
| 现状评估结论、数据战略、治理组织与制度、数据架构、数据资产 | 数据治理规划（一） | 本节引用其结论与交付时点，作为路径安排的依据 |
| 数据标准、数据质量、数据安全、数据生存周期、数据应用流通五域的域内设计 | 数据治理规划（二） | 本节引用域间接口与交付时点 |
| 三十七项治理文档的清单、章节骨架与提交节点 | 数据治理规划（二）治理规划文档交付清单一节 | 本节按合计口径与三阶段节点引用，并在第 4 章给出其与平台配置、运行记录、数据集交付的对应 |
| 九业务域与九项治理内容的落地矩阵、实施路径与里程碑 | 数据治理规划（二）实施路径一节 | 本节引用三阶段划分与阶段门禁 |
| 业务数据的质量规则与稽核 | 数据治理规划（二）数据质量一节 | 本节给出与数据集质检的接口口径 |
| 四类数据集的质量评测指标与方法 | 服务方案「数据集质量评测方案」 | 本节给出评测结论向治理质量规则的回流关系 |
| 分级标签的技术管控实现、国密与等保测评 | 「安全方案」 | 本节给出分级口径作为其输入的说明 |
| 数据集目录、确权、挂牌、交易与审计功能 | 「数据集运营平台」 | 本节给出治理资产目录与运营目录的接口 |
| 标注实施方法与标注工具链 | 「数据加工生产（二）」「工具链二」 | 本节给出标注规范的体系构成与评审发布 |
| 数据卡、质检报告、验证报告模板 | 附录佐证卷 | 各节按模板出具，不另拟格式 |

#### 1.1.5 治理在项目生产逻辑中的位置

招标文件把本项目的生产逻辑写得很清楚：以数据治理为横向贯穿管控层，以知识本体与知识库为统一知识底座，以采集、预处理、标注、合成、增强、质检、验证为纵向生产链路，并以血缘追溯驱动定向回流（b1215）。治理不是生产链路上的某一个环节，而是贯穿各环节的约束与留痕机制。图 1-1 按这一关系给出治理与生产链路、三个平台之间的位置与数据流向。

#### 图 1-1　治理作为横向管控层在项目中的位置

<svg viewBox="0 0 820 400" xmlns="http://www.w3.org/2000/svg"
     font-family="Noto Sans CJK SC, PingFang SC, SimHei, sans-serif" font-size="13">
  <defs><marker id="t4-a" markerWidth="9" markerHeight="9" refX="8" refY="4.5" orient="auto">
    <path d="M0 0 L9 4.5 L0 9 z" fill="#334155"/></marker></defs>

  <rect x="14" y="16" width="792" height="46" rx="6" fill="#f8fafc" stroke="#334155"/>
  <text x="26" y="36" font-size="12.5">源系统侧（甲方及原厂维护）　17 个外围应用系统 · 纸质与离线档案 · 设备测点</text>
  <text x="26" y="54" font-size="12">责任：按已授权范围开放只读接口与数据，处置源头数据错误</text>

  <path d="M410 62 V92" stroke="#334155" stroke-width="1.5" marker-end="url(#t4-a)" fill="none"/>
  <text x="418" y="82" font-size="12">只读取数</text>

  <rect x="14" y="96" width="560" height="140" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="26" y="118" font-size="13">纵向生产链路（数据集加工生产平台）</text>
  <rect x="26" y="130" width="74" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="63" y="155" text-anchor="middle" font-size="12">采集</text>
  <rect x="104" y="130" width="74" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="141" y="155" text-anchor="middle" font-size="12">预处理</text>
  <rect x="182" y="130" width="74" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="219" y="155" text-anchor="middle" font-size="12">标注</text>
  <rect x="260" y="130" width="74" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="297" y="167.6" text-anchor="middle" font-size="12">合成</text>
  <rect x="338" y="130" width="74" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="375" y="155" text-anchor="middle" font-size="12">增强</text>
  <rect x="416" y="130" width="70" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="451" y="155" text-anchor="middle" font-size="12">质检</text>
  <rect x="490" y="130" width="70" height="40" rx="4" fill="#ffffff" stroke="#334155"/>
  <text x="525" y="155" text-anchor="middle" font-size="12">验证</text>
  <path d="M100 150 H102" stroke="#334155" marker-end="url(#t4-a)" fill="none"/>
  <path d="M178 150 H180" stroke="#334155" marker-end="url(#t4-a)" fill="none"/>
  <path d="M256 150 H258" stroke="#334155" marker-end="url(#t4-a)" fill="none"/>
  <path d="M334 150 H336" stroke="#334155" marker-end="url(#t4-a)" fill="none"/>
  <path d="M412 150 H414" stroke="#334155" marker-end="url(#t4-a)" fill="none"/>
  <path d="M486 150 H488" stroke="#334155" marker-end="url(#t4-a)" fill="none"/>
  <rect x="26" y="182" width="534" height="42" rx="4" fill="#f1f5f9" stroke="#64748b" stroke-dasharray="4 3"/>
  <text x="293" y="200" text-anchor="middle" font-size="12">知识本体与知识库（统一知识底座，术语与字段定义引用治理侧标准）</text>
  <text x="293" y="218" text-anchor="middle" font-size="12">错样归因沿血缘定向回流至上游环节，重新质检与验证</text>

  <rect x="586" y="96" width="220" height="140" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="696" y="118" text-anchor="middle" font-size="13">数据集运营服务管理平台</text>
  <text x="696" y="140" text-anchor="middle" font-size="12">目录 · 元数据 · 版本 · 权限</text>
  <text x="696" y="160" text-anchor="middle" font-size="12">登记注册 · 确权 · 挂牌</text>
  <text x="696" y="180" text-anchor="middle" font-size="12">服务与对外接口 · 全流程审计</text>
  <text x="696" y="208" text-anchor="middle" font-size="12">共 16 个功能模块</text>
  <text x="696" y="226" text-anchor="middle" font-size="12">（b0804r04）</text>
  <path d="M560 160 H582" stroke="#334155" stroke-width="1.5" marker-end="url(#t4-a)" fill="none"/>
  <text x="294.2" y="152" text-anchor="middle" font-size="11.5">成品</text>

  <rect x="14" y="268" width="792" height="96" rx="6" fill="#eef2f7" stroke="#334155" stroke-width="1.6"/>
  <text x="26" y="290" font-size="13">横向贯穿管控层：数据治理（治理平台承载）</text>
  <text x="26" y="312" font-size="12">九大能力域：数据战略 · 数据治理 · 数据架构 · 数据资产 · 数据标准 · 数据质量 · 数据安全 · 数据生存周期 · 数据应用流通</text>
  <text x="26" y="334" font-size="12">下行约束：数据元与值域 · 分级标签 · 质量规则 · 权限与审批策略　｜　上行采集：血缘 · 质量评分 · 操作留痕 · 使用计量</text>
  <text x="26" y="356" font-size="12">覆盖九个业务域：研发设计 · 生产制造 · 质量管理 · 仓储物流 · 设备管理 · 采购管理 · 营销管理 · 财务管理 · 人力资源</text>
  <path d="M200 268 V240" stroke="#334155" stroke-width="1.3" marker-end="url(#t4-a)" fill="none"/>
  <text x="208" y="258" font-size="11.5">标准与规则下行</text>
  <path d="M330 240 V266" stroke="#334155" stroke-width="1.3" stroke-dasharray="4 3" marker-end="url(#t4-a)" fill="none"/>
  <text x="338" y="258" font-size="11.5">血缘与质量上行</text>
  <path d="M660 268 V240" stroke="#334155" stroke-width="1.3" marker-end="url(#t4-a)" fill="none"/>
  <text x="668" y="258" font-size="11.5">资产与权属口径</text>
</svg>

图 1-1　治理作为横向管控层在项目中的位置。数据来源：招标文件第五章 3.2.6 生产逻辑表述（b1215）、3.2.1 服务采购清单第 1、3 项（b0804r02、b0804r04）、3.2.6.1.2 实施要求（b1336）。

### 1.2 全域数据治理成熟度评估与 DCMM 三级达成路径

#### 1.2.1 三级的判据是执行记录，不是文档数量

招标文件要求对标 DCMM 三级成熟度要求开展全域成熟度评估，形成三级现状诊断报告，明确短板与优化路径（b1219、b1220）。三级在 GB/T 36073—2018《数据管理能力成熟度评估模型》中的表述是稳健级：管理过程已被定义并形成文件，相关人员按定义的过程执行，过程的执行留有记录并可被检查。三个条件里，前两个靠编制与发布，第三个靠时间。

这一点决定了本项目贯标工作的排法。如果把制度集中在项目后期发布，发布之日距评审之日只有数月，评审时能提交的执行记录就只有几个批次，定级会被核减。因此制度与标准的发布时点在规划中被刻意提前，流程优先上线以积累记录——这与「数据治理规划（一）」把制度发布过晚列为贯标风险、以及「数据治理规划（二）」的实施路径把标准与分级排进第一阶段，是同一条考虑。两处的时点安排以本节表 1-4 的路径为准。

这里需要把「二级与三级的差别」说透，因为它决定了本项目治理工作的投入分布。二级（受管理级）要求过程在局部被管理、有人负责、有基本记录；三级（稳健级）增加的是三条：过程被定义并形成文件、**相关人员按定义的过程执行**、**执行留有记录并可被检查**。

差别不在文档的厚度，在于能否证明「不是写了一套、做了另一套」。评估师现场取证的典型动作是：随机抽一个业务域、抽一个时间段，要求调出该时段内这一过程的全部执行记录，核对记录中的责任人、时点、结论是否与制度规定一致。记录条数少、时间跨度短、责任人与制度不符，三项中任一项不过，该过程域就会被核减到二级。

由此确定本项目的两条排法。第一条是**制度先行、流程随后、记录积累贯穿全程**：政策与标准类文件在第一阶段发布，不等到建设后期；流程在平台上线后即刻启用，哪怕初期批次少，也让记录从第一天开始累积。

第二条是**优先在有真实业务量的域上跑流程**：研发设计、生产制造、质量管理三个域有持续的数据加工批次，同样的制度在这三个域上能在半年内积累出上百条执行记录，而在人力资源域可能只有十几条。评估抽样时，抽到前者能拿出完整证据链，抽到后者也能说明记录条数与该域实际业务量相称——这两点都是评估师认可的答法。

贯标评估的组织与申报由招标方主导，我方承担诊断、规划、制度编制、流程落地与证据归集五项工作，并配合评估准备与现场答疑。评估结论由认定机构作出；我方对上述五项工作的完成质量与证据的可核查性负责。责任边界在 2.5 节另有说明。

#### 1.2.2 四段路径与证据积累

贯标路径分四段：诊断、规划、实施、送审。四段不是依次完成再交棒，规划与实施有相当长的重叠期，否则记录来不及积累。

表 1-4　DCMM 三级达成路径与各段产出

| 段 | 主要工作 | 产出 | 与数据集建设的关系 | 单元 |
|---|---|---|---|---|
| 一、诊断 | 九大能力域按组织、制度、流程、工具四个维度逐项核查；不足项分类梳理并定整改优先级；全域数据资产调研盘点 | 现状诊断报告；高质量数据集验证场景数据需求清单 | 需求清单直接决定四类数据集的可得样本与补录范围 | b1219、b1220、b1221、b1229—b1236 |
| 二、规划 | 九个能力域逐域输出制度、流程与管理办法，明确组织岗位职责、管控流程与落地策略 | 数据治理顶层规划方案与九域规划成果，合并不少于 25 份治理文档 | 标准、分级与质量规则是加工环节的前置约束 | b1221、b1222、b1223、b1227 |
| 三、实施 | 治理平台建设与九项治理内容在九个业务域落地；同步构建决策数据指标体系 | 平台上线运行；元数据、标准、规则、标签、血缘、台账等运行记录 | 加工生产在治理约束下运行，记录随之产生 | b1224、b1225、b1226 |
| 四、送审 | 整理评审证据包，支撑甲方向认定机构申请贯标评估 | 评审证据包；能力域逐项的过程说明与记录索引 | 数据集加工与场景验证的过程记录是证据的一部分 | b1219 |

四段中第三段最长，因为记录需要在真实业务上跑够周期。本项目的安排是把第一阶段的制度与标准发布节点压在首批数据汇聚与数据集加工开始之前，使加工过程本身就在治理约束下运行，加工留下的血缘、质量评分与审批留痕同时成为贯标证据。这样记录的积累周期与项目的加工周期同步，不另占时间。

##### 图 1-2　贯标四段路径与执行记录的积累关系

<svg viewBox="0 0 820 320" xmlns="http://www.w3.org/2000/svg"
     font-family="Noto Sans CJK SC, PingFang SC, SimHei, sans-serif" font-size="13">
  <defs><marker id="t4-b" markerWidth="9" markerHeight="9" refX="8" refY="4.5" orient="auto">
    <path d="M0 0 L9 4.5 L0 9 z" fill="#334155"/></marker></defs>

  <line x1="40" y1="286" x2="790" y2="286" stroke="#334155" stroke-width="1.4" marker-end="url(#t4-b)"/>
  <text x="40" y="306" font-size="12">合同生效</text>
  <text x="760" y="306" text-anchor="middle" font-size="12">2028-05</text>
  <text x="400" y="306" text-anchor="middle" font-size="12">项目周期（质保期不少于 12 个月，自验收起算）</text>

  <rect x="40" y="26" width="168" height="48" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="124" y="46" text-anchor="middle">一、诊断</text>
  <text x="124" y="64" text-anchor="middle" font-size="12">九域四维核查 · 资产盘点</text>
  <rect x="150" y="84" width="300" height="48" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="300" y="104" text-anchor="middle">二、规划</text>
  <text x="300" y="122" text-anchor="middle" font-size="12">九域规划成果 · 不少于 25 份治理文档</text>
  <rect x="300" y="142" width="420" height="48" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="510" y="162" text-anchor="middle">三、实施</text>
  <text x="510" y="180" text-anchor="middle" font-size="12">治理平台落地 · 九项内容 × 九业务域 · 决策指标体系</text>
  <rect x="596" y="200" width="196" height="48" rx="5" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="694" y="220" text-anchor="middle">四、送审</text>
  <text x="694" y="238" text-anchor="middle" font-size="12">评审证据包 · 贯标支撑</text>

  <path d="M208 50 H340 V80" stroke="#334155" stroke-width="1.2" fill="none" marker-end="url(#t4-b)"/>
  <text x="276" y="44" text-anchor="middle" font-size="11.5">诊断结论为规划唯一输入</text>
  <path d="M450 108 H520 V138" stroke="#334155" stroke-width="1.2" fill="none" marker-end="url(#t4-b)"/>
  <text x="486" y="102" text-anchor="middle" font-size="11.5">制度先行</text>
  <path d="M720 166 H756 V196" stroke="#334155" stroke-width="1.2" fill="none" marker-end="url(#t4-b)"/>

  <rect x="300" y="256" width="420" height="22" rx="3" fill="#f1f5f9" stroke="#64748b" stroke-dasharray="4 3"/>
  <text x="510" y="272" text-anchor="middle" font-size="12">执行记录积累区间：标准发布、质量稽核、分级审批、服务授权的运行留痕</text>
  <path d="M510 190 V252" stroke="#334155" stroke-width="1.2" stroke-dasharray="4 3" marker-end="url(#t4-b)" fill="none"/>
  <path d="M694 252 V248" stroke="#334155" stroke-width="1.2" fill="none"/>
  <path d="M694 248 V246" stroke="#334155" stroke-width="1.2" marker-end="url(#t4-b)" fill="none"/>
</svg>

图 1-2　贯标四段路径与执行记录的积累关系。数据来源：招标文件第五章 3.2.6.1（b1219—b1226）、3.2.6.1.1（b1227）、3.2.6.1.2（b1335）；周期取招标文件第 3 章建设周期与质保期要求。

#### 1.2.3 七个阶段的输入、活动、证据与通过条件

四段路径是时间上的粗分，排到执行层面还要再细一层。从现状调查到正式评价共七个阶段，每个阶段有自己的输入、活动与证据，也各有一条判断能否往下走的通过条件。通过条件写明了，阶段推进就是逐条核对；没写明，每到一个节点都要临时议一次，工期就是这样拖掉的。不通过时的整改口径同样事先定下，表 1-5 逐阶段列出。

表 1-5　贯标七个阶段的输入、活动、证据、负责人与通过条件

| 阶段 | 输入 | 主要活动 | 证据 | 负责人 | 通过条件 | 不通过的整改 |
|---|---|---|---|---|---|---|
| 一、现状调查 | 甲方现行制度文件清单；17 套外围应用系统的元数据与数据样本；九域访谈安排 | 按组织、制度、流程、工具四个维度逐过程域取证；全域数据资产调研盘点 | 访谈记录、制度清册、系统盘点表、取证导出件与截屏 | 我方项目组承办，数据管理办公室组织 | 二十八个过程域均取得不少于两条相互独立的证据，无整域空白 | 未取证的过程域列入补证清单并在两周内补证；因源系统未授权而无法取证的，出具说明并在诊断报告中单列，不以访谈结论顶替系统证据 |
| 二、差距分析 | 现状调查证据包；GB/T 36073—2018 三级要求 | 逐过程域对照定级标尺评分，量化差距，按影响面与整改成本定优先级 | 成熟度评分表、差距项清单、整改优先级四象限 | 数据管理办公室，我方项目组支撑 | 每个差距项都能指到具体过程域条款与具体证据缺口 | 评分有争议的由对口工作组复评，复评仍不一致的提交数据治理委员会裁定，裁定结论写入诊断报告 |
| 三、制度发布 | 差距项清单；甲方现行文件体例 | 九域规划成果编制、三道评审、按企业文件发布程序发文 | 送审稿、评审意见与处理表、正式发文件、生效日期 | 我方起草，工作组会签，数据管理办公室报批 | 第一阶段的制度与标准按节点发文，发文件有文号与生效日期 | 发文延期的，先以项目联合工作组决议作为临时依据并登记在案，发文后追认；延期超过一个月的，相应调整送审时点 |
| 四、实际运行 | 已发布的制度与标准；治理平台上线 | 标准加载、规则上线、分级标注、审批流启用；九个业务域按批次纳管 | 平台配置记录、稽核台账、审批流水、血缘登记、变更记录 | 数据管理办公室，各业务域数据专责 | 关键过程域的执行记录覆盖不少于两个考核周期，记录中的责任人与制度条款一致 | 记录条数不足的业务域延后纳入送审范围，先行补跑流程；记录与制度不一致的，先改执行再议是否改制度 |
| 五、内部审核 | 运行记录；制度文本 | 按能力域抽样核对记录与制度的一致性，出具内审发现项 | 内审计划、抽样清单、内审发现项与整改要求 | 数据管理办公室牵头，我方项目组配合取证 | 抽样覆盖九个能力域，发现项全部有责任人与整改时限 | 发现项未闭环前不进入送审；判为重大不符合的，整改后重新抽样复核 |
| 六、改进 | 内审发现项；质量与安全的运行问题 | 修订制度条款、调整规则阈值、补齐缺失记录对应的流程动作 | 修订记录、版本对照、复核结论 | 承办工作组，数据管理办公室复核 | 发现项闭环率达到内审计划约定的基线，未闭环项有明确时限与责任人 | 同类问题两次重复出现的，判为机制缺陷，整改落到流程设计一层，不停留在补单条记录 |
| 七、正式评价 | 评审证据包；能力域逐项的过程说明与记录索引 | 甲方向认定机构提出评估申请，接受文件评审与现场评审，回应问询并整改 | 申请材料、评审问询记录、整改回复、认定机构出具的评估结论 | 甲方申报，我方承担材料组织与现场支撑 | 以认定机构出具的结论为准 | 按认定机构出具的不符合项组织整改并申请复评，整改过程同样留痕 |

第五、第六两个阶段的结论是内部结论。这两个阶段我方出具的是自评报告与内审发现项，用途是判断送审准备是否充分、哪些能力域还不具备送审条件。自评得分不作为能力成熟度等级的结论使用，项目进度汇报与阶段验收材料中同样按此口径表述；等级结论只来自认定机构的正式评价。把内部自评写成认证结果，评审现场一对证据就会露底，代价远大于如实说明准备程度。

#### 1.2.4 能力域数量的口径说明

招标文件两处写「DCMM 九大能力域」（b1221、b1229），并在 3.2.6.1.1.2 项下实列九个规划域：数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。GB/T 36073—2018 的能力域为八个、过程域为二十八个。

本投标文件统一按招标文件原文口径使用「九大能力域」一词，并在「数据治理规划（一）」的能力域与过程域对照表中把九个能力域逐一对照到基准模型的过程域，使评估结论既能逐条回到招标文件的规划域要求，又能直接支撑按基准模型开展的贯标送审。两套划分之间的对应关系在诊断报告中作为附表给出，评审时可双向查对。

#### 1.2.5 贯标评估的组织分工

DCMM 贯标评估由具备资质的认定机构实施并出具结论，认证主体是甲方。我方承担的是达成三级所需的能力建设与送审支撑：开展现状诊断、编制九域规划成果、建设治理平台、推动治理实施、整理评审证据包、配合现场评审与问题整改。认证的受理时点与出证时点取决于认定机构的受理安排，本节不就出证时点作承诺。

若在送审准备中发现某一能力域的执行记录积累不足两个考核周期，我方的建议是调整送审时点而非压缩记录周期：送审被核减的代价高于延后送审。这一回退口径与「数据治理规划（一）」列出的贯标风险条一致。

### 1.3 数据治理规划要求（3.2.6.1.1）

#### 1.3.1 三套九项清单，不是同一组九

招标文件在三处各出现一组九，三组的对象不同，合读时很容易混为一谈，混了以后矩阵、排期与验收口径都会错位。

第一组是**九大能力域**，出自治理规划要求（b1221、b1227），指数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。它们是规划与制度的分域，决定写哪些文件、设哪些岗位、按什么条款考核。本投标文件中「能力域」与「规划域」同义。

第二组是**九项治理内容**，出自治理实施要求（b1336），指数据汇聚、数据处理、元数据管理、数据资产管理、数据标准管理、数据质量管理、数据安全管理、数据指标管理、数据服务管理。它们是治理平台上的执行能力，决定用什么功能做、产生什么记录。

第三组是**九个业务域**，同样出自 b1336，指人力资源、研发设计、生产制造、仓储物流、财务管理、设备管理、采购管理、营销管理、质量管理。它们是治理动作的落地对象，决定在谁的数据上做。

三组的关系是一句话：能力域出规则，治理内容是平台把规则执行出来的动作，业务域是动作施加的对象。以「数据标准」为例，它在第一组里是一个能力域，产出数据元标准与参考数据码表；在第二组里对应「数据标准管理」，是平台上的标准录入、版本管理、映射对照与下发功能；在第三组的九个业务域里，表现为各域的字段分别挂到哪一条标准上、挂了多少、还差多少。名称相近而所指不同，本投标文件自本节起统一按此区分。

#### 1.3.2 三套清单的对应关系

三组之间不是一一对应，强行对齐反而会造出不存在的格子。表 1-6 以第二组的九项治理内容为主键，向左指出规则由哪个能力域产出，向右指出在九个业务域的落地次序，中间给出平台承载的模块与产生的运行记录。这张表是后续排期、平台配置与验收核对共用的底表。

表 1-6　九项治理内容与九大能力域、九个业务域的对应

| 治理内容（平台执行） | 规则来源的能力域 | 平台承载模块 | 产生的运行记录 | 在九个业务域的落地次序 |
|---|---|---|---|---|
| 数据汇聚 | 数据架构（数据集成共享管理规范）、数据安全（分级判定） | 采集任务配置、连接器管理 | 汇聚批次台账、接口调用日志 | 研发设计、生产制造、质量管理、仓储物流、设备管理先行；其余四域随第二批 |
| 数据处理 | 数据生存周期（数据设计开发规范）、数据标准 | 处理任务编排、规则执行引擎 | 处理作业记录、规则命中统计 | 与数据汇聚同批推进，按同一批次纳管 |
| 元数据管理 | 数据架构（元数据管理办法） | 元数据采集与登记、血缘视图 | 元数据变更记录、字段级血缘登记 | 九域同批建立基本登记，血缘粒度按域分期加深 |
| 数据资产管理 | 数据资产 | 资源目录、权属登记、价值评估 | 目录上下架记录、权属确认单、评估结论 | 研发设计、生产制造、设备管理先行 |
| 数据标准管理 | 数据标准 | 标准录入与版本、映射对照、标准下发 | 标准发布记录、映射变更与例外登记 | 术语与数据元九域同批，指标标准随第二批 |
| 数据质量管理 | 数据质量 | 规则库、稽核调度、问题工单 | 稽核台账、整改工单与复核记录 | 研发设计、生产制造、质量管理先行 |
| 数据安全管理 | 数据安全 | 分级标注、权限与审批、脱敏策略、审计 | 分级审批单、授权与撤销记录、访问审计日志 | 人力资源、财务管理、营销管理的分级动作前置，其余随汇聚批次 |
| 数据指标管理 | 数据标准（指标标准）、数据战略（度量指标） | 指标卡登记、口径会签、指标计算配置 | 指标卡会签记录、口径变更记录 | 第二批，随决策指标体系的三个确认时点推进 |
| 数据服务管理 | 数据应用流通 | 服务目录、服务分级、授权与计量 | 服务授权记录、调用计量、降级记录 | 第三批，随数据集运营推广推进 |

表 1-6 里没有「数据战略」与「数据治理」两行，不是遗漏。这两个能力域产出的是目标、组织、制度与考核，落在发文件、会议纪要与考核结果上，由平台的流程与审批功能留痕，不对应某一项具体的治理内容。九个业务域的逐格优先批次与各域实施重点在「数据治理规划（二）」的落地矩阵中逐格给出，本节给的是对应关系本身。

##### 图 1-3　三套九项清单的对应关系

<svg viewBox="0 0 820 420" xmlns="http://www.w3.org/2000/svg"
     font-family="Noto Sans CJK SC, PingFang SC, SimHei, sans-serif" font-size="13">
  <defs><marker id="t4-e" markerWidth="9" markerHeight="9" refX="8" refY="4.5" orient="auto">
    <path d="M0 0 L9 4.5 L0 9 z" fill="#334155"/></marker></defs>

  <rect x="14" y="46" width="232" height="240" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="130" y="68" text-anchor="middle" font-size="13">九大能力域（规划域）</text>
  <text x="130" y="86" text-anchor="middle" font-size="11.5" fill="#475569">出规则：写哪些文件、设哪些岗位</text>
  <text x="26" y="112" font-size="12">数据战略</text>
  <text x="26" y="131" font-size="12">数据治理</text>
  <text x="26" y="150" font-size="12">数据架构</text>
  <text x="26" y="169" font-size="12">数据资产</text>
  <text x="26" y="188" font-size="12">数据标准</text>
  <text x="26" y="207" font-size="12">数据质量</text>
  <text x="26" y="226" font-size="12">数据安全</text>
  <text x="26" y="245" font-size="12">数据生存周期</text>
  <text x="26" y="264" font-size="12">数据应用流通</text>

  <rect x="294" y="46" width="232" height="240" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="410" y="68" text-anchor="middle" font-size="13">九项治理内容（平台执行）</text>
  <text x="410" y="86" text-anchor="middle" font-size="11.5" fill="#475569">做动作：平台上落地哪些能力</text>
  <text x="306" y="112" font-size="12">数据汇聚</text>
  <text x="306" y="131" font-size="12">数据处理</text>
  <text x="306" y="150" font-size="12">元数据管理</text>
  <text x="306" y="169" font-size="12">数据资产管理</text>
  <text x="306" y="188" font-size="12">数据标准管理</text>
  <text x="306" y="207" font-size="12">数据质量管理</text>
  <text x="306" y="226" font-size="12">数据安全管理</text>
  <text x="306" y="245" font-size="12">数据指标管理</text>
  <text x="306" y="264" font-size="12">数据服务管理</text>

  <rect x="574" y="46" width="232" height="240" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="690" y="68" text-anchor="middle" font-size="13">九个业务域（落地对象）</text>
  <text x="690" y="86" text-anchor="middle" font-size="11.5" fill="#475569">在谁的数据上做</text>
  <text x="586" y="112" font-size="12">研发设计</text>
  <text x="586" y="131" font-size="12">生产制造</text>
  <text x="586" y="150" font-size="12">质量管理</text>
  <text x="586" y="169" font-size="12">仓储物流</text>
  <text x="586" y="188" font-size="12">设备管理</text>
  <text x="586" y="207" font-size="12">采购管理</text>
  <text x="586" y="226" font-size="12">营销管理</text>
  <text x="586" y="245" font-size="12">财务管理</text>
  <text x="586" y="264" font-size="12">人力资源</text>

  <text x="270" y="156" text-anchor="middle" font-size="11">规则下发</text>
  <path d="M250 170 H288" stroke="#334155" stroke-width="1.4" marker-end="url(#t4-e)" fill="none"/>
  <text x="550" y="156" text-anchor="middle" font-size="11">作用对象</text>
  <path d="M530 170 H568" stroke="#334155" stroke-width="1.4" marker-end="url(#t4-e)" fill="none"/>

  <rect x="14" y="302" width="792" height="104" rx="6" fill="#f8fafc" stroke="#334155"/>
  <text x="26" y="326" font-size="12">读法：左列出规则，中列是平台把规则执行出来的动作，右列是动作施加的对象。</text>
  <text x="26" y="350" font-size="12">数据战略与数据治理两域产出目标、组织与考核，落在制度与会议记录上，不对应中列的某一项。</text>
  <text x="26" y="374" font-size="12">「数据标准」在左列是能力域，在中列是标准录入、版本与下发功能，在右列是各域字段挂到哪条标准。</text>
  <text x="26" y="398" font-size="12">名称相近而所指不同：规划域即能力域，平台上的九项称治理内容，纵向对象称业务域。</text>
</svg>

图 1-3　三套九项清单的对应关系。数据来源：招标文件第五章 3.2.6.1（b1221）、3.2.6.1.1.2 项下实列的九个规划域、3.2.6.1.2 九个业务域与九项治理内容（b1336）。

#### 1.3.3 九大能力域的三层结构

九个能力域放在一张表里看像九件平行的事，实际它们是三层。最上面两域回答「谁来管、按什么方向管」：数据战略定方向与路线图，数据治理定组织、制度与考核。中间三域回答「管什么」：数据架构定数据怎么组织与怎么流动，数据标准定每个字段与每个指标的口径，数据资产定哪些数据被登记为资产、归谁、值多少。外围四域回答「管得住没有」：数据质量校验数据对不对，数据安全管住谁能看、看多少，数据生存周期管住从需求到退役的每一步有没有留痕，数据应用流通管住数据以什么形态出去。

这个分层有实际用处。诊断时若某个域评分低，分层能指出是上层缺位还是下层缺工具——战略与治理两域弱，则下面七域的规划无人审批、无人考核，先补组织；中间三域弱，则外围四域的规则无依据可写，先补标准；外围四域弱而中间三域齐备，则多半是平台能力与执行记录的问题，补工具与流程即可。「数据治理规划（一）」的整改优先级四象限就是按这一判断给出的。

##### 图 1-4　九大能力域的三层结构与域间主要接口

<svg viewBox="0 0 820 430" xmlns="http://www.w3.org/2000/svg"
     font-family="Noto Sans CJK SC, PingFang SC, SimHei, sans-serif" font-size="13">
  <defs><marker id="t4-c" markerWidth="9" markerHeight="9" refX="8" refY="4.5" orient="auto">
    <path d="M0 0 L9 4.5 L0 9 z" fill="#334155"/></marker></defs>

  <rect x="14" y="14" width="792" height="92" rx="6" fill="#f8fafc" stroke="#334155" stroke-dasharray="4 3"/>
  <text x="26" y="34" font-size="12.5" fill="#475569">第一层　定方向与定规矩　（详见数据治理规划（一））</text>
  <rect x="140" y="44" width="240" height="50" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="260" y="64" text-anchor="middle">数据战略</text>
  <text x="260" y="83" text-anchor="middle" font-size="12">愿景 · 重点任务 · 路线图 · 评估</text>
  <rect x="440" y="44" width="240" height="50" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="560" y="64" text-anchor="middle">数据治理</text>
  <text x="560" y="83" text-anchor="middle" font-size="12">三层组织 · 制度 · 考核 · 数据文化</text>
  <path d="M380 69 H436" stroke="#334155" stroke-width="1.3" marker-end="url(#t4-c)" fill="none"/>
  <text x="408" y="62" text-anchor="middle" font-size="11">目标</text>

  <rect x="14" y="118" width="792" height="100" rx="6" fill="#f8fafc" stroke="#334155" stroke-dasharray="4 3"/>
  
  <rect x="36" y="148" width="236" height="56" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="154" y="170" text-anchor="middle">数据架构</text>
  <text x="154" y="190" text-anchor="middle" font-size="12">五层分层 · 分布流图 · 元数据血缘</text>
  <rect x="292" y="148" width="236" height="56" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="410" y="170" text-anchor="middle">数据标准</text>
  <text x="410" y="185.2" text-anchor="middle" font-size="12"><tspan x="410">术语 · 主数据 · 参考数据 · 数据元 ·</tspan><tspan x="410" dy="15.0">指标</tspan></text>
  <rect x="548" y="148" width="236" height="56" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="666" y="170" text-anchor="middle">数据资产</text>
  <text x="666" y="190" text-anchor="middle" font-size="12">权属 · 目录 · 价值评估 · 运营流程</text>
  <path d="M272 176 H288" stroke="#334155" stroke-width="1.3" marker-end="url(#t4-c)" fill="none"/>
  <path d="M528 176 H544" stroke="#334155" stroke-width="1.3" marker-end="url(#t4-c)" fill="none"/>
  <path d="M260 94 V144" stroke="#334155" stroke-width="1.2" marker-end="url(#t4-c)" fill="none"/>
  <path d="M560 94 V144" stroke="#334155" stroke-width="1.2" marker-end="url(#t4-c)" fill="none"/>

  <rect x="14" y="230" width="792" height="104" rx="6" fill="#f8fafc" stroke="#334155" stroke-dasharray="4 3"/>
  <text x="26" y="250" font-size="12.5" fill="#475569">第三层　管得住没有　（均见数据治理规划（二））</text>
  <rect x="26" y="260" width="184" height="62" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="118" y="282" text-anchor="middle">数据质量</text>
  <text x="118" y="301" text-anchor="middle" font-size="12">六维度 · 规则库</text>
  <text x="118" y="317" text-anchor="middle" font-size="12">稽核 · 五环整改</text>
  <rect x="220" y="260" width="184" height="62" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="312" y="282" text-anchor="middle">数据安全</text>
  <text x="312" y="301" text-anchor="middle" font-size="12">五级分级 · 权限</text>
  <text x="312" y="317" text-anchor="middle" font-size="12">脱敏 · 审计</text>
  <rect x="414" y="260" width="184" height="62" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="506" y="282" text-anchor="middle">数据生存周期</text>
  <text x="506" y="301" text-anchor="middle" font-size="12">需求 · 设计开发</text>
  <text x="506" y="317" text-anchor="middle" font-size="12">运维 · 退役</text>
  <rect x="608" y="260" width="184" height="62" rx="5" fill="#eef2f7" stroke="#334155"/>
  <text x="700" y="282" text-anchor="middle">数据应用流通</text>
  <text x="700" y="301" text-anchor="middle" font-size="12">应用 · 外部数据</text>
  <text x="700" y="317" text-anchor="middle" font-size="12">开放共享 · 服务</text>
  <path d="M410 204 V256" stroke="#334155" stroke-width="1.3" marker-end="url(#t4-c)" fill="none"/>
  <text x="418" y="226" font-size="11.5">数据元与值域作为校验依据</text>

  <rect x="14" y="348" width="792" height="36" rx="5" fill="#e2e8f0" stroke="#334155"/>
  <text x="410" y="371" text-anchor="middle" font-size="12.5">落地对象：九个业务域（研发设计 · 生产制造 · 质量管理 · 仓储物流 · 设备管理 · 采购管理 · 营销管理 · 财务管理 · 人力资源）</text>
  <path d="M118 322 V344" stroke="#334155" stroke-width="1.1" marker-end="url(#t4-c)" fill="none"/>
  <path d="M312 322 V344" stroke="#334155" stroke-width="1.1" marker-end="url(#t4-c)" fill="none"/>
  <path d="M506 322 V344" stroke="#334155" stroke-width="1.1" marker-end="url(#t4-c)" fill="none"/>
  <path d="M700 322 V344" stroke="#334155" stroke-width="1.1" marker-end="url(#t4-c)" fill="none"/>
  <text x="410" y="402" text-anchor="middle" font-size="12" fill="#475569">分级标签贯穿第三层四域，并回写第二层标准与资产目录（虚线框内各域的详细设计见对应子节）</text>

  <rect x="22.0" y="122.9" width="543.3" height="21.0" fill="#f8fafc" stroke="none" data-halo="1"/><text x="26" y="138" font-size="12.5" fill="#475569">第二层　管什么　（数据架构与数据资产见规划（一）；数据标准见规划（二））</text>
</svg>

图 1-4　九大能力域的三层结构与域间主要接口。数据来源：招标文件第五章 3.2.6.1.1.2 项下实列的九个规划域（b1237 以下各项）、3.2.6.1.2 九个业务域（b1336）。

#### 1.3.4 域间接口：谁的产出是谁的输入

九域之间的衔接点须单列。各域的域内设计分别写在两个子节里，域与域之间的交接若不单列，合在一起读会出现同一个对象在两处有两套说法。表 1-7 按「产出—接口件—消费方」三栏列出主要接口，接口件是可以指着看的具体东西，不是抽象的协同关系。

表 1-7　九大能力域之间的主要接口

| 产出方 | 接口件 | 消费方 | 接口口径 |
|---|---|---|---|
| 现状评估 | 现状诊断报告、场景数据需求清单 | 九个规划域 | 诊断结论是九域规划的唯一输入；规划中每项任务须能指回诊断报告的差距编号 |
| 数据战略 | 三阶段路线图、度量指标 | 数据治理、各域实施计划 | 路线图的阶段切分即各域成果物的交付时点依据 |
| 数据治理 | 三层组织、岗位职责、考核细则 | 全部八域 | 各域成果物的审批主体与会签路径由此确定；组织未发文前成果物只出送审稿 |
| 数据架构 | 数据元与物理字段映射、元数据与字段级血缘 | 数据标准、数据质量、数据生存周期 | 血缘粒度到字段级；质量问题的定位与错样归因均沿血缘回溯 |
| 数据标准 | 数据元标准、参考数据码表、指标卡 | 数据质量、数据安全、知识本体、指标体系 | 校验规则引用数据元与值域；知识本体引用术语标准，不另立术语 |
| 数据资产 | 资源目录条目、权属登记、价值等级 | 数据应用流通、运营平台 | 目录条目实时带出质量分与安全级别；运营平台的挂牌与确权以权属登记为据 |
| 数据质量 | 规则库、质量评分、整改台账 | 数据集质检、数据服务、资产价值评估 | 质量未达门限的数据按置信标记降级输出，不直接中断加工 |
| 数据安全 | 五级分级标签、权限与脱敏策略 | 数据架构、生存周期、应用流通、安全方案 | 分级标签是权限、脱敏、审计三类管控的唯一驱动输入 |
| 数据生存周期 | 采集、加工、接口开发规范与评审检查点 | 加工生产链路、运维 | 规范的检查点即开发过程的放行条件 |
| 数据应用流通 | 服务目录、SLA 分级、授权与计量 | 场景验证、运营推广 | 三级服务在资源紧张时降级，一级服务优先保障 |

表中有两条接口在子节里分别出现过，合读时以本表为准。一是知识本体与数据标准的关系：知识本体引用治理侧的术语标准、参考数据标准、数据元标准与指标标准，不另立一套术语；本体先行定义的领域概念回流为标准草案，字段定义冲突时以数据元标准为准。二是业务数据质量与数据集质量的关系：治理侧的质量规则管的是九个业务域的业务数据，数据集的质量评测按《高质量数据集质量评测规范》开展，两者的关系是前者为后者供料、后者的错样归因结论回流为前者的规则修订线索。

#### 1.3.5 九个业务域的落地不均匀

九项治理内容是横向能力，九个业务域是纵向对象，交叉形成落地矩阵。矩阵不是均匀的：研发设计、生产制造、质量管理三个域直接产出工艺设计类、制造过程类与产品质量类数据集的主体样本，治理动作排在第一批；仓储物流与设备管理支撑供需计划类数据集与设备诊断相关场景，同在第一批但元数据与安全动作可后置；采购、营销、财务、人力资源四个域主要支撑决策指标与通用场景，治理动作整体后置，但其中三个域的安全分级要前置，原因是这三个域集中了分级标准中最高两级（L4 与 L5）的数据。

人力资源域在数据集贡献上权重最低，组织与岗位主数据却须排在第一批——它是其余八域权限模型与操作留痕的前提，也是第 1.5.4 节权限撤销一条能够成立的前提。逐格的优先批次与各域实施重点在「数据治理规划（二）」的落地矩阵与逐域实施重点中给出。

矩阵不均匀带来一个实际问题：同一项治理动作在不同业务域的成熟度不同步，跨域的数据一旦汇到一起，口径就会打架。最常见的三类冲突值得先讲清处置办法。

**第一类是同一业务对象在两个域有两套编码。** 例如同一台刮板输送机，设备管理域按设备台账编码，生产制造域按产品编号，两者在历史上各自独立维护、互不回指。处置办法不是强行统一编码——那会要求两个域同时改造既有系统，工期不可控——而是在主数据域建立对照关系并指定权威源：设备台账为权威源，生产侧保留原编码并挂对照，汇聚到数据集时按权威源归一。对照关系的建立与维护纳入主数据管理流程，新增对象在源头即登记对照，存量对象按批次补录。

**第二类是同一指标在两个域有两个口径。** 例如「在制品数量」，生产制造域按工序流转口径统计，仓储物流域按实物在库口径统计，两者在数值上长期不等且各有道理。处置办法是在数据标准域把两个口径都登记为正式指标，各自给出计算逻辑、适用场景与责任部门，**不做二选一**；在数据集中以指标标识区分，使用方按场景选用。强行取一个口径会让另一个域的历史数据全部失效，代价远大于并存。

**第三类是同一份数据在两个域有不同的密级判定。** 例如客户工况资料，营销域按商业信息判为内部级，而其中含矿方的地质参数，安全域按行业要求判为更高级别。处置办法是**取高不取低**，并把判定依据连同判定人一并登记；后续若业务部门主张降级，须以书面依据走变更流程，不以口头协商改变密级。这一条在本项目尤其要紧——数据集一旦按较低密级发布，回收的代价极高。

三类冲突的共同处置原则是：**先登记、再裁决、不静默归并**。任何一次归并都在元数据中留下归并前的原值与归并依据，使后续发现判断有误时可以回退。争议从登记到裁定的完整流程、各步的时限与裁决前的数据处置口径，在第 1.5.2 节给出。

#### 1.3.6 十七套源系统的端到端控制链

治理落到执行层面，对象是十七套外围应用系统（b0804r02）。十七套按它们在数据链上的角色分五组，纳管重点与批次各不相同。分组的意义在于：同一条控制链在不同组系统上的难点不一样，把难点提前认出来，批次才排得准。

表 1-8　十七套外围应用系统的分组、纳管重点与批次

| 组别 | 系统 | 承载的主要数据 | 纳管重点 | 批次 |
|---|---|---|---|---|
| 生产与工艺执行（3 套） | MES、SCADA、热处理群控系统 | 工单与工序流转、设备运行参数、热处理炉次与温控测量值 | 时序测点的口径与工况分段依据；28 道备料工序在各系统中的名称归一 | 第一批 |
| 设计与文档（2 套） | PLM、OA | 设计图纸、工艺文件、技术文档、公文与审批件 | 图纸与工艺卡的配对规则；文档版本与密级的对应 | 第一批 |
| 质量与售后（3 套） | QMS、SOS、安全监管平台 | 四类检验记录与质量台账、报警与维修记录、安全事件与隐患 | 缺陷类型码表归一；报警与处置的配对口径；敏感事件的分级与脱敏 | 第一批 |
| 供应链与资产（6 套） | ERP、SCM、WMS、LMS、EAM、EMS | 物料与库存、采购与供应商、运单与节点时间、设备台账、能耗计量 | 物料与设备主数据去重；同一实体在多套系统中的编码映射 | 第二批 |
| 经营与主数据（3 套） | CRM、久其系统、主数据管理平台 | 客户与商机、经营指标、企业主数据 | 经营指标口径随决策指标体系成文；主数据以主数据管理平台为上游，治理侧不另建码表 | 第二批 |

对这十七套系统，治理落地的形式是七条控制链：数据标准、主数据、元数据、数据质量、数据安全、数据生存周期、共享流通。每条链都要讲清同样的六件事——规则从哪来、每个环节谁负责、谁有权批、平台执行什么动作、不通的时候怎么办、留下什么记录。六件事缺一件，这条链在评审现场就答不上来。表 1-9 给出前三件，表 1-10 给出后三件。

表 1-9　七条控制链的规则来源、环节责任与审批权限

| 控制链 | 规则来源 | 环节与责任人 | 审批权限 |
|---|---|---|---|
| 数据标准 | 业务术语标准、数据元标准、参考数据标准、指标标准（数据标准域发布） | 草案由我方项目组与标准岗起草；对口工作组会签；业务归口部门确认本域口径；数据管理办公室报批 | 标准新增与修订由数据管理办公室批准；跨域口径冲突报数据治理委员会裁定 |
| 主数据 | 主数据管理平台为上游数据源，参考数据标准定码表体例 | 变更由业务归口部门提出；主数据维护岗执行；数据管理办公室复核并分发 | 新增主数据类目由数据管理办公室批准；编码规则调整报数据治理委员会 |
| 元数据 | 元数据管理办法（数据架构域） | 技术元数据由平台自动采集；业务元数据由各域数据专责填报；数据架构岗复核 | 元数据模型与采集范围的变更由数据管理办公室批准 |
| 数据质量 | 数据质量校验规则库，规则引用数据元与值域 | 规则由质量岗与业务数据专责共同定义；对口工作组会签；平台按调度执行稽核；问题工单由责任域承办 | 规则上线与阈值调整由数据管理办公室批准；跨域整改方案报数据治理委员会 |
| 数据安全 | 数据安全分级标准、数据权限管理规范 | 分级由业务归口部门判定、安全岗复核、办公室备案；授权由使用方申请、数据责任部门审核 | L1 至 L3 的授权由数据责任部门审批；L4、L5 的授权报数据治理委员会；分级结论有争议的由委员会裁定 |
| 数据生存周期 | 数据需求管理规范、数据设计开发规范、数据运维管理制度、数据退役管理规范 | 需求由业务提出；数据架构岗评审；开发按规范实施；运维岗接管；退役由数据责任部门申请 | 需求与设计评审由数据管理办公室批准；退役由数据管理办公室批准，涉及已交付数据集的报数据治理委员会 |
| 共享流通 | 数据开放共享管理规范、外部数据引入管理办法 | 服务需求由使用方提出；数据责任部门确认范围；办公室登记服务目录；平台发布接口 | 内部共享由数据责任部门审批；对外开放与数据集挂牌报数据治理委员会；外部数据引入另行合规审查 |

表 1-10　七条控制链的平台执行动作、例外处理与留痕

| 控制链 | 平台执行动作 | 例外处理 | 留痕 |
|---|---|---|---|
| 数据标准 | 标准录入并生成版本号；向十七套系统的接入配置下发字段映射；加工侧按版本号引用 | 源系统现用字段与标准不一致且短期无法改造的，登记为映射例外并挂入标准映射对照表，设复核期，到期重新判定 | 标准发布记录、映射对照版本、下发回执、例外登记与复核结论 |
| 主数据 | 订阅主数据变更并同步到资产目录与加工侧字典，同一变更在各处的生效时点一致 | 同一实体在多套系统有不同编码的，建立交叉引用而不强制改造源系统；归属有争议且未裁决的，以主数据管理平台口径为准 | 主数据变更单、同步执行记录、交叉引用表 |
| 元数据 | 定期采集与比对，变化项生成变更记录；血缘登记到字段级 | 采集不到的离线来源（纸质档案、离线交换件）手工登记并标注来源方式，与自动采集分开统计，不计入自动采集覆盖率 | 元数据变更记录、字段级血缘登记、采集任务日志 |
| 数据质量 | 按调度执行稽核，生成质量评分与问题工单；评分回写资产目录与数据卡 | 质量未达门限的数据按置信标记降级输出并在数据卡标注，不中断加工；源头确实无法修复的列入已知缺陷清单，在验收材料中一并说明 | 稽核台账、问题工单与复核记录、质量评分历史 |
| 数据安全 | 打分级标签，按标签驱动权限、脱敏与审计三类管控；越权访问实时拦截并告警 | 分级尚未判定而加工排期已到的，该批次进入落地区待判定分区，不进加工区；存放期上限 15 个工作日，超期未判定的升级至数据治理工作组裁决 | 分级审批单、授权与撤销记录、脱敏策略版本、访问审计日志 |
| 数据生存周期 | 在需求、设计、开发、运维、退役各阶段设评审检查点，检查点未过不进入下一阶段；退役对象标记为停用并保留血缘 | 已被数据集引用的对象不直接物理删除，先转为只读并标注退役状态，待引用关系解除后按归档策略处理 | 需求单与评审记录、设计评审检查表、退役申请与执行记录 |
| 共享流通 | 按服务目录发布接口，按服务分级限流与计量；调用记录回流作为资产价值评估的输入 | 三级服务在资源紧张时降级，一级服务优先保障；外部数据来源合法性未经核实的不予引入 | 服务授权记录、调用计量、降级与限流记录、合规审查结论 |

七条链在同一套系统上是叠加的，顺序不能乱。以热处理群控系统为例：炉次曲线要先有数据元标准与温度量纲口径，才谈得上登记元数据；要先有设备主数据，才知道这条曲线属于哪台炉；要先判定分级，才决定取数时是否脱敏；三件齐了才进入汇聚与加工，之后由质量稽核按规则打分，由生存周期的检查点控制接口变更，最终由共享流通决定它以什么形态出去。图 1-5 给出这一顺序。

##### 图 1-5　一套源系统从接入到出数据的控制链

<svg viewBox="0 0 820 392" xmlns="http://www.w3.org/2000/svg"
     font-family="Noto Sans CJK SC, PingFang SC, SimHei, sans-serif" font-size="13">
  <defs><marker id="t4-f" markerWidth="9" markerHeight="9" refX="8" refY="4.5" orient="auto">
    <path d="M0 0 L9 4.5 L0 9 z" fill="#334155"/></marker></defs>

  <rect x="14" y="20" width="792" height="60" rx="6" fill="#f8fafc" stroke="#334155"/>
  <text x="26" y="42" font-size="12.5">源系统（示例：热处理群控系统）　炉次曲线 · 设定温度与实测温度 · 装炉清单 · 工艺参数设定值</text>
  <text x="26" y="64" font-size="12">责任：按已授权范围开放只读接口；源头数据错误由系统管理岗处置，不在加工侧就地改数</text>
  <path d="M410 80 V114" stroke="#334155" stroke-width="1.5" marker-end="url(#t4-f)" fill="none"/>

  <rect x="22" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="74" y="144" text-anchor="middle" font-size="12.5">标准映射</text>
  <text x="74" y="164" text-anchor="middle" font-size="11">办公室批准</text>
  <rect x="134" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="186" y="144" text-anchor="middle" font-size="12.5">主数据对照</text>
  <text x="186" y="164" text-anchor="middle" font-size="11">主数据岗维护</text>
  <rect x="246" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="298" y="144" text-anchor="middle" font-size="12.5">元数据登记</text>
  <text x="298" y="164" text-anchor="middle" font-size="11">架构岗复核</text>
  <rect x="358" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="410" y="144" text-anchor="middle" font-size="12.5">分级判定</text>
  <text x="410" y="164" text-anchor="middle" font-size="11">安全岗复核</text>
  <rect x="470" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="522" y="144" text-anchor="middle" font-size="12.5">质量稽核</text>
  <text x="522" y="164" text-anchor="middle" font-size="11">按规则调度</text>
  <rect x="582" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="634" y="144" text-anchor="middle" font-size="12.5">周期检查点</text>
  <text x="634" y="164" text-anchor="middle" font-size="11">评审后放行</text>
  <rect x="694" y="120" width="104" height="58" rx="5" fill="#e8eef6" stroke="#334155"/>
  <text x="746" y="144" text-anchor="middle" font-size="12.5">服务授权</text>
  <text x="746" y="164" text-anchor="middle" font-size="11">责任部门批</text>

  <path d="M126 149 H132" stroke="#334155" marker-end="url(#t4-f)" fill="none"/>
  <path d="M238 149 H244" stroke="#334155" marker-end="url(#t4-f)" fill="none"/>
  <path d="M350 149 H356" stroke="#334155" marker-end="url(#t4-f)" fill="none"/>
  <path d="M462 149 H468" stroke="#334155" marker-end="url(#t4-f)" fill="none"/>
  <path d="M574 149 H580" stroke="#334155" marker-end="url(#t4-f)" fill="none"/>
  <path d="M686 149 H692" stroke="#334155" marker-end="url(#t4-f)" fill="none"/>

  <text x="74" y="196" text-anchor="middle" font-size="11.5" fill="#475569">前三道为接入门槛</text>
  <text x="410" y="196" text-anchor="middle" font-size="11.5" fill="#475569">第四道未过不进加工区</text>
  <text x="700" y="196" text-anchor="middle" font-size="11.5" fill="#475569">后三道贯穿运行期</text>

  <rect x="14" y="212" width="792" height="64" rx="6" fill="#eef2f7" stroke="#334155"/>
  <text x="26" y="234" font-size="12.5">留痕：映射对照版本 · 主数据变更单 · 字段级血缘 · 分级审批单 · 稽核台账 · 评审检查表 · 服务授权记录</text>
  <text x="26" y="258" font-size="12">这些记录既是质量溯源的依据，也是贯标评审时「过程被规范执行」的证据，不另攒一套台账</text>
  <path d="M240 178 V208" stroke="#334155" stroke-width="1.2" stroke-dasharray="4 3" marker-end="url(#t4-f)" fill="none"/>

  <rect x="14" y="290" width="792" height="86" rx="6" fill="#f8fafc" stroke="#334155" stroke-dasharray="4 3"/>
  <text x="26" y="312" font-size="12.5">例外：字段与标准不一致 → 登记映射例外，设复核期；分级未判定 → 入待判定分区，15 个工作日上限</text>
  <text x="26" y="336" font-size="12.5">质量未达门限 → 置信标记降级输出并在数据卡标注；血缘缺失 → 按可溯源程度分档处置</text>
  <text x="26" y="360" font-size="12.5">每一次例外都产生记录，例外本身也在管理之内；五类非常态情形的完整处置见第 1.5 节</text>
</svg>

图 1-5　一套源系统从接入到出数据的控制链。数据来源：招标文件第五章 3.2.1 服务采购清单第 1 项（b0804r02）、3.2.6.1.2 九项治理内容（b1336）。

### 1.4 数据治理平台建设与数据治理实施

#### 1.4.1 三个平台的职责分界依据

招标文件要求依据诊断报告与治理规划开展数据治理平台建设与数据治理实施工作（b1224），并要求九项治理内容在数据治理开发工具平台上落地（b1336）。同时，服务采购清单第 1、2、3 项另有数据资源建设、工具链建设与运营服务管理平台建设（b0804r02、b0804r03、b0804r04）。这里有三个平台角色，职责必须分清，否则实施时会出现同一份元数据在两处登记、同一个口径在两处定义。

分法的依据是三者管的东西不同。治理平台管的是约束与证据——数据元长什么样、字段属于哪一级、规则怎么判、血缘往哪连、谁在什么时候批准了什么。加工生产平台管的是生产动作——采集、预处理、标注、合成、增强、质检、验证各环节的任务编排与算力调度。运营服务管理平台管的是成品的对外服务——数据集目录、版本、权限、确权、挂牌、交易与审计。三者在本项目中作为奔牛数据智能平台的治理组件、加工组件与运营组件部署，共用统一身份与统一审计，但数据对象与责任主体各自独立。

这样分的实际好处在换件时能看出来：工具链随技术演进替换，加工组件变；治理侧的数据元、分级与规则不变，已加工数据的血缘与质量档案也不作废。反过来，治理标准修订时，受影响的加工任务由血缘反查出来，重跑范围是可计算的，不必全量重做。

##### 图 1-6　三个平台的职责分界与接口

<svg viewBox="0 0 820 420" xmlns="http://www.w3.org/2000/svg"
     font-family="Noto Sans CJK SC, PingFang SC, SimHei, sans-serif" font-size="13">
  <defs><marker id="t4-d" markerWidth="9" markerHeight="9" refX="8" refY="4.5" orient="auto">
    <path d="M0 0 L9 4.5 L0 9 z" fill="#334155"/></marker></defs>

  <rect x="14" y="16" width="250" height="186" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="139" y="40" text-anchor="middle" font-size="14">治理平台</text>
  <text x="139" y="58" text-anchor="middle" font-size="12">管约束与证据</text>
  <line x1="30" y1="68" x2="248" y2="68" stroke="#94a3b8"/>
  <text x="30" y="88" font-size="12">· 元数据与字段级血缘</text>
  <text x="30" y="108" font-size="12">· 五类数据标准与映射对照</text>
  <text x="30" y="128" font-size="12">· 质量规则库与稽核调度</text>
  <text x="30" y="148" font-size="12">· 分级标签与权限审批策略</text>
  <text x="30" y="168" font-size="12">· 资产目录、权属与价值等级</text>
  <text x="30" y="188" font-size="12">· 指标卡与服务目录</text>

  <rect x="290" y="16" width="250" height="186" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="415" y="40" text-anchor="middle" font-size="14">数据集加工生产平台</text>
  <text x="415" y="58" text-anchor="middle" font-size="12">管生产动作</text>
  <line x1="306" y1="68" x2="524" y2="68" stroke="#94a3b8"/>
  <text x="306" y="88" font-size="12">· 七环节任务编排与重跑</text>
  <text x="306" y="108" font-size="12">· 9 类 25 个工具链运行</text>
  <text x="306" y="128" font-size="12">· 知识本体与知识库构建</text>
  <text x="306" y="148" font-size="12">· 标注作业与一致性校验</text>
  <text x="306" y="168" font-size="12">· 质检门控与验证终验</text>
  <text x="306" y="188" font-size="12">· 算力调度与训推服务</text>

  <rect x="566" y="16" width="240" height="186" rx="6" fill="#e8eef6" stroke="#334155" stroke-width="1.5"/>
  <text x="686" y="40" text-anchor="middle" font-size="14">运营服务管理平台</text>
  <text x="686" y="58" text-anchor="middle" font-size="12">管成品对外服务</text>
  <line x1="582" y1="68" x2="790" y2="68" stroke="#94a3b8"/>
  <text x="582" y="88" font-size="12">· 数据集目录与检索预览</text>
  <text x="582" y="108" font-size="12">· 上传下载与动态更新</text>
  <text x="582" y="128" font-size="12">· 版本管理与权限管理</text>
  <text x="582" y="148" font-size="12">· 登记注册、确权、挂牌</text>
  <text x="582" y="168" font-size="12">· 交易合同与费用管理</text>
  <text x="582" y="188" font-size="12">· 对外接口与全流程审计</text>

  <path d="M264 100 H286" stroke="#334155" stroke-width="1.5" marker-end="url(#t4-d)" fill="none"/>
  <text x="275" y="92" text-anchor="middle" font-size="11">①</text>
  <path d="M286 150 H266" stroke="#334155" stroke-width="1.5" stroke-dasharray="4 3" marker-end="url(#t4-d)" fill="none"/>
  <text x="275" y="172" text-anchor="middle" font-size="11">②</text>
  <path d="M540 100 H562" stroke="#334155" stroke-width="1.5" marker-end="url(#t4-d)" fill="none"/>
  <text x="551" y="92" text-anchor="middle" font-size="11">③</text>
  <path d="M562 150 H542" stroke="#334155" stroke-width="1.5" stroke-dasharray="4 3" marker-end="url(#t4-d)" fill="none"/>
  <text x="551" y="172" text-anchor="middle" font-size="11">④</text>

  <rect x="14" y="228" width="792" height="128" rx="6" fill="#f8fafc" stroke="#334155"/>
  <text x="26" y="248" font-size="12.5">接口说明（箭头方向即数据流向，虚线为回流）</text>
  <text x="26" y="270" font-size="12">① 下行约束：数据元与值域 · 分级标签 · 质量规则 · 加工与接口开发规范的检查点 — 未登记标准与标签的对象不进入加工</text>
  <text x="26" y="292" font-size="12">② 上行采集：字段级血缘 · 质量评分与稽核结果 · 加工操作留痕 — 作为质量溯源与贯标执行记录</text>
  <text x="26" y="314" font-size="12">③ 资产口径下行：权属登记 · 资产价值等级 · 安全级别与授权策略 — 挂牌与确权以治理侧登记为据</text>
  <text x="26" y="336" font-size="12">④ 使用情况回流：调用计量 · 使用评价 · 外部反馈 — 作为资产价值评估与规则修订的输入</text>

  <rect x="14" y="372" width="792" height="36" rx="5" fill="#e2e8f0" stroke="#334155"/>
  <text x="410" y="395" text-anchor="middle" font-size="12.5">共用：统一身份与权限 · 统一审计日志 · 统一数据集与模型版本血缘（三者作为同一平台的不同组件部署）</text>
</svg>

图 1-6　三个平台的职责分界与接口。数据来源：招标文件第五章 3.2.1 服务采购清单第 1、2、3 项（b0804r02、b0804r03、b0804r04）、3.2.6.1（b1224）、3.2.6.1.2（b1336）。

#### 1.4.2 四条接口的落地口径

四条接口在实施中各有一条可检查的放行条件，口径如下。

下行约束这一条的放行条件是：接入对象的元数据登记、数据元映射、分级标签、入口校验规则四项齐备，未齐备的对象不进入下一环节的加工。这一条是治理侧对加工侧唯一的硬门槛，也是贯标时「过程被规范执行」最直接的证据。

上行采集这一条的放行条件是血缘粒度。血缘须登记到字段级，否则质检发现错样时无法定位到源字段，错样归因就只能停在数据集层面，定向回流无从下手。血缘不完整的对象在质量溯源中标记为不可溯源并优先补齐，这与「数据治理规划（二）」的元数据验收口径一致。

资产口径下行这一条的要点是单一事实源。资源目录条目、权属登记与价值等级只在治理侧维护一份，运营平台的挂牌、确权与交易以此为据展示与校验，不在运营侧另建一套权属台账。

使用情况回流这一条是价值评估的数据来源。使用计量不足一个季度的对象暂不作价值评估，避免以偶发调用量给出等级。

表 1-11 把三个平台的职责、对应的招标文件条款与论述位置并列，便于核对。

表 1-11　三个平台的职责与论述位置对照

| 平台 | 管什么 | 不管什么 | 对应条款 | 论述位置 |
|---|---|---|---|---|
| 治理平台 | 元数据、标准、质量规则、分级与权限策略、资产目录与权属、指标卡、服务目录 | 不承担数据集的加工作业与对外交易 | b1224、b1336 | 第 1.4 节；实施落地见数据治理规划（二）实施路径一节 |
| 数据集加工生产平台 | 七个生产环节的任务编排、工具链运行、知识底座、质检与验证、训推服务 | 不自行定义数据标准与分级口径 | b0804r02、b0804r03 | 四大数据集加工生产总述及其分节；工具链总述及其分节 |
| 运营服务管理平台 | 数据集目录与版本、权限、确权、挂牌、交易与审计，共 16 个功能模块 | 不另建权属台账与质量评分体系 | b0804r04 | 数据集运营平台 |

四条接口都有「不通」的时候，口径须事先写明，否则实施期每遇一次就要议一次。

下行约束不通的典型情形是：某一批数据的分级标签尚未判定，而加工排期已到。处置是**挂起该批而不是降级放行**——按最小必要原则，该批先进入落地区的待判定分区，不进入加工区；待判定分区的存放期上限为十五个工作日，超期未判定的升级至数据治理工作组裁决。这样做的代价是该批次延期，收益是不会出现「先加工后发现密级判高了」这种只能整批作废的局面。

上行采集不通的典型情形是：血缘字段级登记缺失，而质检已经发现错样。处置是**按可溯源程度分档**：能溯源到字段的，走定向回流；只能溯源到批次的，整批复核；连批次都溯不到的，该数据子集标记为不可溯源并暂停发布，同时倒查血缘写入环节的缺陷。第三种情形在实施期应当趋近于零，若出现即为公共层缺陷，进缺陷台账按一级处置。

横向校验与标准下发两条接口的失效处置相对简单：横向校验不通时，以治理侧的规则库版本为准、加工侧按该版本重跑受影响批次；标准下发不通时，加工侧沿用上一版标准并在数据卡中标注所用标准版本号，待标准到位后评估是否需要回溯处理。**四条接口的失效处置均产生记录，记录本身就是贯标评审时「过程异常也被管理」的证据。**

### 1.5 治理机制的运行：五类情形的处置

控制链写的是常态。机制立不立得住，要看非常态怎么办。本项目的治理与数据集交付同时进行，下面五类情形在实施期一定会出现：制度改了而数据集已经发布、两个部门对同一个口径各执一词、历史数据有错要修、人员岗位变了权限要收、某一版数据集发出去之后发现要重发。这五类情形如果没有事先定好的处置办法，每出现一次都要临时开会商量，而商量的结果往往是把问题挂起来——挂起来的问题最终会变成验收时的争议。

下面逐类给出触发条件、处置步骤、责任与审批、平台动作、时限与留痕，并以本项目可能遇到的具体情形说明。表 1-12 在末尾汇总。

#### 1.5.1 制度变更对已发布数据集的影响分析

典型情形：热处理工艺参数中的温度字段，首版数据元标准按「设定温度」定义，现状评估后期发现工艺与质量两个部门实际使用的是「炉内实测温度」，标准需要修订；而制造过程类数据集的首批已经发布，并已被两个场景的验证用例引用。

处置分六步。第一步，变更登记：由提出方填写变更申请，写明修订内容、依据、建议生效时点，数据管理办公室受理并编号。第二步，影响反查：平台按字段级血缘向下游反查，列出受影响的物理表、加工任务、数据子集与已发布版本，反查结果是一份可以逐行核对的清单，不是估计。第三步，影响分级，分三档——一档只是口径说明变化，数据值不变；二档需要重算派生值或重跑加工任务；三档需要重新标注或重新采集。第四步，按档处置：一档更新数据卡中的标准版本号与口径说明；二档重跑受影响的加工任务并发布新版本；三档列入定向回流计划并按批次排期，排期须与数据集交付节点一并核算。第五步，评审与批准：一档由数据管理办公室批准，二档、三档涉及跨域影响的报数据治理委员会。第六步，执行与通知：已发布版本不就地覆盖，发新版本并在数据卡中标注与上一版的差异，场景验证侧据此判断是否重测。

时限：影响分析在变更申请受理后 10 个工作日内出具；二档处置在新版本发布前完成；三档处置的排期在影响分析结论中一并给出。留痕：变更申请单、血缘反查清单、影响分级结论、新旧版本对照、通知回执。

这一步里最容易被跳过的是第二步。没有字段级血缘，影响范围就只能靠人回忆，回忆不全的部分会以「漏改」的形式在验收时暴露出来。这也是本节反复把血缘粒度写成字段级的原因。

#### 1.5.2 跨部门口径争议的裁决

典型情形：同一道备料工序，总工艺路线上称一个名称，车间工艺卡片上称另一个名称；28 道备料工序中有若干道存在这类差异。工艺部门主张以总工艺路线为准，生产管理部门主张以车间卡片为准——车间卡片是实际执行用的。

处置分五步。第一步，争议登记：由发现方或业务数据专责提出，登记内容包括两种口径的表述、各自依据、涉及的字段与数据集范围。第二步，协商：数据管理办公室在 5 个工作日内组织对口工作组与双方归口部门协商；达成一致的，形成口径确认单并更新对应标准。第三步，裁定：协商不成的提交数据治理委员会，按季度例会或专题会裁定，裁定结论为唯一口径并写入标准。第四步，裁定前的数据处置：该字段在平台上标注「口径待确认」，相关数据子集可以继续加工但不进入发布；依赖该口径的场景验证范围相应收窄，并在验证报告中记录当时的数据条件。第五步，裁定后的收口：统一更新标准、映射与已加工数据的标签，已发布版本按 5.1 的影响分析流程处理。

第 1.3.5 节列出的三类冲突——同一对象两套编码、同一指标两个口径、同一数据两种密级——都走这条流程，差别只在裁定原则：编码类建对照不强行统一，指标类两个口径并存且各自登记，密级类取高不取低。留痕：争议登记单、协商纪要、委员会决议、口径确认单、受影响对象清单。

#### 1.5.3 历史数据的修复

典型情形：约 63 万张历史工艺样本中存在扫描件缺页、图纸与工艺卡配对错位、关键字段缺失三类问题，这批数据已经汇聚并进入预训练语料的候选池。

处置分五步。第一步，发现与归因：由质量稽核或数据集质检发现，生成问题工单，按错样归因沿血缘定位到源字段与源批次。第二步，可修复性判定，分三档——可由源系统补数、可由档案原件重新采集、不可修复。第三步，分档处置：可修复的排入修复批次，修复后重新走质检门控；不可修复的从候选池剔除，在数据卡与已知缺陷清单中登记，同时核算该数据子集的规模缺口，缺口通过扩大其他来源的采集范围补齐，补齐方案随当期交付说明一并提交。第四步，版本处置：修复不就地覆盖原始落地件，原始件只读保存，修复结果作为新版本，血缘登记两者关系。第五步，统计处置：修复批次的质量指标与首批分别统计，避免修复后的数据拉高整体基线造成对数据质量的误判。

时限与门限：修复批次在问题确认后 1 个月内排期；同一源批次经两轮修复仍未达门限的，判为源头缺陷，转入采集方案或制度层面的调整，不再在加工侧反复返工。留痕：问题工单、归因结论、修复批次记录、原始件与修复件的血缘、已知缺陷清单。

#### 1.5.4 权限撤销

典型情形：项目期内人员岗位调整、外部评测机构的临时账号到期、某业务域数据因分级上调需要收回已经授出的访问权。

处置分五步。第一步，触发：岗位变动由人力资源域的组织与岗位主数据变更驱动，账号到期由平台按有效期自动触发，分级上调由安全岗提出。第二步，权限反查：平台按权限模型列出该主体当前持有的全部授权，包括数据集下载、接口调用、标注任务与平台功能权限，反查结果需逐项处置，不做批量勾销。第三步，撤销方式分两种：岗位变动与分级上调即时撤销；账号到期给出不超过 5 个工作日的过渡期用于交接，过渡期内的操作全部进审计。第四步，副本核查：已下载的数据集副本不随授权撤销自动失效，因此撤销同时触发副本登记核查，要求持有方在约定期限内销毁或退回并出具回执。第五步，撤销后监控：撤销后的访问尝试进入审计告警，连续出现的按安全事件处置流程办理。

这条链能够成立的前提是组织与岗位主数据先行——不知道谁在哪个岗位，就无从判断谁该被撤权。这也是人力资源域虽然在数据集贡献上权重最低、治理动作却排在第一批的原因。留痕：撤销工单、权限反查清单、过渡期说明、副本销毁或退回回执、撤销后的访问审计记录。

#### 1.5.5 数据集版本的重发

典型情形：某数据子集发布后，发现其中一个来源批次的安全分级判定有误——判高导致部分本可使用的样本被排除，或判低导致脱敏不足。

重发的触发条件写死三条：分级判定有误、质量门限误判、口径变更达到 5.1 所述的二档以上影响。三条之外的问题走修订而不走重发，避免版本号被频繁消耗、下游无从引用。

处置分六步。第一步，冻结：确认后 1 个工作日内冻结该版本的下载与挂牌，已授权方同步收到冻结通知。第二步，范围确定：平台按血缘确定受影响样本范围。第三步，重算与出版：重算受影响样本，出具新版本，并给出与上一版的差异清单，差异按新增、剔除、字段变更三类分别计数。第四步，旧版处置：旧版本标记为「已被替代」并保留可查，不删除——评测结论与场景验证结论都引用了版本号，删除会让这些结论失去依据。第五步，通知：通知已授权方与场景验证侧，由后者判断是否重测。第六步，复测衔接：若重发涉及已出具盖章评测报告的数据集，按评测方的复测口径安排复测，复测结论并入该数据集的质量档案。

留痕：冻结通知、重发申请与批准、差异清单、新旧版本对照、复测安排与结论。

表 1-12　五类情形的处置要素对照

| 情形 | 触发 | 承办与审批 | 平台动作 | 对已发布数据集的处置 | 时限与留痕 |
|---|---|---|---|---|---|
| 制度变更影响已发布数据集 | 标准或制度条款修订申请受理 | 我方项目组承办影响分析；一档由数据管理办公室批准，二档、三档跨域的报数据治理委员会 | 按字段级血缘反查受影响表、任务、子集与版本，输出可逐行核对的清单 | 一档更新数据卡与标准版本号；二档重跑加工任务并发新版本；三档进定向回流计划 | 影响分析 10 个工作日内出具；留变更申请单、反查清单、分级结论、新旧版本对照、通知回执 |
| 跨部门口径争议 | 业务数据专责或加工环节发现两套口径 | 数据管理办公室组织协商；协商不成由数据治理委员会裁定 | 字段标注「口径待确认」，相关子集可加工不可发布 | 裁定后统一更新标准、映射与标签；已发布版本按制度变更流程处理 | 协商在 5 个工作日内启动；留争议登记单、协商纪要、委员会决议、口径确认单 |
| 历史数据修复 | 质量稽核或数据集质检发现错样 | 责任业务域承办修复；数据管理办公室复核修复结论 | 沿血缘归因到源字段与源批次，生成修复批次并重走质检门控 | 原始落地件只读保存，修复结果作为新版本，血缘登记两者关系 | 确认后 1 个月内排期；留问题工单、归因结论、修复批次记录、已知缺陷清单 |
| 权限撤销 | 岗位主数据变更、账号到期、分级上调 | 安全岗承办；数据责任部门确认；L4、L5 相关的报数据治理委员会 | 按权限模型反查全部在手授权，逐项撤销并开启撤销后审计告警 | 已下载副本触发登记核查，持有方按期销毁或退回并出具回执 | 过渡期不超过 5 个工作日；留撤销工单、反查清单、销毁回执、审计记录 |
| 数据集版本重发 | 分级误判、质量门限误判、口径变更达二档以上 | 我方项目组承办；数据责任部门批准；对外已挂牌的报数据治理委员会 | 冻结下载与挂牌，按血缘重算受影响样本并出新版本与差异清单 | 旧版本标记为已被替代并保留可查，不删除；已评测的按复测口径安排复测 | 冻结在确认后 1 个工作日内执行；留冻结通知、差异清单、新旧版本对照、复测结论 |

五类情形的共同点是三条：处置动作都落在具体岗位上，不写「由相关部门协商确定」；处置过程都产生记录，记录既用于内部复核，也是贯标评审时「过程异常也在管理之内」的证据；对已发布数据集一律发新版本而不就地覆盖，使任何一份引用了版本号的评测结论与验证结论都不会因后续修订而失去依据。

### 1.6 决策数据指标体系与治理规划的时点绑定

招标文件要求在治理实施的同时构建决策数据指标体系，支撑高质量数据集建设并强化数据对经营管理决策的支撑能力（b1225、b1226）。这件事有一个容易被忽略的前后关系：指标体系的口径来自数据标准中的指标标准，指标标准的覆盖范围又取决于现状评估盘出的数据元与可得字段。换句话说，指标体系不能与治理规划并行起步，它必须排在标准与资产盘点之后。

本项目把这一关系固化为三个确认时点，写进治理规划的交付节点。表 1-13 逐时点给出完成内容、前置条件与下游依赖。时点的作用是给下游一个可依赖的日期：以决策指标为输入的场景验证按这三个时点排期，不以推定口径提前出结论。

表 1-13　决策数据指标体系的三个确认时点

| 时点 | 完成内容 | 前置条件 | 下游依赖 |
|---|---|---|---|
| 一、指标规范就位 | 指标标准与指标卡规范发布；指标分层（原子、派生、复合）与四项要素定义生效 | 数据元标准首批发布；现状评估完成 | 场景侧按指标卡结构提出指标需求 |
| 二、九业务域指标体系首批成形 | 按九个业务域给出首批指标清单与指标卡草案，口径可向下追溯到数据元与源字段 | 各业务域归口部门确定；参考数据码表首批发布 | 决策类场景的验证基准分册开始编制 |
| 三、指标口径经甲方确认 | 首批指标的计算逻辑与口径由甲方业务归口部门逐项会签 | 治理组织正式发文，有会签主体 | 口径未会签的指标不进入验证基准分册 |

三个时点落在治理规划的第二阶段，与「数据治理规划（二）」的阶段划分一致：指标标准与决策指标体系首批属第二阶段件。以决策指标为数据输入的通用场景验证据此排在场景序列的后段，口径未经确认的指标不以推定口径出验证结论。指标体系的指标选取方法、分层设计与首批规模估算在「数据治理规划（二）」的指标标准一节逐项给出，问答场景的交互设计在「五个通用场景验证方案」一节给出。

指标口径的确认进度是本项目的一项外部依赖。若某业务域的口径在计划时点未能会签，我方的做法是该域指标按草案口径标注「待确认」并暂不发布，相关场景的验证范围相应收窄并在验证报告中记录数据条件，而不是以项目组的推定口径替代业务口径对外出结论。

## 2、技术标准验证要求（3.2.6.7）

### 2.1 现行标准在矿山装备制造场景下的不适配

招标文件要求结合矿山装备制造行业特点与高质量数据集建设实践经验，积极参与全国数标委标准验证和试点应用工作，持续完善标准技术指标，提升行业标准的先进性、科学性与适用性（b1846、b1847）。采购清单第 5 项的第 2 条是同一要求（b0804r06）。

标准验证不是写一份标准建议书交上去。现行的高质量数据集相关标准多数是面向通用语料与通用模态制定的，落到矿山装备制造这个场景上会遇到几类具体的不适配：工艺图纸的符号表达（粗糙度、坡口、倒角、形位公差）在通用文档结构标准里没有对应的元素定义；设备时序数据的工况分段在通用时序数据规范里没有分段依据的约定；焊接参数流与焊道标识的时间窗对齐，其对齐容差在通用多模态对齐规范里没有可引用的取值范围。

这些不适配只有在真实加工上千万级样本时才会暴露出来，而本项目恰好要加工预训练 615 亿 Token、指令微调 89 万条、强化学习偏好 6.6 万组与基准测试 0.95 万条四类数据集，在加工过程中会形成大量可用于标准验证的实测数据。

我方参与标准验证的立足点就是这批实测数据与随之形成的作业规范，而不是概念性的意见。

### 2.2 参与方式与产出

表 2-1　技术标准验证的参与方式与产出

| 参与方式 | 具体做法 | 产出 | 时点 |
|---|---|---|---|
| 标准适用性验证 | 以本项目四类数据集的加工过程为验证载体，按现行规范逐项执行并记录不适配点、执行成本与替代做法 | 标准适用性验证报告，逐项给出指标在矿山装备制造场景下的可执行性结论 | 首轮全量评测完成后 |
| 技术指标实测 | 对评测规范中的量化指标提供本项目的实测取值与分布，包括各模态的质量指标基线、标注一致率、对齐容差、去重阈值 | 技术指标实测数据集与统计附表 | 各批数据集评测完成后滚动提供 |
| 规范草案贡献 | 把本项目形成的标注规范、数据卡规范、质检与验证报告规范整理为可供参考的行业规范草案 | 面向矿山装备制造领域的数据集建设规范草案建议稿 | 规划期第二阶段起滚动提交 |
| 试点应用 | 以本项目的数据集与场景验证作为试点应用案例，提供可公开的实施路径、问题清单与改进建议 | 试点应用案例材料 | 场景验证完成后 |
| 标准征求意见 | 参与相关标准的征求意见与审查环节，按行业实践提出修订建议 | 意见汇总与修订建议 | 按标准制定机构的工作安排 |

参与方式的落点在前三行。标准适用性验证与技术指标实测的依据是《高质量数据集质量评测规范》等现行评测依据，评测的指标体系、评测方法与实施过程在服务方案「数据集质量评测方案」一节论述；本节交付的是以该评测过程为载体的标准验证成果，两者是同一批作业的两种产出，不重复投入。

### 2.3 验证作业的实施流程、记录与质量控制

标准验证不另起一条作业线。四类数据集的加工与评测本身就是验证载体，验证作业挂在既有工序上：工序责任人在执行中发现某一条款无法执行或执行结果不可判定时，当场按统一模板登记一条标准适配问题，其余四步由标准岗与质量岗在既有的批次节奏上完成。

作业分五步。第一步，问题捕获。执行主体是采集、预处理、标注、合成、增强、质检、验证七个环节的工序责任人与评测环节的评测岗；输入是现行标准条款与本批次的真实数据对象；产出是一条标准适配问题记录。判定条件是记录中必须指明具体数据对象——指不出对象的，按意见登记而不进入验证流程。

第二步，复现与定级。执行主体是质量岗。输入是问题记录与该批次的全量样本；产出是复现范围、样本量与占比。定级分三档：一档为条款表述歧义，执行结果因人而异；二档为条款在本场景下缺少可引用的取值范围或判定方法；三档为条款与矿山装备制造的数据形态不适配，按条款执行会得到错误结论。三档均进入后续步骤，一档在建议中以澄清诉求提出，二档、三档以修订诉求提出。

第三步，实测取值。执行主体是质量岗，依据服务方案「数据集质量评测方案」确立的指标体系与评测方法，给出与该条款相关的实测值、统计口径与分布。不重复组织评测：取值取自同一批评测作业的中间结果，只是按标准条款重新归集一次。

第四步，修订建议成文。执行主体是项目组标准岗。输入是前三步的记录与实测值；产出是一条可被第三方按同一方法复算的修订建议，内容包含建议改什么、改后如何判定、支撑该判定的样本量与实测分布。判定条件是复算可行性：第三方拿到同样的数据与方法应当得到同一结论，做不到的退回第三步补实测。

第五步，复核与汇总。执行主体是项目组标准岗与甲方业务归口部门，双方对每条建议签署成立、不成立或证据不足待补三类结论之一；成立的进入半年度汇总件《标准适配问题与修订建议》，证据不足的退回补证据并记录退回次数，同一条退回两次仍无法补足的转为内部留存，不再提交。

一条建议能否成立，判据是证据而不是意见。支撑样本量低于 200 条、或在本项目范围内无法复现的，只登记不成建议；200 条是按基准测试数据集 0.95 万条的 2% 取的首批门限，首轮全量评测完成后按各模态的实际分布复核一次并相应调整。若某一模态的样本总量不足以支撑该门限，该模态的建议改以逐例说明的方式提出，并在建议中写明实际样本量与该样本量下结论的适用范围，不以不足量的样本给出普适结论。

记录用统一模板，字段与填写要求见表 2-2，不由各环节自拟格式——字段不统一，半年度汇总时就无法按标准条款归集。

表 2-2　标准适配问题记录的字段与填写要求

| 字段 | 取值要求 | 填写与复核 | 校验规则 |
|---|---|---|---|
| 问题编号 | 按「SV-年份-序号」由平台顺序生成 | 平台自动 | 全项目唯一，不重用 |
| 发现环节 | 采集、预处理、标注、合成、增强、质检、验证、评测八选一 | 工序责任人 | 必填，须与加工任务编号对应得上 |
| 涉及标准条款 | 标准号、条款号与条款原文摘录三项齐全 | 工序责任人 | 标准号须在本项目引用标准清单内 |
| 问题现象 | 该条款在本项目数据对象上无法执行或执行结果不可判定的具体表现 | 工序责任人 | 至少指明一个具体数据对象 |
| 复现范围与样本量 | 出现该问题的样本条数、占本批次比例、涉及的数据子集 | 质量岗 | 样本量低于门限的只登记、不成建议 |
| 本项目的处理办法 | 当前采用的替代做法及其依据 | 工序责任人 | 必填，须与作业规范中的实际做法一致 |
| 实测取值 | 与该条款相关的实测指标值、统计口径与分布 | 质量岗 | 须注明取值所属的评测批次 |
| 问题定级 | 一档表述歧义、二档缺取值范围或判定方法、三档与数据形态不适配 | 质量岗 | 二档、三档须附实测取值 |
| 建议的修订方向 | 建议条款怎么改、改后如何判定 | 项目组标准岗 | 须可被第三方按同一方法复算 |
| 复核结论 | 成立、不成立、证据不足待补三选一 | 项目组标准岗与甲方业务归口部门会签 | 两方签署齐全方可进汇总件 |
| 处置去向 | 进半年度汇总件、转为规范草案条目、内部留存三选一 | 数据管理办公室 | 进汇总件的须登记汇总件编号与提交日期 |

记录与汇总件进入治理文档体系统一编号与归档，并作为贯标评审中「过程被规范执行」的一类执行记录。记录的完整性按季度自查：抽取当季各环节的加工任务，核对该季度内发现的适配问题是否都有对应记录与去向，缺记录的补登记并倒查该环节的登记习惯。

### 2.4 组织分工与可检查的交付承诺

标准化工作的分工是确定的：标准的立项、起草、审查与发布由归口单位主导，参与单位提供实测证据与修订建议。我方在本项目中承担的正是后者——以四类数据集的真实加工与评测过程为载体，提供可复算的验证材料、实测数据与修订建议，并按标准化技术组织的工作安排参与试点应用。相关知识产权产出（论文、发明专利、软件著作权）的指标与安排在「技术创新与机制创新」一节论述（b0804r06）。

我方就此作出三项可被逐条检查的承诺：其一，在数据集加工过程中按统一模板记录标准适配问题，每条记录包含问题现象、涉及的标准条款、本项目的处理办法、建议的修订方向与支撑该建议的样本量；其二，每半年汇总一次形成《标准适配问题与修订建议》，经招标方确认后由招标方决定是否向归口单位提交；其三，若归口单位开展标准验证或试点应用工作并需要实测数据，在招标方同意且符合保密要求的前提下提供去敏后的验证数据与测试结论。

三项承诺的交付节点、产出形式与验收方式列入治理成果的交付口径（第 4 章），不单独计量工作量。之所以挂在半年度汇总上而不另设里程碑：标准验证的成效取决于归口单位的工作节奏，设为独立里程碑会让项目进度受制于外部环节，而半年度汇总既保证工作持续进行，又使进度可控。

## 3、数据标注规范建设要求（3.2.6.9）

### 3.1 需要解决的标注口径与流程问题

招标文件要求聚焦多模态数据高质量供给需求，制定覆盖不同数据类型的标准化、流程化标注规范，解决多模态数据标注口径不一、流程混乱、与业务场景适配性不足的问题（b1851、b1852）。采购清单第 5 项的第 4 条是同一要求（b0804r06）。

这三个问题在本项目的具体表现是可以指认的。口径不一：同一道备料工序在总工艺路线上叫一个名字、在车间卡片上叫另一个名字，28 道备料工序在不同系统中的名称差异若不先归一，标注出来的工序标签互相对不上。流程混乱：图纸与工艺卡的配对关系在甲方现状中未建立，约 63 万张历史工艺样本若没有配对规则就直接发给标注员，标注结果无法形成成对监督样本。与业务场景适配性不足：缺陷描述是自由文本，标注员按字面分类得到的标签与质量管理部门实际使用的缺陷类型对不上，标出来的数据场景侧用不了。

因此标注规范不能只写标注流程，它要先把标签体系的来源锁住——标签取自治理侧的参考数据码表与数据元标准，不由标注环节自创。这是本节把标注规范放在治理部分而不是加工部分的理由。

### 3.2 规范体系的构成

规范按一份总则加分册的结构组织，共十份，列入治理文档体系一并交付。

表 3-1　数据标注规范分册清单

| 序号 | 分册 | 覆盖数据类型 | 规定的核心内容 | 标签来源 |
|---|---|---|---|---|
| 1 | 标注规范总则 | 全部 | 标注流程、角色与职责、标注员培训与准入、一致性要求、返工条件、交付物格式 | — |
| 2 | 文本与文档标注分册 | 管理制度、公文、合同、技术文档 | 段落与条款切分粒度、实体与关系标签集、引用关系标注 | 业务术语标准 |
| 3 | 图纸与工艺图标注分册 | 设计图纸、工艺图、工艺卡 | 图元与尺寸标注、符号表达（粗糙度、坡口、倒角、形位公差）的标注口径、图卡配对规则 | 数据元标准、物料与工序主数据 |
| 4 | 图像标注分册 | 交检拍照、缺陷图像、装配现场影像 | 目标框与分割粒度、缺陷类型标签层级、拍摄条件与不可用判定 | 缺陷类型参考数据码表 |
| 5 | 时序数据标注分册 | 振动、温度、电流、液压等测点数据 | 工况分段依据、异常区间标注、缺段与失效测点标注 | 设备与测点主数据 |
| 6 | 视频标注分册 | 作业过程录像、巡检视频 | 事件区间切分、动作标签集、视频与文本对齐容差 | 工序主数据 |
| 7 | 对话与工单标注分册 | 服务工单、运维记录、问答语料 | 轮次切分、意图与槽位标签集、工单转对话的字段映射 | 业务术语标准、故障类型码表 |
| 8 | 推理过程标注分册 | 思维链与推理步骤 | 推理步骤粒度、步骤有效性判定、关键依据标注 | 指标标准、工艺要求数据元 |
| 9 | 标注一致性校验规范 | 全部 | 一致率计算方法、抽检比例与抽检方式、争议裁决流程、低一致率的返工口径 | — |
| 10 | 标注质量与质检衔接规范 | 全部 | 标注交付物进入质检的入口条件、错样归因回流到标注环节的处置流程与时限 | 数据质量规则库 |

十份分册中第 1、9、10 三份是跨模态的通用件，先行发布；第 2 至 8 份按数据集加工的批次顺序发布，与「数据治理规划（二）」第一阶段的标准发布节点对齐。各分册的编制、评审、发布与培训准入按第 3.3 节的六阶段口径执行。

### 3.3 规范的编制、评审与发布

十份规范不是一次写完再统一发布。总则与两份跨模态通用件先行，模态分册按数据集加工的批次顺序滚动发布，使每一批标注作业开工时都有已生效的规范可依。编制与发布按六个阶段推进，每个阶段的输入、承办、产出与通过条件事先写死，不通过的去向也一并写明。

需求输入阶段确定一件事：这一份分册要支撑哪些训练目标与哪些验证用例。输入有两路——四类数据集的数据卡对该模态提出的字段与标签要求，以及 11 个场景验证方案中反向落下来的能力点。两路需求合并成标注需求清单，逐条标明对应的数据子集与验证用例，不能对应到任何一条的需求退回提出方说明用途。这一步的意义在于把标签体系的来源锁死在下游用途上，避免出现标了一批用不上的标签、而场景要的标签没有标。

标签取数阶段只做一件事：把本分册要用的标签集从治理侧取出来。工序、物料、设备、测点、缺陷类型、故障类型等标签一律取自参考数据码表与主数据，术语取自业务术语标准，字段定义取自数据元标准。分册中出现的每一个标签都要能指回码表中的一行；指不回去的，先走码表的新增申请流程，申请通过后再写入分册。这一条是标注规范放在治理部分编制的直接原因，也是它与标注作业方法分开成件的分界线。

草案编制阶段产出分册草案，内容按总则规定的统一体例组织：适用范围、标签集与取值、标注粒度与判定规则、典型样例与边界样例、不可标注情形的判定、交付物格式与校验项、一致性要求与返工条件。样例必须取自本项目的真实数据对象，不用通用示意图；边界样例尤其要给足，标注员之间的分歧绝大多数出在边界上。

三道评审依次进行，三道都通过才发布。第一道由项目组内部评审，核体例完整性与可执行性——判据是一名未参与编制的标注员仅凭该分册能否独立完成一组试标。第二道由甲方业务归口部门评审，核标签体系与本域实际业务口径是否冲突——判据是标签集中的每一个取值在业务侧都有确定含义，且与该部门在用的分类不矛盾。第三道由管理层评审，确认责任分工、评审与变更的审批路径。任一道不通过的，退回草案编制阶段并记录不通过的具体条目与理由，修订后重新进入该道评审，不跳道。

发布与版本登记阶段由数据管理办公室执行：分册在治理平台上登记版本号与生效日期，标注任务创建时强制引用生效版本，未登记版本不可被引用。发布同时下发标签集到标注工具，使标注员在工具中只能从已发布标签集中选择。

培训与准入阶段是规范能不能落地的最后一关。标注员上岗前须通过本分册的培训与试标考核，试标样本由质量岗从真实数据中抽取并事先标定；试标结果与标定答案的一致率达到准入门限方可承接正式任务，未达门限的补训后重试，两次未达的不承接该模态的标注任务。分册发布新版本且涉及标签集或判定规则变更的，已上岗标注员须重新试标。

六个阶段的输入、承办与审批、产出、通过条件与不通过的去向汇总于表 3-2。

表 3-2　标注规范的编制与发布流程

| 阶段 | 输入 | 承办与审批 | 产出 | 通过条件 | 不通过的去向 |
|---|---|---|---|---|---|
| 一、需求输入 | 四类数据集数据卡的字段与标签要求；11 个场景验证方案反向落下的能力点 | 我方项目组承办，对口工作组确认 | 本分册的标注需求清单 | 每条需求可对应到具体数据子集与验证用例 | 对应不上的退回提出方说明用途，不进清单 |
| 二、标签取数 | 参考数据码表、主数据、业务术语标准、数据元标准 | 标准岗承办，数据管理办公室批准 | 本分册的标签集与取值范围 | 每个标签可指回码表中的一行 | 指不回去的走码表新增申请，通过后再写入分册 |
| 三、草案编制 | 需求清单、标签集、真实数据样例 | 我方项目组 | 分册草案与样例集 | 体例齐备；边界样例覆盖已知分歧点 | 补齐后再送评审 |
| 四、三道评审 | 分册草案 | 项目组内部评审、甲方业务归口部门评审、管理层评审 | 评审意见与修订稿 | 三道依次通过，每道意见逐条关闭 | 退回编制阶段并记录不通过条目，修订后重进该道，不跳道 |
| 五、发布与版本登记 | 评审通过的分册 | 数据管理办公室 | 平台上的生效版本与标签集下发 | 版本号与生效日期登记完毕，标签集已下发到标注工具 | 未登记版本不可被标注任务引用 |
| 六、培训与准入 | 生效分册、标定试标样本 | 质量岗组织，项目组实施 | 培训记录与试标考核结果 | 试标一致率达到准入门限 | 补训后重试，两次未达的不承接该模态标注任务 |

### 3.4 规范的执行、检查与修订

规范发布之后要能被查出有没有被执行，否则它只是一份文件。执行、检查与修订三件事按下述口径固定下来。

执行靠平台约束而不是靠提醒。标注任务在创建时必须引用一个已生效的分册版本号，引用不到的任务创建不成功；标注工具中的标签集由平台从参考数据码表下发，标注员不能在工具中自建标签，确需新增的走码表新增申请，申请期间该样本挂起不强行归类。交付物的格式与必填校验项由工具按分册配置自动校验，校验不通过的批次不进入质检环节。这三条合起来构成标注环节的入口约束，与加工链路上其他环节的门控口径一致。

检查分三层。任务层由平台自动校验，对象是每一个标注任务，核的是规范版本引用、标签集合法性与交付物格式，频次是实时，不通过即阻断提交。批次层由质量岗按批抽检，对象是已提交的标注批次，核的是标注员之间的一致率与标注结果同业务口径的符合性，抽检比例按批次规模与该模态的历史一致率确定，低于门限的整批返工并提高下一批的抽检比例。周期层按季度由数据管理办公室组织规范执行情况检查，对象是当季全部标注作业，核的是规范版本是否及时更新、新增标签申请是否走完流程、返工记录与整改是否闭环，检查结论进治理执行记录。

一致性要求的量化口径以实测基线为准。首轮标注完成后按模态分别出具标注员间一致率基线，基线连同抽检方法写入项目质量计划，并作为返工条件的判定依据；此后各批次以逐步接近该基线之上的水平为目标，逐批记录实测值与基线的差距。某一模态连续两个批次低于基线的，处置按三档推进：先收紧——提高抽检比例并对分歧集中的标签补充边界样例；再隔离——该批次不进入发布版本，仅作内部复核；仍不达标的复议——由质量岗与业务归口部门共同复核该模态的标注粒度与标签划分是否本身不可操作，必要时修订分册而不是反复返工。

修订的触发条件写死四条：新增标签申请在同一分册上累积到一定数量，说明标签集覆盖不足；某一标签的一致率持续低于基线，说明判定规则表述不清；场景验证侧反馈某一标签不可用或粒度不合用；上游的参考数据码表、数据元标准或业务术语标准发生修订。四条中任一条成立即启动修订。修订稿走与编制阶段相同的三道评审，通过后发布新版本并登记版本差异；已按旧版本标注的数据按制度变更的影响分析流程处理——只是口径说明变化的更新数据卡中的规范版本号，需要重标的列入定向回流计划并按批次排期。

三层检查的对象、方法与频次、判定依据、不达标处置与留痕汇总于表 3-3。

表 3-3　标注规范执行情况的三层检查

| 层次 | 检查对象 | 方法与频次 | 判定依据 | 不达标处置 | 留痕 |
|---|---|---|---|---|---|
| 任务层 | 每一个标注任务 | 平台自动校验，实时 | 规范版本引用有效、标签取自已下发标签集、交付物格式与必填项齐备 | 阻断提交，退回修正；标签缺失的走码表新增申请，样本挂起 | 校验日志、阻断记录、新增标签申请单 |
| 批次层 | 已提交的标注批次 | 质量岗抽检，按批次 | 标注员间一致率与基线的差距；标注结果同业务口径的符合性 | 低于基线的整批返工并提高下一批抽检比例；连续两批低于基线的按收紧、隔离、复议三档处置 | 抽检记录、一致率实测值、返工单、整改关闭记录 |
| 周期层 | 当季全部标注作业 | 数据管理办公室组织，按季度 | 规范版本是否及时更新、新增标签申请是否走完流程、返工与整改是否闭环 | 出具检查结论与整改项，整改项按期关闭并在下季度复查 | 季度检查报告、整改台账、复查结论 |

三层检查的记录与标注规范本身一并归入治理文档体系，既用于标注质量的内部复核，也作为贯标评审中标注过程被规范执行的证据。标注粒度的具体取值、标注工序的组织、预标注与人工复核的配合方式在「数据加工生产（二）」一节给出，承载标注作业的四类标注工具链在「工具链二」一节给出，标注模板与样例在附录佐证卷提供。

## 4、治理成果的交付口径

### 4.1 七类交付物的合计口径

治理部分的交付物按七类归并，表 4-1 给出合计口径与分布。各成果物的章节骨架、验收口径与提交节点在两个子节的对应章节逐项给出。

表 4-1　治理成果的交付口径

| 类别 | 内容 | 数量 | 论述位置 | 单元 |
|---|---|---|---|---|
| 现状评估成果 | 数据治理现状诊断报告、高质量数据集验证场景数据需求清单 | 2 份 | 数据治理规划（一）现状评估一节与成果物清单 | b1219、b1220、b1236 |
| 九域规划成果 | 招标文件逐行列明的治理文档，我方按 37 份编制，不低于不少于 25 份的要求 | 37 份 | 数据治理规划（二）治理规划文档交付清单 | b1221—b1223、b1331—b1334 |
| 配套细则 | 落实治理机制所需的职能级细则（治理组织运行细则、数据口径确认与争议处理细则、数据管理考核细则） | 3 份 | 数据治理规划（一）成果物清单中的三份职能级细则 | b1249、b1254、b1255 |
| 标注规范 | 标注规范总则、七个模态分册、一致性校验规范、质检衔接规范 | 10 份 | 第 3 章表 3-1 | b1851、b1852、b0804r06 |
| 标准验证成果 | 标准适用性验证报告、技术指标实测数据与统计附表、规范草案建议稿、试点应用案例材料 | 4 类 | 第 2 章表 2-1 | b1846、b1847、b0804r06 |
| 治理平台 | 治理平台建设与九项治理内容在九个业务域落地运行 | 1 套 | 第 1.4 节；数据治理规划（二）实施路径一节 | b1224、b1226、b1336 |
| 决策指标体系 | 九个业务域首批指标清单与指标卡，口径经业务归口部门会签 | 按九域首批范围 | 第 1.6 节；数据治理规划（二）指标标准一节 | b1225 |

治理文档的交付数量按「只增不减」执行：37 份是下限，实施中若某一主题需单独成文则增编并登记入引用关系表；拆分或合并须提交变更申请并保留与招标文件原清单的逐项对应关系，使验收时可逐行核对（b1334）。各份文档的全文按项目计划在相应阶段提交评审，投标阶段提交的是编制方案与模板样例。

### 4.2 三十七项规划成果的落地对应

一份治理文档交上去，怎么证明它不只是文本？本项目的答法是：每一项规划成果都要在治理平台上有对应的配置项，配置项运行起来产生对应的记录，记录又对应到数据集交付中的某一个环节。三者齐备，这份成果才算落了地。表 4-2 逐项给出这一对应关系，三十七项逐行可核。

表 4-2　三十七项规划成果与平台配置、运行记录、数据集交付的对应

| 序号 | 规划成果 | 平台配置项 | 产生的运行记录 | 与数据集交付的关系 |
|---|---|---|---|---|
| 1 | 数据战略管理办法 | 战略任务与度量指标登记 | 战略评估会议纪要、任务进度记录 | 治理与加工的阶段排期由此对齐，数据集分批交付节点据此确定 |
| 2 | 数据战略规划 | 路线图与里程碑配置 | 里程碑完成确认记录 | 四类数据集的交付节奏与治理路线图取同一时间轴 |
| 3 | 数据战略实施计划 | 工作包与责任岗位配置 | 工作包进度与偏差记录 | 工作包中的标准与规则件是数据集加工的前置条件 |
| 4 | 战略评估报告 | 度量指标取数配置 | 周期评估结论 | 评估结论可触发排期调整，影响后续批次的交付时点 |
| 5 | 数据治理顶层规划方案 | 治理域与组织模型初始化 | 方案评审与发布记录 | 划定九项治理内容的落地范围，数据集加工在此范围内运行 |
| 6 | 数据治理组织架构 | 角色、岗位与审批流配置 | 审批流水 | 数据集发布、分级与授权的审批主体由此确定 |
| 7 | 全套数据治理顶层管理制度 | 制度库条目与条款索引 | 制度发布与修订记录 | 制度条款是数据集交付合规性核查的依据 |
| 8 | 数据文化建设方案 | 培训与考核记录模块 | 培训签到、考试与案例作业记录 | 标注员与数据专责的准入培训并入执行，影响标注一致率 |
| 9 | 数据模型分层架构 | 分层模型与表关系登记 | 模型变更记录 | 加工中间表按分层归位，血缘链路据此可读 |
| 10 | 数据分布及数据流图 | 系统与数据流登记 | 流转链路变更记录 | 采集范围与断点处置据此确定 |
| 11 | 数据集成共享管理规范 | 连接器与接口配置校验规则 | 接口调用日志、配置校验结果 | 17 套系统的汇聚动作按此规范执行 |
| 12 | 元数据管理办法 | 元数据模型与采集任务配置 | 元数据变更记录、字段级血缘登记 | 字段级血缘是错样归因与定向回流的前提 |
| 13 | 数据资产管理办法 | 资产登记字段与流程配置 | 资产上下架记录 | 数据集作为资产登记并挂接权属 |
| 14 | 数据资源目录 | 目录分类与条目 | 目录变更记录 | 数据集目录与治理资产目录共用权属与分级口径 |
| 15 | 资产价值评估办法 | 价值评估模型参数 | 评估结论记录 | 数据集的价值等级作为运营挂牌的定价参考 |
| 16 | 数据资产运营流程规范 | 申请、审批、交付流程配置 | 申请与交付记录 | 数据集对外服务走同一条流程，不另设通道 |
| 17 | 数据标准管理办法 | 标准生命周期与版本策略配置 | 标准发布与废止记录 | 数据集字段所引用的标准版本号写入数据卡 |
| 18 | 业务术语标准 | 术语库 | 术语变更记录 | 知识本体与标注标签引用术语，不另立一套 |
| 19 | 参考数据标准 | 码表与值域配置 | 码表版本记录 | 标注标签集取自码表，保证跨批次标签可对齐 |
| 20 | 数据元标准 | 数据元与物理字段映射 | 映射变更记录 | 质检规则引用数据元与值域作为校验依据 |
| 21 | 指标标准 | 指标卡模板与计算配置 | 指标口径会签记录 | 决策类场景验证的指标输入 |
| 22 | 标准映射对照表 | 系统字段到数据元的映射表 | 映射例外登记与复核结论 | 多源同义字段合并的依据 |
| 23 | 数据质量管理办法 | 质量流程与角色配置 | 稽核任务记录 | 数据集质检门控与业务质量规则同源 |
| 24 | 数据质量需求清单 | 质量维度与对象范围配置 | 需求确认记录 | 决定哪些字段进入质检门控 |
| 25 | 数据质量校验规则库 | 规则与阈值配置 | 规则命中与评分记录 | 质检门控直接调用，规则版本写入质检报告 |
| 26 | 质量分析报告 | 质量报表配置 | 月度质量分析报告 | 构成数据质量档案的组成部分 |
| 27 | 质量问题整改台账 | 工单流程配置 | 工单与复核记录 | 错样归因回流的承载件 |
| 28 | 数据合规管理制度 | 合规检查项配置 | 合规核查记录 | 数据来源合法性与去标识化处理的检查依据 |
| 29 | 数据安全管理办法 | 安全策略与审计配置 | 访问审计日志 | 数据集全流程审计的制度依据 |
| 30 | 数据安全分级标准 | 分级标签体系配置 | 分级审批单、标签变更记录 | 数据集样本的可用范围与脱敏要求由分级决定 |
| 31 | 数据权限管理规范 | 权限模型与审批矩阵 | 授权与撤销记录 | 数据集下载与接口调用的授权依据 |
| 32 | 数据需求管理规范 | 需求单模板与评审检查点 | 需求单与评审记录 | 新增数据需求进入采集范围的入口 |
| 33 | 数据设计开发规范 | 开发阶段检查点配置 | 评审检查表 | 加工任务与接口开发的放行条件 |
| 34 | 数据运维管理制度 | 运维工单与监控配置 | 运维工单、监控告警记录 | 汇聚与加工作业的连续性保障 |
| 35 | 数据退役管理规范 | 退役标记与归档策略配置 | 退役申请与执行记录 | 被数据集引用的对象转为只读而非删除 |
| 36 | 外部数据引入管理办法 | 外部来源登记与合规校验配置 | 引入审查记录 | 外部语料进入预训练候选池的前置审查 |
| 37 | 数据开放共享管理规范 | 服务目录与服务分级配置 | 服务授权与计量记录 | 数据集对外服务的分级、限流与计量依据 |

这张表双向可用。验收时从左往右查：每一项规划成果都要能在平台上指出对应的配置与记录，指不出来的成果只是一份文本，不计入落地。实施时从右往左查：数据集交付过程中遇到的口径、权限或质量问题，都能回到某一项成果去修订，而不是在加工侧临时打补丁——临时补丁改的是单个批次，修订成果改的是此后所有批次。

三十七项的名称、形态、所属规划域与提交节点在「数据治理规划（二）」的治理规划文档交付清单中逐行列出，与本表同序，可并排核对。

## 5、前置条件与回退口径

两个子节已分别列出域内的前置条件与应对。站在总述一级，有三项条件对治理部分的整体节奏起决定作用，在此单列并给出回退口径。

表 5-1　治理部分的总述级前置条件

| 前置条件 | 不成立时的影响 | 我方应对 | 回退口径 |
|---|---|---|---|
| 治理组织正式发文设立 | 九域规划成果无审批与会签主体，制度无法发布，贯标缺少组织维度的证据 | 项目启动会提交三层组织架构与岗位职责建议稿，推动按企业文件发布程序设立 | 组织设立前成果物只出送审稿，以项目联合工作组形式临时议事，决议事后追认 |
| 源系统按已授权范围开放只读接口，涉及原厂的配合到位 | 相关业务域无法汇聚，诊断只能依赖访谈与文档，依赖该域的数据集样本量不足 | 按域分批推进，优先推进已可开通的域；接口协调按月与甲方对接 | 未开通的域以现场导出或离线交换作为过渡，并在数据卡中记录来源方式；诊断报告标注未取证的过程域，授权到位后出补充章节 |
| 执行记录的积累周期满足三级要求 | 送审时定级被核减 | 制度与标准发布节点前置，流程优先上线，使加工过程本身产生记录 | 调整送审时点而非压缩记录周期；按能力域分批送审，记录充分的域先行 |

三项条件里前两项是进度变量，第三项是定级变量。本节的处理方式是把它们写成前提而不是隐含假设，并给出过渡办法与可重新核算的口径，使治理进度、数据集规模与贯标时点之间的关系在前提变化时可被重新计算，而不是在交付时才发现差距。
<!-- 覆盖·节级：b1217 -->
