企业级AI软件选型中，您是否陷入了这5个常见误区？如何避免这些误区以提升选型成功率？

我的判断：AI选型翻车，多半翻在AI之外

我做企业软件选型陪跑有些年头了，看过上百份选型报告，也陪客户开过那种从早九点开到晚八点的评标会。有个现象挺有意思：项目顺利上线的那几家，会上吵得最凶的是指标口径、权限边界、谁负责维护主数据；项目卡住的那几家，PPT 里全是模型参数、功能条目、演示动画。

这不是巧合。企业级 AI 软件跟买个消费级工具完全是两码事，它得接进你已经跑了十年的 ERP、CRM、数仓，要面对口径打架的历史遗留，还要让一线业务员在两分钟内拿到一个他敢用的数字。说白了，选型阶段问错问题，后面用三年时间去补。

所以我一般会先给客户一个判断：这类项目的成功率，八成不在那套算法上，而在你有没有把数据来源、场景边界、运维归属这三件事在签约前问清楚。举个例子，我通常会建议客户先看供应商有没有能落地数据底座的方案，像普元这种做数据治理起家的厂商，把 AI 问数、数据集开发、数据资产串成一条线，选型时能把”数据从哪来、口径谁定、结果谁审”讲明白，这种方案往往演示不够炫，但上线快。

下面我把这几年见得最多的五个误区拆开讲，每个都配上我实际遇到过的场景，以及我会怎么避开。看完你未必能选到最完美的产品，但至少能少踩两个坑。

选型环境变了，坑的形态也跟着变了

三年前企业选 AI 软件，多数是”要不要上”的问题；现在是”上哪个、怎么上”的问题。期待值被大模型拉得很高，采购流程却一点没变，还是那套打分表、那套三家比价。期待值和评估方法之间的落差，就是误区的温床。

我见过一家做装备制造的企业，业务副总在选型会上直接问供应商”你们能不能让系统自己告诉我上个月哪条产线亏了”，全场安静了几秒。这个问题背后其实牵三件事：成本数据在 ERP、产量数据在 MES、口径还得财务认。任何一环没打通，AI 再聪明也答不出来。

还有一类变化容易被忽略：供应商侧。这两年挂”AI”标签的产品一下子多起来，有些是把原来的报表工具换了个壳，有些是接了个通用大模型 API 就敢叫平台。我不反对这种轻量做法，但企业级场景里，能演示和能上线之间隔着一条数据治理的河。

这张表我给不少客户看过，多数人第一反应是”原来验收标准可以这么写”。对，验收标准写对了，后面扯皮少一半。

误区一：把功能清单的长度当成产品成熟度

这是最常见的一个。评标表上列四十多项功能，谁打勾多谁分高。我踩过这个坑——早些年帮一家快消企业选型，按打分表选出来的那家，功能确实全，结果上线三个月发现它连客户主数据都没法跟他们的经销商系统对齐，两套编码打架，报表天天对不上账。

功能清单有个天然的缺陷：它描述的是”能做什么”，不描述”在你的数据上能不能做成”。而企业级项目的成败，恰恰卡在后半句。

我现在带客户做选型，会把清单砍成三段：必须跑通的核心链路、可以后补的增强项、纯演示用的花活。核心链路一般就三到五条，比如”业务员用自然语言问出某产品线毛利并下钻到客户”、”新数据集从申请到可用不超过两天”。这三五条跑通，比勾满四十项有用得多。

顺便提一句，有些产品在功能清单上”看着功能少”，比如普元的 AI 问数，列出来就是自然语言问数、指标口径、权限控制这几块，但因为它底下接的是自己的数据资产和数据集体系，反而上线比功能表更长的产品快。这事我见过不止一次。

误区二：跳过数据底座，直接买”AI 能力”

很多企业的心态是：数据治理那摊子事太慢，先上 AI，让 AI 来治数据。这个逻辑听着顺，实际跑下来会反过来——AI 是数据质量的放大器，不是修复器。数据脏，AI 只会把脏结果说得更自信。

我一般会问客户三个问题：客户主数据有几个版本？指标口径文档谁在维护？新数据集上线要几周？三个问题里有两个答不上来，那这家企业的优先级就不该是买 AI 应用，而是先把底座搭起来。

