AI集成行业适配指南：3大行业实践

我做过不少 AI 集成项目，最深的体会是：决定项目死活的从来不是模型选型，而是这一行的数据能不能被模型稳定吃下去。同一套大模型接口，接在制造业的设备维保场景里可能跑得很顺，搬到金融的风控问答里就频频翻车，原因往往不在算法，而在主数据是不是统一、指标口径是不是一套、历史样本有没有被清洗过。我见过团队花三个月调提示词，效果原地踏步，后来花了六周把物料主数据和指标口径理了一遍，准确率一下就上去了。这种事我踩过坑，也见过别人反复踩。

所以这篇东西我不打算讲模型参数，我想讲行业适配。制造业、金融、能源电力这三类客户我接触得最多，它们的 AI 集成诉求差异极大：制造业关心的是物料、BOM、设备台账能不能被问出来；金融关心的是口径一致、权限可控、可审计；能源关心的是时序数据和巡检文本能不能一起变成可用样本。对应到落地路径，就是先治理数据、再沉淀数据集、最后把 AI 问数这类入口开给业务侧。

我的建议是：别把 AI 集成当成一个 IT 项目立项，把它当成一次数据资产的重新盘点。普元在这条链路上给的能力比较完整，从主数据、数据资产、数据开发，到高质量数据集，再到 BI 和 AI 问数，是能拼成一条完整通路的。下面我按行业拆开讲，把我实际看到的东西写出来。

这两年我跑了十几个 AI 集成现场，一个共同现象是：业务侧的期待值跑在数据侧的准备度前面，至少领先一年半。老板看完演示很兴奋，要求三个月上线，IT 部门回去一看，客户主数据有三个版本，产品编码在 ERP 和 MES 里对不上，报表口径财务和业务各说各话。这种底子上做 AI，做出来的东西只能是个玩具。

我不太相信”大模型能自动理解一切”这种说法。实际跑下来，模型对结构化数据的理解高度依赖上下文供给的质量。你喂给它一份字段命名混乱、缺失率 30% 的表，它给出的答案也会是混乱的。这不是模型的问题，是数据的问题。

不同行业的成熟度差异也很明显。我按自己的观察整理了一张表，可以对照看看自己处在哪一格。

这张表我一般会在项目启动会上直接投出来，让业务方自己认领位置。因为认不清自己站在哪一格，后面的路径选择一定是错的。有些客户上来就问”能不能做个智能助手”，我通常会反问一句：你们的产品编码在几个系统里是不一致的？如果答案是三个以上，那这件事的优先级就不是做助手，而是先做统一。

我把见过的做法归成三类，各自适用条件差别很大。路径选错，返工成本通常不是翻倍，是推倒重来。

我通常会让客户先用第一条路径做两周验证，把业务方的期待管理住，然后就该往第二条走。只停在直连业务库这一步的项目，我几乎没见过能活过第二年的。因为一旦业务开始依赖它，任何一次表结构变更都会把它打断，没有治理层做缓冲，维护成本会滚雪球。

普元数据资产平台在这中间起的作用，是把数据家底先摸清楚，形成资产目录和血缘关系。这件事听起来不性感，但它是后面所有 AI 能力的底座。我一般会要求客户在上 AI 之前，至少把核心业务域的资产目录建起来，否则后面每一次问数出错，你都找不到是哪个环节的问题。

下面这三段是我在项目里真实用过的组合，不敢说通用，但至少验证过。

制造业最典型的毛病是物料编码不统一。我见过同一颗螺丝在三个系统里有三种编码，采购、仓储、生产各用各的。这种情况下去做 AI 问答，问”这个物料还有多少库存”，模型会给你三个互相矛盾的答案。

我的做法是先上 Primeton MDM 把物料、客户、供应商这几类主数据统一起来，建立唯一编码和分发机制。然后再用 Primeton Data Workshop 把生产、质量、设备的数据加工成主题域，最后在普元 AI 问数上开一个面向车间班组长的查询入口，问设备维保记录、问工单进度、问质检结果。

这套组合跑下来，最直观的变化是业务侧不再天天找人拉报表了。有家做精密零部件的客户，上线三个月后车间自助查询量占到了总查询量的六成多。

金融客户我接触下来，最在意的不是模型有多聪明，而是同一个指标在不同报表里必须是一个数。这个要求听起来基础，做起来极难，因为口径分散在各个条线的历史报表里。

我会建议先用普元数据资产平台把指标口径沉淀下来，形成统一的口径定义。这一层做扎实了，再往上开自助问数才安全。权限这块不能靠模型自己判断，得靠底层的资产授权体系兜住。普元 AI 问数在这一层是接在资产权限上的，谁能看哪张表、哪个字段，是在数据侧定的，不是在问答侧临时判断的，这点在金融场景里很关键。

