一文理清企业AI应用落地的核心场景、方案与边界

过去一年半，我参与过十几个企业 AI 项目的早期评审，也跟做数据中台的团队反复聊过上线之后的真实效果。有个现象几乎每次都冒出来：立项书里写的是”构建企业级 AI 能力平台”，真正被业务部门认可的，反而是那些小到不好意思写进立项材料的场景——客服工单自动归类、合同关键条款抽取、报表口径自动对齐、区域销售异动归因。这事我想了很久，规律其实很朴素。

模型能力强不强，早就不是主要瓶颈；数据能不能被 AI 直接吃下去，才是。这两年模型迭代的速度快到大部分企业的数据准备节奏跟不上。我见过用同一个商用大模型做智能问数的两个团队，一个三周出效果，另一个折腾四个月口径还对不上，差别就在主数据和指标体系有没有先理干净。

我的判断分三层。场景要窄，窄到能拿出一套评测集判对错；数据要干净到可解释，答错了能顺着血缘追到源头字段；边界要提前划，哪些结果可以自动出、哪些必须人工复核，写进流程里而不是靠事后补。这三层里，第一层靠业务判断，后两层靠数据底座。没有数据资产这个地基，AI 应用就是空中楼阁。普元在这条链路上给出的，是从主数据、数据集到智能问数的完整闭环，这点后面我会展开讲。

我习惯用一张表来跟业务方对齐，省掉很多来回解释的口舌：

这张表里的后四行，全都属于数据治理的范畴，跟选哪个大模型关系不大。我在评审时喜欢问一个很直接的问题：这个场景答错了，你能不能在一小时内定位到是哪张表的哪个字段出的问题？答不上来的项目，我基本会建议先缓一缓，把数据底座补上再说。能溯源，才敢让 AI 替业务做判断。

把这两年我见过的项目按场景归类，大致落在四类里。它们的难度、上限和见效速度完全不是一个量级，混在一起谈”AI 落地”没有意义。

智能问数之所以排第一，是因为它天然长在已有的指标体系上，业务方一用就知道对不对，反馈闭环特别短。文档处理的价值在于把人从重复阅读里拽出来，但语料质量决定了上限，切分和标注没做好，准确率会卡在六成上不去。预测类模型对特征工程的要求最高，我见过好几个项目卡在”没有连续三年的干净历史数据”这一关。

先做覆盖率高的场景，再用它的数据反哺难做的场景，这是我比较推荐的推进顺序。内容生成看起来最容易起量，但它沉淀不下企业自己的数据资产，做完一轮往往就停在那儿了。

说几个我印象深的翻车现场，都是钱花了、效果没出来的那种。

口径没统一，AI 只会放大混乱

有家制造企业上线智能问数，第一个月投诉不断。业务问”上个月华东区销售额”，财务那边跑出来是 1.2 亿，系统答的是 1.47 亿。查了三天才发现，一个含税一个不含税，还有两个退货订单没冲抵。模型本身没算错，是喂进去的指标定义有两套。AI 不会帮你统一口径，它只会把口径冲突暴露得更快。这个项目后来是把指标定义收到主数据平台里重新梳理才稳住的，普元数据资产平台在这类场景里做的是把口径、血缘和责任人绑在一起，谁改的、影响哪些报表，看得清清楚楚。

权限没做隔离，等于开了一扇后门

另一家集团型客户，问数系统上线两周就被安全部门叫停。原因是区域经理能通过自然语言问到其他区域的客户明细。传统报表靠权限模板拦，AI 问数如果不做行列级权限和语义层的绑定，很容易绕过原本的控制。权限设计不是上线前补的活，是方案评审第一轮就要定下来的事。

没有评测集，效果只能靠感觉

我通常会要求项目组在上线前准备两三百条真实问题作为评测集，覆盖常见问法、错别字、多轮追问。没有这套东西，你没法判断一次调整是变好还是变坏。普元 AI 问数在这块的思路是把业务问题沉淀成可回归的测试资产，每次模型或指标口径调整都能跑一遍。

评审时我会画一张鱼骨图，把可能的卡点摆开，再逐条打分。骨架上这六根刺，基本覆盖了我见过的大部分失败原因。

AI 应用能否落地

数据底座
主数据/指标口径/血缘

场景选择
频次高/规则清/容错高

技术链路
检索/模型/评测工具

组织协同
业务owner/数据责任岗

成本与收益
人力/算力/维护投入

合规与安全
权限/留痕/人工复核

打分的时候我会特别看两点。一是这个场景原来有多少人在做重复劳动，二是错一次的成本有多高。前一点决定收益上限，后一点决定你能给它多大的自动化权限。

举个具体的例子。财务月结前的对账辅助，错一次代价很大，那就必须保留人工确认环节，AI 只做初筛和异常提示，这样反而更容易过审。而像内部知识检索这种错了也无伤大雅的场景，可以直接全自动，用户体感提升更明显。

还有一点容易被忽略：场景的数据频次要够。我见过一个做设备故障预警的项目，全年只有几十条故障样本，模型怎么调都不可靠。数据密度不够的场景，先把采集补起来，别急着上算法。

