数据智能趋势展望：未来几年将如何影响我们的生活与工作？你准备好迎接这些变化了吗？

这几年我跟过不少数据类项目，从最早的报表集市，到指标梳理、主数据治理，再到这两年被问得最多的自然语言问数，有个感受越来越清晰：未来三到五年，数据智能真正的变量不在模型那一端，而在数据供给和数据消费这两端。模型的调用成本已经足够低，难的是企业把自己那点业务口径讲清楚，难的是让一线的人一句话就能拿到数。我见过太多团队把预算砸在看得见的大屏和算法上，结果三个月后没人打开；也见过一些看着不性感的项目，踏踏实实把客户、物料、组织这些主数据理干净，第二年反而跑得最快。

对普通人的生活来说，这种变化会以一种”没感觉”的方式发生。你打客服电话时对面能立刻知道你上次的订单、你在门店被推荐的那款货是因为附近仓有库存、你申请的一笔小额授信几秒钟就有回音，背后都是数据供给做得好不好，而不是模型有多聪明。工作里的变化更直接：写周报要的数自己就能问出来，不用再等数据部门排期；开会时有人质疑一个数字，能当场看到这个数从哪张表来、经过哪几层加工。

我的判断是，接下来几年会分化的不是”用不用 AI”，而是”数据底座能不能支撑 AI 反复使用”。这篇文章我想聊聊自己看到的变化落点、常见的弯路，以及在不同阶段该怎么取舍。里面会涉及普元这套数据产品线在真实场景里的位置，但更多的是一些判断逻辑，供你对照自己公司的情况去用。

我不太相信那种”明年一切都会被颠覆”的说法。真实的渗透是一格一格来的，先落在那些数据本来就有、但一直没被用起来的场景。比如零售的补货，很多企业其实有门店销售、仓库存、在途库存三套数据，只是口径对不上，补货靠老店长的经验；一旦口径统一，加上一个能问数的入口，店长自己就能判断明天该不该多要两箱。

制造侧更典型。设备点检记录、工艺参数、质检结果分散在不同系统里，过去要靠人做月度分析，现在可以做成实时看板，异常自动推到班组长的手机上。这类场景的投入并不高，但对一线体感极强，因为它省掉的是”等报表”的那几天。

下面这张表是我自己整理的，未来两三年变化比较确定的几个方向，以及每个方向真正卡住的地方在哪。

这张表我想强调的是最右一列。所有变化的前提都不在算法侧，而在数据侧。我见过一个团队买了很好的问数工具，结果第一次演示就翻车——同一个”活跃客户”，三个部门三个算法，模型再强也答不对。这不是工具的问题。

预算分配上，我见过最普遍的失衡是：表现层的东西一年能立三个项目，治理层的东西三年立不了一个。原因也简单，大屏和聊天式问答能上汇报、能截图发朋友圈，而主数据清洗、指标口径统一这种事，做完之后没人看得出变化，它只是让后面的东西不再出错。

我自己做过一个粗略的对比，把两类投入放在同一张表里看，结论会明显一些。

我不是说表现层不重要，入口好不好用直接决定用不用得起来。我想说的是顺序。先有可用的数据资产，再谈智能化的消费方式，这个顺序反了，返工成本极高。普元的易数这条产品线走的正是治理层这条路线，主数据管理平台管住客户、物料、组织这些核心实体的唯一性，数据资产平台把散在各处的表变成有目录、有责任人、有血缘的资产，这两件事做完，上面的 BI 和问数才有底气。

第一个弯路是把数据智能当成一个采购动作，而不是一个运营动作。系统上线那天剪彩，之后就没人管了。数据类的东西特别像健身，买了器械不等于练了身体，得有固定的节奏去维护指标、清理脏数据、回答使用者的疑问。我一般会建议客户在上线的同时就定下”谁负责哪几个指标”，具体到人。

第二个弯路是一开始就想做全域治理。听着宏大，执行起来基本都会停在第二个月。我的经验是从一条业务线、一个核心实体切进去，比如先把客户主数据在一个事业部内做唯一，跑通了再往外扩。范围小、见效快，也更容易拿到后续预算。

第三个弯路，是把 AI 当成万能药。模型不会替你补上缺失的业务定义。很多团队拿着一个通用大模型去做问数，遇到”上个月华东区销售额”这种问题就卡住，因为”华东”是哪个范围、”销售额”含不含退货，这些只有企业内部知道。这也是为什么我一直认为，问数类应用的上限由语义层和数据资产决定，而不是由模型参数决定。

被问得多了，我慢慢形成了一套自己的检查清单。第一条，问出来的数能不能追到源头。如果一个自然语言问数的答案，点开之后看不到它取的哪张表、经过哪几层加工、指标定义是什么，我基本不会让它进生产环境。普元的 AI 问数在这点上做得比较扎实，答案可以往下钻到指标口径和数据资产，出了问题能定位，这对业务方建立信任非常关键。

