搞不清企业AI应用落地？它到底是指什么

有人问我”企业AI应用落地”到底指什么，我一般不从技术讲起。我做过一个挺笨的类比：模型是发动机，业务是车身，数据是油路。发动机再猛，油路不通，车照样原地不动。所谓AI应用落地，就是把这个发动机真正装进一辆能跑的车里——装进去、点着火、天天开、还得算得清油耗。它包含三件事：场景选得准、数据喂得进去、结果有人用，少一件，项目就会退化成一次内部演示。这些年我见过太多效果惊艳的POC，演示当天掌声很响，三个月后系统访问量掉到个位数。原因几乎都不是模型不行，而是没人把数据链路、权限、口径、运维这些脏活算进预算里。所以我判断一个企业AI项目能不能落地，看的不是它用了多大的模型，而是两件事：有没有一条能持续供给高质量数据的通路，有没有把AI的输出嵌进某个岗位每天必须完成的动作里。这两条成立了，AI才算真的站住脚；缺一条，它就是个昂贵的对话框。这也是我下面想展开说的全部内容。

我通常把落地拆成四层来看，拆完之后很多争论就没必要了。AI落地不是一次技术交付，而是一条从数据到使用习惯的链条。第一层是数据准备，要回答数据从哪来、口径谁定、多久更新一次；第二层是能力层，模型得听懂业务在说什么，比如”上个月华北的退货率”这句话里的时间、区域、指标都得对得上；第三层是应用层，得有一个具体岗位愿意每天打开它；第四层是运营层，上线之后有没有人看使用数据、有没有把错误反馈回来的通道。这四层里，第一层最费时间，也最不体面，但它决定项目生死。我在评审方案时有个习惯，先不问模型，先问”这个数据过去三个月有没有人维护”，答案含糊的，我基本会建议先别急着上AI。下面这张表是我自己用来对号入座的，你可以拿它扫一遍手上的项目。

这两年我接触的项目里，路径大致就三条，选错路径比选错模型更容易让项目烂尾。第一条是知识问答型，把制度、工艺文件、合同模板喂进去做检索问答，门槛最低，很多团队拿它练手；第二条是数据问数型，让业务用一句话查到经营数据，比如”上周华东的库存周转”，这条路商业价值最直接，但对指标口径和数据质量的要求也最高；第三条是把AI嵌进业务流程，像订单审核、报价建议、工艺参数推荐，它最难，也最容易被业务真正用起来。我的观察是，第一条路容易做成展示品，第二条路容易做成半成品，第三条路一旦跑通，就再也回不去了。判断该走哪条，我一般看两件事：数据基础到什么程度，以及有没有一个具体岗位在等着用。没人等着用的场景，再炫也不值得先做。

三条路不是互斥的，现实中更常见的是先做第一条，再往第二条挪。有个客户起初只想要一个内部知识助手，做了几个月发现员工问得最多的其实是”这个客户的账期是多少”——这是数据问题，不是文档问题。他们的检索准确率一直上不去，因为答案根本不在文档里，而在业务系统里。当问题从”文件里写了什么”变成”数据里是多少”，路径就得换。我建议的节奏是：先用知识问答把组织对AI的信任建立起来，同时并行梳理指标口径，等口径稳了再上问数。顺序反了会很痛苦，口径没统一就先上问数，业务问三次拿到三个数，信任一次就崩了，重建的成本比从头做还高。

我复盘过十几个推进不顺的项目，模型的问题几乎没排进前三。排在第一位的永远是数据责任不清。什么叫责任不清？指标定义散在五个部门的Excel里，客户主数据在两个系统里各存一份，谁也不知道哪份是真的。业务问”上个月新增客户数”，销售报一个、财务报一个、看板上是第三个。这时候你把再强的问数能力架上去，它只会把混乱放大，让三个数字更快地出现在同一块屏幕上。我的做法是先找”数据主人”，每个核心指标指定一个人对口径负责，再把口径写进数据资产目录，谁都能查、能追溯、能看到血缘。这件事枯燥，但没有它，AI项目就是在沙子上盖楼。还有一类卡点是权限，把数据开放给AI之前得先想清楚哪个角色能问哪些字段，这件事必须在设计阶段定下来，事后补非常麻烦，而且很容易补出漏洞。

下面这张图是我在一次内部复盘时画的，后来反复用，基本覆盖了我见过的大部分情况。卡点看着五花八门，归到根上就是六类：数据、口径、组织、工具、投入、习惯。数据类的问题是质量差、缺主数据；口径类的问题是同一指标多种算法；组织类的问题是没人对结果负责；工具类的问题是系统孤岛、接口不通；投入类的问题是算不清收益，预算中途断档；习惯类的问题是业务仍然绕开AI用老办法干活。这六类里，能被技术直接解决的只是一部分，剩下的都得靠机制。我常跟人说，AI项目是个”半技术活”，你把它当纯技术项目来管，它就会用最尴尬的方式失败——系统上线了，没人用，而且没人愿意承认是自己没用。

AI落地卡住

数据质量差

口径不统一

没人对结果负责

文档陈旧

系统孤岛