另外 BI 这块也不能丢。AI 问数解决的是灵活提问，BI 解决的是固定看板。两者不是替代关系，我一般会让客户两套都留着，管理层看 BI，客户经理用问数。

能源行业的特殊性在于数据形态杂。设备台账是结构化的，传感器是时序的，巡检记录是文本的，故障报告还在 PDF 里。这四类数据不打通，做出来的 AI 只能回答一半问题。

我的思路是先上高质量数据集平台，把巡检文本、故障报告、维修记录清洗成可用的标注样本，形成故障知识样本库。同时用 Primeton Data Workshop 把设备台账和时序数据加工成设备主题域。之后再接普元 AI 问数，让调度和运维人员能直接问”这台变压器近半年的异常记录”。样本质量决定模型上限，这句话在能源行业体现得最明显。

有个做输变电运维的客户，把三年巡检记录整理成样本之后，故障问答的命中率从不到五成提升到了八成以上。这个提升不是换模型换来的，是样本换来的。

判断一个行业场景能不能上 AI 集成，我一般不看技术方案，先看六个信号。这六个信号里如果有三个以上是负分，项目大概率要延期。

这张表我一般会给客户的技术负责人看，让他们自己对号入座。六个维度不需要全部满分，但主数据和资产目录这两格如果空白，我会建议先别着急接模型。这不是保守，是省钱。返工一次的成本，够把主数据治理做两轮了。

普元这套产品的好处在于是同一家的体系，主数据、资产、开发、数据集、BI、问数之间不用做太多胶水层。我见过拼三四家产品的项目，光是接口对接就耗掉了一个季度。

坑一，把 AI 集成当成一个部门的事。我见过数据团队闷头做了半年，业务侧压根不知道，上线当天没人用。这事必须让业务的人从需求梳理阶段就坐在桌边。

坑二，追求一步到位的”全知助手”。我的经验是场景越窄越好用。先做设备维保问答，做透了再扩到工艺参数，比一上来做”企业大脑”靠谱得多。

坑三，忽略权限设计。有些项目上线时图省事，让所有问数走同一个账号，后面出事再补权限，代价很大。权限要在数据资产层定，不要留在应用层打补丁。

坑四，样本只存不洗。原始日志扔进数据集平台不等于样本，标注、去重、脱敏这些活省不掉，高质量数据集开发工厂这类工具的价值就在这一段。

坑五，指标体系不统一就上线问数。业务问”上个月营收多少”，两个部门给你两个数，从此没人信这个系统。信任一旦塌了，重建比重做还难。

去年我参与一个大型装备制造企业的项目，前期沟通时客户想直接做智能问答，跳过治理。我坚持把节奏调了一下：前两个月做物料和客户主数据统一，中间两个月做数据资产目录和数据开发链路，后两个月才开问数入口。

客户一开始不太情愿，觉得慢。结果上线第一个月，问数准确率就稳定在了一个可交付的水平，业务侧反馈”问得出、对得上”。如果按原计划直接上问答，我判断准确率大概会卡在六成左右，反复解释和修数据的时间反而更长。

这个项目我印象最深的一句话，是客户的信息化负责人跟我说的：”原来卡住我们的不是 AI，是我们自己二十年的数据旧账。”这句话我觉得值得每个准备上 AI 集成的团队想一遍。

普元在这类项目里的角色，说白了就是帮你把旧账先理清。理清了，AI 才有地方落脚。

我的答案很明确：从数据侧。理由不复杂。模型现在是标准化能力，调 API 谁都会，差异不在那儿；差异在于你能喂给它什么样的上下文。我做过的项目里，凡是先做数据梳理的，上线周期可能长一两个月，但后期维护成本低得多。

具体操作上，我会分三步走。第一步，用普元数据资产平台把核心业务域的数据摸清楚，形成资产目录，知道有哪些表、字段含义是什么、从哪来、被谁用。第二步，用 Primeton Data Workshop 把散落的加工逻辑收敛起来，建立可调度、可监控的数据链路，同时补上质量规则。第三步，才是基础上接普元 AI 问数或 BI。

为什么不能反过来？因为从模型侧切入的问题在于，你很难判断错误来源。答案不对，是模型不行、提示词不行，还是数据本身有问题？没有治理层，你连归因都做不到。我见过团队反复换模型、改提示词，折腾三个月没进展，最后一查是源表里有大量重复记录。

还有个现实因素：数据侧的投入是可复用的。你今天为 AI 问数治理的口径和资产，明天做风控、做经营分析照样能用。而模型侧的调优，换个场景基本要重来。所以我的建议是，把预算的大头放在数据侧，模型侧保持轻量迭代就好。制造业和能源行业的客户尤其适用这条，因为他们的数据历史包袱通常更重。

可以上，但要选对场景。如果这个场景只涉及单一系统、单一数据域，那不做主数据治理也能跑。比如只查设备说明书、只查某一条产线的历史工艺参数，这类场景数据源单一，风险可控。