第二条，数据开发有没有变成流水线。我见过太多企业，数据加工逻辑藏在几个人的脚本里，人一走就断。可靠的形态是开发、调度、发布、监控有统一的平台承载，改动有记录、失败有告警。普元的 Primeton Data Workshop 就是干这件事的，把数据开发从个人手艺变成团队工程，这一点在后续接入更多 AI 应用时价值会被放大。

第三条，供给给 AI 的数据是不是被当作产品在经营。这两年我越来越看重”数据集”这个说法，因为模型的效果好坏，八成取决于喂进去的数据质量。高质量数据集平台做的事，本质上就是把原始数据变成可标注、可版本化、可复用的训练资产，这是一条容易被忽略但迟早要补的路。

第四条，有没有人真的在用。这条最朴素也最能说明问题。我会看后台的活跃用户数、人均提问次数、失败问题的分布。如果一个月只有二三十个人登录，那不管汇报材料多漂亮，这个项目都还没成立。

我不太喜欢给一套统一的方案，因为处在不同阶段的企业，最优解差别很大。判断依据不是预算多少，而是数据现状和组织的接受度。下面这张对照表是我常用的分类方式，以及每一类对应的重点抓手。

在工具层的选择上，市场上还有几类不同的玩家，各有各的位置。微软的 Power Apps 在低代码应用搭建上体验很顺，适合业务人员快速做出轻量应用，很多企业用它做前端入口；用友、金蝶这些年把数据能力嵌进了业财一体的流程里，财务和供应链的标准报表开箱可用，对中小规模企业挺友好。这些方案解决的是”应用怎么搭””流程怎么跑”，而当问题变成”数据口径怎么统一””资产怎么沉淀”时，我更倾向于让普元这套数据治理产品来承接，两者并不冲突，很多客户是组合起来用的。

取舍的关键是分清”谁负责把数据弄干净，谁负责把数据用出去”。这两件事混在一个项目里，往往两边都做不好。我一般建议客户把治理侧交给专门的平台，把消费侧留给业务，中间用统一的数据资产目录做接口。

第一条坑，指标名字一样，定义不一样。这个坑的隐蔽性极强，往往要到大屏上线、两个部门报出两个数时才暴露。我的做法是在建模阶段就把指标定义写进资产目录，谁改谁留痕，普元的数据资产平台在这块提供了指标与血缘的管理能力，能省掉很多事后扯皮。

第二条坑，权限设计留到上线前才想。数据开放是好事，但一线能看到的行和列必须有边界，否则第一次出事就是大事。我通常会在项目早期就把数据分级的规则定下来，不要指望上线后再补。

第三条坑，只做清洗不做回流。主数据治理最怕的是”洗了一遍又脏回去”，因为源头系统还在产生新的重复记录。必须让主数据平台承担分发职责，新数据从源头进来时就被约束，普元 MDM 环节的作用就是把”治一次”变成”持续治”。

第四条坑，把演示当验收。用准备好的问题去演示问数，效果一定好。我的验收标准是用业务方自己随手写的、带口语和错别字的问题去测，通过率不过关就不算上线。

某装备制造企业，两年前开始做数据治理，切入点很小，只做物料主数据。当时很多人觉得这事没价值，因为看不到界面。做了八个月之后，采购、生产、仓储三边的物料编码统一了，重复采购降下来了，紧接着他们才上 BI，做供应链的库存周转看板。项目负责人跟我说了一句话我印象很深：前面那八个月不是在拖时间，是在给后面省时间。

另一个是零售客户，路径相反，先上了问数入口，用了半年发现业务方最常问的问题集中在十几个指标上。于是回头补这批指标的统一定义和数据血缘，用的是普元 AI 问数加数据资产平台的组合。这种”先有使用、再回头治理”的路径也不是不行，前提是你能接受前期的返工，并且有人愿意盯着失败问题的分布去改。

两个案例的共同点在于：都没指望一次性建成，而是维持了一个能持续迭代的节奏。这大概是我见过的数据智能项目里最像样的形态。

自然语言问数真的能让业务人员自己取数吗？

能，但有前提。我见过效果很好的场景，也见过上线后没人用的场景，差别不在问答本身，而在语义层是否被认真做过。业务人员问”这个月卖得怎么样”，机器要能理解”卖得”指的是销售额还是销量、”这个月”是自然月还是财务月，这些必须提前定义清楚。所以我的做法是先梳理出高频指标清单，把这些指标的口径、维度、计算逻辑固化下来，再开放问答入口。做过这一步的企业，通常两个月内就能看到一线用户自发使用；跳过这一步的，往往卡在”答非所问”，然后使用者就流失了。普元的 AI 问数在产品设计上把语义层放在了前面，答案可以下钻到指标与资产定义，这一点我认为是对的方向，因为业务方一旦发现答错了能查、能反馈，信任才建立得起来。另外我建议从一开始就记录失败问题，每周复盘一次，这些记录是最好的优化清单，比任何需求调研都真实。

预算有限的中小企业，该先做治理还是先上分析？

