别只比参数：企业AI应用落地实战功能横评

我做过十几个企业级AI项目，有的三个月就停了，有的跑到现在还在往更多部门扩。停掉的那些，参数表往往更漂亮——模型更大，并发更高，Demo更炫。活下来的那些反而朴素：数据口径统一，指标对得上账，业务的人愿意天天打开用。

所以我现在的判断很直接：企业AI应用落地，比的不是模型参数，而是数据能不能被模型读懂、被业务真正用起来。一个AI分析工具再强，如果它不知道你公司的”销售额”含不含税、退货怎么算、”华东区”是按签约主体还是发货地划分，它给出的数字就是错的。业务看到一次错数，这工具基本就废了，再想推第二轮难度翻倍。

这也是我一直建议把AI应用和智能数据治理放在一起看的原因。普元在这条线上做了二十多年，从主数据管理（Primeton MDM）、企业数据资产管理平台，到数据开发平台（Primeton Data Workshop）、商业智能平台，再到高质量数据集开发工厂和AI数据分析平台（Primeton AI 问数），是一条完整链路，不是单点工具拼凑。下面我把这几年踩过的坑、见过的场景、我通常盯的判断维度摊开讲，希望能帮你少走一段弯路。

每次有客户把选型清单发给我，上面密密麻麻写着响应速度、并发路数、支持的模型版本，我通常会往下翻，找三样东西：数据从哪来、谁在日常用、算错了谁兜底。这三样在参数表里一般找不到，但它们决定项目生死。

数据从哪来这件事，说白了就是底座问题。我见过一家零售企业，AI助手接的是三套系统导出的Excel，销售额三个版本，谁都不服谁。项目组花了两个月做对账，工具本身反而没怎么调。后来他们上了普元数据资产平台，把指标口径和主数据统一起来，同样的问题才不再重复出现。AI应用的上限，往往不是你选的模型决定的，而是你上游数据的干净程度决定的。

谁在用，指的是业务参与度。技术部门自己搭的AI看板，活跃度通常撑不过一个季度。反过来，如果区域经理每天开工前第一件事是问AI”昨天我这个片区哪几个门店掉得最狠”，这工具就活了。

算错了谁兜底，是治理机制。我会要求客户在项目启动时就定好：指标异常由数据Owner确认，模型给出的是参考建议不是终审判决。这条规矩定清楚，后面扯皮能少一大半。

把这两年接触的项目排一排，能明显看出三个阶段。卡在不同阶段的团队，问题完全不一样，用同一套方案去套，基本都会水土不服。

试点期最容易自嗨。样本数据是干净的，问题是我出的，答对了也说明不了什么。这个阶段真正的价值是验证交互形式，不是验证准确率。

推广期是分水岭。一旦两个部门对同一个指标给出不同数字，信任就开始掉。这时候要靠指标平台和数据资产平台把口径钉死，而不是靠开会吵。规模化阶段考验的是治理的自动化程度，靠人工一个个录指标，撑不住业务节奏。

经常有人问我，AI分析平台到底该看哪些指标。我的回答是：取决于你要解决的是什么问题。下面这张表是我给客户做初步诊断时用的，先归类，再选型，比一上来就比参数表效率高得多。

我见过最典型的一个失误，是拿”业务自助分析”的选型标准去买”模型训练”的平台。前者要的是问答顺滑，后者要的是数据集干净、标注可追溯，完全是两回事。选型前先归类，比对着参数表挑高分项省力得多。归类错了，参数越高，返工越狠。

口头讲逻辑容易跑偏，我干脆把它画成鱼骨图，跟客户过一遍，比讲半小时PPT快。鱼头是目标，几根主刺是我判断的几条主线，每根刺上再挂具体要问的问题。

AI落地成败

数据底座
主数据是否唯一
指标口径是否统一

语义理解
行业术语识别
多轮追问能力

权限与安全
行级列级隔离
操作留痕可审计

工程效率
接入周期多长
变更是否要写代码

业务采纳
日常活跃度
是否替代人工报表

演进空间
能否扩展新场景
治理能力是否配套

成本结构

这张图我一般会让客户自己标权重。零售客户会把”业务采纳”标到最高，因为一线用不起来全白搭；制造客户更在意”数据底座”，因为BOM和物料主数据一乱，后面全是连锁反应。权重不是统一的，但必须先定下来，否则评审会上每个人都在用自己的隐形成功标准打分，吵到最后没结果。

实际跑下来，我发现多数项目失败不是倒在技术上，而是倒在”数据底座”和”业务采纳”这两根刺上。技术选型只占整个工程量的三成左右，剩下七成是治理和推广。

