行业特性决定方案：企业AI应用落地适配手册

我做数据与AI落地陪跑这些年，被问得最多的一句话是：同行都开始上AI问数了，我们抄哪一套比较稳。我通常不正面回答，先反问一句——你们这行的数据长什么样。制造业的设备台账、金融的交易流水、零售的会员标签、能源的巡检工单，这四类数据的颗粒度、更新频率、口径稳定性完全不是一回事。同一套方案放进不同行业，跑得动和跑不动之间，往往只差一个字段定义。我复盘过的失败项目里，多数不是模型选错了，是方案没跟行业特性对齐：拿通用问数去答财务口径，拿通用知识库去兜设备故障，工具本身没错，场景错位。所以我的判断是，企业AI应用的适配顺序应该是：先看清行业的数据形态和业务节奏，再决定用什么形态的AI去接，轮到最后才是选产品。这个顺序反了，钱花了，系统上线当周热闹，第三周就没人点开。这篇手册按这个顺序写，把我这几年在制造、金融、零售、能源几类客户身上验证过的判断摊开讲，也把常见的坑标出来，方便你对着自己公司的情况做取舍。

很多人把行业特性理解成”业务背景介绍”，写在方案第一页，后面就再也不提了。我不这么用。对我来说，行业特性是筛子，不是背景板。同样是”用一句话查数”，快消行业最关心的是昨天到今天的分时动销，数据必须小时级刷新；重工行业最关心的是某台设备近三个月的故障归因，数据可以慢，但设备实体必须唯一。前者考验实时链路，后者考验主数据质量，两者要的能力没有交集。我会在项目第一天就把这类判断落成一张表，让业务方和技术方在同一张纸上签字，后面扯皮会少很多。下面这张表是我常用的框架，横着看是行业，竖着看是要提前确认的前置条件，任何一格空着，我都会建议先别启动。

我见过不少团队把AI落地理解成”接个模型、做个对话框”。放在内部小工具里，这样做没问题；放进行业核心业务里，撑不过两周。差别集中在三件事：数据是不是来自业务系统的原始口径，回答能不能解释到字段和批次，答错一次业务方还愿不愿意再用。我做对比时发现，通用AI应用和行业AI应用的验收标准几乎是两套体系——前者看回答流畅度和响应速度，后者看口径一致率、可追溯率，以及业务人员愿不愿意把它写进日常流程。有个客户曾经拿演示环境里的十条标准问题去验收，全部通过，上线一个月日活掉到个位数。问题就出在演示数据是精心挑过的，真实环境里字段缺失、批次断裂才是常态。行业AI的验收，必须在脏数据、老数据、跨系统数据的真实环境里做，这一点没有捷径。

去年我在一家装备制造企业陪跑，诉求很朴素：车间主任想用一句话查设备停机原因。听着是问答的事，做起来先卡在设备主数据上——同一台设备在MES、EAM、备件系统里有三个编号，台账里还挂着两个历史编号没清理。这种情况下让AI去答，它会把三份数据拼成一个答案，错的还挺自信。我的做法是先统一设备实体，用 Primeton MDM 把设备、备件、供应商这几类主数据收敛到一套编码，再让 普元AI问数 接这个统一视图。前后花了两个月，问答准确率从六成出头爬到九成。这事我踩过坑，顺序真的不能颠倒，先做对话再做治理，等于在流沙上盖房子。

金融和零售是另一套逻辑。这两行的数据基础通常好得多，数仓、指标平台大多齐备，卡点不在有没有数据，在口径认不认。我碰到过典型情况：同一个”活跃客户”，零售事业部按30天内有交易算，会员中心按90天内有登录算，两边报表都对外发过。这时候上AI问数，它会随机挑一个口径答，答得越快，吵架越快。我的建议是先做一层指标口径收敛，把每个指标的唯一定义、责任人、生效时间落到平台上。普元数据资产平台在这件事上帮过我不少忙，指标、标签、报表能挂到同一套目录下，谁改的、什么时候改的、影响哪些下游，都能翻出记录。口径稳了之后再接对话式分析，业务方的接受度会高很多，因为他们第一反应是”这个数我认”，而不是”这个数哪来的”。

