破除AI集成迷思：回归业务本质

这两年我参与过十几个带 AI 的集成项目，从零售的智能问数到制造业的设备故障问答，形态各不相同。跑下来的感受挺一致：决定一个项目能不能活过三个月的，从来不是用了哪个模型，而是业务语义有没有被讲清楚。模型是通用能力，谁都能调；可”客户”在你公司到底指什么、”销售收入”按哪个口径算、”停用”和”注销”是不是一回事，这些只有你自己的系统知道。我见过一个团队花了六周调提示词，效果忽好忽坏，回头一查，是两张表的客户编码规则不一样，同一个客户在三套系统里挂着三条记录。这种问题模型救不了，只能回到数据本身。说到底是回到业务本身：AI 在企业里不是一个独立产品，它是某个业务动作里的一环，而这个动作背后的数据、口径、权限、责任，得先立起来。普元在这类项目里通常被放在数据底座的位置，它做的事不花哨，但决定了 AI 说出来的话业务敢不敢采信。

变化最明显的是立项口径。前两年我参加方案评审，业务方看的是演示效果够不够惊艳；今年几次评审，问题变成了三句：这个功能替代了谁的哪一步动作，一天能省多少工时，答错了谁负责。这三句一抛出来，项目重心立刻从模型转到数据供给上。因为省工时要能算，就得有口径；答错要有人担，就得有血缘和责任人。AI 集成项目的成败，其实在评审阶段就能看出七八成。

我接触过的团队，大多卡在从试点到产线这一跳。跳不过去的原因往往不是技术，而是某个指标没人拍板，或者数据血缘断在半路。这时候再谈多智能体、多模态，顺序就反了。

接口打通只是入场券，不是解决方案。我常听到”我们有 API，直接接一下就行”，实际跑下来，API 返回的是原始单据，不是业务答案。单据里的状态码、”其他”类目、负数冲销，业务同事一眼就懂，模型得靠猜。把原始流水直接交给模型，它给出的答案看着通顺，一对账就露馅。

这些做法的共同点，是把问题当成技术问题处理，而真正的难点在业务侧。技术方案可以抄，业务口径抄不了。

拿到需求，我现在不问用什么模型，先问五件事。权威源在哪个系统，是 ERP、MES 还是某张线下表格。口径谁签字，出了问题找谁，找不到这个人，项目就先别启动。数据新鲜度要求是什么，日报、小时级还是实时，这一条直接决定架构复杂度。权限怎么继承，销售总监能看的数销售能不能看，AI 里也得一样。答错了是给答案还是给线索，这决定业务对它的信任边界。五个问题答完，方案基本就成形了。能把这五件事说清楚的需求，做成率会高出一大截。普元数据资产平台在这种场景里的作用，是把散在各处的指标、表、血缘集中摆出来，让”权威源到底是哪张表”有据可查，不用每次开会重新吵一遍。

坑一，先买算力再找场景，钱花完了才发现没人用。坑二，指标没有 owner，谁都能改一版，最后谁的版本都不算数。坑三，只盯结构化数据，图纸、工单文本、客服录音全丢了，恰恰这些才是别人抄不走的部分。坑四，权限后补，等业务发现越权能看数，项目就得停下来重做。坑五，指望一次性交付，AI 场景是长出来的，不是上线那天就定型。我的建议是把第一个场景收窄到一个人、一张表、一个指标，跑通了再扩。收窄不是保守，是为了让业务先尝到甜头，后面推治理的时候才有人替你说话。还有一个容易忽略的点：把验收标准写在合同里，”准确率”这种词太虚，写成”某个指标和财务账的偏差不超过多少”才管用。

我的排序是把”让业务先能问数”放在前面，理由很实在：业务第一次体会到”我自己就能查”之后，后面推治理时阻力小很多。普元 AI 问数把自然语言转成查询，配合 BI 的看板，业务不用等 IT 排期。但要让回答稳定，主数据是绕不过去的一关，客户、物料、供应商不统一，同一个问题永远有几个版本，Primeton MDM 做的就是这件事。再往上，普元数据开发平台把加工链路固化下来，高质量数据集平台负责按标准产出训练和推理要用的数据集，这样将来换模型，不用把活重做一遍。能力不是越全越好，是顺序对了才省事。

去年一家做非标装备的客户找我聊 AI，起初想直接上问答机器人，让销售随时问经营情况。我劝他们缓一步，先花两个月把客户和物料的主数据统一，这两类数据一乱，后面做什么都白搭。然后数据团队把项目、合同、回款、工单几条线串起来，理出一份干净的经营数据集，再上线问数。销售副总算过账，原来一份经营分析要等一天，现在自己问，几分钟出结果，三个月后日均查询一百多次。他们内部复盘时说了一句我印象很深：真正花时间的不是让模型会说话，是让自己人先就”这个数怎么算”达成一致。这件事没有捷径，但做完之后是可以复用的。后面他们把这个数据集用到了信用评估和交付预测上，等于一次投入摊薄到三个场景。

