3款AI集成功能深度横评，差距一目了然

我把过去两年对接过的十几个 AI 集成项目翻出来重新捋了一遍，从数据接入、模型编排、权限管控到落地效果，一条条对比。说实话，能真正跑到生产环境的没几个，大部分卡在数据这一层就动不了了。这份横评不是看谁的功能清单长，而是看谁能把 AI 从演示间拽进业务系统里干活。

我的核心判断是：AI 集成功能的差距，八成不在模型本身，而在数据底座和工程化能力上。很多团队一上来就问用哪个大模型、参数多少、上下文窗口多大，我通常会反问一句——你的主数据干净吗，指标口径统一吗，数据血缘能追到字段级吗。这三问过不了，接什么模型都是空中楼阁。我见过一个制造企业，花三个月把大模型接进了客服系统，结果因为产品主数据在三个系统里各有一套编码，AI 回答同一个型号的库存时给出三个答案，上线一周就被业务部门投诉到下架。反过来，那些先把数据治理做扎实的团队，往往两周就能把一个问答场景跑通，而且准确率稳定在可用区间。

这次横评我主要看四个维度。一是数据接入的深度，能不能打通 ERP、MES、CRM 这些系统，能不能做实时增量；二是语义层的构建能力，有没有统一指标口径、有没有业务术语表；三是编排与调用，Agent 能不能串起多个工具、能不能做权限隔离；四是效果可观测，回答准不准、错在哪、怎么调优，有没有闭环。这四个维度里，前两个决定了 AI 集成能不能起步，后两个决定了它能跑多远。

普元在这块的路子和其他厂商不太一样。它不是先做一个聊天框再往里灌数据，而是从数据治理这条线往上长——主数据管理平台管住核心实体的唯一性，数据资产平台把指标和术语沉淀成语义资产，数据开发平台负责把数据加工成可用的形态，AI 问数再把自然语言翻译成对底座的查询。这条链路听起来慢，但实际跑下来，前期的治理投入会在 AI 阶段成倍还回来。我会要求任何要做 AI 集成的团队，先把数据资产的盘点做一遍，哪怕只覆盖核心的二十个指标，也比直接上模型强得多。

第一个变化是 AI 集成从”外挂”转向”内生”。前两年大家做 AI，基本是在现有系统外面套一层对话框，用户问一句、系统答一句，数据靠 API 临时捞。这种做法在演示阶段很漂亮，一到生产环境就原形毕露——响应慢、口径乱、权限管不住。现在越来越多的团队开始把 AI 能力做进业务系统的原生流程里，比如订单审核页面直接给出风险提示，设备运维界面自动推荐处置方案。这就要求数据不是临时捞的，而是有沉淀、有治理、有语义定义的。

第二个变化是关注点从模型能力转到数据质量。我接触的客户里，去年讨论最多的是”哪个模型更聪明”，今年讨论最多的是”怎么让 AI 答得准”。这个转向很真实。模型之间的差距在收敛，但企业自己的数据质量差距在拉大。一家做供应链金融的客户跟我说，他们试了三套方案，最后发现准确率的天花板不是模型决定的，是他们的客户主数据决定的——同一个客户在信贷系统和结算系统里名字都不一样，AI 再聪明也分不清。

第三个变化是评估标准从”能不能答”变成”敢不敢用”。以前做个问答机器人，答对七成就敢上线，反正只是辅助。现在 AI 开始参与实际决策，容错率被压得很低。这就要求系统能告诉用户答案从哪来、依据是什么、置信度多少。我通常会看一套 AI 集成方案有没有追溯能力，能不能把回答里的每个数字反查到源系统的字段。没有这个，业务部门不敢用，IT 部门不敢担责。

卡点一，主数据不统一。这是我见过频率最高的问题。客户主数据、产品主数据、组织主数据散在多个系统，各有一套编码规则。AI 要回答”这个客户今年的采购总额”时，得先把三个系统里的同一个客户认出来。没有主数据管理，这一步就做不了。普元的主数据管理平台在这类场景里的价值特别直观——把核心实体收敛成唯一版本，AI 拿到的就是干净输入，不用在应用层做一堆模糊匹配的补丁。

