企业想做 AI 之前，多半会先听到一句劝告：先把数字化做完。

这话理论上没错。AI 需要线上数据，需要标准化的流程，也需要能和业务系统连上。如果客户、商品、订单、库存全在线下，AI 确实无从下手。

但真到要动手，两个问题马上卡住：数字化要花多少钱？完善到什么程度才算"完成"？

企业上了进销存，还有客户管理系统；上了客户管理系统，还有供应链、知识库和数据中台。系统建完了，业务又变了，原来的字段、流程和权限还得接着改。数字化本身就是一条持续建设的路，很难找到一个清晰终点。

如果一家企业先花两年把数字化做完，再开始研究 AI，两年之后黄花菜都凉了——模型能力、业务环境和竞争格局早就不是原来那个样子。

这篇就聊这件事：没有数字化底子的企业，路该怎么走。

一、差距不在买的模型上

先看一组对比，能说明"数字化基础"到底意味着什么。

Gartner 今年四月的分析发现，AI 做得出成绩的企业，在数据质量、治理、人才和变革管理上的投入，最高是落后企业的四倍。注意，这些钱主要不是花在模型上。

同一个调研里，只有 39% 的技术负责人相信自己公司的 AI 投入能收回成本，对安全治理"非常有信心"的只有 23%。换句话说，差距不在买了什么模型，而在模型周围那一圈东西有没有人认真建。

另一边的现实是：真正把智能体推进到生产的企业还很少。S&P Global 的数据是 31% 的企业至少有一个智能体在跑，而 42% 的企业已经放弃了大部分 AI 项目——这个数字比上一年的 17% 涨了一倍多。麦肯锡今年的口径是只有 11% 的企业做到了真正的规模化。Gartner 判断，70% 的智能体用例最终无法兑现预期价值，根子在成本模型算错了。

还有一组数字值得单独提。麻省理工学院的 NANDA 团队去年发布过一份报告，150 位高管访谈加 350 份员工问卷，结论是约 95% 的企业生成式 AI 试点没有产生可衡量的损益影响，只有 5% 真正拿出了百万级以上的价值。他们给出的核心解释不是模型不行，而是存在"学习鸿沟"——报告里有句话说得很准：大多数生成式 AI 系统不保留反馈、不适应上下文、也不会随时间改进。

把这些放在一起看，结论是：没有数字化基础的企业当然不能跳过数据和流程建设，但也不必等所有基础设施全部齐活再起步。

二、AI 牵引式数字化：先选场景，再倒推缺口

更合理的路径是让数字化和 AI 化互相牵引、互相补齐、齐头并进。

具体做法是反过来的：先挑一个值得解决的 AI 场景，再根据智能体需要做出的判断，反向梳理它需要哪些数据、流程、系统和接口。缺什么数字化能力，就围绕这个场景补什么。

这条路可以叫"AI 牵引式数字化"。

它和传统的数字化建设顺序正好相反。传统做法是从系统功能出发：业务系统有什么字段就先收什么字段，软件能出什么报表就先看什么报表。倒推做法是先问"智能体要完成什么判断"，再根据判断倒推数据。

顺带提一句，这个思路正好对应今年数据圈被反复提起的一个话题。Gartner 在数据与分析峰会上把"上下文"抬到了关键基础设施的高度，负责这块研究的 Rita Sallam 提出，企业应该把上下文当成下一项核心基础设施来投资，把语义层这类东西作为长期战略资产来养。他们的预测是：到 2028 年，那些只靠 MCP 接口、没有统一语义层的智能体分析项目，会有 60% 失败。

原因不难理解。模型再强，如果没有一份统一的口径告诉它"这个字段在我们公司到底指什么"，它只能自己猜，而猜出来的东西没法用来做经营判断。

三、案例拆解：一个连锁餐饮的菜单营销智能体

道理说起来抽象，拿一个具体的场景拆开就清楚了。

这个场景是一家连锁餐饮企业的菜单营销智能体：旗下几十家门店分布在全国多个城市，主营野生菌火锅，最初的需求是帮顾客和门店营业员完成菜品推荐。

比如顾客说：我们有 4 个人，不吃辣，其中一个人湿气比较重。

智能体要听懂人数、口味、忌口和体质，再推荐合适的锅底、菜品组合和推荐理由。

这句话听着简单，拆开运行逻辑以后，至少牵扯到六类数据：

哪些锅底和菜品不辣；

哪些食材适合对应的身体状态；

当前门店有什么菜、哪些已经售罄；

哪些食材正当季；

