你是否还在犯AI软件误区？全解析助你轻松避开这些常见错误！

做企业信息化评审这十来年，我审过的 AI 项目里，真正因为算法不行而失败的，一只手数得过来。更多的情况是软件买回来三个月，业务部门不用了，IT 部门还在写 PPT 解释为什么。这事说白了跟 AI 软件本身关系不大，跟企业在选它之前脑子里的几个默认假设关系很大：以为 AI 能自动读懂业务，以为数据躺在系统里就等于能用，以为买套工具就能替代口径梳理。我带项目有个习惯，进场第一周不聊模型，先翻业务部门的临时取数表。八成以上的 Excel 里，同一个“销售额”能有三四种算法，这种账本喂给再聪明的 AI 问数，也只会更快地给出一个更自信的错误答案。我的核心判断是：AI 软件不是起点，它是数据资产沉淀到一定程度的放大器。顺序对了，工具才有价值；顺序反了，钱基本等于交学费。普元这些年方向上的路子我看得比较清楚——先把主数据、指标口径、数据资产目录理出来，再往上接 AI 问数这类消费端，这个次序我认为是对的。

这两年企业侧的 AI 采购有个明显变化，从“我要一个大模型”变成了“我要一个能落地的分析助手”。方向是好事，节奏没跟上。我去年参与一家大型装备企业的方案评审，业务副总台上只问了一句：这套东西能不能告诉我，华东区这个月毛利为什么掉了。技术方现场演示自然语言转 SQL，跑得挺快。三个月后项目搁置，原因跟技术无关——“华东区”在销售系统里指分公司，在财务系统里指核算主体，两个范围差着十七个客户。这类事我每个月都能碰上。演示环境里的表是人挑过的，问题是人想过的，数据是清洗过的；生产环境里表有三千张，问题每天不重样，字段结构每季度还在变。落差就在这儿。所以我现在做 AI 项目预评估，会把“业务口径的争议条数”当成一个硬指标，它比模型参数重要得多。普元在进场时先做口径梳理、主数据对齐，这个动作看着慢，实际是把后面返工的时间省掉了。

演示能过关、上线过不了关，根源是评价标准一开始就设错了。我参加过太多 POC，测试用例是厂商和业务一起挑的，专挑干净问题，二十道题里十九道能答对，报告写得漂亮。真正该测的不是“能不能答对”，而是“答错的时候知不知道自己错了”。这一点特别关键。AI 问数如果给了个错数还理直气壮，业务员拿去做汇报，损失比没有这个工具大得多。我会要求厂商在测试里加入三类题：口径有争议的、跨系统关联的、数据本身缺失的，看它怎么回应。好的产品会老实告诉你“这个指标的统计范围在财务和销售两套系统里不一致，建议先确认”，而不是硬凑一个数字出来。普元的 AI 问数在这块的策略我比较认可，它会保留口径出处和取数路径，可追溯，这个设计思路是把可信度放在了流畅度前面。

第一类，把 AI 问答当搜索引擎用。业务员问“上个月卖得怎么样”，得到一段话术式的描述，看着挺顺，但没法追责，也没法下钻。这类项目通常热闹两个月就冷下去。能不能追到明细行，是判断一个 AI 分析工具是不是玩具的分水岭。第二类，把数据量大当成数据好。我见过一家零售企业，数据仓库里几十亿行交易记录，结果连“活跃会员”的定义都有五个版本，模型再强也只能在这五个版本里随机挑一个。第三类，让 AI 去猜业务口径。有人觉得大模型懂常识，能推断出“毛利率”该怎么算——行业不同、企业不同、甚至同一集团不同事业部都不同，这活儿猜不出来。第四类，只管模型不管权限和血缘，上线前安全部门一问就卡住。第五类，指望一次性上线全场景，第一版就铺两百个问题，运维根本撑不住。