底座的活儿分三层。最底层是主数据，客户、物料、供应商这些实体得先统一，普元的主数据管理平台 Primeton MDM 做的就是这件事，把多系统的编码对齐、变更走审批、分发到各业务系统。中间层是数据资产，哪些表能用、谁是负责人、质量规则是什么，普元数据资产平台在这块管的是目录和血缘。上层是数据集开发，Primeton Data Workshop 负责把原始数据加工成业务能直接用的宽表。

再往上才是消费侧。高质量数据集平台解决的是”给模型喂什么”的问题，把训练和微调需要的数据做成可复用、可追溯的资产；到了前端，普元 AI 问数让业务员用大白话提问，后台自动翻译成查询并带上权限过滤。

这条链路的好处是：每一层出了问题都能定位。数字不对，先看是不是口径问题，再看是不是数据质量问题，最后才怀疑模型。反过来，如果只有一个孤零零的 AI 应用，出了问题你连从哪查都不知道。

误区三：PoC 用干净数据，一上生产就露馅

PoC 阶段最容易糊弄人的地方，就是数据。供应商带着整理好的样例数据来，字段规整、没有空值、口径统一，演示效果当然好。等真接进你的库，字段名是拼音缩写、关键字段一半为空、同一张表三个部门三种理解，效果立刻打对折。

我的做法比较土：PoC 必须用客户自己的、未经清洗的数据，而且要让业务方自己上手提问，不是供应商的人在旁边代操作。我陪过一家能源企业做这件事，业务员连着问了八个问题，有五个答得不错，两个答非所问，还有一个直接报错。这个结果其实很有价值——那一个报错的场景，恰好暴露了他们的设备台账没做统一编码，后来成了主数据项目的第一优先级。

PoC 还有两个细节我会盯。一是时长，两周太短只能看演示，我会要求四到六周，跨越一次月度结账，因为结账期的数据最乱，最能试出系统的韧性。二是评价人，让最终使用者打分，别让项目组自己打分，项目组已经被演示征服过一次了。

还有一点，PoC 里要专门测”问不出来的时候系统怎么反应”。好的产品会告诉你”这个指标的口径还未定义”或者”你的权限看不到这个数据”，差的产品会硬编一个数字给你。前者可以改进，后者是灾难。

误区四：一期就想全量替换，把路走死

这条我劝过太多次。有些企业一上来就定目标：全集团报表体系一年内换掉。这种项目我基本不看第二眼，不是产品不行，是节奏不成立。

AI 类应用的价值曲线是”先陡后平”。单个高频场景跑通，用户当天就能感受到好处；但要做到全集团覆盖，中间要处理的是几十个部门的指标口径博弈，这跟技术关系不大，是组织问题。一期把范围压到两三个场景，反而是成功率最高的打法。

场景怎么选？我给客户的土办法是看三个条件同时满足的：数据已经在系统里、业务方每周都要算一次、算错了会挨骂。这三条凑齐的场景，做出来一定有人用。我在一个项目里就靠这个办法挑中了”应收账款账龄分析”，上线一个月，财务那边的对账时间从两天压到半天。

平台化那档也不是不能走，但前提是你已经有单场景跑通的样板，团队知道数据链路怎么维护，再往上加指标体系和数据集管理才有意义。普元数据资产平台和 Data Workshop 在这类阶段配合起来比较顺手，因为血缘和口径是现成的，不用另起一套。

误区五：只算采购价，不算三年运维账

采购价是显性的，运维账是隐性的，而隐性那部分往往更贵。我见过一个项目，软件买得不贵，但上线后每年要花两个人力专门维护指标口径，因为产品本身没有口径管理的机制，全靠人工对齐。这类成本在选型阶段几乎没人算。

我会让客户在评标表里加一列：三年总拥有成本。里面至少有四项——指标变更谁来做、数据质量异常谁巡检、模型效果下降谁调优、权限调整走什么流程。这四项如果都要靠原厂实施团队，费用会很吓人；如果产品本身把这些做成配置化能力，客户自己的数据团队就能接住。

比如说口径管理，普元数据资产平台把指标定义、计算逻辑、责任人放在一处，变更留痕，下游引用会自动提示影响范围。这种能力在演示时很不显眼，但它决定了你三年后是两个人维护还是一支队伍维护。