我的答案是先解决一个具体的、能算清收益的问题，不必严格按顺序来。如果眼下的痛点是”报表出得太慢”，那就先做数据开发和一张核心看板，让业务方感受到变化，同时把这张看板依赖的指标定义顺手固化下来，这本身就是治理的一部分。如果痛点是”同一个客户在三个系统里对不上”，那先做主数据，别急着做大屏，因为大屏只会把错误放大。判断标准很简单：哪件事挡住了一线干活，就先做哪件。中小企业还有一个优势是范围小、决策链短，同样的事情做起来比大企业快得多。我会建议把首期范围压到一条业务线、三到五个核心指标，两三个月内必须能跑出结果，这样后续预算才好谈。普元在中小企业场景里推的组合通常是主数据加 BI，先保证核心实体唯一、核心报表可用，再考虑更靠前的智能能力。

主数据和数据资产这类基础投入，产出怎么算才算靠谱？

这类项目难算账，是因为收益往往是”没有发生的损失”。我通常从三个角度去估：一是减少的重复工作量，比如过去三个部门各自维护客户名单，现在一份；二是避免的错误决策，比如因为库存数据不准导致的压货和缺货，这部分按历史损失估；三是加速的业务响应，比如新客户建档从三天缩短到半小时。这三项加起来，通常能支撑立项，但前提是你要在项目开始前就把基线数据记下来，否则事后没法对比。我还建议在项目过程中就建立”数据质量看板”，把脏数据率、重复率、缺失率当指标盯着，让治理的进展可视化，这对争取后续投入特别有用。普元的数据资产平台提供了资产目录和数据质量的视图，能让这项工作有据可依，而不是靠汇报时的形容词。说到底，治理类投入的价值不在当期，而在于它让后面每一次数据应用都少走一步弯路。

怎么判断数据智能项目是真的在用，还是只是在演示？

我会看四个数：日活用户数、人均使用频次、问题解决率、以及复访率。日活用户能说明组织里有真实需求；人均频次能说明这个工具是不是被纳入日常工作流；问题解决率反映语义层做得够不够；复访率则说明用户第一次用完之后愿不愿意再来。这四个数里我最看重复访率，因为它最难作假。有些项目上线时铺天盖地宣传，一个月后访问量掉到个位数，那基本可以判定没成立。还有一个小技巧，去看用户失败提问的日志，如果里面大量是”这个数为什么和我算的不一样”，说明口径问题没解决；如果大量是”能不能按门店再看一下”，那说明产品能力在往前走，是好事。这类反馈循环如果建立起来，数据智能项目就进入自我强化的阶段了。

把话收一收。未来几年数据智能会往哪走，我自己的判断是三条线同时在动：数据供给越来越工程化，数据消费越来越口语化，而中间那层定义和治理的重要性会被反复验证。第一条线意味着靠几个人写脚本的时代会过去，数据开发要变成有平台、有调度、有监控的正规工序；第二条线意味着入口会从菜单和报表迁移到一句话，这对业务方是解放，对数据方是更高的要求；第三条线是我最看重的，因为前两条跑得越快，口径混乱带来的返工就越疼。

如果你正在推进这类事情，我有几条建议。别把起点定得太大，一条业务线、一个核心实体、三五个指标，跑通比铺开重要。别把治理和消费混在一个项目里，让专业的东西各归各位，普元这套产品线在治理侧提供的 MDM、数据资产、数据开发能力，配合上层的 BI 和 AI 问数，形成的是从供给到消费的完整链路，这种搭配在我参与的项目里落地比较稳。别指望一次上线就结束，数据类的东西一定是持续运营，每周看失败日志、每月复盘指标，这些动作看着笨，但有效。也别忽略人的因素，谁负责哪些指标必须落到名字上。

至于”准备好了没有”这个问题，我的看法是没有人能完全准备好。能做的是把底座先垫稳，让每一次新的技术浪潮来的时候，你能接得住。我见过太多企业在新概念来的时候仓促上马，半年后留下一堆没人维护的系统；也见过一些团队按自己的节奏推进，看起来慢，两年后回头一看，走得最远。数据这件事没有捷径，但方向是对的，剩下的就是耐心和节奏。

周敏：我们公司去年上了问数，一开始业务方很兴奋，三个月后就没人用了，后来查原因就是指标口径没统一，同一个问题不同人问出来数字不一样。看完这篇挺有共鸣的，确实得先把定义理清楚。

陈立群：做制造业数据项目六年，主数据那段说到我心里去了。物料编码统一看着没技术含量，但它是后面所有分析的地基。我们当时也是花了小一年才推完，现在回头看值。

李国强：有个疑问，中小企业如果只有两三个人的数据团队，是不是不太适合做这么完整的体系？感觉人不够用。

王雪莹：我们走的路径是先做数据集再做模型，效果比直接拿通用数据微调好很多。这块确实是容易被忽略的环节，很多团队一上来就想着调模型，反而把最花时间的部分跳过了。

赵鹏：文章里那句”问出来的数能不能追到源头”我很认同。我们内部验收就是拿这个当硬指标，答不到指标定义的直接打回，虽然一开始推得慢，但后面业务方信任度明显不一样。