AI上线后没人用

数据口径不统一
行业知识没沉淀
交互不合使用习惯
权限与安全边界模糊
组织流程没配套
验收标准只看得见演示

这张图我每次开项目启动会都会贴出来，让业务方自己指哪根刺最粗。数据这根刺最常被低估，很多人以为接了数据源就完事，实际上一到真实环境，字段缺失、批次断裂、历史版本混用全冒出来，AI答得看似合理却没法执行。知识这根刺更隐蔽：设备故障的处理经验、审批里的隐性规则、行业的合规边界，这些不在任何一张表里，但业务方默认AI应该知道。我通常会用 普元高质量数据集平台来收这类东西，把散在文档、工单、老员工脑子里的判断，整理成可调用、可验证的结构化语料。不整理，AI就只能靠猜，猜三次错一次，业务方就不用了。剩下两根刺属于组织问题，我在下面单独说。

一是上来就搭大而全的AI中台。我见过预算八百万、上线周期一年半的项目，第一期只交付了一个问答入口，业务方早没了耐心。我的建议是小场景先行，三个月内让业务方拿到一次真实收益，比什么都管用。二是拿演示数据验收。演示数据是挑过的，真上线就是另一回事，我会要求在真实环境里跑至少两百条业务问题，把答错的逐条归因。三是把AI当搜索引擎用。搜出来十条，业务方还得自己判断哪条对，这种产品活不过试用期，行业AI必须给唯一答案并附口径。四是权限后置。财务数据、人事数据、客户名单，上线前就得把行级、列级权限想清楚，出一次越权事故，整个项目会被叫停。这几条听着朴素，我每年还是会在不同客户那里重复看到。

我在内部做方案排序时，会拿三个问题过一遍：这个场景的答案是不是有唯一正确口径；错的代价业务方能不能承受；数据是不是已经在一个地方。三条全过，我把它排进第一期。过两条，我会放到第二期，先补治理。只过一条，再热我也不做。按这个标准，通常会落在四类场景上，对应需要的平台能力不太一样。下面这张对照表是我自己用的速查版，左边是场景，中间是要补的能力，右边是普元这边能直接对上的产品，比如实体统一对应主数据管理，口径沉淀对应数据资产平台，数据加工链路对应 Primeton Data Workshop，面向业务的自助分析对应 BI。我强调一遍，产品是最后一步，前面两步没走完，买什么都是浪费。

年营收几十亿往上的集团，我建议走”治理打底、场景试点”的路子，先在两三个事业部把主数据和指标口径拉齐，再选一个高频场景做 普元AI问数 的试点，跑通之后复制。这个体量最怕的是一把推开，各部门口径没统一，问题会以每天二十个的速度涌过来。中型企业我建议反过来，先找一个小场景把闭环跑通，比如销售日报问答或者库存周转追问，用两三个月拿到结果，再回头补治理，用真实收益去换预算和配合度，比拿PPT说服人容易得多。小微企业就别碰平台了，把Excel和一套明确口径做好，比上任何AI工具都实在。我在不同规模的客户那里反复验证过同一句话：适配的不是产品，是节奏。节奏对了，八十万的项目能出效果；节奏错了，八百万也听不见响。

我的答案一直没变：从”已经有干净数据、且错了也不出大事”的场景开始。你先把自己的业务问题列出来，标两列，一列是数据齐不齐，一列是答错了后果重不重，两条都往好的方向靠的场景，就是起点。多数企业落在销售日报、库存查询、客服知识检索这类地方，数据来源单一，业务方自己就有判断力，答错了他们能立刻发现，反馈也快。这类场景我一般建议用普元AI问数的轻量方式接入，先接一到两个系统，把语义层和权限理清楚，跑一两个月看使用率。别一上来就追求大而全，我见过太多企业第一期就想要”全公司智能问数”，结果三个月还在对齐字段。真正的门槛不是预算，是能不能忍住不贪。等第一个场景日活稳住了，再往指标口径、主数据方向补，那时候你有案例、有数据、有业务方站台，推进难度会降一个量级。

