运维团队要引入 AI，第一个动作常常是找供应商比模型。这一步其实排在后面。
更靠前的问题是：现在的运维流程有没有把"异常—诊断—处置—结果"这条链跑通并留下记录。没有这条链，物联网数据再多也缺一半——工业级 AIoT 需要的不只是设备读数，还需要人做过什么、结果如何。
通微智慧在项目里用的是一个四步顺序。每一步都有独立价值，也都不能跳。
第一步：连接与监测
设备与数据统一接入，在线状态、运行参数、趋势可视。这一步用工业网关和扩展模块把现场对象接进来，形成站点与设备的统一台账。
没有这一步，后面全是空谈。这也是最容易被低估的一步——物联网接入不是插上网线就算完成，前面几篇讲过的数据完整性、时间一致性、口径统一都在这一层解决。
这一步的独立价值：状态可见，异常不用等客户来电。
第二步：告警闭环
告警分级、去重、责任到人、派工、移动巡检、现场反馈、报表统计。
这一步是全文的重点，因为它同时在做两件事。管理上，它解决"告警不到人、重复告警多、责任分派不清"的问题。数据上，它在生产标注。
一条完整的闭环记录包含：什么时候出现什么异常、当时各参数是什么状态、谁去处理的、判断原因是什么、做了什么动作、之后是否复发。这就是一个带标签的样本。AI 要学会判断"这类异常通常是什么原因"，学的正是这批样本。
反过来，如果告警发出去就没有下文，处置在微信群里口头完成，那么系统里只有一堆孤立的告警记录，没有对应的原因和结果。这批数据用来训练，模型学不到任何有效关联。
所以闭环不是 AI 的前置管理要求，它本身就是数据生产环节。这一点在评估投入顺序时值得算进去。
这一步的独立价值：责任清楚、处置可追、月报不用手工拼。
第三步：让 AI 先进入可验证、可回退的环节
有了前两步的数据，AI 可以开始做事了。选什么场景切入有讲究——要挑可验证、可回退、有人工审核兜底的环节。
比较合适的几类：从多条告警中汇总事件经过，帮值班人员快速理解影响范围；从历史工单和运维手册中检索相似案例，生成排查清单；把巡检记录、设备状态和处理反馈整理成月报初稿；对趋势和多源数据关联给出风险提示，再由专业人员确认。
这几类的共同点是：输出错了不会造成现场后果，人能看出错在哪，效果能被度量。切入时要同时设定人工审核环节和效果指标——比如告警摘要是否减少了值班人员的判断时间，检索到的相似案例命中率有多高。
不合适的是一上来就做自动决策、自动远控、无人值守。不是技术上完全不可能，而是此时既没有足够的验证数据，也没有回退机制。
这一步的独立价值：重复的信息整理工作减少，散落在物联网数据和工单里的经验更容易被调用。
第四步：按数据积累逐步扩展
故障样本和完整的故障前后记录积累到一定程度，才谈得上趋势预判和预测性维护。
这一步没有固定时间表，取决于设备数量、故障频次和记录质量。诚实的说法是：到了那时再评估，而不是现在就写进合同。
通微智慧的分层能力
广州通微的方案配套覆盖前两步，第三步提供可验证的辅助能力。AIoT 的能力在端边云底座上分两侧：
边缘侧负责实时判断与执行——阈值、状态、趋势与异常模式的本地判断，规则执行与现场联动，断网缓存与恢复续传。
中心侧负责全局分析与持续优化——跨设备跨站点关联与辅助根因分析，风险与能效趋势的提前提示，规则与处置经验的沉淀复用。
边界
现阶段重点交付可视化监测、主动告警和运维闭环，以及可验证的辅助诊断与报表；预测性维护按数据积累逐步开放。
不把辅助分析写成无条件的自动诊断、预测或决策。设备安全、生产控制和现场联锁不因模型输出被替代。
远控权限与安全策略在项目阶段书面确认。
下一步
先确定自己当前在四步中的哪一步。如果第一步还没做完，讨论模型没有意义；如果第二步的闭环记录还散在群里和表格里，那么先把留痕做起来，这件事本身就有回报，而且它决定了将来 AI 能不能用得上。
通微智慧可以做一次需求诊断，把当前位置和下一步范围盘清楚。