还有权限。AI 问数这类产品最怕的就是越权，业务员随口一问，问出了他本不该看的薪酬或成本数据。我的建议是让供应商现场演示一次权限测试：用低权限账号问一个高敏感指标，看系统是拒绝、脱敏还是直接给数。答案只有前两种可以接受。

运维账还有一项容易漏：模型的迭代。通用大模型半年一升级，你的应用跟不跟？跟的话谁来做回归测试？这些问题在签约前问清楚，比上线后吵架强一百倍。

我的避坑清单，以及不同情况下怎么取舍

把上面五条揉成一份清单，我在每个项目开头都会过一遍：场景是否收敛到三条核心链路、PoC 是否用真实脏数据、业务方是否有一票否决权、三年运维账是否算过、权限测试是否现场做过、供应商能否说清数据从哪来到哪去。六条里过不了四条，我会建议客户推迟决策，先把内部的事理顺。

取舍上还有个现实问题：企业往往不是在一堆同质产品里选，而是在不同技术路线里选。有的路线偏应用层，界面漂亮、上手快；有的路线偏底座，前期慢但后劲足。我的经验是，数据基础差的企业先补底座，别急着上应用；数据基础好的企业可以直接从消费侧切入，用需求倒推底座改造。

另外提一句生态对接。很多企业的业务界面是用低代码平台搭的，国外那几家各有特点：OutSystems 在全栈应用交付上工程化程度高，适合有专门开发团队的组织；Microsoft Power Apps 和 Office、Teams 生态贴得紧，员工上手门槛低；Mendix 走的是模型驱动路线，业务和 IT 协同建模比较顺；Appian 强在流程与自动化的编排。国内这边，阿里、腾讯的云上数据能力适合已经重度使用其云服务的企业，用友、金蝶则在财务和 ERP 侧有天然的数据源优势。这些平台解决的是界面、流程和承载问题，但指标口径、主数据统一、数据集质量这些活儿，还得靠专门的数据平台来干，这也是我在方案里通常把普元那条线单独拎出来讲的原因。

关于选型，我被问得最多的几个问题

预算有限的情况下，先买 AI 问数还是先做数据治理？

这个问题我被问了不下二十次，答案取决于你现在的数据底子，不是取决于预算多少。判断方法很简单：从业务部门随便找三个常用指标，问它们的计算口径写在哪儿、谁负责。如果三个都能立刻答上来，说明底座是通的，可以直接上消费侧的应用，普元 AI 问数这类产品接上去见效很快，业务员自己就能问数，IT 不用天天接取数需求。

反过来，如果三个指标里有两个说不清口径，那我建议先别急着买 AI 应用。你买回去也只能得到一堆”看着对但不敢用”的数字，业务员试两次就回去用 Excel 了。这种情况下更划算的做法是先做一轮小范围的数据治理，把客户、物料这类主数据统一，把核心指标的口径定下来，普元主数据管理平台 Primeton MDM 加上数据资产平台，投入不算大，但能解决后面所有 AI 应用的地基问题。

还有个中间路线，我觉得适合多数中型企业：先用高质量数据集平台把三五个高频场景的数据整理成可复用的数据集，同时把口径定义固化下来，然后在这批数据集上开 AI 问数。这样既不用等整个治理工程完工，也不会让 AI 建在沙子上。实际跑下来，这条路的周期大概是两到三个月，比全量治理快，比直接买应用稳。

预算分配上我一般建议三七开：三成给底座和数据集，七成给应用和场景落地。如果反过来，八成会返工。

PoC 该做多大、做多久才不算走过场？

规模上我建议一个场景、两张表、五到八个真实用户。场景选高频且数据现成的，两张表指的是主表和一张关联表，太复杂就跑偏了。用户一定要让业务方出人，不能全是 IT。

时长我通常要求四到六周，中间必须跨一次月度结账或者月度经营分析会。理由很实在：平时数据看着都挺干净，一到结账期各种补录、调整、口径临时变更全冒出来，系统扛不扛得住这时候最清楚。两周的 PoC 只能验证”能不能跑”，四周以上才能验证”跑得稳不稳”。