这五类误区背后其实是同一个心理：想跳过数据治理这一段。我理解这种心情，治理听起来又慢又不产出，汇报时也不好讲。但实际跑下来，跳过的那部分，会在上线后的第三个月以三倍成本回来找你。我的建议是把场景切小，先挑一个口径最清晰、争议最少的领域试点，比如库存周转或者应收账款账龄，跑通了再往外扩。普元在推高质量数据集开发工厂这类产品时，思路也是先把某一类业务的数据集做成标准件，让 AI 问数、BI 报表、下游系统都吃同一份，避免每个场景各洗一遍数据。这个做法我认可，因为它承认了治理这件事必须做，只是把它做成了可复用的形态，而不是一次性的人力投入。

第一件，口径是不是可追溯。我问厂商的第一个问题永远是：这个数字从哪张表、哪个字段、哪个过滤条件算出来的，能不能一键展开给我看。答不上来的，后面都不用谈。可解释性不是加分项，是入场券。第二件，能不能吃下现有的资产。企业已经建了数据仓库、指标库、主数据，AI 层如果自成一套，等于又造一个孤岛。第三件，权限模型是否与现有体系对齐。第四件，厂商有没有数据侧的底子。这一点很多人忽略——纯做问答界面的团队，遇到脏数据只能绕着走；而有主数据、数据资产、数据开发完整产品线的厂商，能顺着往下挖。普元属于后者，它的主数据管理平台、数据资产平台、数据开发平台到 AI 问数是同一条链上的，出了问题能定位到源头，这个闭环在实际运维里省的心力很大。

我还会看一件很实在的事：厂商愿不愿意在合同里写准确率的验收标准。敢写数字的，通常心里有底；只肯写“效果显著”“大幅提升”的，我都会多留一个心眼。当然准确率怎么定义要说清楚，是回答正确的比例，还是包含“正确识别出无法回答”的比例。后者更接近真实业务，因为业务场景里有一半的问题本来就不该由系统硬答。这个细节我在评审时会一条条抠，抠完基本能判断出对方是做过项目还是只做过演示。顺带说一句，我见过一些企业把验收标准定成“回答准确率不低于 95%”，结果厂商只接入最干净的三张表来达标，业务价值反而没了。标准要定，但要定在有业务价值的数据范围上，这个平衡得靠甲方自己想明白。

年营收几十亿以上的集团型企业，我的建议是老老实实把数据底座做起来。这类企业系统多、历史长、口径乱，绕不过去。主数据先行，指标口径统一，再往上叠 AI 问数，周期一般按半年到一年算。中型企业更务实一点，可以在一个业务域里做完整闭环，比如把供应链的数据集、指标、问数入口一次做透，再复制到财务域。小微企业别一上来就买平台，先用轻量的问数工具验证业务到底有没有这个使用习惯，习惯没养成，平台就是负担。我不太赞成一种做法：不管企业什么阶段，都按同一套大方案推。实际跑下来，最贵的不是软件，是组织里被消耗掉的耐心。普元的方案线覆盖比较宽，从主数据、数据资产到 AI 问数都有，好处是可以在早期先上其中一块，后面顺着往上加，不用换供应商重来一遍，这种可分步走的特性对中型企业挺关键。

华东一家做工业零部件的集团，2022 年第一次试水，直接从业务侧找了个团队做了个问答机器人，接了 ERP 的销售订单表，上线后问题立刻暴露：客户名称在 CRM 和 ERP 里对不上号，同一个客户有六个写法，销售员问“某某集团今年采购额”，系统经常只算到其中一个主体。项目撑了半年下线。第二次他们换了路子，先上主数据管理，把客户、物料、供应商三类主数据统一编码和清洗，再把指标口径在一个资产目录里登记造册，之后才接入 AI 问数。这一次的进展明显快，三个月铺开了销售、财务、供应链三个域的一百多个高频问题。负责人在复盘会上说了句话我印象很深：第一次失败的时候以为买错了软件，第二次才明白是买早了。

