【轨物方案】企业数据不少，为什么 AI 仍然答不好业务问题？
不少制造企业已经上线 ERP、PLM、MES、OA，也积累了大量图纸、报价单、工艺文件和质量记录。按理说，数字化基础并不薄弱。但当管理者问出一个具体问题时，答案往往还是要靠员工逐个系统查找、复制数据、核对口径，再凭经验给出结论。
例如：某个型号过去一年报价差异主要来自哪里？材料价格上涨后，哪些在手订单的毛利空间受到影响？同一种结构在不同车间的工时差异集中在哪道工序？这些问题并不只是“搜索一份文件”，而是需要多个来源的数据共同参与判断。
这正是制造业知识底座建设中的关键难题：企业拥有数据，不代表数据已经具备协同分析的条件。
ERP 管理订单、采购和库存，PLM 管理产品结构与设计资料，MES 记录生产执行，CAD 保存图纸，质量系统记录检验与返工。每套系统都可能完成了自己的任务，但它们通常围绕不同业务流程建立，字段、编号、时间口径和数据粒度并不完全一致。
同一台设备，在技术部可能使用产品型号，在商务台账里使用报价编号，在采购记录里对应物料编码，在生产环节又关联工单号。要把这些数据放到一起，首先要确认它们指向的是同一个业务对象。
其次，即便对象能够对应，统计口径也未必一致。材料价格是含税还是未税？工时采用标准工时还是实际工时？成本按下单时点还是当前价格计算？历史成交价是否包含运输、安装或特殊付款条件？如果这些问题没有定义清楚，跨表计算得出的数字可能看起来精确，实际上却不可比较。
所以，制造企业的数据难题并不只是“数据散落在不同系统”，还包括主键不统一、字段语义不一致、数据时点不同、业务规则没有显式化，以及缺少对结果负责的确认机制。
大模型擅长理解自然语言、归纳文本和组织答案，但它不能凭空知道企业内部每个字段的真实含义，也不能仅凭一段提问就保证不同系统的数据已经正确关联。
如果用户问“这个型号上次报多少”，系统必须先明确“这个型号”对应哪个型号版本、“上次”按询价日期还是报价日期排序、“报多少”是初始报价还是最终成交价。若历史记录中存在多个版本、不同税口径或不同客户条件，直接返回一个数字，反而可能把复杂问题伪装成确定答案。
同样，把几份 Excel 上传给 AI，也不等于建立了可靠的数据分析能力。文件可能有重复记录、缺失字段、单位不一致和过期数据。没有清楚的关联规则和业务校验，模型即使生成了一段流畅的解释，也不能证明其结论正确。
因此，企业需要的不是单纯增加一个聊天窗口，而是为 AI 提供可追溯的数据来源、明确的业务关联规则、受控的权限边界，以及能够让业务人员核对的证据链。
T-HUB 的一个设计原则，是尽量不要求企业先把现有系统推倒重建。它以只读方式，在授权范围内访问 ERP、PLM、MES、CAD、报价台账、图纸库和共享盘等已有数据源，不写回业务数据，不改变原系统页面和既有工作流程。
这种方式的价值，不在于宣称“一次打通所有系统”，而在于把接入范围、权限和业务目标说清楚：先选定一个具体场景，明确需要读取哪些字段、来自哪些系统、由谁授权、如何验证，再逐步扩大范围。
只读并不意味着可以忽略安全设计。企业仍需明确账号权限、访问日志、数据出网边界、异常处理和运维责任。不同系统的接口能力也不一样，具体接入范围应在摸底阶段确认，而不能在方案阶段笼统承诺。
只读接入解决的是“能不能看见”，交叉分析解决的是“能不能对得上”。
以产品型号为例，系统可以尝试关联图纸参数、材料价格、生产工时、历史报价和质量记录。但关联不是简单地把几张表拼起来。企业需要先定义主键映射、数据时点、单位换算、成本范围和异常值处理规则，并由业务岗位确认这些口径是否符合实际。
完成这些工作后，企业才有条件提出更有价值的问题：同一型号不同订单的成本差异，来自材料、工时还是商务条件？某类返工是否反复出现在相似结构中？历史上赢单与失单的报价差异，是否与某项成本假设有关？
这些问题的答案仍需要基于实际数据验证。交叉分析的价值，是把原本分散在多个部门、需要人工反复核对的信息组织起来，让分析过程更有依据，而不是保证每个问题都能自动得到唯一答案。
数据告诉企业发生了什么，经验则帮助企业理解为什么这样判断，以及下次遇到类似情况该如何处理。
例如，某类结构需要额外工艺余量，某些付款条件应考虑资金成本，某类材料价格波动较大时需要缩短报价有效期。这些判断如果只存在于员工脑中，即使企业接入了大量系统，AI 仍然缺少关键的业务规则。
T-HUB 通过访谈、业务复盘和规则整理，将这些判断转化为可查询、可核查、可维护的经验条目。每条经验都应尽可能保留来源、适用条件和确认责任；遇到条件不完整或超出规则范围的情况，应提示人工核对。
这也是知识底座与单纯数据集成之间的重要区别：数据连接提供事实，经验规则提供解释框架，两者结合才有机会支持更接近业务实际的问题。
传统数据工程经常会把数据抽取、清洗后汇集到集中存储环境中。这种方式在某些场景下有其必要性，但对于涉及图纸、成本、报价、客户和生产信息的制造企业，集中复制可能带来额外的数据治理、安全和维护成本。
T-HUB 提出的“取数不入湖”，强调按需读取、按需关联，尽量避免为了查询而把全部业务数据长期复制到另一个数据湖。交叉查询所需的数据按授权调用，用完后不保留临时副本；如果某些场景确实需要全量历史比对，则应在企业书面授权下建立只读镜像，并明确镜像归属与管理责任。
这里必须区分设计原则与具体实现：不同数据源、查询方式和业务场景，可能需要不同的缓存、索引或历史数据处理策略。因此，企业应在技术方案和合同中明确哪些数据会被保存、保存在哪里、保存多久、谁能访问，以及如何删除或审计，不能只凭一句口号替代技术验证。
制造业 AI 的难点，不是让系统说出一段像样的话，而是让它使用正确的数据、遵循明确的口径，并把依据交给人核对。只读打通、交叉分析和经验沉淀，分别对应数据访问、业务关联和判断复用。三者共同构成知识底座的工作基础。