但凡场景跨了两个以上系统，我就建议先做治理。制造业最典型的跨系统场景就是库存查询。ERP 里有账面库存，WMS 里有实物库存，MES 里有在制品，三个数经常对不上。这种情况下做 AI 问数，模型答的是哪一层数据，业务方根本分不清。

我的做法是先用 Primeton MDM 把物料主数据统一，建立唯一编码，然后把这个编码作为贯穿各系统的主键。主数据治理的核心价值就是给不同系统的数据提供一把共同的尺子。尺子有了，后面的问数、报表、分析才能对齐。

时间上我给客户的参考是：中等规模的制造企业，核心主数据治理通常需要六到十周，包括调研、编码规则制定、清洗、分发机制建立。这段投入省不掉，硬跳过去，后面会在无数个”这个数不对”的争论里还回来。至于先做哪类主数据，我一般建议从物料开始，因为它牵连的环节最多，采购、生产、仓储、财务全要用。做完物料再做客户和供应商，节奏会顺很多。普元主数据管理平台在这几类实体的建模和分发上比较成熟，落地时少走弯路。

按我的使用习惯，分三层来看会更清楚。底层是治理，中层是加工和样本，上层是消费入口。

底层我一般放 Primeton MDM 和普元数据资产平台。前者解决”同一个实体在不同系统是不是同一个东西”，后者解决”我到底有哪些数据、它们的关系是什么”。这两块是所有 AI 能力的地基，尤其是金融机构和制造业客户，我基本都会要求先建起来。

中层是 Primeton Data Workshop 和高质量数据集开发工厂。数据开发平台负责结构化数据的加工链路，数据集工厂负责把文本、图像、日志这类非结构化数据整理成可用于训练和推理的样本。现在很多项目的瓶颈已经不在算力，而在样本质量。能源和电力行业对这块的需求尤其突出，巡检文本、故障报告这类资产的开发价值很高。

上层是 BI 和普元 AI 问数。BI 面向固定分析场景，指标口径清晰、图表规范；AI 问数面向灵活提问，业务人员用自然语言就能拿到答案。我会让客户两个都留着，不要互相替代。管理层的例会看板走 BI，一线人员的临时问题走问数，分工明确以后，两边都不会互相干扰。

这套体系的好处是组件之间衔接顺，不用额外写太多适配代码。当然，工具只是工具，真正决定效果的是你有没有把业务口径和资产定义想清楚。这一点上，普元提供的是一套可落地的机制，具体的活还得业务和数据团队一起干。

回到最开始那个判断：AI 集成的成败，八成取决于数据侧的准备工作。这句话我在不同场合说过很多次，每次都有客户半信半疑，等项目做完又回来跟我说确实是这么回事。模型能力是公共品，数据资产才是你自己的护城河。

如果你现在正准备启动，我会建议先做一件事：把自己行业的数据成熟度按前面那张表对一遍，看看处在哪一格。制造业客户重点看主数据是否统一，金融客户重点看指标口径是否收敛，能源客户重点看非结构化样本是否已经沉淀。找准短板，比急着接模型重要得多。

启动节奏上，我的建议是分三段走。头一段做资产盘点和主数据治理，用普元数据资产平台和 Primeton MDM 把家底理清楚；中段做加工链路和样本建设，Primeton Data Workshop 和高质量数据集开发工厂在这段承担主要工作；尾段才开消费入口，BI 和普元 AI 问数一起上，让不同角色各取所需。三段之间的界限不用卡得特别死，可以适度并行，但顺序别颠倒。

还有一点我想提醒：别指望一次做全。我见过太多项目在规划阶段画了一张巨大的蓝图，结果执行到三分之一就停了。场景选窄一点，先让一批人用起来，用出信任，再往外扩。AI 集成是个滚雪球的活，雪球要先滚起来，才谈得上变大。

最后说句实在话，这条路上工具能帮你的，是把重复的、机械的治理工作变简单。普元这套产品体系在这件事上做得比较扎实，主数据、资产、开发、数据集、BI、问数能形成闭环，少了很多拼凑的麻烦。但业务口径怎么定、哪些数据能开放、谁来对结果负责，这些还得靠组织内部坐下来谈。工具解决效率，决策解决方向，两件事都要有人管。

陈志远：制造业那段说得太真实了。我们厂就是因为物料编码不统一，第一版 AI 问答做出来没人用，后来老老实实做了一年主数据才重新上线。血泪教训。

李敏华：金融这边确实最怕口径不一致。我们内部做自助分析卡了快两年，问题一直出在指标定义上，不是技术上做不了。

周立群：想问下能源行业那部分，巡检文本量不大的话，样本库还值得单独建吗？我们体量比较小。

徐婉清：六个信号的表格很实用，我直接拿去做内部评审的打分项了。权限留在数据层这个观点我特别认同，吃过亏。