主题
04 AI 智能巡检 — 以视觉巡检为主
对应需求：
IBMS功能模块-V1.md一.9「运维工单管理模块」——「巡检管理（人工 + AI 智能巡检）」。 已有基础：NIMBUS 已有巡检工单，支持定义巡检点和巡检标准，也支持定时生成巡检任务；当前由人工执行。 项目背景：上海交通大学新院区，以 MBA 教学为主；重点巡检对象是阶梯教室、案例讨论室、报告厅、面试间、公共区的设备与空间。
1. 定位与边界
单点阈值越限、设备离线、状态异常，规则引擎 + 告警 + 自动工单已经覆盖。巡检再做一套同样的规则，是重复建设。
| 能力 | 回答的问题 | 触发 | 覆盖 |
|---|---|---|---|
| 告警 / 规则引擎 | 现在有没有超限、离线、异常？ | 实时 | 单点、单指标 |
| 巡检 | 这一轮整体达不达标？有没有视觉异常？记录全不全？ | 周期 / 定时 | 多指标、视觉、证据、记录 |
一句话：告警管「点、实时、单指标」，巡检管「面、周期、多指标 + 视觉 + 记录」。
一个巡检项值得自动化，只有三种情况：
- IoT 没有，或 IoT 不可靠（需要图片 double-check）；
- 状态本身是视觉/物理的（水、门、灯、布局、清洁、表计、故障码）；
- 需要照片/记录作为证据。
不属于巡检的：
- 单点阈值越限 → 规则引擎 / 告警；
- 历史告警统计、保养后复发 → 工单 / 保养分析；
- 「晚上该关没关」等复合规则 → 节能诊断规则引擎；
- 实时安全联锁 → 消防 / 安防系统。
本方案的主线是视觉巡检；规则巡检只做物属性周期比对与留痕；人工巡检做现场补充。
2. 三类巡检
| 类型 | 对象 | 输入 | 执行 | 价值 | 边界 |
|---|---|---|---|---|---|
| 视觉巡检（主） | 设备 / 空间 | 摄像头抓拍 + 巡检说明（提示词） | 系统定时 | IoT 覆盖不到的物理状态、IoT double-check、证据 | 不替代消防/安防；依赖相机视角 |
| 规则巡检（辅） | 设备 + 关联 IoT | 物属性实时/历史值 + 标准 | 系统定时 | 周期比对、报告、长尾覆盖、留痕 | 不重复告警阈值；不做实时检测 |
| 人工巡检（兜底） | 设备 / 空间 / 自定义点 | 现场观察、拍照、语音 | 人 + AI 辅助 | 物理检查、判责、证据 | 不替代法定检查 |
规则巡检做什么：
- 按巡检标准逐项比对物属性（回风温度偏差、滤网压差、瞬时流量等），输出巡检点/设备级结论。
- 对没有告警规则的长尾设备做周期性基础检查。
- 生成周期巡检记录/报告。
规则巡检不做什么：
- 不重复已有告警阈值；不替代实时监控；不做故障根因。
3. 现有巡检体系
3.1 已确认的字段结构（来自「运维 2.0」截图）
巡检标准：
| 区块 | 字段 | 说明 |
|---|---|---|
| 基本信息 | 标准名称、类型（设备/空间）、设备类型、描述、状态 | 设备类型为空 = 适用全部设备 |
| 巡检项 | 检查内容、物属性（可选）、巡检说明（≤1000 字）、指导图片、排序 | 物属性用于规则巡检；巡检说明作为视觉判定提示词；指导图片是参考图 |
巡检点（巡检计划第 3 步）：
| 字段 | 说明 |
|---|---|
| 巡检点名称 | 如「电池组5」 |
| 位置 | 空间位置，可为空 |
| 类型 | 自定义 / 设备 / 空间 |
| 巡检标准 | 绑定一个标准，可查看详情 |
| 巡检顺序 | 计划内的执行顺序 |
| 添加方式 | 自定义 / 选择设备 / 选择空间 |
巡检计划：
- 四步：基础配置 → 时间配置 → 巡检点 → 扩展配置。
- 支持批量设置标准、批量删除；标准支持批量导入/导出。
3.2 对象与数据可用性
- 设备 + 关联 IoT → 可做规则巡检。
- 设备无 IoT → 只做人工巡检。
- 空间 → 有相机做视觉巡检，无相机做人工巡检。
- 自定义巡检点 → 人工巡检。
- 标准项有物属性 → 规则巡检可自动取值；有巡检说明/指导图片 → 视觉或人工巡检。
4. 视觉巡检场景清单
4.1 教室 / MBA 教学
| 场景 | 看什么 | 为什么 IoT 不够 | 判定标准 | 频率 | 动作 |
|---|---|---|---|---|---|
| 课前就绪 | 灯亮、投影幕降下、窗帘位置、桌椅布局、白板干净、无垃圾 | IoT 只知道电源，不知道物理位置/布局/清洁 | 参考图 + 提示词 | 课前 30 分钟 | 通知物业/AV；重复→工单 |
| 课后复位 | 灯关、投影关、白板擦净、桌椅归位、无遗留物 | 同上 | 参考图 | 课后 | 保洁/AV 工单 |
| 案例讨论室布置 | 分组桌椅、翻页纸/笔、屏幕 | 布局不是 IoT 状态 | 参考图 | 课前 | 通知布置 |
| 报告厅活动就绪 | 舞台、讲台、麦、屏、灯光、出口畅通 | 多因素视觉 | 参考图 + 提示词 | 活动前 | 通知 |
| 面试间就绪 | 桌椅、水、资料、门关 | 布置 + 隐私 | 参考图 | 面试前 | 通知 |
4.2 安全 / 消防
| 场景 | 看什么 | 为什么 IoT 不够 | 判定标准 | 频率 | 动作 |
|---|---|---|---|---|---|
| 地面积水 | 水渍/反光/积水 | 水浸传感器只覆盖点位，不覆盖开放地面 | 提示词 + 参考图 | 每 2h / 雨后 | 保洁/安全工单 |
| 防火门未关 | 门扇状态 | 门磁可能没有、被屏蔽、被顶开 | 提示词 | 定时 | 安全工单 |
| 出口堵塞 | 纸箱/杂物挡门 | 无 IoT | 提示词 | 每日 | 安全工单 |
| 灭火器在位/压力表 | 灭火器、压力表指针 | 无 IoT | 参考图 + OCR | 每周 | 安全工单 |
| 消防通道被占 | 车辆/杂物 | 无 IoT | 提示词 | 定时 | 安保工单 |
4.3 设备房 / 表计
| 场景 | 看什么 | 为什么 IoT 不够 | 判定标准 | 频率 | 动作 |
|---|---|---|---|---|---|
| 设备面板故障码 | 屏幕错误码/红灯 | 老设备无 API | OCR + 提示词 | 定时 | 工单 |
| 阀门手柄位置 | 开/关 | 无 IoT 或无反馈 | 参考图 | 每日 | 巡检记录 |
| 管道/地面渗漏 | 水渍/锈迹/结露 | 无 IoT | 提示词 | 每日 | 维修工单 |
| 配电柜门/指示灯 | 门关、指示灯 | 门磁可能没有 | 提示词 | 每日 | 安全工单 |
| 表计读数 | 水/电/气表盘 | 无远传 | OCR | 抄表周期 | 抄表记录 |
4.4 公共区 / 停车充电
| 场景 | 看什么 | 为什么 IoT 不够 | 判定标准 | 频率 | 动作 |
|---|---|---|---|---|---|
| 垃圾溢出 | 垃圾桶满溢 | 无 IoT | 参考图 | 定时 | 保洁 |
| 充电枪落地/油车占位 | 充电枪、车牌/车位 | 地磁只判占用，不判这些 | 提示词 | 定时 | 充电运维/安保 |
| 信息屏黑屏/花屏 | 屏幕内容 | 电源状态不等于内容正常 | 提示词 | 定时 | 发布/维修 |
4.5 IoT 失真 double-check
| 场景 | IoT 说 | 摄像头看 | 动作 |
|---|---|---|---|
| 灯 | 回路“开” | 实际亮度/灯管坏/闪烁 | 维修 |
| 门 | 门磁“关” | 被顶开/虚掩 | 安全 |
| 投影 | 电源“开” | 黑屏/无信号/错误码 | AV 工单 |
| 信息屏 | 电源“开” | 黑屏/花屏/内容错 | 发布/维修 |
| 车位 | 地磁“占用” | 油车占充电位/充电枪落地 | 安保/运维 |
5. 视觉巡检配置与判定
5.1 相机注册
| 字段 | 说明 |
|---|---|
| camera_id | 相机唯一标识 |
| 空间/位置 | 绑定空间编码；用于巡检点和权限 |
| 预置位 | PTZ 预置位，或固定相机视角 |
| ROI | 只看设备/地面等目标区域，避开人和无关区域 |
| 抓拍方式 | ONVIF / RTSP / 厂商 API |
| 图像质量基线 | 参考背景图、亮度范围、清晰度阈值 |
5.2 巡检项配置
| 字段 | 说明 |
|---|---|
| 检查内容 | 短名称，如「地面积水」「防火门状态」 |
| 巡检说明 | 作为 prompt 给多模态大模型，包含判定标准和输出格式 |
| 指导图片 | 参考图，1–3 张正常/异常样本，可选 |
| 物属性 | 规则巡检用；视觉巡检可不填 |
| capture_method | camera / human_photo / iot_property / manual |
| camera_id / preset | 视觉巡检用；哪台相机、哪个视角 |
| confidence_threshold | 低于阈值转人工 |
| review_policy | 是否必须人工复核 |
5.3 巡检说明写成 prompt（含输出格式）
不需要单独约定一套系统级输出结构。在巡检说明的文本输入框里，直接写清判定标准 + 输出格式，由多模态大模型按提示词输出，类似 Dify 里用 prompt 约束输出。
示例：地面积水
检查画面中的地面是否有明显积水、反光或水渍。
只输出一行 JSON，不要解释、不要代码块：
{"result":"符合|不符合|无法判定","evidence":"画面中看到的现象","confidence":"high|medium|low"}示例：防火门
检查防火门门扇是否完全闭合。门扇有缝隙、被物品顶开、虚掩，均判不符合。
只输出一行 JSON：
{"result":"符合|不符合|无法判定","evidence":"门扇状态描述","confidence":"high|medium|low"}设计要点：
- 巡检说明 ≤1000 字，足够放判定标准 + 输出格式；复杂场景可加参考图。
- 系统解析 LLM 返回的 JSON；解析失败 → 判「无法判定/需人工」，不硬判。
- 提示词可以按场景做成模板，批量导入/导出。
- 提示词变更要版本化，避免历史巡检结果口径不一致。
5.4 抓拍与判定流程
定时任务触发
→ 相机转到预置位/抓拍
→ 图像质量检查（模糊/过暗/遮挡/视角偏移）
├─ 不合格 → 抓拍失败，转人工，不判
└─ 合格 → 多模态大模型按「巡检说明」判定
→ 符合 / 不符合 / 无法判定 + 证据 + 置信度
→ 低置信度/无法判定 → 人工复核
→ 不符合 → 生成异常标准怎么给：
- 二值/物理状态（门开关、灯开关、有水/无水）：提示词写清楚即可；参考图用于校准。
- 布局/清洁/就绪：参考图更重要。
- 表计/故障码：OCR/视觉读数，不做像素 diff。
- 不要做像素级比对：光照、角度、时间一变就误报；用多模态语义判定 + 置信度 + 人工复核。
5.5 异常与工单
- 异常由多模态大模型判定后产生，带证据图、置信度、时间、位置。
- 异常后是「新建工单」还是「原工单流程流转到人」，本文不定义，交由工单产品经理定义。
- 本文只定义异常输出：对象、巡检项、证据图、置信度、建议动作、是否需人工复核。
- 低置信度/抓拍失败/数据缺失 → 人工复核，不直接派单。
5.6 反馈闭环
人工确认/纠正
→ 调整巡检说明（prompt）/参考图/阈值
→ 统计误报率、抓拍成功率、复核率
→ 更新巡检标准6. 巡检日报（定时汇总）
巡检报告做成日报：设置一个定时任务（如每天 08:00），汇总前一天的巡检任务，生成日报并推送。
6.1 日报内容
| 区块 | 内容 |
|---|---|
| 巡检概览 | 计划巡检点数、完成任务数、完成率、漏检数 |
| 分类统计 | 视觉巡检 / 规则巡检 / 人工巡检分别完成情况 |
| 视觉抓拍 | 抓拍总数、成功数、失败数（模糊/过暗/遮挡/视角偏移） |
| 异常清单 | 异常数、等级、空间/设备、证据图 |
| 工单情况 | 转工单数、闭环数、待处理数 |
| 人工复核 | 待复核、已复核、误报数 |
| 重点关注 | 重复异常、连续异常、TOP 空间/设备 |
| 建议 | 提示词/参考图/阈值调整建议 |
6.2 日报示例
【巡检日报 2026-11-03】
计划巡检点 12 个 / 完成 11 / 漏检 1（3F 设备房）
视觉抓拍 36 张，成功 34，失败 2（2 张过暗）
异常 3 项：地面积水 1（1F 大厅）、防火门未关 1（3F 东）、灯未关 1（2F 走廊）
已转工单 2，待复核 1
重点关注：3F 东防火门连续 2 天未关6.3 交付方式
- 工单系统「巡检日报」列表 + 企微/小程序推送。
- 日报由定时任务生成，LLM 负责文字汇总；数字来自巡检任务/明细，不由 LLM 计算。
- 可按空间/设备类型/巡检计划订阅；周报/月报作为可选扩展。
7. 数据模型
在现有「巡检工单 + 巡检点 + 巡检标准」上扩展：
巡检计划 InspectionPlan（现有，扩展）
├─ 名称、周期、生效期、下次执行
├─ 巡检点集合（现有）
├─ 执行方式：vision / rule / human / mixed
├─ 日报订阅：接收人、推送时间
└─ 状态：启用/停用
巡检点 InspectionPoint（现有）
├─ 名称、位置（可为空）
├─ 类型：自定义 / 设备 / 空间
├─ 对象：设备 / 空间 / 无
├─ 巡检标准 ID、巡检顺序
└─ 数据可用性：有相机 / 有 IoT / 需现场 / 无对象
巡检标准 InspectionStandard（现有）
├─ 标准名称、类型（设备/空间）、设备类型
├─ 描述、状态
└─ 巡检项列表
巡检项 InspectionStandardItem（现有，扩展）
├─ 检查内容
├─ 巡检说明（作为 LLM prompt，含判定标准 + 输出格式）
├─ 指导图片（参考图）
├─ 物属性（可选，规则巡检用）
├─ capture_method：camera / human_photo / iot_property / manual
├─ camera_id / preset（视觉巡检用）
├─ confidence_threshold / review_policy
└─ 排序
巡检任务 InspectionTask（现有，扩展）
├─ 计划 ID、计划执行时间、实际开始/结束
├─ 范围快照（巡检点数、巡检项数）
├─ 执行方式、数据可用性预检结果
├─ 状态：待执行/执行中/已完成/部分失败
└─ 统计：正常/异常/无法判定/抓拍失败
巡检工单 InspectionOrder（现有，扩展）
├─ 任务 ID、巡检点 ID、对象 ID
├─ 执行方式：vision / rule / human / mixed
├─ 状态（按执行方式走不同状态机）
├─ 汇总：正常/异常/无法判定/抓拍失败
└─ 复核人、复核时间
巡检明细 InspectionItemResult（扩展）
├─ 工单 ID、对象 ID、巡检项 ID、标准 ID
├─ 巡检项快照（检查内容/巡检说明/参考图/prompt 版本）
├─ 结果：符合 / 不符合 / 无法判定 / 数据缺失
├─ 证据：证据图、点位值、告警、知识引用
├─ 判定方式：多模态大模型 / 规则 / 人工
├─ 置信度、抓拍质量（ok/模糊/过暗/遮挡/失败）
├─ 是否需要人工复核
└─ 异常 ID
异常 Exception（扩展）
├─ 对象、空间、巡检项、异常类型、等级
├─ 来源：vision / rule / human
├─ 首次发现、持续时长、重复次数
├─ 证据图、置信度
├─ 处置状态：待复核/待处理/已转工单/已忽略/已闭环
└─ 忽略/误报原因8. 实现要点
| 要点 | 说明 |
|---|---|
| 定时任务 | 巡检计划定时生成任务；抓拍/判定/汇总按计划执行 |
| 相机抓拍 | 预置位/固定视角；ONVIF/RTSP/厂商 API；抓拍失败重试有上限 |
| 图像质量检查 | 模糊/过暗/遮挡/视角偏移 → 抓拍失败，转人工，不判 |
| 提示词判定 | 巡检说明作为 prompt；输出 JSON；解析失败转人工 |
| 结果落库 | 巡检工单 + 明细 + 证据图；支持追溯 |
| 日报汇总 | 定时任务汇总巡检任务；LLM 写文字，数字来自系统 |
| 工单流转 | 异常输出后，新建工单 or 原工单流转，由工单产品经理定义 |
| 权限与隐私 | 按空间/角色授权；避开人脸；不连续录像 |
9. 运行设计
| 项 | 设计 |
|---|---|
| 视觉巡检范围 | 只对「已注册相机 + 视角稳定 + ROI 明确」的点位 |
| 抓拍质量 | 模糊/过暗/遮挡/视角偏移 → 抓拍失败/转人工，不判 |
| 成本控制 | 按点位/频率抓拍；模型调用缓存；失败重试有上限 |
| 质量指标 | 完成率、抓拍成功率、人工复核率、误报率、数据缺口率 |
| 人工复核 | 不符合/无法判定/低置信度/抓拍失败 → 复核队列 |
| 隐私合规 | 卫生间/更衣室/办公室内部不装；避开人脸；按巡检时刻抓拍 |
| 责任边界 | AI 是辅助判责，最终责任仍由复核人/运维承担 |
验收用运营指标，不设模型准确率。
10. 落地顺序
| 步骤 | 内容 |
|---|---|
| 1 | 梳理现有巡检工单/巡检点/巡检标准；补视觉巡检字段（camera、capture_method、confidence） |
| 2 | 相机注册：点位、预置位、ROI、抓拍方式、图像质量基线 |
| 3 | 视觉巡检 MVP：地面积水、防火门未关、公区灯未关、教室课前就绪、设备面板故障码 |
| 4 | 巡检说明写成 prompt（判定标准 + 输出格式）+ JSON 解析 + 人工复核 |
| 5 | 巡检日报：定时任务 + 汇总 + 推送 |
| 6 | 异常工单流转（与工单产品经理定义：新建工单 vs 原工单流转） |
| 7 | 规则巡检、人工巡检 AI 辅助、统计与设备体检 |
11. 需要澄清
已确认：
- 巡检标准字段：标准名称、类型（设备/空间）、设备类型、描述、状态；巡检项：检查内容、物属性（可选）、巡检说明（≤1000字）、指导图片、排序。
- 巡检点字段：巡检点名称、位置、类型（自定义/设备/空间）、巡检标准、巡检顺序；巡检计划四步：基础配置 → 时间配置 → 巡检点 → 扩展配置。
- 对象数据可用性：设备且关联 IoT → 规则巡检；设备无 IoT → 人工；空间/自定义点 → 人工，有相机可视觉。
仍需澄清：
- 摄像头基础设施：哪些点位有相机？视角/预置位/ROI 是否可控？夜间/光照/遮挡是否满足？是否允许按巡检时刻抓拍？
- 巡检说明 prompt：提示词由谁维护？是否需要模板库？变更是否要版本化？
- 输出解析：LLM 返回 JSON 解析失败时，是否接受「无法判定/转人工」？
- 异常工单流转：新建工单，还是原工单流转到人？由工单产品经理定义。
- 巡检日报：受众是谁？推送时间、渠道、订阅粒度？
- 隐私合规：教室/公共区/设备房的抓拍范围、人脸规避、告知与授权由谁负责？
- 规则巡检与告警边界：哪些物属性项已有告警规则？避免重复建设。
12. 一句话总结
巡检聚焦视觉巡检：摄像头定时抓拍，巡检说明作为 prompt（含判定标准和输出格式）交给多模态大模型判定，异常带证据图；规则巡检只做物属性周期比对，人工巡检做现场补充。巡检报告做成定时日报，汇总巡检任务、异常、抓拍和工单情况。异常后新建工单还是原工单流转，交给工单产品经理定义。
附录：AI 摄像头与 VLM 巡检的区别
这里不假设 AI 摄像头具体用什么算法（YOLO、SSD、ResNet、厂商自研都有可能），只按「实时连续事件检测」和「定时抓拍语义判断」两种定位来区分。
A.1 一句话区别
- AI 摄像头：实时、连续、已知类别、事件驱动，像一个「一直盯着的传感器」。
- VLM 巡检：定时、抓拍、按文字标准判断，像一个「按巡检表看照片的检查员」。
A.2 对比
| 维度 | AI 摄像头 | VLM 巡检 |
|---|---|---|
| 任务 | 已知类别的检测/计数/入侵 | 开放式语义判断（按文字标准） |
| 输出 | 框、类别、计数、事件 | 符合/不符合/无法判定 + 理由 + 置信度 |
| 触发 | 实时、连续、事件驱动 | 定时抓拍、周期巡检 |
| 训练 | 需要标注/训练/调优（厂商预训练 + 项目微调） | 零样本/少样本，通常不需要训练 |
| 实时性 | 高，边缘计算 | 较低，单张几秒 |
| 成本 | 一次性硬件 + 边缘算力 | 按图计费/GPU 推理，频率高就贵 |
| 强项 | 人/车/入侵/烟火/PPE/客流 | 水/门/灯/布局/清洁/表计/故障码 |
| 弱项 | 开放类别、细粒度语义 | 实时、精确计数、高并发 |
A.3 VLM 的「免训练」怎么理解
大方向对，但免训练 ≠ 免工程。
- 免掉的是：标注数据、训练模型、部署模型。
- 不免的是：写清 prompt/标准、给参考图、调置信度、做图像质量检查、解析输出、人工复核、隐私合规。
- 对常见巡检项（水/门/灯/布局），零样本通常够用；对细粒度/高精度项（表计读数、轻微渗漏、特定故障码），可能需要 few-shot、专用小模型或厂商算法。
- 巡检的验收通常不是「99% 准确」，而是「把可疑项挑出来给人复核」——这个标准零样本 VLM 是合适的。
A.4 怎么分工
- 实时、安防、已知类别 → AI 摄像头更合适。
- 周期、开放式、文字标准 → VLM 更合适。
- 同一台相机可以作为两者共同的传感器：AI 摄像头出事件，VLM 定时抓图做巡检。硬件不冲突，算法层互补。
- 混合用法：AI 摄像头检测/裁剪 ROI（人、车、设备），VLM 再做语义判断（是否阻挡、是否违规、是否异常）。是否采用取决于实际效果，不绑定具体算法。
A.5 科技馆项目的经验
- 如果当时是海康等 AI 摄像头，大概率是实时事件检测，不是周期巡检；算法层不冲突。
- 可复用的是：相机接入（ONVIF/RTSP/SDK）、抓图/取流、平台集成、点位管理。
- 不需要复用的是：它的固定类别算法；VLM 走另一条路。
- 如果已有海康平台，可以两条腿：海康事件 → 告警/安防；VLM → 巡检/语义判断。
A.6 几个例子
- 消防通道被占：AI 摄像头可能检测到车/人，但「被纸箱挡住」不一定有类别；VLM 可以按「通道是否被任何物体阻挡」判断。
- 有人闯入：AI 摄像头更合适，实时、成熟；VLM 不适合做实时安防。
- 地面积水：AI 摄像头通常没有这个类别；VLM 零样本可以判断。
一句话：AI 摄像头是「实时找已知目标」，VLM 是「按文字标准看照片下判断」。定位重叠在「看图」，但触发方式、能力边界、成本和实时性完全不同；相机可以共用，脑子不一样。