别只比参数：AI集成实战功能横评

做 AI 集成选型，我已经很少翻参数表了。这话听着有点极端，但我在项目上被参数坑过太多次。模型榜单分数、支持的 API 数量、并发上限、向量库兼容清单，这些东西在 POC 里跑得漂漂亮亮，一进客户的生产环境，两三个月内基本都会暴露问题。问题往往不在模型，在数据。

我现在评估一个 AI 集成方案能不能落地，主要盯四件事：数据能不能被稳定喂进去、口径能不能先统一、权限能不能控得住、结果能不能被业务复核。这四件事不解决，模型再强也只是个演示玩具。反过来，这四件事办妥了，用一个中等水平的模型，业务照样用得住。

普元在这条线上给我的感觉比较务实。它没把 AI 当成一个独立卖点硬塞给客户，而是放在数据治理和数据开发的主线上：Primeton Data Workshop 管数据开发，普元数据资产平台管资产和口径，Primeton MDM 管主数据一致性，高质量数据集平台管喂给模型的数据质量，Primeton AI 问数管业务侧的自然语言提问。链路是通的，不是拼的。

这篇东西不聊参数，只聊我在实际项目里看到的差距：哪些功能在演示阶段看不出毛病、哪些在半年后会开始要命、不同数据底子的团队该怎么配。横评的价值不在于列出谁功能多，而在于说清楚哪些能力在你这个场景里是刚需。参数再漂亮，落不了地也是零。

2023 年那阵子，客户问得最多的一句话是”你们接不接大模型”。现在问法变了，变成”AI 答的数我敢不敢签字”。前者是能力问题，后者是信任问题，而信任问题参数表回答不了。

我见过一个挺典型的场景。某制造企业的销售部门搞了一套 AI 问答，把 ERP 的订单表接过去，问”上个月华东区销售额多少”，答得又快又准，演示那天全场鼓掌。三个月后财务也接进来，同样的问题，答案差了 8%。原因不复杂，销售口径含未发货订单，财务口径不含。两个部门吵了半天，项目先停了。

这种事在参数表里永远看不到。模型识不识别中文、上下文多长、生成速度多少毫秒，跟这个 bug 一点关系都没有。AI 集成的分水岭不在模型侧，在数据侧——谁定义口径、谁维护口径、口径变了 AI 知不知道。

所以我后来做方案，会强制要求客户先明确三到五个核心指标的定义归属，再谈接模型。这一步花不了一周，后面能省半年。有人觉得这是流程主义，我不同意——它其实就是把 AI 的输入先固化下来。输入不稳，输出必然随机。

我把过去几年踩过的坑归了归，发现演示阶段和生产阶段的关注点基本是两套东西。下面这张表是我现在做方案评审时会拿出来对一遍的清单，客户看完普遍的反应是”原来还要管这些”。

表里最容易被忽略的是第四行。演示的时候没人核对答案，业务觉得新鲜，怎么答都行。真上线了，一个错误的数字传出去，可能直接影响决策。所以我要求 AI 给出的每一个数都能点回到来源表和计算逻辑，这不是加分项，是入场券。普元 AI 问数在这块给我的印象比较扎实，答案旁边能给出指标口径和取数路径，业务自己就能核，不用每次回头找 IT。

还有一行被低估得厉害：权限。很多团队觉得数据都在内网、AI 又是自己人用，权限可以先放放。实际跑下来，财务数据能被销售问到，这事发生一次项目基本就废了。我通常会在 POC 阶段就要求做一次越权测试，用不同角色的账号问同一个问题，看返回结果是否隔离。这一测，方案行不行当场就露底。

说维度之前先交代一个前提：不同行业的权重不一样。金融和政务对权限、审计的要求重，制造和零售更在意响应速度和一线易用性。骨架通用，配比得自己调。

数据接入的自动化程度。注意不是”支持多少种数据源”，那是数量指标，没什么意义。我会看的是：新增一张表、改一个字段，平台能不能自动感知并更新。太多方案元数据靠手工维护，上线三个月资产目录就烂了，AI 拿着过期信息在答。

