拒绝PPT：工业AI的“烂尾楼”工程，问题出在哪？

上一篇文章《工业AI的“最后三公里”》拆解了架构。这一篇，我们要直面血淋淋的现实。

我去过很多工厂，见过太多“AI烂尾楼”——花了几十万上百万，最后只剩一个电子看板，数据不准，没人看，也没人维护。

这不是技术问题。这是架构问题。今天，我们把这些问题一个一个剖开。

一、触目惊心：90%的工业AI项目，都在“烂尾”
先给你看一组真实的数据（来源：我个人的实地调研）：

87% 的工业 AI 项目从未进入过真正的生产环境。

其中 60% 死在了数据采集阶段。

另外 25% 死在了“无法闭环”上——AI能分析，但不能控制。

只有不到 3% 的项目真正实现了 ROI 回正。

这些项目，花了钱，占了人，最后留下的是什么？

一块漂亮的电子看板（数据经常不准）

一套没人用的预测模型（因为分析结果无法指导行动）

一堆“待优化”的Bug列表（因为供应商已经撤了）

这就是工业AI的“烂尾楼”现象。

下面，我要给你看三个最典型的烂尾楼工程。如果你们工厂正在上马或已经上马了AI项目，请对号入座。

二、烂尾楼一号：“数据黑洞”
项目背景
某汽车零部件工厂，年产值5亿，老板在行业峰会上听了一场“工业4.0”演讲，决定上马“AI预测性维护”项目。预算：80万。目标：通过分析设备振动数据，提前预测轴承故障，减少非计划停机。

供应商是一家中型软件公司，演示PPT里AI模型精准预测的画面，让老板当场签了合同。

项目过程
第1-2个月：数据采集阶段。 工厂设备种类繁多：西门子PLC、三菱伺服、发那科机器人、还有一些老旧的Modbus仪表。供应商的工程师团队花了六周时间，才把70%的设备数据采集上来。剩下的30%，因为协议文档不全、设备停产、厂家不配合等各种原因，始终采不上来。

第3-4个月：模型训练阶段。 由于数据不全，AI模型只能在有限的数据集上训练。振动数据的采样频率不够，导致高频特征丢失；部分传感器精度不足，数据噪声严重。模型在训练集上准确率达到95%，但现场测试时，误报率高得惊人。

第5-6个月：项目收尾阶段。 供应商心力交瘁，项目严重超期。最终交付了一个“降级版”——一个显示设备振动数据的电子看板，和一个“还在优化中”的预测模型。

烂尾结果
项目实际花费：120万（严重超预算）

最终交付物：一个电子看板 + 一个准确率不达标的预测模型

当前状态：看板还在跑，但数据经常中断；模型没人维护，已经停用

老板评价：“感觉像是花120万买了一个大号的设备监控屏幕。”

根因诊断
这个项目，从架构上就已经注定烂尾。

它的数据采集架构是一个典型的“烟囱式”架构：针对每种设备协议，独立开发驱动。这种方法在小规模（3-5种设备）时可以应付，但面对工厂常见的十几二十种设备协议，复杂度呈指数级增长。

你需要的是一个“通用翻译器”——一个支持40种主流工业协议的采集引擎，而不是一个一个去“翻译”每种方言。

三、烂尾楼二号：“AI瞎子”
项目背景
某食品加工企业，上了“AI质量管控”项目。目标是通过AI视觉检测产品外观缺陷，并联动产线控制进行自动分拣。预算150万。

项目过程
系统上线第一个月：AI视觉系统本身表现不错，能识别出95%以上的外观缺陷。

试图联动控制时：发现了致命问题。AI系统需要知道“当前这条产线上跑的配方号对应的标准参数是多少”。但这个信息，存储在另一个老旧的MES系统里。MES系统太老，没有标准API，且参数是以老师傅能看懂的“工艺卡”形式存储的，不是结构化数据。

供应商尝试“硬打通”：花了一个月，试图解析MES系统的数据库表结构，但发现很多关键参数是文本备注的形式（“比平时多加一点水”、“颜色看起来偏深就调低温度”），根本无法被程序解析。

老板质问团队：“AI为什么连‘这个产品的标准温度是多少’都不知道？”

烂尾结果
项目实际花费：200万

最终交付物：一个独立的AI视觉检测系统，能发现问题，但无法自动分拣。

当前状态：AI负责“看”，工人负责“动手”。一条本应全自动的分拣线，变成了需要3个人在AI屏幕前待命的半自动线。

产线组长评价：“这AI就是个瞎子。看得见毛病，但不知道怎么治。”

根因诊断
这个项目的致命伤，是 “语义断点”。

AI视觉系统识别到了缺陷，但它不知道：

这个缺陷叫“气孔”，还是“裂纹”？

它的标准是什么？允许多大？

产生气孔的可能原因是什么？跟当前的温度、压力、原料批次有什么关系？

应该怎么处理？是停机？报警？还是调整某个参数？

这些知识，存在于老师傅的脑子里、工艺卡片的文字里、老MES系统的备注里——它们从未变成AI能理解的语言。

你需要一个“语义建模层”——让老师傅的经验、工艺卡的参数、设备间的关系，变成AI可以查询的知识图谱。

四、烂尾楼三号：“断线风筝”
项目背景
某化工厂，投资300万上马“AI能耗优化”项目。目标是通过实时分析各工段的能源数据，自动优化蒸汽、电力分配，降低能耗成本。

这是三个项目里起点最高的一个。数据采集基本完整（厂内自动化程度较高），AI模型也训练得不错，能耗预测准确率达到95%以上。

问题出在最后一环。