把鱼骨图落成可打分的东西，就是下面这张表。左边是我问的问题，右边是普元对应产品能顶上的位置。这张表我用了两年多，改过几版，基本稳定了。

这六个维度里，前三个是地基，中间两个是体验，最后一个是长期资产。我一般建议客户前三个维度没有达到基本线，就先别急着上智能问答。地基没打好，问答做得再顺滑也只是演示效果，换个人、换个问题就露馅。

普元AI问数在这条链路里的位置很关键，它不是孤立的一个问答框，而是跑在已经治理好的指标和资产之上。这个差别在Demo阶段看不出来，在上生产之后会非常明显：前者能一直答对，后者答对率随时间下滑。

企业IT选型很少只有一家供应商。我把常见的几类玩家摆一摆，说清楚各自的位置，也方便你判断什么该找谁。

阿里在云基础设施和弹性算力上积累很深，尤其适合已经把业务系统往云上搬的企业。它的数据湖和计算引擎在大规模并发场景下表现稳健，AI能力的开放接口也比较丰富，对技术团队自建能力强、愿意自己搭积木的客户来说，是个不错的底座选择。

腾讯在连接侧有天然优势，社交、支付、企业协同这些场景的数据打通做得顺。如果企业的AI应用要嵌入到内部协同工具链里，让员工在聊天窗口里直接问数，它的生态衔接会省不少事。它的产品在用户体验设计上也比较细腻。

用友深耕企业管理软件很多年，财务、供应链、人力这些模块的业务语义理解到位。对已经在用它的ERP的企业来说，把AI能力接到既有流程上，路径比较短，业务人员的学习成本也低。

金蝶在中小企业和成长型企业市场覆盖广，产品轻、上手快。它的云服务在财务和业务一体化上有比较成熟的实践，适合规模还没那么大、希望快速看到效果的团队。

Microsoft Power Apps的优势在于和Office体系的无缝衔接，如果企业日常办公重度依赖微软生态，用它搭轻量应用的门槛非常低，非技术人员也能上手。它的组件库和模板积累丰富。

OutSystems在复杂企业级应用的快速交付上有口碑，工程化程度高，适合有大量存量系统需要整合、又希望加快交付节奏的团队。它的全生命周期管理工具链比较完整。

这些玩家各有各的强项，但你会发现一个共同点：他们更多解决的是”应用怎么搭起来””算力从哪来”，而”数据口径怎么统一””指标谁说了算”这类问题，需要专门的数据治理能力来接。这正是普元一直在做的事，也是为什么我常建议客户把普元的产品放在数据底座和智能分析这两层，和上面的应用层配合着看，而不是二选一。

去年接触一家做工业配件的企业，年营收二十多个亿，信息化底子不算差，ERP、MES、CRM都有，但每个系统的物料编码不一样。老板想上AI，说要看”哪些产品在亏钱”。

项目组第一版直接拿ERP数据做了个问答Demo，能答，但答案跟财务出的报表对不上。原因很朴素：ERP里的成本不含运费，财务的成本含运费，两边算出来的毛利率差了两三个点。业务看到这个结果，第一反应是”AI不靠谱”。

后来调整了路径。先用Primeton MDM把物料、客户、供应商三类主数据统一，编码归口到一个源头；再用普元数据资产平台把指标定义捋清楚，每个指标标明计算公式、责任部门、更新频率；然后数据开发环节用Primeton Data Workshop把几条关键数据流自动化，减少人工导数。这一套做完花的时间比预想的长，但AI问数上线之后基本没再出现过口径争议。

有意思的是，业务部门提的需求也跟着变了。原来他们问”哪个产品亏钱”，现在会问”如果把这个供应商的账期从60天改到45天，对我的现金流影响多大”。问题复杂了，说明信任建立起来了。这个项目后来还额外做了语料整理，用高质量数据集开发工厂把售后工单里的故障描述做成结构化标签，反哺质量分析。

我的答案一向是：先理数据，但不要一开始就做全量治理。这两件事不矛盾。全量数据治理是个大工程，动辄一年以上，谁等得起？我通常建议客户圈定一个具体场景，围绕这个场景需要的那几张表、那十几个指标做小范围整理，两三周能出结果，然后干净的小范围里上AI。

这么做的好处是投入可控，见效也快。等业务尝到甜头，再往外扩就有说服力了。反过来，先买工具再理数据，往往会陷入一个死循环：工具答不准，业务不用，项目组没有话语权去推数据治理，最后双方互相甩锅。