哪些菜品符合品牌当前的经营策略；

4 个人该推多大分量、怎样的组合；

推荐理由怎么体现野生菌和药食同源的特色。

上面任何一类数据缺失，推荐就可能跟门店真实情况脱节。全部算下来有六大类。

这就是 AI 牵引的意义：一句顾客需求，倒推出了六大类数据要求。如果没有这个具体场景，你很难回答"菜单数据到底要整理到什么程度"。

四、为什么不直接用现成的点餐系统

现在扫码点餐和各类餐饮 SaaS 已经很成熟了，为什么还要单独做一个智能体？

因为两者职责不同。普通点餐系统负责的是完成交易：展示菜单、选菜、加购物车、下单、支付。而这个场景要解决的是交易之前的推荐决策。

野生菌火锅的信息密度很高，顾客可能不认识不同菌类，不知道食材和锅底怎么搭，也不了解不同季节该吃什么。企业想传递的山野文化、药食同源理念和品牌知识，很难靠一张菜单讲清楚。

再加上三个现实问题：

门店分散在多个城市，服务行业人员流动快，服务员对菜单本身也不熟，培训要一遍遍重复。靠员工记忆，很难保证不同门店用同一套推荐逻辑和表达方式。

推荐还要结合经营信息。同一道菜的库存、成本和毛利一直在变，哪些菜品库存高、哪些利润高、哪些不能长期存放，前堂服务人员根本不知道。

品牌想传达的知识需要一致的口径，而人对知识的记忆和转述每次都不同。

所以两者分工：点餐系统负责展示和交易，智能体负责理解需求、调用知识、结合经营数据辅助推荐。

菜单也因此成了一个很好的 AI 切入点。它既是顾客看到的销售目录，也是门店背后的生产目录——往前连着顾客、会员和营销，往后连着菜品、原料、库存、供应链和毛利。一个点餐场景，能牵动企业好几个核心数据域。

五、旧数据太乱，有时候重建比治理更划算

这个场景还有一层背景值得说。

这家企业过去用过一套大型餐饮管理软件，后来换了供应商。随着系统更换，原来的业务、财务和管理数据慢慢断了：同一个概念在不同系统里叫法不一样，菜品、原料、库存和财务字段之间缺少稳定映射；一部分历史数据来自旧系统，一部分散在不同部门的表格里，还有一些只存在员工脑子里。

大多数企业遇到这种情况，第一反应是做历史数据治理：清洗、统一字段、补标签，再把旧数据迁进新系统。

也有企业做了更狠的选择：业务改造层面不再迁移和治理原有经营数据，围绕新的系统架构从头建一套干净的数据体系。

不让混乱的旧数据继续带进新的经营体系，也不让历史包袱决定新系统该怎么建。

新体系重新划了各系统的职责：点餐收银类系统承接点餐、收银、会员、库存和供应链；财务系统拆出独立数据中心，负责核算、报表、资金和往来；协同办公平台承接审批、任务和内部管理；数据中台汇集经营数据；智能体能力层连接数据、知识和推荐决策。

但这个做法不能机械复制。它有自己的适用条件：

历史数据质量很差，清洗出来的东西可用性本来就低；

旧系统本身已经在准备替换；

关键数据无法可靠映射，硬迁只是把混乱搬个地方；

治理成本已经高于重新积累的成本。

同时还要评估历史数据的业务价值、法律保存要求、系统切换风险，以及新旧数据怎么衔接。企业敢这么选，往往是因为它本身就在替换多套核心系统，有机会从数据产生的第一天重新定义规则。

有测算认为，光是脏数据每年就从美国经济里抽走约 6170 亿美元，大约相当于 GDP 的 2%；按人头算，科技和软件行业企业每年为数据问题花的钱，人均超过 1.2 万美元。这些数字不能直接套到某一家企业头上，但它说明一个常识：数据债不会自己消失，只会换个时间、换个名目付出去。

六、从决策倒推数据，再从数据倒推系统和责任

决定重建数据体系之后，下一个问题是：新体系按什么标准建？

还是倒着走。拿点餐场景举例：智能体要推荐菜品，就得知道顾客需求、可售菜品、库存、毛利、时令、食材属性和品牌知识。这些信息进一步决定了：

菜品表需要哪些字段；

菜品和原材料怎么建立映射；

库存和毛利多久更新一次；

哪些数据由点餐系统提供；

哪些数据来自财务系统或数据中台；

药食同源的知识怎么整理和维护；

不同系统之间通过什么接口传递；

数据为空、已售罄或接口超时的时候怎么处理；

