抓出来的数据能不能用，取决于它能不能干净地落进业务系统。字段映射表怎么建、单位与编码怎么归一、校验规则放在哪一层，以及回写时如何用幂等与留痕机制避免脏数据污染主数据——这几件事决定了集成是省事还是添乱。
图纸抽取项目验收时常有这样的场面：正确率报表很漂亮，业务系统却迟迟不敢开接口。原因往往不是识别不准，而是数据形态对不上——单位不统一、编码不在字典里、重跑一次就多出重复记录。
一、抓得准不等于用得上
抽取侧关心「这个格子里的字读对了吗」，业务系统关心「这条记录能不能作为主数据被下游引用」。后者严格得多：字段要有类型与取值域，物料编码要在主档里存在，版本要能和现有 BOM 对上。所以集成应在立项时就设计成独立的中间层——上游接抽取结果，下游接 PLM / ERP，映射、归一化与校验都收敛在这里。
二、字段映射表：从图纸字段到业务字段的一一对应
映射表至少要有这几列
- 图纸字段名与它在图上的位置（标题栏 / 明细表 / 说明区）。
- 目标系统的表名、字段名、数据类型与长度限制。
- 转换规则与是否必填，以及缺失时的策略（阻断、留空、写默认值）。
- 责任人。每行都要有人签字确认。
不要跳过这张表直接写代码——规则散落在代码里，半年后没人说得清「为什么这个字段这样填」。
处理一对多与多对一
真实映射很少是干净的一对一：图纸上一个「规格」可能要拆成 ERP 的公称直径、壁厚、材质；PLM 的物料描述又由图名、规格、标准号拼接而成。这类映射要单独标注并配示例。
三、单位、编码与命名的归一化
归一化是脏数据的主要来源，三类问题最常见：
- 单位。同一批图纸可能混有 mm、cm、m 和英寸，还有「1.5 米」这类表述；中间层统一换算到基准单位并保留原文。
- 编码。材质写法五花八门：Q235、Q235B、Q235-B、「碳钢 Q235」。要维护同义词到标准编码的字典并由物料部门运营。
- 命名与全角半角。括号、连字符、空格混用会让精确匹配失效，入库前统一规范化。
归一化命中不了的值不要猜，走人工确认队列并把新写法回流到字典。
四、校验放在哪一层：抽取侧、中间层还是目标系统
- 抽取侧：只做格式与自洽校验——图号符合编码规则、数量为正整数、日期可解析。
- 中间层：做业务规则校验，如编码是否在主档、单位是否可换算、BOM 合计是否与总装数一致。绝大多数校验放这里，因为它能同时看到源数据与目标系统状态。
- 目标系统：只保留最后一道强约束（唯一键、外键、字段长度）；它报错意味着中间层漏了规则。
如果目标系统频繁抛出约束错误，说明校验层次设计失败了。中间层的职责就是让写入几乎永不失败。
五、回写的幂等设计：重复执行不产生脏数据
批量回写一定会遇到失败重试与手工重跑。幂等的核心是「同一批数据执行 N 次等于执行 1 次」：给每条记录算业务幂等键（图号 + 版本 + 字段集哈希），不存在则插入，哈希一致则跳过，不同则更新并记录变更。
还要区分新增与更新的权限：典型事故是重跑把人工修正过的字段覆盖回识别值——给字段加来源标记，人工值默认不被自动覆盖。
六、留痕与回滚：出问题时怎么追到那一次写入
每次写入都要能追溯到批次、图纸、图上位置、置信度与执行人；这些信息与业务数据分开存储，量不大但排查时不可替代。
回滚不建议做数据库整体还原。更实际的做法是按批次记录变更前后的值逐条反向写入，且回滚本身也生成新批次，保证审计链条不断。
七、灰度接入与对账
正式开通写入前先跑影子模式：照常执行映射与校验，但只生成待写清单不真正写入，再与人工填报结果对账，两三轮后差异会收敛。
之后按范围灰度：先一条产品线，再一个事业部，最后全量；每阶段保留日对账报表，差异超阈值就自动暂停写入，让故障停留在报表里。
小结
难点不在接口协议，而在映射的严谨、归一化的完备、校验的分层与回写的可控。做扎实这四件事，抽取结果才能成为主数据，而不是没人敢用的导出文件。