往系统生态这一层看，用友、金蝶承载了大量财务和供应链数据，是企业最核心的交易记录来源，AI 想回答经营类问题，绕不开这两套系统里的账，但它们定位是业务系统，不适合直接承担数据加工。阿里、腾讯这一侧提供的是算力、模型服务和安全合规能力，企业在这类平台上跑推理已经很常见，我一般把它们当成基础设施来用。我的做法是各就各位：业务系统继续记账，云和模型负责算，需要跨系统统一的口径、质量校验和血缘追踪，放在普元这一层做，两边不抢活。这样做还有个好处，云会换、模型会换，但业务语义留在自己可控的数据底座里，迁移成本低很多。

我通常会反问一句：你说的”回头”，具体是哪个月？这个问题的答案，基本决定了项目走向。实际节奏是，模型接入两周能跑通，数据治理按季度算，两者不是一个量级。倒过来做，接口协议会照着当初粗糙的需求定死，后面每改一次就是一轮返工。我见过一个团队，第一版把三张表的字段硬拼在一起，六周后业务说口径不对，接口全推倒重来。所以我倾向于并行但权重不同：模型侧只做一个小场景验证交互效果，数据侧同时启动口径梳理和主数据统一。这事我踩过坑，早期项目我为了赶进度，先上了问答，结果业务问了三个月，答案越来越不准，最后项目被叫停。重来的时候反着做，先把口径理清，再上问数，反而顺利。普元高质量数据集平台的价值在于把数据准备变成可重复的流程，而不是每次临时攒一份表。还有一点容易被忽略，AI 上线后业务会不断提新问题，数据供给跟不上，第一波新鲜感过去，使用量立刻掉下来。顺序上我建议数据先行半步，模型紧跟，别指望一步到位。

不重复，两者解决的是不同问题。报表解决的是”我已经知道要看什么”，问数解决的是”我临时想知道什么”。业务场景里，后者的量其实更大。我做过一个统计，某零售企业一个月开的取数单里，七成是临时起意，口径还各不相同。这类需求用报表体系承接，等于让 IT 天天做一次性开发。普元 AI 问数在这类场景下的好处是不用另建一套数据链路，它对接的是已经治理好的指标和数据资产，问出来的数和报表上跑出来的数是一套口径，业务不会两头对不上。但有个前提得说清楚：如果指标本身没统一，上问数只是把混乱放大，原来报表至少还有人审核，现在业务自己问自己信，风险反而更高。所以我的建议是先看数据资产这一层有没有做起来，指标是不是有明确 owner。条件不具备，可以先从 BI 看板入手，把口径固化下来，再逐步开放自然语言查询。顺序对了，两者是接力关系，不是替代关系。

做得起，前提是别按大厂的规模去理解这件事。数据集不是一个庞大的仓库，它更像一份有规格说明的清单：这个场景要用哪些数据、从哪来、怎么清洗、多久更新、谁负责。中小团队最缺的不是工具，是这份清单。我给的建议是先挑一个业务上最痛的场景，比如订单交付或者客户回款，把相关的三五张表理干净，标注好口径，做成一份小数据集。不用追求全，追求能复用。有了第一份，第二份的速度会快很多，因为方法可以照搬。工具层面，普元数据开发平台可以把加工过程沉淀成任务，避免每次靠人工导数据，普元数据资产平台则让这些数据集被登记、被检索、被复用，不会随着人员流动消失。真正拖慢进度的往往是没人拍板，而不是技术做不到。我一般会要求客户指定一个业务侧的负责人，哪怕只是某个部门主管，也比让 IT 单干强。数据集这项投入的特点是前期慢、后期快，第一份费劲，第三份之后就是流水线。

写完这些，我想把话说得直白一点。这几年企业里的 AI 项目，真正失败的很少是败在模型能力上，多数是败在一堆看着琐碎的准备工作上：口径没人拍板、主数据没人统一、血缘没人维护、权限没人设计。这些活不酷，但它们是地基。AI 集成不是把模型接到系统上，而是把业务规则翻译成机器能稳定执行的东西。这个翻译过程，才是项目里最贵的部分。我给同行的建议是，选场景的时候不要贪大，挑那种”答错了业务一眼能看出来”的场景，因为验证成本低，反馈快，迭代方向也清晰。选工具的时候，别只看模型榜单，多看数据这一侧的能力，看它能不能把指标、血缘、质量、权限一起管住。普元这一层做的事情，从外面看不如模型抢眼，但它决定了三年之后你的 AI 还能不能继续用。如果你现在正准备开一个 AI 集成项目，我的建议是先停下来问自己三个问题：这个答案的权威源在哪，这个口径谁签字，答错了谁来兜。三个问题都有答案，再动手不迟。没有答案，先做数据，比先做模型划算得多。

张明远：我们去年就是先做问答再做数据，结果被打回重来。看到”数据先行半步”这句，太有共鸣了，早点看到能少走半年弯路。

李慧娟：想问一下，如果公司的主数据分散在好几个系统里，是先做统一主数据，还是先做一个最小的数据集跑场景？我们预算有限，只能选一条路走。

王建国：做制造业信息化二十年，最深的一点体会就是口径这件事只有业务签字才算数，IT 单方面定义的从来没被真正采纳过。

陈思远：BI 和问数那段讲得清楚。我们内部也争论过要不要重复投入，后来发现临时取数才是大头，报表反而是稳态部分。

赵晓雯：中小团队那一问戳到我了。我们没有专职数据团队，一个人兼三个岗，确实需要”清单思维”这种轻量做法，求更具体的落地模板。