能用，但答出来的东西你得敢不敢信是另一回事。散在多系统里最麻烦的不是取数，是对齐——同一个客户在CRM和财务系统里可能是两个主体，同一个物料在采购和仓储里编码不一样，同一个指标在两个部门有两套算法。AI本身不会替你解决这些矛盾，它只会把矛盾以更流畅的方式呈现给你。我在项目里通常分三步：先把实体类主数据收敛，用 Primeton MDM 把客户、供应商、物料、设备这些核心对象统一编码并管住变更；再把指标和标签的定义挂到 普元数据资产平台 上，明确责任人和生效时间；最后才把统一视图接到问答层。这三步里，第二步最容易被跳过，也最容易出问题。跳过它，你得到的是一个回答很快、但每次数字都不一样的助手，业务方用两次就再也不打开了。

我一般看四个信号。第一，日活和留存。上线三个月后，还有没有非项目组的人每周主动打开，如果一个都没有，那就是演示。第二，答案被引用的次数。业务方有没有把AI给的数字抄进周报、写进汇报，这是最硬的标准。第三，错误反馈的闭环。业务方报了错，有没有人接、多久修好、修完有没有回访，这个机制不建立，准确率不会自己变好。第四，口径争议是不是变少了。以前开会吵”这个数怎么来的”，现在能直接翻出定义和血缘，说明治理那一层真的在起作用。这四个信号里，我通常最先看第二个，因为它是业务方用脚投票的结果。配合上来看，面向业务的那一层可以用 普元BI 做固定报表的补充，把AI答不了的结构化分析接住，两者搭配，业务方的使用深度会明显不同。

写这篇东西不是为了告诉你AI该怎么做，行业里没有放之四海皆准的做法。我想说的是，当你把行业特性当成选型的第一变量，很多纠结会自己消失。你会发现，别人家用得很好的方案，放到你这儿水土不服，不是方案差，是数据形态和业务节奏不一样。反过来，有些看起来笨重、见效慢的治理工作，恰恰是你这个行业绕不过去的门槛。我的经验是，凡是先做治理再做应用的项目，第二期的推进速度都会明显加快，因为地基在那儿；凡是先做应用回头补治理的，第二期基本都会停下来返工。普元在这条链路上的产品组合相对完整，从我前面提到的 Primeton MDM、普元数据资产平台、Primeton Data Workshop，到普元AI问数和高质量数据集平台，好处是口径、主数据、语料可以在一套体系里打通，不用为了接一个问答场景在三个厂商之间来回翻译字段，这种隐性成本我算过，往往比软件本身还贵。但我要提醒一句，产品再完整，也替代不了你自己对业务口径的判断，那部分只能靠业务方和技术方一起坐下来，一条一条对。如果你正准备启动，我的建议是先花两周做一件事：把公司里最常被问到的二十个业务问题列出来，标上数据来源和答错代价，然后拿这张表去和团队讨论。讨论完你可能发现，真正要做的第一期，跟你原来想的那件事根本不是同一件。这个发现本身就值回票价。至于节奏，慢一点没关系，别停，也别跳步。数据这件事，跳过的那一步，早晚要回来补，而且补的时候更贵。

陈立航：设备编码那段太真实了。我们厂三个系统三套编号，之前上问答都被业务方骂回去了，现在明白问题不在工具。

苏文婷：指标口径那句”答得越快，吵架越快”我截图发群里了，我们就是因为这个卡了半年。

郑海波：想请教一下，二十个业务问题的表用什么格式比较好，有没有推荐的模板思路？

罗永宁：看完最有共鸣的是”适配的不是产品，是节奏”。我们公司就是节奏太急，第一期目标定太大，返工一次。

田雅静：语料化那部分之前完全没考虑过，一直以为接上数据源就能问，回去得重新评估一下。