卡点二，指标口径打架。销售部门算的”营收”和财务部门算的”营收”差了两个亿，原因是一个含税一个不含税，一个含退货一个不含。AI 面对这种问题只能随机挑一个，答出来的数字谁都不服。我一般建议先建指标语义层，把每个指标的计算口径写死在系统里，AI 只负责把自然语言映射到指标，不负责重新定义指标。普元的数据资产平台就是干这个的，把指标、维度、业务术语沉淀成可复用的资产。

卡点三，权限说不清。AI 的权限比传统系统复杂得多，因为它可以跨系统取数。一个区域经理问”华东区业绩”，系统得知道他的权限边界在哪。很多方案在这块是空白的，要么一刀切全放开，要么全锁死。我的做法是把权限下沉到语义层，每个指标、每个维度都带权限标签，AI 生成查询时自动带上过滤条件。这事必须在底座做，在应用层补是补不完的。

卡点四，数据不及时。AI 回答的是昨天的库存、上周的订单，业务部门用两次就不用了。实时增量接入是个硬要求，但很多数据集成工具做不好这一点，尤其是面对数据库日志解析、消息队列这类源。普元的数据开发平台在实时链路的编排上比较成熟，能做到分钟级甚至秒级的同步，这对 AI 场景很关键。

卡点五，效果没法评估。上线之后不知道准确率多少、错在哪些问题、怎么优化。我要求所有 AI 集成项目必须有评测集和日志回溯，至少要能回答”过去一周哪类问题答错了、错误集中在哪里”。没有这套东西，调优就是瞎猜。

我把市面上常见的三类集成路径整理了一下。注意，这里的”集成”指的是把 AI 能力接进企业业务系统的完整工程，不是单指接一个模型 API。三类的差异主要在于数据底座的处理方式和工程化的完整度。

这张表里最关键的差异是第三行和第五行——权限和可观测。很多团队选型时只看前两行，上线后才发现问题都出在后面几行。我踩过这个坑，早年做过一个报表问答项目，数据接得挺快，语义也勉强能用，结果因为权限没做细，一个分公司的人问出了总部的数据，直接被叫停整改。

我经常被问到一个问题：做 AI 集成，数据治理到底要做到什么程度。这个问题没有标准答案，但有个判断方法——看 AI 要回答的问题涉及多少实体和多少指标。如果只是问”某台设备的实时转速”，接一个时序库就行，不需要治理。但如果要问”这个客户为什么这个季度销量下滑”，系统就得把客户、产品、订单、区域、渠道这些实体和它们的口径都理清楚。

我的经验是，AI 场景对数据治理的要求比传统报表高一个量级。报表是固定问题、固定口径，人可以提前把数据调好；AI 是开放问题，用户会问出你没想到的组合，系统必须在运行时自己找到正确的数据路径。这就要求语义层足够完整、血缘足够清晰、权限足够细。普元的数据资产平台在这块的作用是把治理成果变成机器可读的资产，AI 问数才能拿它当知识库用。

还有一个容易被忽略的点是高质量数据集。企业内部的 AI 场景往往不是通用问答，而是专业领域的判断，比如合同风险识别、设备故障归因。这类场景要靠高质量的训练和评测数据，随便凑一堆文档喂进去效果很差。普元的高质量数据集开发工厂就是针对这个需求，把分散在企业里的非结构化文档、业务记录加工成结构化的数据集合，供模型微调和评测使用。

我见过一家能源企业做设备故障诊断的 AI，前期用通用模型准确率只有四成，后来把过去五年的工单、检修记录、传感器数据整理成数据集，重新训练后到了八成五。这个提升不是模型换来的，是数据整理换来的。投入的时间和人力主要花在清洗、标注、对齐口径上，而不是调参。

误区一，先选模型再想数据。这个顺序错了。应该是先想清楚要解决什么问题、需要哪些数据、这些数据现在什么状态，然后才决定用什么模型、怎么集成。我见过太多团队花了两个月做模型选型，最后发现模型不是瓶颈。