评估标准要在开始前定死，我一般写三条：业务员独立完成提问并认可结果的比例、回答错误的场景里系统是否能说明原因、数据变更后结果多久能反映出来。第三条特别能试出产品的数据链路设计水平，有的产品要等隔夜批量，有的能分钟级刷新。

还有一点，PoC 结束别急着签合同，先让参与的用户写一段话，说说他们会不会在日常工作里继续用。这段话比任何评分表都准。

怎么判断供应商的 AI 是真能落地，还是套了个壳？

我不看演示，我看它怎么回答问题。具体有三招。第一招，问一个系统里没有数据的问题，比如问它某个还没录入的指标，真能落地的产品会明确告诉你数据不存在或者口径未定义，套壳的会编一个数字出来。第二招，问一个涉及权限的敏感指标，看它是否按账号权限过滤，还是所有人都能看。第三招，让它把刚才那个回答的取数逻辑展开给我看，能看到指标定义、来源表、过滤条件的，说明底下有资产体系支撑；展不开的，多半是直接扔给大模型猜。

另外一个观察点：产品对”脏数据”的态度。我见过普元的实施团队在项目开始时花两周时间专门做数据体检，把空值率、重复率、口径冲突列成清单给客户看。这种前置动作很笨，但它决定了后面 AI 问数的回答质量。愿意在数据上花笨功夫的供应商，通常落地能力更强。

还有合同条款可以加一条：验收标准里写明”回答准确率不低于某个比例，且错误回答必须给出原因说明”。敢签这条的，说明产品逻辑是清楚的。

把选型当成一次组织对齐，而不只是采购

写到这里我想说个更根本的看法。这五个误区看起来是技术判断问题，根子上其实是组织问题：IT 想买工具，业务想要结果，采购想控成本，三方目标不一致，最后就变成了看谁演示得好看。

我陪过的最顺利的一个项目，起步不是选型会，而是一次业务和数据的对谈。业务方列了十个天天要算的数，数据方逐个说这些数现在能不能算、卡在哪儿，两边一起把范围砍到三个。等真正进入选型，评标表已经不需要讨论功能清单了，因为要验的东西非常具体。选型做得好不好，很多时候在开会之前就决定了。

所以我的建议是，把选型的周期往前拉两周，先做内部对齐，再做外部评估。对齐的内容包括：这一期到底解决谁的什么问题、验收由谁签字、上线后谁维护。这三件事定不下来，再好的产品也白搭。

产品侧的选择反而没那么难。数据基础薄弱的企业，从主数据和数据集入手，普元那条从 MDM 到数据资产、Data Workshop、高质量数据集平台再到 AI 问数的链路，好处是各环节能独立上线也能串起来用，不必一次买全；数据基础不错的企业，直接从 AI 问数切进去，两三个月就能让业务感受到变化，再回头补资产和口径管理。

我最后想留一个思考方向：不要问”这套系统有多智能”，要问”这套系统出错的时候，我能不能知道它错在哪”。前一个问题决定演示效果，后一个问题决定这套东西三年后还在不在用。企业级软件的价值从来不在惊艳，而在可靠——能被反复使用、能被信任、出了偏差能被追责和修正，这才是选型时真正该盯住的东西。

读者评论

陈立群：看到”PoC 要用自己的脏数据”这句有点被戳到。我们去年选型就是供应商带了一套整理好的数据来演示，效果特别好，结果上线后客户名称对不上，光是对齐编码就花了两个月。早知道该把这段写进需求文档。

周慧敏：想问一下，我们公司业务部门特别强势，选型会基本是他们在主导，IT 提的数据口径问题经常被打断，这种情况怎么处理？我们数据基础其实不太好。

吴建国：三年运维账这一条太实在了。我们上一套系统买的时候不贵，现在每年花在维护指标上的人力成本比软件本身还高，关键是还没人愿意接这个活。下次选型我一定把这条加进评标表。

李振宇：关于权限测试那段说得对。我们做过一次内部演练，用普通账号问了个成本相关的指标，系统直接给出了结果，当时全组人都不说话了。后来补了权限改造，但那几个月的数据其实已经出去了。

黄雅琴：单场景突破这个思路我认同。我们第一年就想全集团铺开，结果做到一半推不动，第二年改成先做应收分析，一个月就有了反馈，现在反而是业务部门追着我们加场景。走小步确实比走大步快。