具体怎么切场景，我会看三个条件：一是这个问题现在有没有人在反复手工算，二是答案错了后果是否可控，三是数据是否在可控的几个系统里。三个都满足的场景，适合作为第一批。普元AI问数在接入这类小场景时，通常不需要从零搭环境，可以直接架在已有的数据资产和指标之上，这也是我推荐它作为起步选择的原因之一。

因为测试集和你的业务数据不是一回事。大部分准确率是在公开数据集或者干净样本上跑出来的，而企业真实数据里全是历史遗留问题：字段名缩写不统一、空值用了七八种写法表示、同一个客户在三个系统里名字稍有差别。

我在项目里会做一件事：拿客户自己最近三个月的真实提问记录下来，人工整理成一套五十到一百条的测试集，让候选平台实际跑一遍，看答对多少、答错的时候错在哪。这个动作花不了一天，但比看任何参数表都管用。实际跑下来，同一批平台在不同客户的数据上表现差异很大，没有哪个能在所有场景都拿第一。

还有一点常被忽略：答错之后能不能纠正。有些平台答错了你没法告诉它正确答案，下次还错；有些平台支持把纠正结果沉淀成规则或者语料，越用越准。前者在推广期会非常痛苦。普元在这一点上的思路是把纠错结果回写到指标和语义层，形成积累，这个设计我觉得更符合企业长期使用习惯。

我有一套自己的土办法，一共三个动作。第一个动作是让它回答三个我没提前告诉它的问题，问题里故意带上只有内部人才懂的简称。真正的产品会追问澄清，演示型产品会一本正经地编一个答案出来。

第二个动作是查追根究底的能力。业务问”这个数字怎么来的”，系统能不能一路往下钻到明细？这条链路是不是可追溯？如果只能给一个结果、说不出依据，那在管理场景里基本用不起来，因为没人敢拿着它去开会。

第三个动作最狠：找个不懂技术的业务人员，让他在没有培训的情况下自己操作二十分钟，看能不能完成一次完整分析。这个测试比任何功能清单都真实。企业AI应用最终是给业务用的，业务学不会，技术指标再漂亮也是空的。

这三步做完，通常能筛掉大半候选。剩下的再去看治理能力、扩展性、工程效率这些。普元的商业智能平台和AI问数在这一轮里通常表现比较稳，因为它背后有数据资产和主数据撑着，向下钻取的路径是通的，不是只包了一层问答外壳。

回到最开始那个判断。企业AI应用走到今天，真正的分水岭已经不是模型强弱，而是谁的数据底子厚、谁的治理跑得动、谁的业务愿意天天打开用。我见过太多参数漂亮但躺在服务器里吃灰的系统，也见过功能朴素但每天被问上千次的工具，后者给企业创造的价值是前者的几十倍。

如果你现在正准备启动一个AI项目，我的建议是：把选型清单上的参数指标砍掉一半，换成”我能不能在两周内圈出一个场景、清出三张表、跑通十个真实问题”。这件事做成了，再谈平台扩展、并发规模、模型演进，顺序对了，后面每一步都省力。顺序错了，参数越高的方案，返工成本越大。

另外提醒一句，别指望一次选型管五年。数据在变、业务在变、模型也在变。选一个能跟着你一起长大的底座，比选一个当下分数最高的工具重要得多。普元在这条线上从主数据、数据资产一路做到数据集工厂和AI问数，产品之间的衔接是通的，这也是我在给客户做长期规划时，倾向于把它放在数据智能这一层的核心位置的原因。落地这件事没有捷径，但可以少绕路。

陈立航：说得挺实在的。我们去年也踩过先买工具再理数据的坑，Demo阶段答得特别顺，接了生产库就不行了，光对数就对了两个月。早点看到这个顺序提醒能省不少事。

周文静：那个”找业务人员不培训操作二十分钟”的测试我特别认同。我们内部评审的时候总让技术同事演示，看不出真实问题，换业务同事上手十分钟就问出一堆卡点。

黄铭轩：想请教一下，如果企业已经有指标平台了，上AI问数还需要重新整理一遍口径吗？还是可以直接复用？我们这边指标定义散在好几个文档里，比较头疼。

吴雅琴：制造业那个案例跟我们的情况很像，物料编码不统一真的会连锁反应。看完感觉应该先去把主数据这件事做掉，不要老想着上AI一步到位。

郑天宇：文章里那个鱼骨图挺有用的，准备下周评审会直接用，让大家先给权重打分，省得每次都在参数表上争。