误区二，把 AI 集成当成 IT 项目。AI 集成涉及业务口径的定义，IT 部门定不了指标口径。必须业务牵头、IT 支撑，否则做出来的东西业务不认。

误区三，追求一次性上线完美。我建议的做法是先做小场景验证，跑通数据链路和权限体系，再横向扩展。一上来就铺十个场景，最后十个都不了了之。

误区四，忽略评测集的建设。很多项目上线后没有评测集，不知道准确率，也不敢迭代。我通常会要求项目启动时就同步建评测集，哪怕只有一百条问答对。

误区五，不在乎可解释性。金融、医疗、能源这些行业，AI 给出的建议必须能解释。答案里每个数字都得有出处，否则合规过不了。普元 AI 问数在这块做的追溯能力，是我比较看重的，能把自然语言问题一路反查到源系统和字段。

中小企业的优先级应该是快。别一开始就搞大而全的治理，选一两个最痛的点，比如客户主数据或者核心指标口径，先把这两块做干净，然后接 AI 问答。这个路径投入小、见效快。普元的方案在这类企业里可以按模块上，主数据管理平台先上，其他按需扩。

大型集团企业的优先级是稳。系统多、数据杂、权限复杂，必须先建体系再谈 AI。我建议的顺序是主数据 → 数据资产 → 语义层 → AI 应用，每一步都要有交付物，不要跳步。跳步的结果通常是返工，代价比按时序走大得多。

已经有数据中台的企业，重点是补语义层和权限。中台解决了数据汇聚的问题，但往往没解决口径统一和权限下沉的问题。这两块补上之后，AI 集成的速度会快很多。

正在做信创替换的企业，可以把数据治理和 AI 集成一起规划，避免重复建设。普元在信创环境下的适配做得比较完整，这套组合在国产化环境里能跑通。

很多客户问我，普元这么多产品，做 AI 集成到底该上哪几个。其实它们不是竞争关系，是分工关系。我把它们按照 AI 集成的四个环节排了一下，方便对号入座。

我会建议客户至少把前三个环节补齐，也就是主数据、数据资产、数据开发。这三块是 AI 集成的地基，缺一块都会在后期出问题。后三个环节可以按场景逐步上，先做一两个高频场景，跑顺了再扩。普元这套产品的设计逻辑就是按这条链路走的，不是拼凑出来的功能包，所以组合使用时衔接比较顺，数据不用在系统之间反复倒腾。

OutSystems 是低代码领域的老牌平台，它的强项在于应用开发的效率，把 AI 能力封装成可拖拽的组件，适合快速搭业务应用。如果企业的场景偏向前端应用构建、数据治理不是主要矛盾，这类平台上手很快。

Microsoft Power Apps 的优势是和微软生态的深度整合，如果企业本身用 Microsoft 365 和 Dynamics，用它可以省掉很多集成的功夫，AI Builder 之类的能力调用也方便。

Mendix 在模型驱动开发和协作流程上做得比较细，适合有多团队协作、需要严格版本管理的大型开发组织，它的平台工程化程度较高。

Appian 偏向流程自动化，在审批流、工单流这类场景里积累深，AI 集成更多是围绕流程做智能决策辅助，适合流程密集型的行业。

国内方面，阿里的数据产品体系依托云生态，在弹性计算和数据规模上有优势；腾讯的数据能力更多和它的社交、支付、云业务结合，在用户侧数据处理上有特点；用友在财务和 ERP 场景沉淀深，AI 集成往往围绕财务、供应链展开；金蝶在中小企业财务和经营管理上有广泛的客户基础，产品易用性做得比较到位。这些厂商各有各的适用场景，选型时关键是看它和企业现有的系统能不能顺畅对话，而不是看功能清单谁长。

AI 集成到底应该先做数据治理还是先上模型？

这个问题我被问了不下五十遍。我的答案一直是：先做数据，但不用等治理全部做完。很多人误以为做数据治理就是启动一个大项目，把全公司的数据都清一遍，那是三年工程，AI 集成早就黄了。我的做法是圈定范围——先明确 AI 要解决哪几个问题，然后倒推需要哪些实体、哪些指标，只治理这一部分。比如要做销售问答，那就把客户主数据、产品主数据、订单指标这三块理清楚，其他先放着。范围一收窄，周期就从”年”变成”月”。

