坑一：没有主数据
同一客户在三个系统里有三种编号，接入后无法合并，回答里出现互相矛盾的信息。为什么：主数据不统一时，模型会同时把两套事实当真。改法：先确定主数据来源与唯一键，再谈接入，口径不清宁可少接一个源。
坑二：导出件当源头
业务同事手工维护的表格看起来最方便，但改动无法回流、版本无人管理。为什么危险：模型会把这个表格当成权威事实，错误被系统性放大。改法：确认权威系统，表格只作补充并标注更新时间与来源人。
坑三：编码格式漂移
字符集、日期格式、小数点与单位在不同批次间变化，导致解析失败或数值错位。怎么做：在接入层做显式类型转换与校验规则，异常数据落入隔离区而不是静默丢弃，否则缺口会越积越大，最后无法追溯。
坑四：测试数据带敏感信息
直接把生产库复制到测试环境，个人信息随之扩散，审计时难以解释。规避：测试数据先脱敏或使用合成数据，确需真实样本时限定字段、人员与保存期限，用完按约定销毁并留存记录，这条边界要写进数据处理协议。
坑五：同步没有对账
任务显示成功但数据少了一批，问题在业务侧发现时已过数周。改法：每日比对源与目标的记录数与关键汇总值，差异超过约定范围即告警并暂停下游写入。怎么做：把规则与责任人提前写进值班手册，别等季度对账时才发现缺口。
适用与不适用
适合谁
- 正在做数据接入、担心上线后数据失真的团队
- 多系统并存、主数据不统一的企业
- 需要向审计说明数据使用合规性的组织
不适合谁
- 仅接入单一系统、数据结构稳定的简单场景
- 不涉及任何真实业务数据的演示环境
典型场景
某制造集团的设备维保助手接入三个系统后，同一台设备出现两个保养周期。排查发现主数据未统一，且其中一个来源是车间手工表。团队确定以设备台账为主数据，手工表降级为参考并加更新时间标记，回答矛盾随之消失。
可执行步骤
- 为每类核心实体确定主数据来源与唯一键，并把规则写入接入说明。
- 区分权威系统与人工补充表格，并为补充数据标注来源与更新时间。
- 在接入层设置显式类型转换与校验规则，让异常数据自动进入隔离区。
- 测试环境使用脱敏或合成数据，并限制访问人员、导出权限与保存期限。
- 配置每日对账，差异超过约定范围时自动告警并暂停下游写入任务。
常见坑
- 同一实体存在多套编号，回答前后矛盾，用户很快对系统失去信任，客服也解释不清原因。
- 手工维护的表格被当成权威数据，错误随每次同步被固化进知识库，越用越难纠正且无人察觉。
- 编码异常被静默丢弃，业务以为数据完整，实际缺口随时间越来越大，直到对账才暴露，补数成本很高。
- 生产数据直接复制到测试环境，个人信息扩散后几乎无法彻底回收，审计时只能被动解释。
自检与验收清单
- 每类核心实体是否明确了唯一的主数据来源与唯一键
- 人工补充数据是否标注来源、更新时间和责任人
- 异常数据是否有隔离区、人工处理流程和责任人
- 测试数据是否脱敏并限制访问人员、导出与期限
- 对账是否同时覆盖记录数、关键汇总值与差异处置
常见问题
主数据不统一能先上线吗？
可以，但要把范围限制在不依赖该实体的场景。若核心问答涉及客户或设备这类实体，口径不统一会直接产生矛盾答案，上线越快，纠正成本越高，不如先花两周统一口径再推进。
手工表格完全不能用吗？
可以作为补充信息，但要标注来源与更新时间，并明确它不覆盖权威系统。关键是让模型和使用者知道这份数据的可信级别，而不是把所有数据当作同等事实，否则矛盾无法解释。
对账频率多高合适？
与数据变化频率匹配。高频变动的业务数据建议每日对账，低频主数据可按周。对账的目的不是追求零差异，而是让差异在可控时间内被发现并解释清楚，否则对账会流于形式。