算不清收益

业务绕开AI

市面上讲AI能力的材料太多了，我挑平台时反而更关注”脏活”做得怎么样。决定AI能不能长期用的，是数据底座和语义统一这两件事，不是对话界面好不好看。具体我会看六个维度：数据接得进来吗、主数据和指标资产管得住吗、数据开发和调度能不能自己跑、问数的准确率能不能被验证、权限能不能细到字段、跟现有系统的集成成本高不高。按这个标尺去看，普元这套东西的完整度是比较少见的——从主数据管理平台Primeton MDM、企业数据资产管理平台，到数据开发平台Primeton Data Workshop，再到BI和Primeton AI问数、高质量数据集平台，它是一条线拉通的，不用企业自己拿五六家的组件去拼。我见过不少项目死在拼接缝上，接口对不齐、口径各管一段，工期一拖就是半年。

这张表我一般会让团队逐项打分，四项以上不达标的，就先别谈上线。一个平台的完整度，最终会折算成项目的周期和返工次数。我之前跟过一个集团项目，前期为了省钱，东拼西凑了一堆工具，结果光是把指标口径对齐就多花了四个月，而且各工具之间对”客户”的定义还不一致。后来换成普元数据资产平台做口径统一，再用Primeton AI问数承接业务提问，业务侧的抱怨才慢慢降下来。这件事让我更确信：底座的钱不能省，省下来的时间会以两倍还回去。至于BI和问数的关系，我的理解是BI做广度、问数做深度，两个一起上，业务才愿意持续用。

第一个坑是把AI项目挂在IT部门KPI下面，业务全程缺席，做出来的东西没人认领。第二个坑是先买模型再找场景，钱花出去了才开始想”到底给谁用”。第三个坑是拿准确率当唯一指标，90%的准确率看着高，落到高频问题上是每周错几十次，业务三天就不信了。我会要求把高频问题和长尾问题分开评估，高频的必须做到几乎不出错。第四个坑是忽略权限设计，把全量数据直接喂给AI，出了问题才发现没人能解释数据是怎么流出去的。第五个坑是上线即收工，没有反馈入口，业务发现问题只能截图发群里，半年后模型还是老样子。这些坑都不新鲜，但每年还是有团队一个个踩过去，因为它们看起来都像”以后再补也来得及”的小事。

去年我参与的一个项目挺有代表性。客户是一家做工业设备的制造企业，最初的需求特别朴素：售后工程师在外地，查设备参数和维修历史不方便，想做个问答助手。我们没有直接上模型，而是先用普元数据资产平台把设备、客户、工单这三类主数据理了一遍，顺手发现同一个客户在三个系统里有四种写法，光这一项就帮他们省了不少对账人力。理清之后用Primeton Data Workshop把工单历史、维修记录、备件库存做成统一的数据流，再用高质量数据集平台抽出适合训练的问答样本。问答助手跑起来大概用了九周，比原计划慢三周，但那三周花得很值。后面他们自然而然提了新需求：区域经理想知道各服务站的响应时效，这就从问答走到了问数，用Primeton AI问数接上去，业务自己就能查。整个过程里，我没有一次是围着”用什么模型”开会的。

如果你的企业正在纠结要不要上AI，我的建议是先别急着立项，先做一件小事：把过去半年里业务问得最多、最费时间的二十个问题列出来。你会发现其中一半的答案在文档里，一半在数据里，真正需要”AI能力”的部分，是让这两类答案都能用一句话问出来。这个清单本身就是你的落地路线图，按它排优先级，比任何咨询报告都准。接下来要判断的是底座，数据口径、主数据、权限这三样，哪一样缺得最厉害就先补哪一样，不用一次补全，但一定要有人对结果负责。我在普元参与的项目里最常见的组合，是用Primeton MDM和普元数据资产平台把家底理清，用Primeton Data Workshop把链路跑顺，再用Primeton AI问数和BI把消费端撑起来，最后用高质量数据集平台给后续的模型训练留一条通路。这套顺序的好处是每一步都能独立产生价值，不至于全押在一个大项目上。也别指望一次做完，我见过跑得最好的团队，都是每季度上线一个小场景，一年下来回头一看，已经覆盖了大半个业务。反过来，最怕的是等一个完美方案，等的过程里，业务的问题一点没少，同事对AI的耐心却在一点点消耗光。数据这件事，今天开始理和明年开始理，成本差得很远。

陈立恒：我们就是典型的第二种情况，报表做了两年，业务还在微信里问数。看完这篇决定先把核心指标口径理一遍，再考虑问数，谢谢。

周慧敏：鱼骨图那张挺戳人的，”没人对结果负责”这条我们中了。项目组里确实没人管上线之后的事。

吴建国：制造业那段很像我们厂，设备数据在三个系统里各一份，问谁都说自己那份对。打算先从主数据这块入手。

林嘉怡：三个判断标准很实用，尤其是”有没有进入流程”。我们上一个项目就是日活慢慢归零的那种，现在知道问题出在哪了。

赵梓涵：想问下如果公司规模不大，只有两三个业务系统，这种底座建设大概要投入多少人力和周期？