上周跟一家上市制造业企业的流程与IT负责人聊了两个多小时。
他是被老板派来的——公司想引入AI，但怎么做、从哪里做，还没有清晰的方向，于是找到我探讨。
老板的诉求很直接： 想在现有业务系统的某些节点上，快速嵌入AI能力，帮他判断这份合同是否有风险。
而更大的野心，他后来说出来了——不只是合同，是所有软件系统、所有业务节点，都能按需嵌上AI。
这是一个非常典型的诉求。我估计有七成中小企业的老板，心里想的都是这件事。
但能把这件事做清楚、做落地的，极少。
麦肯锡有一组数据，我觉得很能说明现状：全球超过88%的企业已经在用AI，但最终只有6%的企业真正获得了高绩效回报。失败的原因，大部分不是技术不行，而是方向错了——把精力都放在"建平台、选模型、堆算力"上，却没有一个真正跑起来的业务场景。
今天把这次对话的核心逻辑复盘出来，给有同样困惑的人参考。
第一个坑：上来就想建平台
聊到大概十分钟的时候，对方提了一个问题： 要不要建自己的AI平台？
我直接说了我的判断： 现在建平台，不是重点，甚至是个坑。
这不是说平台不重要。而是顺序错了。
很多企业的思路是这样的：我要做AI，所以我要先搭平台、建架构、拉团队、选模型……然后等一切准备好了，再来谈落地。
结果是什么？大半年过去了，平台还没上线，一个有价值的场景都没跑通。
正确的顺序是：场景第一，平台只是解决场景落地过程中出现"不适配"问题的载体。
你得先有一个实际跑起来的场景——比如需求评审的时候让AI自动分析项目可行性，或者报价过来的时候让AI帮你判断这个价格是否合理——然后才知道平台需要解决什么问题。
没有场景就建平台，相当于没有货物就建仓库。
第二个坑：搞错了AI的接入方式
目前企业引入AI，大体上有两条路。
第一条：对话优先。 给员工一个对话平台，什么问题都去问AI，AI作为主入口。
第二条：软件优先（Copilot方式）。 保留现有软件系统不动，在软件的某个节点上嵌一个AI助手，作为辅助。
很多AI圈的人会说第一条更先进，Copilot已经落伍了，未来是智能体对话的天下。
我不完全同意这个判断。起码对制造业、中小企业来说，现在不是。
原因很简单： 制造业的核心操作，不是开放式问答，而是发生在特定系统的特定节点上的。
合同审批，发生在合同管理系统的审批页面上。项目立项，发生在项目管理系统的立项表单里。物料核查，发生在ERP的采购入口处。这些场景员工每天要操作几十次，他的注意力完全在那个页面上，不会去打开另一个对话窗口"问AI"。
你给他一个独立的AI对话框，他要切换场景、复制粘贴数据、重新描述背景——这个摩擦成本，足以让九成员工放弃。
但如果AI就在他正在使用的那个页面里，点一下，数据自动带过去，结果直接返回——这才是他真的会用的方式。
好的AI落地，不是给员工新增一个工具，而是让AI悄悄嵌进他已有的工作流，在最需要的那一刻出现。
核心：不是建智能体，是建Skill
这是这次对话里我认为最关键的一个点。
很多企业的思路是：我要做AI，所以我要建一个智能体。需求评审要一个，报价分析要一个，物料检查要一个……
这个方向有个巨大的问题： 每个智能体都是独立的烟囱，不复用，难维护，越建越乱。
更好的方式是： 建Skill（技能脚本）。
什么是Skill？
我打个比方。
以前企业做AI，思路是"一个场景建一个智能体"——合同风险分析是一个，项目评审是一个，物料核查是一个。每个智能体都是独立的，像一座座孤岛，不能复用，各自维护，越堆越乱。
Skill的思路完全不同：把每个具体场景的业务逻辑，打包成一个可以反复调用的"技能模块"。
打个更具体的比方：Skill就像企业的乐高积木库。
以前每个智能体是一套独立的乐高，用完就扔，下次重新买。现在是一批公用的积木，每做一个场景就往库里加几块，积木越来越多，下次拼新场景的速度越来越快——而且不同业务节点可以调同一块积木，不用重复造轮子。
Skill的核心价值有三点：
第一，可复用。 一个"合同风险识别"的Skill，不只是在合同审批节点用，采购合同、供应商合同、项目合同都能调——写一次，全公司复用。
第二，可积累。 每个Skill都是企业业务逻辑的一次沉淀。老员工的经验、审核的标准、判断的规则，全都打包进去。新员工来了，直接用，不需要重新摸索。
第三，轻量。 一个运行环境 + 多个Skill = 原来N个独立智能体的效果。不用为每个场景搭独立的系统，维护成本低，扩展成本也低。
换句话说： Skill是企业AI资产的最小可积累单位。 你积累的不是一个个独立的智能体，而是一块块可以反复组合的能力积木。这个库越丰富，企业的AI化速度就越快。
技术上怎么做：四层架构
聊到这里，对方问：那技术方案怎么设计？
我给了一个四层结构，不复杂，但每一层职责清晰。
第一层：交互层
就是用户看到的那个界面。在业务系统的页面上，嵌一个侧边栏或悬浮按钮，用JS插件方式注入， 几行代码，完全不动原来的页面结构。
用户在做需求评审的时候，点一下按钮，右侧弹出AI对话窗口，当前表单数据自动带进去，员工身份自动传递，AI拿到上下文直接分析。
第二层：配置与编排层
这是给业务人员和IT管理员用的配置平台。
业务人员在这里决定：哪个页面的哪个节点，要启用哪个Skill，这个Skill需要什么触发条件。
设置好以后，系统自动在对应页面渲染AI窗口，不需要再找开发改代码。
第三层：Skill管理层
管理所有Skill的开发、注册、版本控制和权限。
谁能用哪个Skill、Skill能调用哪些数据接口、哪个版本在生产环境跑——都在这一层管。
第四层：执行引擎层
真正跑Skill脚本的地方。
有安全沙箱，隔离执行。Skill被触发后，引擎去调内部系统接口拿数据，结合大模型分析，把结果吐回给交互层。
用200K上下文窗口的长文本模型，可以把合同全文、历史数据、审核标准一次性喂进去，支持多轮对话，分析结果更准确。
这四层加在一起，对企业IT团队来说， 真正的自研工作量只集中在第三层（Skill管理）和第四层（执行引擎）。 交互层可以先复用第三方工具，配置层搭一个管理后台，不复杂。核心是把Skill跑起来，其他的可以渐进建设。
嵌入的时候，业务系统需要做什么
这是另一个关键问题。对方问：我们的业务系统需要做多大改动？
答案是： 改动极小。
业务系统需要做的只有两件事：
第一，预留一个嵌入口或提供标准API。 本质上就是告诉AI平台：当用户在这个页面点击按钮时，你能拿到哪些数据、员工是谁。这可以是一个JS事件，也可以是一个标准接口。
第二，接受JS插件注入。 AI平台生成一段JS代码，IT人员把它加到对应页面，就像嵌一个客服聊天窗口一样，半天的工作量。
插件注入以后，按钮会在配置的位置自动渲染，点击就触发，完全不影响原有的页面功能和布局。
对于制造业企业来说，这个方案的好处是显而易见的： IT团队不需要动原有系统架构，业务系统该怎么跑还是怎么跑，AI是叠加在上面的，随时可以关。
要不要自建平台，怎么判断
聊到一半，对方又绕回来问：我们到底要不要自建AI平台？
我的回答是： 先别建，先用第三方，等场景验证通了再说。
很多企业自建平台的理由是数据安全。这个理由本身没问题，但需要分级评估。
金融、医疗这些行业，数据合规要求极高，数据不允许离开自己的服务器，自建平台有必要。
但对于一家普通制造业企业来说，如果你只是在OA、项目管理系统里嵌几个审批助手、分析助手——这些场景的数据敏感度有限，云厂商的安全方案完全能覆盖。
这时候上来就自建，是拿最重的武器打最轻的仗。
更务实的路径是这样的：
先跑场景，再建平台，平台是场景跑通之后的自然产物，而不是场景的前提条件。
三步落地路线图
最后给了一个具体的落地节奏，可以直接参考。
第一步：快速验证（第1-2个月）
用第三方智能体平台，选2-3个高频、轻量、数据敏感度不高的场景，快速验证。
制造业可以优先考虑的场景：合同风险识别、需求评审分析、物料齐套性检查。这些场景数据相对开放，一两个月能出结果。
同时，在这个阶段开始梳理第一版Skill清单：每个场景对应一个Skill，明确每个Skill的输入、输出、需要调用哪些接口。
这一步的目标不是做出完美的系统，而是用最小成本验证：AI在这个节点上有没有价值。
第二步：轻量平台同步启动（第2-4个月）
基于验证通过的场景，同步启动轻量自研平台的建设。
先做两个核心模块：Skill管理层（管理Skill的注册、版本、权限）+ 执行引擎层（安全沙箱 + 接口调用）。
交互层先复用第三方平台，不用自己做，降低开发成本。
这个阶段的原则是： 平台建设不能影响场景落地，两条线并行，不互相等待。
第三步：迁移与拓展（第4个月以后）
自研平台能稳定运行之后，逐步把第三方平台上的Skill迁移过来。
同时，开始拓展对数据安全要求更高的场景，比如生产质量异常预警、关键工艺参数监控。这些场景需要调用内部生产系统的核心数据，放自建平台上更安全。
整个过程的主线是Skill的梳理和积累，平台只是载体，Skill才是企业真正的AI资产。
写在最后
这次对话结束的时候，对方说了一句话：
这句话我觉得说到位了。
AI落地，本质上不是系统工程，是场景工程。
你不需要先建一个完整的平台，不需要买最贵的模型，不需要把现有系统推倒重来。
你需要的只是： 找到一个真实的、高频的、痛点明确的业务节点，把第一个Skill做出来，让它稳定跑，让员工真的在用它。
第一个Skill跑通了，第二个就自然来了。
Skill积累多了，你就知道平台要解决什么问题了。
到那时候自建平台，才是真的有底气建，不是拿钱堆一个没人用的东西。
这个路径，我见过不少企业走，没走偏的，都是从"第一个Skill"开始的。