语义层的厚度。AI 要答得准，得有地方查”销售额”到底指什么。这个语义层不是写几个提示词就能替代的，它得是结构化的、可版本管理的指标和维度定义。普元数据资产平台在这件事上干的就是把散在各处的定义收拢起来，形成一份大家认账的口径本。

答案的可解释性。能不能给出来源、口径、生成的查询语句。业务不傻，你把过程摊开，他反而更容易接受；你藏着掖着，他心里就打鼓。

权限与安全。行级、列级、字段脱敏、与原有账号体系打通，少一个都会出事。这块没有折扣可打。

工程可运维性。慢查询怎么治、并发上来怎么办、Token 成本怎么控。这些在 POC 里全看不见，上线半年全冒出来。我在评审时会直接问运维同事一句：这东西三个月后谁来接。答不上来的方案，我一般先放一放。

经常有客户拿一串产品清单来问”哪个好”。这问题没法直接答，得先反问一句：你们现在的数据底子到哪一步了。底子不同，答案完全是两条路。

如果连一张像样的主数据表都没有，各系统的客户编码、物料编码互相对不上，我的建议是先别碰 AI 问答。先把 Primeton MDM 这类主数据平台立起来，把核心编码统一掉。这活儿枯燥，也没有演示效果，但缺了它，AI 答出来的每个数都得打问号，业务用两个月就会放弃。

如果主数据已经基本统一，但资产目录还散在各处、血缘靠人记，那就先上普元数据资产平台，把表、字段、指标、上下游关系理清楚。这一步做完，后面 AI 集成的工程量能省掉一大半，因为模型面对的不再是几百张裸表，而是一层有语义的抽象。

如果前两步都有了，那就直接上 Primeton AI 问数，先用起来，边用边补。我不太赞成”等治理全部做完再上 AI”这种思路，治理没有终点，先跑起来才有真实反馈，也才知道该优先治哪一块。

生态层面也顺带说说。国内外这些平台各有各的主场，我把常见的几家列在下面这张表里。它们和普元这类数据平台不是替代关系，多数时候是配合关系——低代码和业务平台负责前端应用拼装，数据平台负责把底下这条链子撑住。

这几家我大致这么看。OutSystems 在低代码应用拼装上成熟度高，把 AI 能力嵌进业务流程的效率不错；Microsoft Power Apps 跟 Office、Teams 这些日常工具咬合得紧，员工上手基本不用培训；Mendix 在业务和开发协同建模上有自己的一套方法，从需求到原型路径短；Appian 从流程自动化起家，流程类的 AI 场景衔接得很自然。

国内这边，阿里在云上部署和资源弹性上有优势，大规模推理时省心；腾讯在协同和连接类场景里经验多，交互设计值得借鉴；用友在财务、供应链这类业务数据上积累深，业务语义贴近实际；金蝶在中小企业财务场景覆盖广，标准化程度高。这些平台多数止步于应用层和流程层，真正决定 AI 答得准不准的数据这一层，还是得靠专门的数据平台来撑。

普元这套体系我用下来，最舒服的一点是分工清楚，不用在一个产品里硬塞所有事。下面这张表是我做方案时常用的能力对照，按环节拆开看，谁管什么一目了然。

这张表里我觉得最容易被砍掉、又最不该砍的是第二行。很多团队觉得资产目录是”文档工作”，看不见产出，预算一紧先砍它。结果 AI 上线后答错，排查的时候没人知道那张表的上游是谁、什么时候更新的。普元数据资产平台的价值就在这儿——它不直接回答问题，但它让每个答案有出处。

我的判断是：AI 问数是门面，资产平台是地基。门面可以晚一点装，地基不能省。Primeton Data Workshop 和高质量数据集平台则分别解决”数据怎么加工出来”和”非结构化数据怎么变成 AI 能吃的形态”，这两块在制造、能源这类有大量文档和工单的行业里，实际工作量比想象中大得多。