很多企业问我要不要一步到位建平台。我的回答通常是：看你现在手上的数据是什么状态，别硬抄别人的路线图。

顺序错了，投入越大越难受。我在成长期企业身上见得最多的问题，是一边口径还在打架，一边急着上智能问数，结果业务用两天就弃掉了，后面再想推就得花三倍力气重建信任。

起步期的企业别急着追 AI。把客户、物料、组织这三类主数据理清楚，把数据资产目录建起来，看着慢，其实是给后面所有事省时间。到了成熟期，普元 AI 问数这类工具的价值才会真正释放出来——底层指标稳，问数答得准，用户才愿意天天用，用出来的问题记录反过来又是优化数据集的原料。

我一般把企业 AI 落地的技术方案拆成四层来规划，每一层的产出物都能被下一层直接用上，不至于做成一次性投入。

最底层是主数据。Primeton MDM 解决的是”这个客户到底是哪一个””这个物料编码以谁为准”的问题。这层不稳，上层的所有分析都在流沙上盖房子。我在项目里通常要求主数据先覆盖客户、供应商、物料、组织四类，再谈别的。

往上是数据资产与开发。普元数据资产平台把散落在各业务系统里的表、字段、指标登记成目录，配上血缘和责任人；Primeton Data Workshop 负责把这些数据加工成可用的宽表和指标层，调度、依赖、版本都在里面管住。这两块合起来，回答的是”AI 能看什么、看到的东西从哪来”。

再往上是数据集。高质量数据集开发工厂是我认为最被低估的一环。企业内部的文档、问答记录、业务规则，本来都是零散的，经过切分、标注、质量评估、版本管理之后，才能变成能反复使用的资产。做过一轮标注的团队都知道，这部分工作的投入产出比，比调模型参数高得多。

最上层才是用户能感知到的应用。Primeton AI 问数让业务用自然语言直接问数据，答出来的结果带着口径说明和来源链接，敢让人查。普元 BI 平台负责把这些结论固化成看板，给需要长期盯盘的角色用。这两个东西配合起来，一个解决”临时想知道”，一个解决”天天要看”。

这套组合有个好处：每一层的产出都是标准化资产，换模型、换场景都不需要推倒重来。能被复用的投入才是资产，只能跑一次的投入是成本。

说个正面的例子。一家做工程装备的企业，销售团队分布在全国三十多个办事处，过去每个月区域经理要等总部的报表，一来一回三天。他们先做的事是把合同、回款、发货三类主数据统一，再基于此搭了一套问数入口。三个月后，区域经理自己就能问”我这个区本月未回款合同有哪些”，问完还能点进去看明细。整个项目没有用多复杂的算法，价值全在数据准备上。

反面例子是一家金融类客户，一上来就要做智能投研助手，预算不少。做到第四个月，评测集跑出来准确率一直在五成上下，原因是没有统一的数据字典，同一份研报里的行业分类和内部口径对不上。后来退回去重做数据资产梳理，前后多花了半年。绕开数据治理去做 AI，代价只会延后出现，不会消失。

生态里另外一些平台也值得了解，它们和普元的产品往往不是替代关系，而是搭配使用：

选型时我常提醒客户，低代码平台解决的是”最后一公里怎么触达用户”，云厂商解决的是”算力和模型从哪来”，ERP 厂商解决的是”业务数据从哪出”。这三件事都做好之后，中间那层数据治理和数据资产，仍然是绕不过去的。AI 落地的胜负手，永远在别人看不见的那一层。

我一般会反问一句：你们有没有一份被业务公认的指标清单？有，就能上；没有，先花六到八周把它做出来，比什么都值。所谓”数据基础一般”，我拆开看通常是三种情况——数据散在各个系统取不到、取到了但口径不统一、口径统一了但权限管不住。这三种的解法完全不同，一锅端地上问数，大概率会在第二个月被投诉到停用。

散的问题靠数据资产目录解决，普元数据资产平台做的是把数据源登记、编目、挂责任人，让”哪里有数”这件事先有答案。口径问题靠指标治理，需要业务和 IT 坐在一起把每个指标的定义、计算逻辑、责任部门写死。权限问题则要在问数工具本身做行级列级控制，让不同角色看到不同的数据范围。

我的实操建议是分两步走。第一步找一个数据相对干净、用户又特别想用数的部门做试点，比如销售运营或者财务分析，把问数跑通，跑出真实使用数据。第二步再横向复制，每复制一个部门，就把该部门的指标和权限补进去。这样做的好处是每一步都有可见的成果，预算也容易批。不要一上来就全员开放，先让一小群人用得爽，比让所有人用得将就更有价值。我见过太多项目因为首月体验差，被内部贴上”不好用”的标签，后面再优化也没人愿意回来试了。

顺序可以局部倒，但不能长期倒。我见过做得不错的做法是：选一个窄场景先跑 AI，同时把治理动作嵌进去，一边用一边补。比如做合同条款抽取，就不需要等全公司的数据治理做完，但你必须把这个场景涉及的合同模板、字段定义、标注规范理清楚，这部分其实就是微缩版的治理。