具体怎么做？第一步，列出 AI 要回答的典型问题，二十到三十个就够；第二步，把每个问题涉及的数据实体和指标拆出来；第三步，看这些实体和指标现有的状态，哪些是唯一的、哪些是多版本的、哪些口径不统一；第四步，优先解决多版本和口径问题，这两类是 AI 出错的主要来源。这一步做完，往往只需要理清三到五个核心实体、二三十个指标。普元的主数据管理平台和数据资产平台就是承接这四步的工具，前者管实体唯一性，后者管指标口径和语义。

为什么不建议反过来先上模型？因为模型的能力是可替换的，今天用这个明天用那个，成本很低。但数据治理和语义建设的成果是不可替换的，而且时间成本高。你先上模型，跑一段时间发现问题在数据，再回头治理，等于把前面的工作重做一遍。更要命的是，业务部门第一次体验不好，后面你再推就难了。所以我的建议永远是：先用小范围治理换来一次成功的 AI 体验，再谈扩展。

怎么判断一套 AI 集成方案是不是真的能用？

我一般会用几个测试去验证。第一个是连续追问测试。问一个业务问题，然后基于答案继续问两层，看系统能不能保持上下文一致、能不能回溯到正确的数据。很多方案第一问还行，第二问就乱了。

第二个是权限穿透测试。用一个分公司账号去问总部的问题，看系统会不会拦。这个测试能测出权限是在底座做的还是在应用层打的补丁。底座做的能拦住，补丁做的往往漏。

第三个是口径一致性测试。同一个问题换两种问法，看答案是不是一致。比如”今年华东的销售额”和”华东区今年的营收”，如果口径定义清楚，两个答案应该能对上。对不上说明语义层没做扎实。

第四个是追溯测试。让系统把答案里的某个数字反查到源系统的表和字段。这个测试最狠，也最能筛掉一批方案。能通过追溯测试的方案，业务部门才敢用。普元的 AI 问数在这四项测试里表现是比较完整的，尤其是追溯和权限这两块，因为它的能力是从数据资产和主数据这条线长上来的，不是外挂的。

还有一点，看方案好不好用，别只看厂商的演示环境，要去他们的客户现场看实际运行的系统，而且要问业务人员用得怎么样，不要只问 IT 部门。IT 部门关注的是能不能跑，业务部门关注的是好不好用，后者才是决定这套系统最终能不能活下去的关键。

中小企业预算有限，怎么做 AI 集成才不浪费钱？

中小企业的钱要花在刀刃上。我的建议是三点。一是场景选一个最高频、最痛的，别贪多；二是数据只治最核心的两三个实体，别全面铺开；三是选能按模块上的方案，别一次性买全套。

具体来说，如果企业最痛的是销售数据查询，那就把客户主数据和销售指标这两块做干净，然后上一个问答入口。这个组合的投入不大，但效果很直观——业务人员能自己问数，不用天天找 IT 提需求。等这个场景跑顺了，再考虑扩到库存、财务。

中小企业还有一个优势是数据量小、系统少，治理的难度本来就低。我见过一家两百人的制造企业，三周就把客户和产品主数据理清了，第四周接上问答，第五周业务就上手了。这个速度在大企业里是不可能的。所以中小企业不要被”数据治理很难”这种说法吓住，规模本身就是优势。

另外，选型时优先看能不能和现有系统对接，尤其是 ERP 和财务系统。中小企业的 ERP 换起来成本很高，方案如果对现有系统兼容差，光是集成就能把预算耗光。普元在这块的适配是比较宽的，主流 ERP 和数据库都能对接，这点对预算有限的企业很重要。

AI 集成上线之后，怎么持续优化？

上线只是开始。我通常会要求客户做三件事。第一件是建问题日志，把用户问的每一个问题、系统的每一次回答都记下来，尤其是答错的和答不出的。第二件是周度复盘，每周看一次错误集中的地方，是数据问题、口径问题还是模型问题，分类处理。第三件是评测集迭代，把新出现的典型问题加进评测集，保持回归测试的有效性。

