苏州AI峰会圆桌论坛，聊聊不一样的AI落地路径

昨天在苏州，荣格工业传媒办的AI智造创新应用峰会。我坐在圆桌嘉宾席上，主持人抛过来一个话题："在汽车行业验证成功的AI方案，能不能直接复制到医疗器械或消费电子？如果不能，定制改造成本有多高？"

我脑子里同时闪过两个声音。

一个来自DeepSeek、豆包——我之前确实搜过这个问题。AI的回答很一致："不能。不同行业的工艺流程、质量要求、数据标准差异巨大，需要进行大量定制化改造。"

但另一个声音，来自我过去几年在G工厂、在电子行业、在装备制造业亲手做过的项目。这个声音说："能复制。而且我复制过。"

我选择了后者。

然后我说了一句可能得罪了不少人的话——"如果你们的AI方案换一个行业就废了，说明你们做的根本不是AI Agents智能体，而是定制化软件开发。"

一、为什么AI说不能，但我说能？

先别急着骂我。我来说说为什么。

AI给出"不能复制"的答案，是因为它理解的是**表层**——汽车行业的焊接工艺标准和医疗器械的完全不同，消费电子的AOI检测逻辑和汽车零部件也不一样。

但我在G工厂做的事情，不是给某个行业写一套定制算法，而是做了一件事：让AI理解"业务语义"，而不是"数据格式"。

这句话可能有点绕，我举个例子你就明白了。

两台完全不同的设备，一台是汽车行业的焊接机器人，一台是消费电子的贴片机。从设备角度看，它们天差地别——不同的厂商、不同的控制协议、不同的数据格式、不同的工艺参数。

传统做法是什么？给每台设备写一套数据接口，一套解析逻辑，一套告警规则。换了设备类型，前面写的全部重来。这就是行业里大多数AI公司的做法。所以他们当然说"不能复制"——因为他们每接一个新客户，就是重新写一遍代码。

但我们在G工厂的做法不一样。

我们不关心设备型号、不关心数据格式，我们关心的是：这台设备在业务语言里到底是什么？

虽然设备和工艺完全不同，但它们在"业务语义"层面有相同的结构——输入→工艺参数→输出→质量判定。

如果你能把这种“业务语义”抽象出来，用一套通用的语言来描述不同的制造场景，那跨行业复制就不再是神话。

这套语言，在我们的体系里叫“工业语义引擎”。

插一句：为什么大多数人认为"不能复制"？

在圆桌上聊完这个话题，我后来想了一下——为什么AI（DeepSeek、豆包）也说不能复制？

因为它们理解的是主流的AI落地路径：做AI要先做数据标注、清洗、训练。

这条路在大多数AI从业者脑子里是根深蒂固的。你要做一个焊接质量预测模型，先得找一万条焊接数据，每条数据要标注好"合格/不合格"，再清洗掉噪声数据，再训练一个模型。换到医疗器械行业？再来一遍：标注灭菌数据、清洗、训练。

这条路当然不能跨行业复制——每换一个场景，标注和训练的工作量几乎等于重来。

而且还有一个更要命的问题：大多数制造企业，虽然ERP、MES系统里确实有大量数据，但这些数据是"业务数据"，不是"标注数据"。

什么意思？

你的MES里有十万条生产记录，但每条记录上并没有贴"合格/不合格"的标签。数据有，但没有AI能直接用来训练的那种"标注"。让企业回头去标注十万条数据？人工成本和时间成本都受不了。

所以他们的逻辑链条是：没有标注数据→不能训练模型→不能跨行业复制。这个逻辑本身没错，错的是前提——他们假设"做AI"只有这一条路。

Ontology本体建模走的是完全不同的另一条路：**我不需要标注数据，我不需要从零训练一个新模型。我只需要把业务知识的结构定义清楚。**

你可以理解为：

- 传统AI路径：给AI喂一万条标注数据，让它自己"悟"出规律 → 换行业重新喂

- Ontology路径：直接把行业的业务逻辑用机器能理解的方式"告诉"AI → 换行业只需换知识库，不需要重新训练