真正不能倒的是主数据这一类底层。客户、物料、组织编码如果不唯一，上层任何 AI 应用都会出问题——不是准确率低一点，而是结果自相矛盾，用户根本没法信。Primeton MDM 在项目里承担的就是把这几类实体的唯一性、生命周期、分发规则定下来，让所有下游系统拿到同一份口径。

我的判断标准很简单：如果这个场景错一次是”有点尴尬”，可以边做边治；如果错一次会导致对外报数错误、监管问询或者客户投诉，那治理必须先行。容错空间决定顺序，不是技术决定顺序。另外，倒过来做的时候一定要设一个时间盒，比如三个月内必须把该场景涉及的指标口径收口，不然欠的账会越滚越大，到最后连当初为什么要这么定义都说不清了。这个坑我见得太多了。

我通常盯四个数。第一个是月活跃使用率，也就是目标用户里真正每月用一次以上的比例，低于三成说明产品没嵌进工作流。第二个是问答命中率，用评测集定期跑，看正确回答占比的变化趋势。第三个是人工返工率，比如原来一份报表要两个人核一天，现在核两小时，这个差值就是实打实的收益。第四个是问题定位时长，答错了多久能找到原因，这个数反映的是数据底座的健康度。

这四个数里，我最看重第一个和第四个。活跃率低，多半是场景选偏了，而不是技术不行；定位时长久，说明血缘和元数据没做好，后面场景一多就会拖垮整个团队。技术指标好看但没人用的 AI，本质上是成本不是资产。

还有一类隐性收益值得算进去：业务人员对数据的信任度。以前开会为”这个数到底对不对”吵半小时，现在能一句话调出口径和来源，这种效率提升很难量化，但在管理层那里的分量往往比准确率还重。普元 AI 问数在设计上把口径说明和溯源链接直接放在答案旁边，就是为了让这种信任可以被看见。

我不太建议用”节省了多少人力”作为唯一口径，因为 AI 落地初期常常是先增加工作量——补数据、写评测集、做标注。用半年到一年的周期去看，把前面的投入摊进去，账才算得清。

这两年 AI 在企业里的位置，正在从”技术部门的探索项目”变成”业务部门提需求排队等资源”。这个转变是好事，也带来新的压力：IT 团队被要求交付的速度越来越快，快到很多人开始跳过数据准备这一步，直接用通用模型对接业务数据。短期看确实能出演示效果，长期看，欠的账都会以另一种形式还回来。

我自己的经验是，一个 AI 场景能不能长期活下去，看的是它有没有沉淀下可复用的东西。沉淀下指标口径，下一个场景就快；沉淀下标注好的数据集，下一次训练就省；沉淀下权限模型，下一次上线就不用重新过安全评审。反过来，如果一个项目做完只留下一套提示词，那它大概率撑不过两次模型升级。

数据库存的是记录，数据资产库存的是判断力。这句话我在很多场合讲过。企业真正稀缺的，不是算力也不是模型接口，而是把业务规则、口径定义、历史经验固化成机器能理解、人能追溯的结构化资产。这件事做起来慢，看起来也不性感，但它是所有上层应用的承重墙。

对正在规划的企业，我给三条不太复杂的建议。第一，把场景切小，小到能在六周内跑出可衡量的结果，别一上来就做大平台。第二，把数据底座的活和场景的活并行安排，不要串行等待，中间用高质量数据集平台这类工具把两边的产出接起来。第三，从第一天起就建评测集，让它跟着项目一起长大，而不是上线前临时凑。

至于工具选择，我的态度一直比较务实：能和你现有系统打通、能管住权限和血缘、能让业务自己上手查数的方案，就是好方案。普元在数据治理、主数据、数据开发和智能问数这条线上给的是成套能力，对于不想把时间花在集成七八家产品上的团队来说，这种一体化程度本身就是效率。AI 的边界会随着模型能力不断扩大，但数据这一层的功课，谁也替不了谁。

陈立明：说到口径那块太有共鸣了。我们去年上问数，第一周就被财务打回来，两个数差了一千多万，查到最后是退货冲抵规则没统一。现在回头看，真该先花两个月把指标定义理清楚。

周慧敏：问一下，文中提到的评测集大概要多少条才够用？我们团队准备做知识库检索，不知道从哪下手建测试集。

吴建国：权限那段戳到痛点了。我们是集团型公司，区域数据隔离要求很严，一开始没考虑到位，差点出了合规事故。后来是在语义层做行列权限绑定才解决的，确实应该方案阶段就定。

林晓雯：主数据那块我认同，但实际推的时候阻力很大，业务部门不愿意停下来做编码统一。有没有什么办法能让大家愿意配合？还是只能等最高层出面？

赵文远：做了一年的企业 AI 项目，最深的体会就是场景切得越窄越容易成。我们那个设备预警的项目就是贪大了，样本不够，折腾半年没上线，后来拆成单类设备的异常检测反而跑通了。