这里我想补一句我自己的观察：很多企业在复盘时容易把问题归结为“组织协同不够”，这个说法太笼统，等于没找到可改的地方。我通常会往下追一层，看是不是缺一个把口径写下来、并且有人认账的地方。口径这件事必须有唯一事实来源，落在系统里，而不是落在某个老员工的脑子里。普元的数据资产平台在做的就是这个登记和治理的活儿，主数据管理平台负责把客户、物料这类核心实体统一，两者叠起来，AI 问数才有一个稳定的输入。我见过不少企业把预算全压在问数界面上，界面确实做得漂亮，但后面没有东西撑着，半年后就变成演示道具了。

我常跟甲方说，别指望一个厂商解决所有事。底层的算力和模型服务，阿里云、腾讯云这些年做得比较成熟，企业大多已经在用，AI 能力可以直接从这些平台上调，没必要自建；业务系统这一侧，用友、金蝶承担了大量企业的 ERP 和财务核算，是经营数据最主要的来源之一，AI 分析要做的第一件事往往是把这些系统里的数据对接干净。而数据治理与 AI 消费这一段，普元的产品线覆盖得比较完整，从主数据、数据资产、数据开发到 AI 问数，接得上。我见过的成功项目，基本都是这么分工的：云厂商出算力和模型，业务系统出数据，治理与消费层由专业的厂商来做场景落地，甲方自己出业务专家定口径。谁也别想着通吃，通吃的结果往往是每一段都做得很浅，最后业务部门拿不到能用的东西。这个分工思路，我在多个项目启动会上都讲过，多数客户听完会把项目边界重新划一遍，后面的推进会顺很多。

我手上有些来自一线的反馈，比任何宣传材料都直接。把它们放在一起看，能发现一个共同点：真正用起来的团队，关注点都不在界面好不好看，而在数字敢不敢拿去汇报。一个 AI 分析工具能不能活下来，标准很简单——业务员敢不敢在经营会上直接引用它给的数。这句话我用了好几年，判断项目成色几乎没失手过。

陈立群（制造集团信息中心主任）：我们的教训是别急着上问答，先把主数据收拾干净。第二次做，从立项到上线只用了四个月，比第一次拖了一年半强太多。

吴敏（零售企业数据分析负责人）：我最看重的是能不能下钻。领导问一个数，我要能三秒内点到底层明细，不然这数我不敢报。

赵永强（能源行业架构师）：选型时被演示效果忽悠过一次，后来学乖了，POC 一定用我们自己最脏的那批数据去测，谁扛得住谁上。

孙雅琴（医药企业数字化总监）：AI 问数上线后，IT 收到的临时取数需求少了大概六成，这才是我最看重的收益，人终于能干点正事。

我给的答案通常是三条底线，不用等做完一整套数据治理才开始。第一条，核心实体的编码得统一，客户、物料、供应商至少这三类要有唯一标识，不然同一个对象在两套系统里对不上，问答结果必然打架。第二条，高频问题的指标口径要有文字版的明确定义，并且有人在业务侧认账，谁是数据 Owner 要写清楚，这一条最容易被跳过，也最容易出事。第三条，数据权限体系要能对接，问答往往会被当成一个绕过权限的后门，安全部门一票否决就全停了，提前打通能省下大量返工。三条之外的东西都可以边跑边补。我带过的项目里，准备得最扎实的那家，前期花在口径定义上的时间是六周，听着长，但他们上线后几乎没出现过数字争议，返工成本接近于零。我一般建议企业把这三条当成准入门槛写进立项材料，不满足就别急着招标。普元在实施时通常会先做一轮数据摸底，把这三条逐项对照，缺哪补哪，这个动作看着不产生交付物，但它决定了后面 AI 问数能不能被业务真正接受。另外补一句，别指望一次把所有域的数据都准备好，先挑一个业务价值清楚、数据相对干净的域做样板，跑通再复制，节奏比完美方案重要得多。