这个区别，是"能不能复制"的核心分水岭。

所以我的观点是：不是"AI不能跨行业复制"，是"传统的数据标注+模型训练路径不能跨行业复制"。如果你换一种方式做AI——用语义理解替代数据训练——行业壁垒就不存在了。

这也是为什么，我们做工业语义引擎的时候，第一件事不是找数据，是找业务人员聊。把他们的知识结构化成Ontology。这件事做完，后面的AI能力是自然长出来的。

二、什么是工业语义引擎？

说得简单一点：工业语义引擎，就是制造领域的通用翻译器。

不同行业的设备讲不同的方言——汽车行业讲焊接参数，电子行业讲贴装精度，医疗器械讲洁净度。

但它们的底层逻辑是相通的。

我们基于一种叫Ontology（本体建模）的技术，把制造领域的业务知识结构化。不是存数据，而是存"数据之间的关系"。

举个例子

你问一个传统MES系统："这个订单为什么延期了？"

MES会给你一堆数据：A工序完成时间、B工序开始时间、B工序实际耗时……

但你需要自己去查、自己去关联、自己去判断。

而Ontology建模做的是：把订单→工序→设备→物料→质量之间的因果关系，全部用机器可理解的方式定义好。

然后你问同样的问题，AI的回答是：

"订单延期是因为B工序的等待时间比标准多了40分钟，原因是C物料入库晚了2小时，而C物料入库延迟是因为供应商D的交期异常——该供应商最近3个月的交期准时率已从92%下降到78%，建议触发供应商预警。"

这就是工业语义引擎的价值——它不是帮你查数据，而是帮你理解业务。

为什么它能跨行业？

因为业务语义的抽象结构，在不同行业之间是通用的。汽车行业有"焊接"这个工序，医疗器械有"灭菌"这个工序。两件事的具体参数完全不同，但它们在Ontology里属于同一个类别——"工艺步骤"。

工艺步骤有通用的属性：输入物料、工艺参数、输出产品、质量判定标准。我们只需要换一套行业参数，Ontology的结构不需要动。

也就是说，你在汽车行业搭好的工业语义引擎，换到医疗器械行业，只需要导入新的行业知识库，引擎本身几乎不需要改。

这就是我说的"能复制"的底气。

三、G工厂已经验证过的事

我说能复制，不是拍脑袋。G工厂的服务范围覆盖多个行业，我们用一个统一的工业语义引擎，处理了完全不同行业的场景：

| 行业 | 场景 | 语义引擎做的事 |

| 汽车零部件 | 焊接质量预测 | 理解焊接参数、材料、环境温湿度与缺陷的因果关系 |

| 消费电子 | SMT贴片良率优化 | 理解锡膏厚度、贴装压力、回流焊曲线与虚焊的关联 |

| 医疗器械 | 灭菌过程追溯 | 理解灭菌批次、温度曲线、放置位置与灭菌效果的关系 |

| 装备制造 | BOM变更影响分析 | 理解物料、工艺、供应商、产线之间的依赖关系 |

四个完全不同的行业，同一套引擎。区别只是换了行业知识库（Ontology的实例数据），引擎本身——也就是"业务语义的理解方式"——没有动过。这不是理论推演，是实打实干出来的。

四、这对数字化战略意味着什么

如果你正在规划数字化转型，我的建议很直接：在选AI应用之前，先问自己一个问题——你们的工业语义有没有被定义清楚？

- 你的订单数据、设备数据、质量数据之间，有没有一套统一的语言来描述它们的关系？

- 你的工艺参数在你们公司内部，有没有一个标准的、机器可读的定义方式？

- 你换一个产品线、换一个行业，这套语言还能不能用？

如果答案是否定的，那你现在最该做的不是上AI，而是先把语义建起来。

这不只是一个技术问题，这是一个战略问题。

在AI时代，最值钱的能力不是写代码，是把你所在行业的know-how翻译成机器能理解的语言。这件事，AI做不到，只有人能做到。

推荐阅读：