办公室里的设备坏了，最常见的流程是这样：有人在群里发一句「三楼空调不制冷了」，行政看到了转给维修师傅，师傅说手头有活，过两天再接——中间没人知道这件事到底是「已经安排了」还是「被忘了」。催一次动一下，不催就沉底。
问题不在于没人负责，而在于这件事没有单据。没有单据，就没有派给谁、没有承诺时间、没有进度、也没法统计。这篇讲怎么用 OpenClaw 把设备报修和维保这件事做成一条能看清的线。
先说明它和站内几篇的区别：AI Agent 客服怎么搭 和 客服工单 SLA 催办 处理的是对外客户的对话工单——有人来问问题，我们去回应；OpenClaw 巡检证书与域名到期 管的是时效性资产——证书和域名按天数预警。这一篇管的是第三类对象：实物设备的故障处置和定期保养，有明确的现场动作和验收环节。
一、先有设备台账，才有报修单
跳过台账直接做报修，最常见的后果是：报修单里写「空调坏了」，可你有三十台空调，不知道是哪一台，也不知道上一次修是什么时候。所以第一步是把设备本身建档，一台设备记七件事：
- 设备编号——贴在机器上的那个号，报修单只认它，不认「三楼那台」。
- 设备名称与型号——写清楚品牌型号，方便查配件和保修。
- 安装位置——楼层 + 房间号，位置会变，变了要改台账。
- 责任部门与使用人——设备出了问题谁最清楚情况。
- 供应商与保修期——保修期内走厂家，别自己找人修白花钱。
- 维保周期与上次保养日期——这是后面自动提醒的基础。
- 状态——在用 / 停用 / 已报废，报废的设备不再产生报修单。
台账建好之后，Agent 才能做校验：报修单里填的编号存不存在、设备是否在保修期、同类设备近三个月是不是已经修过三次。
二、报修入口：三种来源，五个必填项
报修单要能收进来，而不是靠人转述。常见三种来源：
- 一线直接提交——扫码或填表，最原始也最准确。
- 巡检发现——巡查时发现隐患，直接转成报修单，这类单子往往比故障报修更有价值，因为它是事前的。
- 系统触发——监控发现异常（温湿度超限、设备离线）自动开单。
不管是哪种来源，一张报修单必须有五个必填项，缺一个都不该进流程：
- 设备编号——不填编号的单子一律退回。
- 故障现象——写现象不写下结论，「不制冷」而不是「压缩机坏了」。
- 影响范围——影响几个人、影响哪个区域、有没有安全风险。
- 发现时间——决定后面算不算超时的起点。
- 报修人——现场联系人，师傅到了找不到人最耽误事。
让 Agent 在这里做第一道关：字段缺失、编号不存在、设备已报废的，直接退回补填，不要转给调度。
三、派单规则：按类型分，不按谁叫得响
派单最容易走偏的地方是「谁催得急先给谁修」。合理的做法是按两条线分：
- 按专业分——电气、水暖、空调暖通、电梯、消防、IT 与弱电。分错专业，师傅到了也只能看不能修，一来一回就是一天。
- 按影响面定优先级——涉及安全和多人使用的排最前，影响单人的往后排。建议把优先级写成分档规则，比如「有安全风险 / 影响 10 人以上 / 影响 1–9 人 / 只影响一个人」，不要让调度凭感觉排序。
还有一个细节：派单要考虑师傅当时的负载。一个人手上已经压了五单，第六单派给他只会整体变慢。这套「先看负载再排人」的思路，和 OpenClaw 自动排班 里「先算缺口再排人」是一个道理。
四、进度跟踪：五个状态和超时升级
报修单最有价值的部分不是派单，是「卡住了能被发现」。建议固定五个状态，每个状态设一个超时阈值：
- 已受理——单子进了系统，还没派人。超过约定时间没派单，直接提醒调度。
- 已派单——有明确责任人了，超时未响应就提醒师傅本人和他的主管。
- 处理中——已经到场。长周期维修要设中间检查点，别让「处理中」变成万能挡箭牌。
- 待验收——师傅说修好了，等报修人确认。这一步最容易被忘，所以要主动推送确认请求。
- 已关闭——验收通过，写入设备台账的维修记录。
超时提醒要分层，不要一超时就全员轰炸：第一次只提醒责任人，再超时升级到主管，仍无动作才升级到更高层。当任务彻底推不动时，参考 OpenClaw 转人工队列 的做法把它挂出来，而不是让它烂在自动化流程里。
五、维保计划与到期提醒
报修是被动的，维保是主动的，两者要放在同一张表里看。维保部分做三件事：
- 按周期生成计划——电梯、消防、空调这类按法规或厂家要求有固定周期，到期前自动生成保养任务，而不是等人想起来。
- 分档提醒——提前 30 天进计划、提前 7 天提醒责任人、到期当天升级。这套分档预警可以直接复用在 资产到期巡检 里已经验证过的机制。
- 隐患整改闭环——保养时发现的隐患要单独开一条整改记录，指定责任人和期限，整改完再关。不要写一句「已提醒」就算完。
涉及安全类的设备（消防、电梯、燃气），维保记录本身就是被检查时要拿出来的材料，留痕标准要按 证据包怎么留 的要求来做。
六、数据能回答的三个问题
单子攒下来之后，这套系统才真正开始产生价值。值得每月看一次的有三个问题：
- 哪台设备最常坏——同一台设备反复维修累计到一定次数，就该考虑换而不是修，这是最直接的省钱判断。
- 哪类故障最多——如果某一类故障占总量的三分之一，说明问题在操作规程或使用习惯，不在维修本身。
- 钱和时间花在哪——按设备类别看维修成本和处理时长，能看出哪一类资源分配得不合理。
要看这些数字，字段就得在开单时设计好，参照 AI Agent 审计字段怎么设计 的思路，把「设备编号 + 故障类别 + 成本 + 耗时」这几列固定下来。
七、三条边界
- 不替代安全作业审批。动电、动火、高空、有限空间这类作业，必须走独立的安全作业票，报修单不能充当作业许可。
- 高危场景必须人工到场。涉及燃气、电梯困人、消防设施失效的，Agent 的职责是立刻通知到人并留存通知记录，不是自动处置。
- 不自动下单采购。需要更换配件时，Agent 可以生成请购需求，但采购和付款仍要按采购流程走，权限边界参考 AI Agent 权限管理。
八、五个常见的坑
- 不填设备编号。没有编号就统计不了，也查不到历史维修记录，整个系统退化成聊天记录。
- 故障描述写结论。报修人写「主板坏了」，师傅按结论带错配件，一来一回浪费两天。
- 优先级靠吵。谁会催谁先修，最后所有人都学会催，调度彻底失效。
- 「处理中」没有检查点。长周期维修卡在这里没人发现，等于没有跟踪。
- 验收环节省略。师傅说修好了就关单，过两天同样的问题再报一次，根因永远找不到。
九、适合谁用
适合：有成规模实物设施需要维护的场景——写字楼、园区、工厂车间、门店、机房。尤其是设备数量超过二三十台、已经有专人做后勤或设备管理的团队，这套台账加报修单能立刻把「谁在办、办到哪了」讲清楚。
不太适合：设备就三五台、坏了直接打电话叫人的小团队。这个阶段上一套报修系统是负担，先用一个共享表格记录故障和维修历史就够了。
总结
用 OpenClaw 做设备报修，重点不在「能收到报修」，而在每张单子都知道派给谁、承诺多久、卡在哪一步、最后有没有验收。先建设备台账把对象定清楚，再用五个必填项把单子收干净，派单按专业和影响面分，状态配超时升级，维保单独排计划。五步下来，设备管理才从「群里喊一声」变成一件能被追溯的事。