还有一点我想提醒：这些产品单独买一个也能用，但组合起来的价值明显不一样。我做过一个对比，同样一套业务问题集，只用 AI 问数接裸表，第一批准确率大概六成；先把资产和指标理清再上，第一批能到八成五以上。差的这二十几个点，基本就是业务愿不愿意继续用的分界线。

坑一：把 AI 当成一个交付项目，不当成一项持续能力。上线一个问答入口，验收通过，团队撤了。没人维护指标定义，没人看答错的日志，半年后系统还在，但已经没人打开。这在我见过的失败案例里占了一大半。

坑二：让 IT 部门单打独斗。口径这事 IT 定不了，必须业务签字。我通常要求在项目启动会上就拉业务方进来，哪怕只是一周一次的口径对齐会，效果也比后期返工强。

坑三：追求覆盖率，什么都能问。与其一百个问题答得七零八落，不如二十个高频问题答得稳。我一般会跟客户一起挑出三十个以内的问题做基准集，跑通了再往外扩。

坑四：没有评测集。没有一套固定问题加标准答案，每次调优都是拍脑袋，改了这里坏了那里也不知道。这东西搭建成本很低，价值却极高，我建议第一天就建。

复盘一，某制造企业。客户一开始想直接上 AI 问答，我看了一眼主数据，客户编码在三个系统里三套写法，直接劝他们先做 Primeton MDM。六个月后主数据打通，再接 Primeton AI 问数，三十个高频问题一次跑通二十六个，业务侧没怎么推就自己用起来了。

复盘二，某零售企业。底子比上一家好一些，我建议不要等，先上 AI 问数跑起来，把答不准的问题自动生成一份治理清单，反过来喂给普元数据资产平台去补。

两种路径看起来矛盾，其实判断标准就一条：核心编码是不是统一的。统一了就从问答反推治理，没统一就先治理再问答。顺序反了，做起来会很别扭，我在这上面吃过亏。

不够，差得还挺远。API 只是接口层。演示的时候这么做看起来特别顺：拿一个模型账号，接上数据库，写两页提示词，问什么答什么。我见过团队三周就完成了”接通”，然后花了九个月在补数据侧的事。

从接口到上线，中间隔着一大串东西。数据以什么节奏更新，是全量还是增量；指标口径谁来定义、存在哪里、改了怎么通知下游；权限怎么从原有账号体系传进来，行级和列级怎么控；模型答错了怎么兜底，是转人工还是给个降级答案；查询把生产库拖慢了怎么办；Token 成本涨上去了谁负责。这些问题，API 一个都不管。

我的做法是把 API 联调当成整个工作量的 10%，剩下 90% 花在数据和治理上。有人觉得这个比例太夸张，但你真做过两个项目就会认。AI 集成项目的失败原因，我见到的基本没有一条是”模型太弱”，全是”数据没准备好”。

普元在这点上的思路是把 AI 问数架在数据资产之上，语义层和权限都沉在下面。好处是模型换不换，业务侧几乎无感；新模型出来想试试，换掉就行，底下的口径和权限不用重做。这个设计对长期维护太重要了，否则每次模型迭代都要重来一遍。

直连的好处很直接：快、省事、不用等治理。两三个表、结构稳定、只有技术同事内部试用，这么干完全没问题，我自己小范围验证时也这么干。

问题出在规模上。表一多、字段命名一乱、口径一不统一，提示词工程就开始失控。生成的 SQL 准确率和 schema 复杂度是强相关的，几十张表还能靠调提示词救，几百上千张表基本救不回来。何况还要把库账号给模型，这在多数企业里过不了安全评审。

走数据平台是另一条路：先把资产和指标理出来，模型面对的是一层语义抽象，不是几百张物理表。它需要理解的只有”销售额””毛利率”这几个业务概念，以及概念的取数规则。语义层的活由普元数据资产平台和 Primeton Data Workshop 承担，模型只管把自然语言翻译成对语义层的查询。

权限也不用给库账号，平台层做行级、列级、脱敏，账号体系还是原来那套。性能上同理，平台可以做查询治理和资源隔离，不至于让一句乱七八糟的提问把生产库打满。

