夜雨聆风很多工厂的 AI 项目，开始得都很像。
会议上有人说：“我们也要做 AI 。最好能预测停机、提升良率、减少人工判断。”这句话听起来方向很对，也很难反驳。于是工程师开始找供应商、问传感器、接数据、看 Demo 、做试点。项目刚开始，每个人都很有信心：管理层觉得这是数字化升级，供应商觉得场景很有潜力，工程师觉得只要数据接上，事情应该能推进。
但真正麻烦的，往往在几周之后才出现。
供应商问：到底要预测什么故障？现场问：报警以后谁来处理？品质问：良率提升怎么算？维修问：误报太多算谁的？老板问：这个 AI 项目为什么还没看到效果？最后，工程师发现自己站在中间，既要解释数据为什么不够，又要解释模型为什么不准，还要解释为什么 Demo 看起来很好，到了现场却不稳定。
这不是工程师不努力，而是项目一开始就缺了最关键的一步：没有把“上 AI”翻译成可执行、可验收、可追责的工程任务。
AI 项目最危险的地方，是一开始大家都觉得自己懂了
“做预测维护”“做质量预警”“做智能检测”“做工艺优化”，这些词在会上很顺，但它们不是工程问题。工程问题必须落到对象、工况、测点、数据、动作和验收上。
比如“做预测维护”，到底是预测轴承磨损、泵汽蚀、对中偏差，还是电机过热？预测提前多久才有意义？提前 5 分钟报警和提前 3 天报警，对维修计划完全不是一回事。报警之后是停机检查、降负载运行，还是只做记录？如果报警 10 次里 8 次没事，现场还会不会相信这个系统？如果真故障漏掉一次，责任怎么分？
再比如“提升良率”，到底是减少哪一类缺陷？是尺寸漂移、表面划伤、焊接飞溅、注塑短射，还是薄片孔洞？缺陷有没有绑定工位、批次、材料、设备和工况？如果只是把不良率做成看板，而没有把缺陷和过程变量连起来， AI 能做的也只是更快地告诉你“今天又不稳定了”。
很多 AI 项目不是败在模型，而是败在这种模糊共识。大家都以为自己理解了目标，但每个人理解的其实不是同一个目标。管理层要结果，供应商要数据，现场要少麻烦，工程师要能落地。只要这几件事没有在开工前对齐，项目越往后走，分歧越大。
真正靠谱的开工方式，是先写清 4 张表
第一张，是问题定义表。它要回答的不是“要不要上 AI”，而是“到底要解决哪个现场问题”。对象是谁，异常是什么，发生在哪些工况下，现在靠什么人工判断，失败一次带来什么损失，项目成功后现场应该少做哪一步。只有问题定义清楚，后面的数据和算法才有方向。
第二张，是数据边界表。很多人一听 AI ，就以为数据越多越好。实际工程里，数据不是越多越好，而是越可解释越好。已有数据能不能信，采样频率够不够，数据有没有工况标签，哪些传感器只是设备自带信号，哪些需要新增测点，哪些历史记录不能直接拿来训练，这些必须提前写清楚。否则后面模型效果不好，所有人都会回头争论“数据到底有没有问题”。
第三张，是供应商追问表。不要只听供应商讲案例，也不要只看 Demo 。要问它用什么数据演示，测点怎么布，传感器装在哪里，异常样本从哪里来，误报漏报怎么处理，模型上线后谁维护，阈值谁调整，现场换工况后要不要重新标定。供应商能把这些问题说清楚，才是真的理解现场；只会说“我们算法很强”，还不够。
第四张，是验收闭环表。这张表最容易被忽略，也最要命。 AI 项目不能只验收“系统有没有上线”，也不能只验收“界面有没有报警”。它必须回答：提前多久预警算有效，误报率多少可接受，漏报怎么定义，报警后现场动作是什么，维修或调整后如何复测，结果由谁确认，连续运行多久才算稳定。
这 4 张表的意义，不是增加文档工作量，而是防止项目从一开始就变成风险转移。写清楚以后，老板知道项目要解决什么，供应商知道必须交付什么，现场知道报警以后怎么做，工程师才不会在最后被迫解释所有模糊地带。
别被漂亮 Demo 带偏， AI 项目最后要看验收链
供应商 Demo 很容易让人兴奋。界面漂亮，曲线顺滑，报警准确，案例完整。但工程师要冷静一点： Demo 不是现场，演示数据不是生产数据，模型输出不是现场动作。
一个 AI 项目是否靠谱，不能只看它有没有预测结果，而要看它能不能走完验收链。真实工况下的数据能不能采到，正常和异常有没有可比基线，报警策略能不能被现场理解，报警之后是否真的触发检查或维护，维护之后状态是否回稳，缺陷率或停机时间是否真的下降。
如果这条链断了， AI 就会变成一个“很会输出但没人负责”的系统。它每天给你很多报警，现场不知道该不该信；它生成很多分析，维修不知道该不该动；它做出很多图表，管理层不知道效果怎么算。到这个阶段，项目不是智能化，而是新增了一个解释成本。
所以工程师在项目开工前，一定要把验收链写出来。不要只问准确率，要问这个输出会改变什么动作。不要只问有没有模型，要问模型出错时谁处理。不要只问供应商能不能做，要问做完以后如何证明它真的有用。
智能章鱼适合放在项目最前面，而不是等项目乱了再救火
智能章鱼要解决的，正是这个前置阶段的问题。
很多工程师不是不会判断，而是太多信息散在不同地方：老板一句目标、现场一堆现象、供应商一套话术、历史数据一堆表格、传感器参数一堆 PDF 。真正消耗人的，是把这些东西整理成项目可以继续推进的工程材料。
在智能章鱼里，工程师可以先从一句模糊需求开始：比如“老板要我们做一套空压站 AI 节能和预测维护”“客户想给焊接产线加质量预警”“注塑车间想做缺陷预测”。平台可以帮助工程师把这个需求拆成对象、工况、测点、数据、供应商追问和验收建议，再生成一份更像样的项目开工材料。
它不是替工程师拍板，也不是替现场做责任判断。它更像一个工程参谋：帮你把没问的问题补出来，把没写清的边界标出来，把供应商必须回答的问题列出来，把验收时容易扯皮的地方提前写进表里。
这件事看起来不炫，但非常关键。因为工业 AI 真正难的，不是让模型说一句“可能异常”，而是让这句话在现场变成可执行动作。只要这个动作不能被定义、不能被验证、不能被复盘，项目就很难稳定落地。
智能章鱼平台地址： https://www.gsccdiribo.com
结语：先保护工程问题，再谈 AI 能力
AI 时代，工程师真正需要警惕的，不是 AI 会不会替代自己，而是自己被模糊目标、漂亮 Demo 和不完整数据推到一个说不清责任的位置。
老板让你上 AI 项目，不要第一反应就去找模型、找供应商、找传感器。先把 4 张表写清楚：问题定义表、数据边界表、供应商追问表、验收闭环表。写得出来，项目才有继续推进的基础；写不出来，越早开始，后面越容易返工。
真正成熟的工业 AI 项目，不是从“我们要上 AI”开始，而是从“我们要解决哪个对象在什么工况下的什么问题，并且如何证明它被解决了”开始。
下一篇，我们可以继续拆其中最容易被低估的一张表：供应商追问表。很多工厂不是没买到好设备，而是需求发出去的时候就太模糊，导致供应商只能猜。下一篇我们讲清楚：怎样把一句“帮我做个监测方案”，变成供应商无法糊弄、工程师可以验收的技术问题。
了解智能章鱼： https://www.gsccdiribo.com
请持续关注公众号：全球传感器工业竞争力中心
