夜雨聆风这句话理论上没有问题，AI 需要线上数据，需要标准化流程，也需要和业务系统连接。如果企业的客户、商品、订单、库存都在线下，AI 确实无从下手。
但在实际场景中，会遇到一些问题：数字化成本多高？完善到什么程度，才算真正完成？
企业上了 ERP，还有 CRM；上了 CRM，还有供应链、知识库和数据中台；系统建完了，业务又变了，原来的字段、流程和权限还要继续改。
数字化本身就是一条持续建设的路，很难找到一个清晰的终点。
如果一家企业先花两年完成数字化，再开始研究 AI，两年以后黄花菜都凉了。模型能力、业务环境和竞争格局早就变了。
没有数字化基础的企业当然不能直接跳过数据和流程建设，但也不需要等所有基础设施全部完善以后才开始。
更合理的路径是：数字化和 AI 化相互牵引、相互补齐、齐头并进。
先选择一个值得解决的 AI 场景，再根据智能体需要做出的判断，反向梳理它需要哪些数据、流程、系统和接口。缺什么数字化能力，就围绕这个场景补什么。
我把这种路径叫作：AI 牵引式数字化。
最近我们做的一个餐饮 AI 智能体项目，就是按照这条路径去做的。
一、从一个点餐需求开始
这是一家连锁餐饮企业，旗下有几十家门店，分布在全国多个城市，主营野生菌火锅。
客户最初需求是希望建设一个菜单营销智能体，帮助顾客和门店营业员完成菜品推荐。
例如顾客说：我们有4个人，不吃辣，其中一个人湿气比较重。
智能体需要理解人数、口味、忌口和体质，再推荐合适的锅底、菜品组合与推荐理由。
这句话听起来很简单，但从运行逻辑拆解以后，会发现它至少包含几类数据：
- 哪些锅底和菜品不辣；
- 哪些食材适合对应的身体状态；
- 当前门店有哪些菜，哪些已经售罄；
- 哪些食材正当季；
- 哪些菜品符合品牌当前的经营策略；
- 四个人应该推荐多大分量、怎样的组合；
- 推荐理由怎样体现野生菌和药食同源特色。
只要其中一类数据缺失，智能体的推荐就可能和门店真实情况脱节。
如下图为部分，一共六大类
二、为什么不直接用美团点餐系统？
美团、扫码点餐和餐饮 SaaS 已经很成熟了，为什么还需要单独做一个 AI 智能体？
普通点餐系统主要负责完成交易：展示菜单、选择菜品、加入购物车、下单和支付。
这个项目需要解决的是交易前的推荐决策。
野生菌火锅的信息密度很高，顾客可能不认识不同菌类，不知道食材和锅底怎样搭配，也不了解不同季节适合吃什么。企业希望传递的山野文化、药食同源理念和品牌知识，也很难只靠一张菜单讲清楚。
门店还分布在多个城市，服务行业人员流动快，服务人员对菜单也不熟，培训需要不断重复。依赖员工记忆，很难保证不同门店使用同一套推荐逻辑和表达方式。
与此同时，推荐还要结合经营信息。
同一道菜的库存、成本和毛利会变化。哪些菜品库存高？哪些产品利润高？哪些菜品不能长期存储？这些对前堂服务人员都是不知道的。
因此，普通点餐系统和菜单营销智能体承担不同职责：
- 点餐系统负责菜品展示与交易；
- 智能体负责理解需求、调用知识、结合经营数据辅助推荐。
菜单也因此成为一个很好的 AI 切入点。
它既是顾客看到的销售目录，也是门店背后的生产目录。向前连接顾客、会员和营销，向后连接菜品、原料、库存、供应链与毛利。
一个点餐场景，能够牵引企业多个核心数据域。
三、旧数据太乱，决定重新建一套
这个项目还有一个背景。
他们过去使用过哗啦啦（大型餐饮 ERP 服务商），后续又切换到奥琦玮（同哗啦啦）。随着系统变化，原来的业务、财务和管理数据逐渐断裂。
同一个概念，在不同系统里可能使用不同名称。菜品、原料、库存和财务字段之间也缺少稳定映射。一部分历史数据来自旧系统，一部分保存在不同部门的表格中，还有一些数据只存在于员工经验里。
多数企业遇到这种情况，第一反应是做历史数据治理：清洗数据、统一字段、补齐标签，再把旧数据迁移到新系统。
他们做了一个更激进的选择：业务改造层面不再迁移和治理原有经营数据，围绕新的系统架构，从头建立一套干净的数据体系，原来数据直接不要了。
不把混乱的旧业务数据继续带入新的经营体系，不让历史包袱决定新系统应该怎么建。
新的体系重新划分了几类系统的职责：
- 全来店（类似美团）承接点餐、收银、会员、库存和供应链；
- 金蝶重新拆分独立数据中心，负责财务核算、报表、资金和往来；
- 飞书承接审批、任务和内部管理协同；
- 数据中台汇集业务经营数据；
- 智能体能力层连接数据、知识和推荐决策。
这个做法和常见的数据治理思路不同，但它有自己的适用条件。当历史数据质量很差、旧系统本身准备替换、关键数据无法可靠映射，并且治理成本已经高于重新积累成本时，继续清洗可能只是延长旧系统的技术债。
有些旧数据的治理成本，已经高于重新生成一套干净数据的成本。
当然，这条路不能机械复制，企业需要评估历史数据的业务价值、法律保存要求、系统切换风险和新旧数据衔接方式。客户敢这样做，是因为这次本身就在更换多套核心系统，也有机会从数据产生的第一天重新定义规则。
四、从智能体反向补数字化缺口
决定重新建设数据体系以后，接下来的问题是：新体系应该按照什么标准建？
传统做法容易从系统功能出发，业务系统有什么字段，企业就先收集什么字段；软件能输出什么报表，管理层就先看什么报表。
我们反过来走。
先问智能体需要完成什么判断，再根据判断倒推数据。
以点餐场景为例，智能体要推荐菜品，就需要知道顾客需求、可售菜品、库存、毛利、时令、食材属性和品牌知识。
这些信息进一步决定：
- 菜品表需要哪些字段；
- 菜品与原材料如何建立映射；
- 库存和毛利多久更新一次；
- 哪些数据由全来店提供；
- 哪些数据来自金蝶或数据中台；
- 药食同源知识如何整理和维护；
- 不同系统通过什么接口传递；
- 数据为空、已售罄或接口超时时怎样处理；
- 谁负责判断推荐是否符合真实业务。
这就形成了一条清晰的建设路径：AI 场景 → 决策需求 → 数据需求 → 系统与接口 → 数字化建设 → 更多 AI 场景
数字化建设因此有了明确目标，企业知道为什么要整理这些数据，整理以后由谁使用，也知道哪些字段和流程可以暂时不做。
五、1.0：通过点餐把基础数据建起来
项目一共规划三个阶段，架构大致可以参考这个图。
第一阶段是菜单营销智能体。
这一阶段需要建立六类数据基础：
- 菜品核心数据，包括名称、价格、规格、分类、门店和标签；
- 菜品与原材料的映射关系；
- 原料、采购、库存、供应商和损耗信息；
- 动态毛利、销量、时令和地域属性；
- 顾客口味、忌口、会员和历史偏好；
- 食材药理、体质分类、锅底搭配和养生话术等知识。
在技术上，结构化数据库负责查询菜品、库存和毛利等确定信息，向量知识库负责检索药食同源、品牌文化和养生知识。
顾客通过扫码、小程序或营业员 Pad 提出需求。全来店通过 API 把请求传给智能体，智能体完成意图识别和多轮追问，再结合结构化数据与知识库进行推荐排序，生成菜品组合和推荐话术，最后把结果返回点餐系统。
第一阶段的意义，可以压缩成一句话：
1.0 把基础数据建起来，同时建立顾客与智能体的交互入口。
它从点餐切入，却为后续门店经营和总部管理预留了数据结构。
1.0 流程可参考这张图，当然，和项目实际不完全一样，尤其是权重数据，完全不是这逻辑。
六、2.0：让数据进入门店经营流程
当菜品、库存、原料、销售和知识数据逐渐形成以后，下一层能力开始面向门店内部。
门店经营智能体规划覆盖库存预警、采购提醒、排班、培训、巡检、收银对账、毛利分析、营业预测和原料需求预测等场景。
这一阶段的关键，是把数据和具体岗位连接起来。
店长、厨师长、采购、财务和营业员分别负责什么？智能体在什么时间提醒谁？任务完成以后，结果回写到哪里？出现异常以后，谁负责处理？
只有这些责任和流程被定义清楚，数据才能真正进入业务动作。
因此，2.0 承担的是：把数据转化为门店岗位的任务和行动。
七、3.0：让数据进入总部经营决策
当不同门店开始按照相对统一的数据和流程运行，总部才有条件进一步做跨门店分析。
品牌管理智能体规划关注集团经营目标、门店差异、供应链、经营风险和异常问题。
它需要回答更高层的问题：
- 哪些门店的经营结构发生变化；
- 同一道菜在不同城市为什么表现不同；
- 哪些门店存在库存、毛利或执行异常；
- 哪些经营经验可以在其他门店复制；
- 总部的经营目标有没有落实到门店行动。
因此，3.0 承担的是：把门店数据和行动沉淀为总部经营判断。
八、1.0、2.0、3.0 是一条连续的数据链
这三个阶段看起来是三个智能体，底层依赖的是同一条逐步扩展的数据链。
1.0 从顾客点餐切入，建立菜品、原料、库存、毛利和知识数据。
2.0 让这些数据进入采购、培训、巡检、对账和门店任务。
3.0 再把不同门店的数据和行动汇总起来，支撑总部经营诊断。
它们之间的关系可以概括为：
1.0 把数据建起来，2.0 让数据进入业务流程，3.0 让数据进入经营决策。
或者更简单一点：
1.0 建地基，2.0 跑流程，3.0 做决策。
这也是为什么项目在第一阶段就要考虑后续的数据需求。
如果 1.0 只围绕当前推荐功能临时建几张表，后面做门店经营时，很可能需要推翻重来。整体架构应该提前规划，具体能力可以分阶段建设。
九、AI 不会取代原有系统，它需要重新定义系统分工
企业做智能体时，很容易产生一个误区：希望 AI 把所有业务系统都包进去。
真实企业里，各类系统仍然承担自己的核心职责。
- 全来店负责交易、订单、会员、库存和供应链；
- 金蝶负责财务核算、报表、资金和往来；
- 飞书负责审批、任务和组织协同；
- 数据中台负责汇集和提供经营数据；
- 智能体负责理解需求、调用数据与知识、辅助推荐和决策；
- 客户业务团队负责定义规则、维护知识和判断业务是否合理。
智能体更像一个跨系统的能力层，它不替代所有系统，而是让散落在系统里的数据和知识进入具体业务判断。
这类项目的难点，也往往集中在边界上：谁提供数据、谁开发页面、谁完成交易、谁维护知识、谁判断业务准确性、第三方接口延迟由谁负责。
这些问题如果没有在项目开始前写清楚，后面的每一次联调都可能变成责任争议。
十、AI 牵引式数字化应该怎么做？
从这个项目里，可以提炼出一条相对清晰的路径。
第一步：选择高价值、可验证的 AI 场景
场景要足够具体，能够对应真实业务问题。同时，它还要连接关键数据和流程。菜单营销就是一个典型例子：入口很小，背后连接的数据很多。
第二步：从决策倒推数据
先明确智能体需要做什么判断，再确定每个判断依赖哪些数据和知识。不要先把企业所有数据都搬进知识库，再研究可以用来做什么。
第三步：从数据倒推系统和责任
确认数据来自哪里、谁维护、多久更新、怎样校验。需要新增字段、接口或审批流程时，再安排对应的数字化建设。
第四步：补齐最小数字化闭环
第一阶段只补当前 AI 场景真正需要的数字化能力，同时为后续阶段保留扩展空间。
第五步：让数据逐步进入流程和决策
第一阶段建立数据，第二阶段把数据接入岗位动作，第三阶段再进入总部经营判断。
这条路径同样有边界。
AI 牵引式数字化不等于绕过数字化，更不意味着所有企业都应该放弃历史数据。它强调的是建设顺序：用真实 AI 场景给数字化确定优先级，再让新的数字化基础支撑更多 AI 能力。
最后
企业 AI 转型不需要等待一场漫长的数字化改造全部结束。
更合理的路径，是从一个值得解决的业务问题出发。根据 AI 需要做出的判断，反向补齐数据、系统和流程，再让这些数字化基础支撑更深层的 AI 应用。
这个餐饮项目从点餐开始，向后连接菜品、原料、库存和供应链，再向上延伸到门店经营和总部决策。它说明了一件事：数字化和 AI 化并不存在一条绝对的先后分界线。
数字化为 AI 提供养料，AI 也可以成为数字化建设的抓手。
我是曾俊，AI 创业者、企业 AI 顾问。提供企业 AI 培训、AI 落地咨询、智能体定制开发、落地陪跑、企业高管 AI 私教。服务过得物、建行、立讯精密等上市公司。如果你企业需要 AI 转型，欢迎加 V 详聊合作：ZF1235813266
帮一家传统制造业集团做了 5 小时 AI 落地调研，聊出了 6 个能落地的方向
我翻了 115 篇财务 AI 文章，整理出 15 个场景 75 个具体用法
ClaudeCode 的 172 个应用场景（12）：Claude Code 工具与环境