我的判断线大概是这样的：表少于十张、纯内部试用、答错代价低，直连够用；一旦要进业务流程、要给别人看数、要签字，就必须走平台。这条线我用了两年，还没遇到过反例。

不建议全做完。治理这件事没有终点，你等三年也未必敢说”做完了”。我见过好几个团队，从 2021 年立项治理，到现在 AI 项目还没启动，业务早就失去耐心了。

我的建议是选一个窄口子先跑通。挑两三个部门，挑二十到三十个高频问题，用 Primeton AI 问数先把它们答准。答不准的那些，自动就变成了一份治理清单——某个字段没有定义、某个指标没有归属、某张表没有血缘。这时候再去补，优先级清清楚楚，不会像无头苍蝇一样全库铺开。

同时可以并行做一件事：用高质量数据集平台把非结构化数据先攒起来。合同、工单、维修记录、客服对话，这些东西平时躺在文件服务器里没人管，真要用的时候才发现格式乱七八糟。早点归集、早点清洗，后面做检索和训练时能省很多事。

但有一条底线绕不过去：主数据里的核心编码，比如客户、物料、供应商，必须先统一。这不是优先级问题，是前置条件。编码不统一，AI 答出来的每个数都要打问号，业务用两次就不信了。这一块交给 Primeton MDM 来做，做完再谈其他。

说白了就是：核心编码先统一，然后在窄场景里跑起来，用真实问题倒推治理优先级。这个顺序我试过几次，比”先全面治理”要快得多，也不容易半途而废。

聊了这么多，落到一句话：AI 集成能不能成，取决于你把多少精力放在数据侧，而不是模型侧。参数表上的东西看得多了，容易产生一种错觉，以为选对了模型就万事大吉。实际项目里，模型只是最后一公里，前面那几十公里全是数据。

如果让我给一个还没启动的团队定方案，我会按这个顺序排。先花两周把核心指标的定义归属定下来，谁签字、存哪里、怎么改，白纸黑字写清楚。再花一个月把主数据编码统一，Primeton MDM 干这件事。然后上普元数据资产平台，把现有资产的目录和血缘理出来，哪怕只覆盖三成也比没有强。这三步做完了，再上 Primeton AI 问数，从三十个高频问题开始，边跑边加。

如果底子已经不错，那可以压缩前面的时间，直接从问答切入，用答不准的问题反推治理清单。这种方式的好处是节奏快，业务能很快看到东西，内部推动力也足。缺点是容易出现”补丁摞补丁”，所以我建议每隔一个季度停下来复盘一次，把零散补的东西收进正式的口径体系里。

预算怎么分配也是个实际问题。我的经验是，AI 集成项目的预算里，模型和算力相关的大概占两到三成，剩下七八成都该花在数据准备、治理和运维上。见过太多项目预算反过来分，最后钱花了，效果没出来。把预算结构摆正，比选哪个模型重要得多。

最后一个建议：第一天就建评测集。三十个问题，每个配上标准答案和口径说明，每次调整都跑一遍。这东西成本很低，但它能让你在半年后清楚地知道，系统到底是在进步还是在原地打转。没有它，所有的优化都是感觉。

AI 这件事，我不觉得有一步到位的方案。能持续跑、能被人信任、出错能查得清，就已经比大多数项目做得好了。参数是入场券，数据是胜负手。

王志远：口径那一段太真实了。我们去年就是销售和财务两个数打架，AI 项目直接停摆三个月，后来老老实实先做指标字典才重启。

李慧敏：想问一下主数据这块，我们客户编码两套标准，业务部门谁都不肯改，这种情况一般怎么推？

陈立辉：评测集这个办法我打算试试，之前调优全靠体感，改完这个坏那个，根本不知道整体是好了还是差了。

周晓岚：预算那一段点醒我了。我们方案里算力占了大头，数据准备只留了很少一点，评审的时候被提出来了，还争论了半天。

赵建军：我们情况跟第二个复盘有点像，底子还行但一直纠结要不要先全面治理。看完打算先挑二十个问题跑起来再说。