谁负责判断推荐是否符合真实业务。

这样就串成了一条清楚的建设路径：AI 场景 → 决策需求 → 数据需求 → 系统与接口 → 数字化建设 → 更多 AI 场景。

数字化建设因此有了明确目标。企业知道为什么要整理这些数据、整理完给谁用，也知道哪些字段和流程可以暂时不做。

七、三个阶段是连着的一条数据链

这类项目通常不是一个智能体，而是分阶段推进。可以把三个阶段理解成同一条逐步扩展的数据链：

1.0 建地基：靠点餐把基础数据建起来。

第一阶段建立六类数据基础：菜品核心数据（名称、价格、规格、分类、门店、标签）、菜品与原材料的映射关系、原料采购库存供应商与损耗信息、动态毛利与销量时令地域属性、顾客口味忌口会员与历史偏好、食材药理与体质分类与搭配话术等知识。

技术上，结构化数据库负责查询菜品、库存、毛利这些确定信息，向量知识库负责检索药食同源、品牌文化和养生知识。顾客通过扫码、小程序或营业员 Pad 提需求，点餐系统通过 API 把请求传给智能体，智能体完成意图识别和多轮追问，再结合结构化数据与知识库做推荐排序，生成菜品组合和推荐话术，返回点餐系统。

它的意义可以压成一句：1.0 把基础数据建起来，同时建立顾客与智能体的交互入口。它从点餐切入，却为后面的门店经营和总部管理预留了数据结构。

2.0 跑流程：让数据进入门店经营。

菜品、库存、原料、销售和知识数据逐渐成形之后，下一层能力开始面向门店内部：库存预警、采购提醒、排班、培训、巡检、收银对账、毛利分析、营业预测、原料需求预测。

这一阶段的关键是把数据和具体岗位连起来：店长、厨师长、采购、财务和营业员分别负责什么？智能体在什么时间提醒谁？任务完成后结果回写到哪里？出现异常谁处理？

只有这些责任和流程定义清楚，数据才能真正进入业务动作。

3.0 做决策：让数据进入总部经营判断。

当不同门店开始按相对统一的数据和流程运行时，总部才有条件做跨门店分析：哪些门店的经营结构发生了变化？同一道菜在不同城市为什么表现不同？哪些门店存在库存、毛利或执行上的异常？哪些经营经验可以在其他门店复制？总部的经营目标有没有落到门店动作上？

三个阶段的关系可以概括成：1.0 建地基，2.0 跑流程，3.0 做决策。

这也是为什么项目在第一阶段就要考虑后续的数据需求。如果 1.0 只围绕当前推荐功能临时建几张表，后面做门店经营时很可能要推翻重来。整体架构提前规划，具体能力分阶段建设。

八、AI 不取代原有系统，它让系统重新分工

企业做智能体时很容易有个误区：希望 AI 把所有业务系统都包进去。

真实企业里，各类系统仍然承担自己的核心职责：

系统职责

点餐收银系统交易、订单、会员、库存、供应链

财务系统核算、报表、资金、往来

协同办公平台审批、任务、组织协同

数据中台汇集和提供经营数据

智能体理解需求、调用数据与知识、辅助推荐和决策

业务团队定义规则、维护知识、判断业务是否合理

智能体更像一个跨系统的能力层。它不替代所有系统，而是让散落在各系统里的数据和知识进入具体业务判断。

这类项目的难点也往往集中在边界上：谁提供数据、谁开发页面、谁完成交易、谁维护知识、谁判断业务准确性、第三方接口延迟算谁的。

这些问题如果不在项目开始前写清楚，后面每一次联调都可能变成责任争议。

九、这条路具体怎么走

从这个场景里可以提炼出一条相对清楚的路径：

第一步，选一个高价值又可验证的 AI 场景。场景要足够具体，能对应真实业务问题，同时还要连着关键数据和流程。菜单营销就是典型例子：入口很小，背后连接的数据很多。

第二步，从决策倒推数据。先明确智能体要做什么判断，再确定每个判断依赖哪些数据和知识。不要先把企业所有数据都搬进知识库，再研究能用来干什么。

第三步，从数据倒推系统和责任。确认数据来自哪里、谁维护、多久更新、怎么校验。需要新增字段、接口或审批流程时，再安排对应的数字化建设。

第四步，补齐最小数字化闭环。第一阶段只补当前 AI 场景真正需要的数字化能力，同时给后续阶段留出扩展空间。