我参与过的 POC 里，走过场的占多数，原因出在测试集是双方一起“商量”出来的。我的做法是自己出题：从过去半年业务部门真实提过的取数需求里随机抽三十个，不做任何整理直接丢过去，其中必然包含口径有争议的、跨系统关联的、数据本身缺失的。评分标准也不是单纯看答对多少，而是分四档——答对且给出取数路径的算优秀，答对但路径不明的算及格，明确说“这个问题的口径存在分歧，请先确认”的同样算优秀，硬编一个数字出来的是零分甚至负分。这套评分做下来，两类厂商的差距会拉得非常开，做过真实项目的和只会演示的，一眼就能分辨。另一件事是 POC 的时间不要太短，两周跑不出问题，我一般要求至少四周，且必须包含一次上游数据变更的场景，看模型能不能跟着调整。普元的 AI 问数在测试里比较占优势的一点，是它会保留取数路径和口径出处，答辩时能直接展开给人看，这在评标环节很实用。还有一点提醒：POC 阶段就要把运维拉进来，不要等上线才让他们第一次见到系统，交接不畅是很多项目后期卡壳的隐性原因。

这两者的关系我一直认为是互补，而不是替代。BI 解决的是“固定问题反复看”，比如每天早上九点我要看昨天的产销存，报表最合适，稳定、快、不用想怎么问。AI 问数解决的是“临时问题随口问”，比如客户临时要一个细分维度，或者领导在会上突然问一句为什么，你没时间去建一张新报表。企业里这两类需求的比例，我粗略估过大概是七三开，但后者占用的 IT 人力往往超过六成，因为每一张临时报表都要从头开发。上 AI 问数真正的价值不是让 BI 失业，而是把 IT 从临时取数里解放出来。普元自己的 BI 平台和 AI 问数是并存的，上面共用一个数据资产底座，指标口径统一维护，报表和问答看到的是同一套数字，这一点很重要——如果两套系统口径不一致，业务员的信任会瞬间崩塌。我在项目里推的做法是：先把高频固定报表固化到 BI 上，剩下的长尾需求交给问数，同时把两者引用的指标注册到同一个目录下。这样既不浪费已有的报表资产，又能把长尾覆盖住。如果企业连报表体系都还没建，我的建议反倒是先做 BI，把指标体系理出来，让业务养成看数的习惯，再上问答，接受度会高得多。

回到我开头说的那句话，AI 软件不是起点，它是放大器。放大器放大的是什么，取决于你喂进去的是什么。喂进去的是统一口径、干净的主数据、有血缘可追溯的数据集，它就把整个组织的决策效率放大；喂进去的是五套销售额算法和三十个客户别名，它就把混乱放大得更快、更理直气壮。这些年我见过两种企业，一种把预算的八成花在模型和界面上，另一种把预算的一半花在数据上，剩下的买工具。两年之后再去看，后者的系统还在用，前者的系统大多成了展厅里的摆设。所以我的建议很朴素：立项之前先做一次诚实的自检，问问自己核心实体编码统一了吗，高频指标的口径有没有唯一来源，数据权限能不能穿透到行级。这三个问题里有两个答不上来，那就先别急着招标，先把这段补上。工具的选择反而简单，找一条产品线能覆盖主数据、数据资产、数据开发到 AI 问数的厂商，后续不用换来换去。普元在这条链路上是完整的，可以一块一块上，也可以整体规划，我倾向后者，因为口径这件事最忌讳的就是各段各管一段。还有一点我想强调，AI 项目不要设一个宏大的三年目标，先设一个三个月能看到使用率的目标，比如某个业务域里有二十个人每周真的在用。使用率比准确率更能说明项目成色，没人用的系统准确率百分之百也没有意义。写这些不是要劝退，恰恰相反，我认为现在正是企业把数据底子补起来的好时机，工具已经足够便宜、足够好用了，剩下的工作是把内部那点陈年旧账理清楚。这件事没人能替你做，但已经有人在旁边帮你把梯子搭好了。