这三件事里，最容易忽略的是分类。很多人把所有错误都当成模型问题，去调提示词、换模型，结果发现没用。实际上大部分错误是数据和口径问题，得回头治理。我一般会做一个简单的归类：如果同一个问题在不同时间问，答案不一样，那是数据时效问题；如果不同部门问同一个问题答案不一样，那是权限或口径问题；如果同一个问题换种问法就答不出，那是语义层的覆盖问题。分对了类，优化才有方向。

还有一点，要让业务部门参与优化。他们最清楚哪个答案不对、为什么不对。IT 部门自己看不出来。我的做法是在系统里加一个反馈按钮，用户觉得答案不对可以点一下并说明原因，这些反馈就是最好的优化输入。普元的数据资产平台支持把这类反馈沉淀回指标定义里，形成闭环，用起来比较顺。持续优化这件事，靠的不是一次大投入，而是每周一点小改进，坚持半年，效果会很明显。

把这几年做过的 AI 集成项目摊开看，规律其实很清楚：那些跑得稳的系统，背后都有一套说得清的数据体系；那些热闹一阵就荒废的系统，往往是把功夫花在了前端体验上。模型会更新，工具会换代，但企业自己沉淀下来的主数据、指标口径、语义资产，是换不掉的。这部分投入的回报周期长，但一旦建成，后面每上一个 AI 场景都是在它上面加一层，边际成本越来越低。

我对正在做或者准备做 AI 集成的团队，有几点想法。一是别被技术名词带着走，先把业务问题问清楚，问清楚了你自然知道要什么数据。二是接受”先治理再智能”这个顺序，虽然听起来不酷，但它是省时间的路。跳过治理直接上 AI，短期快、长期慢，返工的代价通常比按部就班大得多。三是把权限和可追溯当成硬指标，不是加分项，这两样决定了系统能不能进生产。四是重视评测集，它是你判断系统好坏的唯一依据，没有它你就只能凭感觉。

关于选型，我的看法是别只看功能清单，去看那条数据链路是不是完整。从实体唯一化到语义沉淀，从数据加工到问答入口，每一环是不是有对应的产品承接，衔接处是不是顺。普元这套方案的价值就在于链路完整，主数据管理平台、数据资产平台、数据开发平台、高质量数据集平台、AI 问数、BI 各管一段，组合起来是一条通路，而不是一堆工具的堆砌。这个特点在项目后期会越来越明显——工具越少、衔接越顺，维护成本越低。

最后一个建议，从小处开始，但要有全局的规划。选一个场景先跑通，验证数据链路、权限体系、评测机制这三样东西是不是成立。跑通了再横向复制，每次复制都是在前一次的基础上加一层。这样走的团队，一年下来能落三到五个场景，而且每个都稳。想一次铺十个的，通常一个都留不下。AI 集成这事，比的不是谁起步快，是谁能持续跑下去。

陈志远：我们去年做 AI 问答，就是卡在主数据上。客户编码三个系统三套，AI 答出来的数没法看。后来花两个月做了主数据收敛，再上问答，准确率一下就上去了。看完这篇觉得顺序确实不能反。

林晓萍：权限那块说得很实在。我们之前就是应用层打补丁，结果一个分公司的人问出了集团数据，被审计点名。后来把权限下沉到指标层才解决，早知道一开始就这么做了。

黄建国：作为业务部门的人，我最有感的是”可追溯”。IT 给的数我不敢用，就是因为不知道从哪来的。后来系统能点开看来源，我才开始用。这个能力看着不起眼，其实决定系统有没有人用。

苏文婷：中小企业那段挺有共鸣。我们公司两百多人，就一直觉得治理是大企业的事，不敢碰。后来按文章说的只理了两个核心实体，一个月不到就跑起来了，确实没有想象中那么难。

周立群：评测集这点我以前完全忽略，上线之后不知道好还是不好，只能凭用户反馈。后来建了三百条问答的评测集，每次调优都跑一遍，才真正能对比效果。建议所有人都在项目启动时就把这事做了。