第五步，让数据逐步进入流程和决策。第一阶段建数据，第二阶段把数据接到岗位动作上，第三阶段进入总部经营判断。

顺带对照一下官方口径：工信部《中小企业数字化转型指南》给的是"评估 → 管理数字化 → 业务数字化 → 融入生态 → 优化实践"的五步路径，属于自上而下的规划视角。本文讲的倒推路径是自下而上的起点选择，两者不冲突——先有一个明确的 AI 场景，反过来能让那五步里的"评估"和"业务数字化"落到具体目标上，而不是为了数字化而数字化。

这条路同样有边界。AI 牵引式数字化不等于绕过数字化，更不意味着所有企业都该放弃历史数据。它强调的只是建设顺序：用真实的 AI 场景给数字化定优先级，再让新的数字化基础支撑更多 AI 能力。

新手最关心的 5 个问题

Q1：怎么判断一个场景值不值得作为第一个切入点？

看三条：入口小（员工或顾客的操作足够简单）、背后连接的数据多（能顺带把关键数据打通）、判断标准明确（推荐得好不好，业务人员一眼能判断）。菜单推荐之所以合适，就是三条都占。反过来，如果第一个场景需要打通五套系统才有产出，风险就太大。

Q2：第一个场景做完，怎么知道数据体系建对了？

看它能不能被"复用"。如果第二个场景来了，发现大部分数据可以直接用、只需补几个字段，说明数据体系建对了；如果每个新场景都要重新拉一遍数据、重新定义一遍口径，说明第一版还是按功能临时建的，需要回头补架构。

Q3：旧数据到底该治理还是该重建？

先算一笔账：治理这批数据需要多少人月、治理完的可用性有多高、能支撑哪些判断。如果治理成本已经接近甚至超过"重新积累一套干净数据"的成本，而旧系统本身也准备替换，重建往往更划算。但涉及法律保存要求、财务审计追溯的数据，不能简单丢弃，要单独评估。

Q4：语义层、统一口径这些听起来很虚，真有必要吗？

它的作用就一个：让所有人（包括 AI）对同一个字段的理解一致。比如"毛利"这个词，门店算的是不含配送成本的，财务算的是含配送和损耗的，两个数都叫毛利。AI 拿到两个口径的数据，只能猜，猜出来的结论没法用来做经营判断。这就是 Gartner 判断"到 2028 年只靠 MCP 接口、没有统一语义层的智能体分析项目会有 60% 失败"的原因。

Q5：业务系统都有自己的厂商，智能体怎么和它们配合？

把智能体当成能力层而不是替代层。原有的交易、核算、审批继续由专业系统承担，智能体只做三件事：理解需求、调用数据与知识、辅助判断。落地时最需要提前写的不是技术方案，而是边界清单：谁提供数据、谁维护知识、接口延迟算谁的、业务判断错了谁负责。这张清单比架构图更能决定项目能不能推下去。

这几条别踩

等数字化"做完"再上 AI。 数字化没有清晰终点，等下去只会错过窗口。用一个具体场景牵引，缺什么补什么。

先把所有数据搬进知识库再想用途。 顺序反了。先明确要做什么判断，再倒推需要哪些数据——不然收了一堆，没有一个用得上。

第一个场景就挑最复杂的。 入口小、连接数据多的场景才适合起步。一上来就打通五套系统的项目，多数死在联调阶段。

照抄别人的重建方案。 放弃历史数据是有前提的：数据质量差、旧系统准备替换、关键数据无法映射、治理成本高于重建成本。不满足条件硬抄，等于把可控的历史问题变成不可控的现状问题。

让智能体替代所有系统。 交易、核算、审批这些核心系统各司其职，智能体做能力层。想一口全包，最后边界全是争议。

只画架构图，不写边界清单。 "谁提供数据、谁维护知识、接口延迟算谁的"——这些问题不提前写清楚，每次联调都会变成责任争议。

尾巴

这一篇真正想说的是一句话：数字化的建设顺序，可以因为 AI 而改变；但该补的课，一课也跳不过。

过去的顺序是先建基础设施，再看能拿来干什么；现在可以反着来——先有一个具体到能说清的场景，再用它去倒推需要什么数据、什么接口、什么责任分工。顺序变了，要补的东西一样没少。

区别在于：倒着补的每一份投入，都有一个明确的使用者；顺着建的时候，很多东西建完了也不知道给谁用。

本系列持续更新中，关注不迷路。

本文数据来自公开研报与行业调研（已在文中标注），观点为分析推演，欢迎讨论。文中案例仅用于说明方法，不涉及任何具体企业评价。