夜雨聆风今天看了一个李锦记的 AI 落地案例。
它最有意思的地方，不是这家公司用了哪些 AI 工具，也不是某个应用做得多炫。
真正值得看的，是一家百年制造企业，怎么让 AI 先进入那些日常、具体、系统外的小流程里。
很多企业一谈 AI，第一反应就是：要不要建大模型平台？要不要做知识库？要不要上 Agent？要不要改造 ERP、MES、财务系统？
这些问题当然重要。
但在真实企业里，AI 往往不是先卡在“模型够不够强”，而是卡在更前面的一步：
业务有一个想法，但它很难被快速做出来、试起来、验证起来。
这个问题，比工具选择更基础。
李锦记这个案例的价值，就在这里。
一、很多 AI 项目，还没开始就已经变重了
在制造业里，很多业务问题看起来都不大。
比如标签合规审核、培训测验、社媒物料生成、外部数据整理、单据识别、供应商风险提醒、实验室样品流程。
单看每一个，都不像是必须立刻启动大项目的事情。
但它们每天都在消耗人。
有人在反复整理 Excel，有人在群里追进度，有人在不同系统之间搬数据，有人在把纸质单据重新录入，有人在等 IT 排期，有人在把业务需求一轮轮讲给不同角色听。
问题不是大家不知道这些事低效。
问题是，一个小需求要变成可用工具，路径太长了。
业务先提需求，BP 或 IT 理解一遍，供应商再理解一遍，方案再讨论，排期再等待，做完还要验收。等工具真的出来，原来的业务场景可能已经变了，或者业务方已经退回 Excel 和群消息。
所以很多企业并不是没有 AI 场景。
更准确地说，是缺少一种机制，让业务里的小问题能低成本地被验证。
二、李锦记没有先从“大系统”开始
李锦记这个案例里，我最关注的不是它用了多维表格、妙搭、Aily，还是其他 AI 能力。
工具名称不是重点。
重点是它的落地顺序。
它不是一上来就说，要把核心系统全部 AI 化，也不是先做一个宏大的企业级智能中台。
它更像是先在核心系统之外，搭了一层“业务验证层”。
业务侧先把那些系统外的小痛点做成看得见、点得动、能试用的原型。小团队先跑闭环。跑得通的，再沉淀成模板、组件、Skill，或者进入正式系统治理。
这条路径很务实。
因为很多企业 AI 项目最大的浪费，不是做错了大系统，而是在还没证明问题值得做之前，就已经把事情做得太重了。
AI 在企业里的第一步，有时候不是重构系统，而是降低业务验证的摩擦。
这个判断很关键。
如果业务想法很难被验证，AI 就只能停留在培训、演示和热闹的试用里。
如果业务想法可以快速变成原型，企业才有机会判断：这个问题是不是真问题？有没有人持续用？数据能不能结构化？流程是否稳定？有没有必要进入正式系统建设？
三、这些“小流程”，反而是 AI 最容易先进去的地方
李锦记案例里有几个场景，很能说明这个问题。
比如合规标签审核。
跨国制造企业面对不同国家和地区的法规要求，标签、包装、文本材料都需要被核对。AI 在这里不是替代专业人员做最终判断，而是先做抽取、识别、初筛和结构化输出。
专业人员仍然负责复核、判断灰区、承担最终责任。
这个分工是合理的。
AI 不应该被包装成“自动负责合规”，但它可以减少大量重复核对和资料整理。
再比如培训和测验门户。
很多公司都有大型学习平台，但部门级培训材料往往仍散落在知识库、网盘、文档和本地文件里。业务想做一个小型学习门户、课程管理、测验生成和成绩追踪，不一定非要等全公司级系统排期。
先用轻量方式跑通局部闭环，反而更现实。
还有社媒物料生成。
总部沉淀菜式、品类、区域偏好、品牌资产和二维码等规则，一线销售根据当地客户和渠道需要，自助生成可分发素材。
这不是让品牌规范失控。
相反，它是把总部规则和一线灵活性放进同一套流程里。
还有单据解析、供应商风险、实验室样品流程。
这些场景不一定是战略级大项目，但它们有共同特点：重复发生、字段相对清楚、结果可以人工复核、风险可以控制，并且有明确的业务 owner。
这类场景，往往比“做一个全公司都会用的超级 AI 应用”更适合作为起点。
四、业务跑起来以后，AI team 的角色也会变
这个案例还有一个很重要的变化：业务同事不再只是提需求的人。
在传统数字化项目里，业务方经常负责描述问题，技术方负责做系统。中间经过多轮转译，最后出来的东西不一定还是业务最初想要的。
但当工具门槛下降以后，一些业务同事会先自己跑起来。
他们不一定会写代码，但可以定义字段、梳理流程、准备规则、验收结果，甚至用低代码和 AI 工具搭出第一版原型。
这会反过来改变 AI team 的定位。
AI team 不应该永远是“帮业务做应用的人”。
它更应该成为企业内部 AI 实践的放大器。
发现哪些业务同事已经跑起来，帮他们补齐方法、边界和工具能力；把个人探索沉淀为模板、组件、流程和验收标准；把可以复用的经验扩散给更多团队。
这也是为什么李锦记案例里，POD 和 Community 这样的组织机制很重要。
企业 AI 落地不是靠一个中台团队把所有需求接完。
更现实的方式，是让业务里的小气泡先冒出来，再由 AI team 和数字化团队把它们托举成组织能力。
五、但这件事不能被误读成“大家都去搭小工具”
这里有一个边界必须讲清楚。
轻量工具可以帮助业务快速验证，但不能替代企业核心系统。
正式订单、库存扣减、财务入账、主数据维护、跨法人流程、高审计审批，这些场景不应该长期靠临时小工具承载。
如果把“业务能自建工具”理解成“正式系统不重要”，那就是误读。
真正成熟的做法，是有分流机制。
低风险、低频、部门内的小场景，可以沉淀为模板、轻应用或自动化流程。
高频、高权限、高稳定、高审计的场景，要进入正式系统和治理体系。
验证层不是终点。
它的价值，是帮助企业更早看清哪些需求值得继续投入，哪些只是临时效率问题，哪些应该进入正式系统建设。
六、普通企业更应该学这个顺序
李锦记这个案例，最不应该被学成“买一套工具，然后要求全员使用”。
也不应该被学成“搭几个 demo，就说明 AI 已经落地”。
更值得学的是它背后的顺序：
先找系统外的小痛点； 先找愿意持续试的业务 owner； 先用低成本原型验证问题是否真实； 先让小团队跑出闭环； 再决定是沉淀模板、扩散复用，还是进入正式系统治理。
很多企业今天做 AI，最大的问题不是没有战略。
战略通常都有。
问题是战略和日常工作之间，缺少一条能走得通的小路。
员工知道哪里低效，但不知道怎么把低效变成原型。
管理层知道要推动 AI，但看不到哪些场景真的能跑起来。
AI team 很想做价值，但容易被大量零散需求拖住。
这时候，与其先问“我们要不要建一个更大的 AI 平台”，不如先问三个更具体的问题：
公司里有哪些事情还停留在 Excel、群消息、纸质单据和人工催办里？ 这些事情是不是重复发生、字段清楚、结果可以人工复核？ 有没有一个业务 owner 愿意持续试，而不是只提一个需求？
如果这三个问题能回答清楚，AI 落地就已经比空谈平台和工具更近了一步。
最后
李锦记做 AI，最值得看的不是工具，而是业务怎么先跑起来。
这句话背后，其实是企业 AI 落地的一个朴素判断：
AI 要真正进入企业，不是先进入口号，也不是先进入大系统，而是先进入那些每天都在发生、但过去不值得立项的小流程。
这些小流程看起来不性感。
但它们连接着真实工作。
当业务想法能被更快做出来、试起来、验证起来，企业才有机会把 AI 从工具热闹，变成流程变化、协作变化和组织能力变化。
这可能才是这个案例最值得看的地方。
案例参考：李锦记 AI 落地案例文档；飞书 AI 开放麦回放
Seven 的 AI 效率实验室：关注 AI 在企业里的真实落地，不止工具热闹，更看它如何进入流程、改变协作、影响业务结果