项目过程
AI模型运行良好：每天生成一份详细的能耗优化建议，精确到每小时、每个工段应该怎么调整。比如：“10:00-11:00，蒸馏塔蒸汽阀开度建议从80%降低至73%。”

交付方式：邮件。 AI系统与设备控制系统之间，没有任何实时连接。分析结果每天生成一份PDF，以邮件形式发送给能源管理工程师。

工程师收到邮件后：通常要等到下次巡检时才会去手动调整，时间差平均在 4-6小时。如果邮件是下班时间发的，要等到第二天早上才有人处理。

后果：AI的优化建议从未被实时执行。 它的建议在发送的那一刻还有效，但4-6小时后，工况已经完全变了。工程师发现，自己手动调整后，效果总是比AI建议的差一截，因为调整太滞后了。

烂尾结果
项目实际花费：300万

最终交付物：一个每天发送优化建议邮件的AI系统

当前状态：AI正常运行，但建议执行率不到 10%。大部分建议因为“时效性”原因被忽略。

工程师评价：“这AI就像一个被绑住手脚的诸葛亮。能算出最好的方案，却没办法自己去执行。”

根因诊断
这是最典型的 “行动断点”。

AI能“看”，能“想”，但不能“动”。它的分析结果，被一道“人工确认”的墙堵住了。

这个断点带来的损失，不仅仅是反应速度的问题。每次人工介入都是一个效率的漏洞，也是安全的风险。 人工确认需要的几分钟甚至几小时，在精密化工过程中，可能就是一次质量事故或能源的极大浪费。

你需要的是一个标准的“行动层”——让AI通过统一的协议（比如MCP），直接调用设备控制的接口。不是发邮件，是直接调整蒸汽阀门。

五、三座烂尾楼的共同病因：“架构性缺陷”
项目 致命伤 临床表现 根因
汽车零部件厂 数据黑洞 70%设备可采，30%采不上 缺少统一的采集引擎
食品厂 AI瞎子 看到缺陷，不知道怎么处理 缺少语义建模层
化工厂 断线风筝 建议发邮件，没人执行 缺少标准行动层
这三个案例，不是个案。它们是工业AI行业的三个缩影。

它们的共同问题是：架构性缺陷。

你花钱买的，是一个“AI模型”，而不是一个“AI系统”。

AI模型只能解决分析的问题。但一个能落地的AI系统，必须先解决数据采集、语义理解、行动执行这三个更底层的问题。

六、什么是正确的架构？
正确的架构，是一个四层的闭环：
┌──────────────────────────────────────┐
│ 第四层: 行动层 │ MCP 协议 │
│ │ AI直接操控设备 │
├────────────────┼────────────────────┤
│ 第三层: 分析层 │ Fabric 引擎 │
│ │ 27个工业分析算子 │
├────────────────┼────────────────────┤
│ 第二层: 语义层 │ 工业知识图谱 │
│ │ 地址 → 知识 │
├────────────────┼────────────────────┤
│ 第一层: 采集层 │ 40种协议驱动 │
│ │ 物理信号 → 数据 │
└────────────────┴────────────────────┘
对比烂尾楼，答案一目了然：

烂尾楼 缺少的层 正确做法
汽车零部件厂 采集层 用40种驱动的统一引擎，而不是一个一个开发
食品厂 语义层 建立工业知识图谱，让AI理解“气孔”和“标准温度”
化工厂 行动层 通过MCP让AI直接调整参数，而不是发邮件等人操作
七、算一笔账：烂尾楼 vs 正确架构
我们用数据说话。

对比项 传统“烂尾楼” 正确架构
数据采集周期 2-4个月 30分钟（选驱动，填IP，启动）
语义建模依赖 依赖人工查询 AI自助查询（get_variable_relations）
AI到行动的延迟 4-6小时（等工程师看邮件） 实时（tools/call）
项目总周期 6-9个月 几天到几周
总成本 100-300万 年费制，十几到几十万
ROI实现 ❤️%的项目 从第一个月就开始回正
这不是营销话术。这是架构带来的结构性效率提升。

当你的架构正确时，成本是线性下降的，效率是指数级上升的。

八、已经跑起来的证据
你可能会问：这套架构真的跑起来了吗？

以下是 AutoClaw Agent 在 2026年8月3日，对 NeoIndustrial 平台的一次全维度实测结果：
测试时间: 2026-08-03 09:34 ~ 16:40
测试项目: 84项
通过: 66项
异常: 18项（其中16项为参数细节问题）
崩溃: 0项

关键事实:

• MCP 49个工具全部可调用，0错误
• 设备采集、语义查询、Fabric分析、数据源查询，全链路打通
• 从发现Bug到修复到回归验证，1小时内完成
  这不是PPT。这是跑在 localhost:5160 上的真实系统。

九、给你的建议
如果你正在或准备在工厂里上AI项目，问三个问题：

数据采集：你能一次接上工厂里所有的设备吗？还是需要花几个月一个一个开发驱动？

语义理解：你的AI知道每个变量的物理含义和关系吗？还是只能看到一堆“地址+数值”？

行动闭环：AI的分析结果，是变成了一封邮件等人处理，还是可以直接调整设备参数？

如果这三个问题里有一个回答是“不确定”，那么请重新审视你项目的架构。

在工业领域，用 PPT 搭建的 AI 系统就像在沙滩上建城堡，它看起来很美，但一阵海浪就能把它夷为平地。而那些已经烂尾的项目，恰恰可以成为你最好的“反例教材”。

拒绝PPT。拒绝烂尾楼。从正确的架构开始。

作者：张成龙
NeoIndustrial 工业数据采集与智能分析平台 创建者
2026年8月4日