设备点检巡检：把例行检查变成可追溯的记录

痛点：检查做了，记录没留下

制造业车间里几乎都有"每日点检"这件事：早班转一圈，看看油位、听听声音、擦擦导轨、记下压力表读数。问题不在有没有做，而在做完之后留下了什么。

常见的三种状态：

• 纸质表格挂在设备上。填完就归档到抽屉，季度设备分析会要用的时候，得一个人一页一页翻，抄进 Excel。想查"这台空压机上个月漏了几次检"，基本靠回忆。
• 微信群发照片。班长要求"每台拍一张"，群里一天几百张图，没有设备编号、没有时间戳约束、没有异常分类。三个月后没人能从中检索出任何东西。
• 有系统但只在办公室。PC 端有个台账页面，可点检发生在车间现场，工人得回办公室开电脑录昨天的数据——于是又变回纸单补录。

对设备管理者来说，真正缺的是三件能被回答的问题：今天该点的都点完了吗、发现的异常谁在处理、处理到哪一步了、哪台设备的异常在反复出现。这三个问题的答案，本质上是一套结构化的数据关系，而不是一张更漂亮的表。

这一篇讲的就是：用 AI 构建器把"设备点检巡检"做成一个业务模块，需要建哪些数据、页面长什么样、手机上怎么走一遍流程、上线前要核对什么。它属于典型的"业务数据 + 管理页面 + 流程闭环 + 移动端伴同"形态，是构建器可以直接交付的模块类型。

先想清楚：点检和巡检不是一回事

很多方案把这两个词混着用，落地时就会踩坑。它们的差别决定了数据结构：

所以一个完整的方案通常同时包含两者：设备档案上挂点检标准（这台机器每天要看哪五项），巡检计划引用一组设备或点位（这条路线今天经过哪些机器）。如果工厂只做区域巡检（比如厂区安全巡查、消防通道检查），那"点位"可以不是设备，而是位置——数据结构同样成立，只是引用对象换成区域档案。

先把这层区分定下来，后面的表和页面才不会拧巴。## 数据怎么建：五张表撑起一条闭环

在构建器里用业务语言描述需求，AI 会生成对应的数据模型。建议按下面这个骨架去提要求，五类数据缺一不可。

1. 设备台账（如果已有就直接引用）

点检的对象。核心字段不需要多：设备编号、名称、类别、所属车间/产线、责任人、状态（在用/停用/封存）。这张表是整个模块的外键来源——没有稳定的设备主数据，点检记录就会散成一堆自由文本，"这台机器"和"那台机器"永远统计不到一起。

已经做过设备台账的企业，这一步只是让新模块引用它，不是重建一份。构建器里的跨模块引用（软外键）就是为这种场景准备的：新建的点检计划选设备时，下拉里出现的是台账里的真实设备，改一处两处同步。

2. 点检标准与检查项

一台（或一类）设备"要看什么"。这是最容易被省略、又最关键的一张表。

• 标准头：标准名称、适用设备或设备类别、版本号、生效状态
• 检查项明细：序号、检查部位、检查内容描述、判定方式、正常范围、必填要求

判定方式决定了移动端长什么样，值得单独设计成字典：

数值型检查项一定要写清上下限。这是后面能做"压力缓慢下降"这类预警的唯一前提——只存"正常/异常"，就永远看不出还没坏但正在变差的设备。

3. 点检任务（执行记录）

一次实际执行的产物。字段：任务编号、设备、引用的标准、计划日期与班次、执行人、开始/完成时间、每项的判定结果与读数、总体结论、异常标记。

这里有个设计取舍要提前定：明细结果存成子表还是 JSON。推荐子表（一行一个检查项的结果），因为"某个检查项的历史趋势"是高频查询，JSON 里取数会很别扭。

另外要明确一点：任务记录一旦提交就不允许随意改动。可以允许"补充说明"或走一次带审批的更正，但不能让执行人把上个月的异常改成正常——否则整条链的可信度归零。

4. 巡检路线与点位

区域巡检专用。路线头（名称、所属区域、预计耗时、启用状态）+ 点位明细（顺序号、点位名称/引用设备、位置描述、该点位适用的检查标准）。

顺序号是有用的字段，不只是好看：手机上按顺序推进，走完一个点位才能解锁下一个，可以避免"站在门口把十个点全打勾"的假巡检。

5. 异常整改单

点检发现异常之后要走的那条流程。字段：来源任务（回链）、设备、异常描述、严重等级、上报人/时间、处理状态（待派工/处理中/已完成/已验证关闭）、责任人、处理措施、完成时间、验证人。

这张表是"检查"和"维修"之间的桥。有了它，点检不再是填完就归档的死数据；没有它，工人很快会发现"报了也没人管"，然后不再认真填。## 页面怎么用：办公室看全局，车间录现场

数据建好之后，构建器会生成基础的增删改查页面。但点检模块真正有价值的是三类被"改造过"的视图。

设备管理员：今日完成率 + 漏检清单

一个概览页，回答"现在情况怎么样"：

• 今日应点 / 已点 / 异常三个数字，按车间或产线分组
• 未完成清单：谁的任务还没交，直接列到执行人和班次，方便催办
• 近三十天漏检趋势：按设备看哪台最常被漏，通常能立刻暴露排班问题（某台机器排在夜班，而夜班没人执行）
• 待处理异常池：所有未关闭的整改单，按严重等级排序

这一屏是每天早会用的，所以信息密度优先，不要放图表装饰。

维修主管：异常派工与闭环

一张整改单列表，默认过滤"待派工 + 处理中"。关键交互是状态流转：指派责任人 → 填写处理措施 → 完成 → 他人验证后关闭。验证人和上报人不能是同一个人，这条规则要在数据层写死，否则闭环会变成走过场。

联查能力很重要：点开一条整改单，能看到它来自哪次点检、当时填的读数是多少、有没有照片；也能看到这台设备历史上所有整改单。反复出现的同一部位异常，说明该修的不是设备而是方案——要么换件，要么改标准。

现场执行人：手机上按项打勾

这是移动端的主战场，单独一节讲。

上线前必查的六件事

构建完成后先别急着发布。用真实场景走一遍，重点核对：

1. 设备主数据是否唯一且稳定。随机抽十台设备，确认编号没有重复、没有"同机两名"。台账脏，后面所有统计都是脏的。
2. 数值型检查项的上下限是否真的填了。留空的上下限等于放弃预警能力，而且会让"超限自动转异常"这类逻辑静默失效。
3. 提交后的记录能否被普通角色修改。用一个测试账号尝试编辑昨天的任务，如果改得动，就把权限收紧。
4. 必填校验在手机上是否生效。故意不填某个检查项就提交，看系统拦不拦。前端拦截和后端校验要同时有——只靠界面提示，绕过一次就永久留下空洞数据。
5. 漏检的判定口径是否明确。"当天没做就是漏检"还是"当班结束前补上不算漏"？这个规则要在计划生成逻辑里说清楚，不然统计出来的漏检率没人认账。
6. 异常上报到整改单的链路是否自动。人工再抄一遍就会断链。理想状态是勾选"异常"并填了描述，系统自动生成一条待派工的整改单，回链到本次任务。

第 4 条和第 6 条是最常见的返工点：前者决定数据可信度，后者决定这套东西能不能长期跑下去。## 移动端：巡检是在车间里完成的

点检的执行现场没有电脑。移动端不是"PC 页面的缩小版"，而是这个模块真正的使用界面。

一次巡检在手机上的走法

1. 打开工作台，看到今天的任务卡片（设备点检 N 项 / 巡检路线 M 条），未完成的排在前面
2. 进入任务，顶部显示设备名称与编号——先核对编号再动手，这一步靠页面把编号做大字显示来强制
3. 逐项打勾或填读数。数值项给数字键盘并即时提示是否超限；需要拍照的项直接调起相机
4. 某项判为异常时，弹出异常描述（必填）+ 严重等级 + 可选照片，提交后自动生成整改单
5. 全部项目完成后点"提交"，任务状态锁定，页面回落到待办列表

区域巡检多一层：按点位顺序推进，当前点位高亮，走完解锁下一个。每个点位可以要求扫码或定位确认到场——这是防假巡检最直接的手段，代价是要配二维码标签，建议只对关键点位启用，全线铺开会招致一线抵触。

弱网与离线

车间信号差是常态。设计时要接受一个事实：现场可能填了但传不上去。可行的处理是把提交动作和保存动作分开——本地先存草稿，网络恢复后再上传，页面上明确显示"已保存/已上传"两种状态。不要假设车间永远有信号，也不要假设工人会记得回办公室补录。

PC 建完，手机自动有

用构建器做这个模块的好处正在于此：数据模型和页面在 PC 端定义，移动端会同步生成对应的任务视图与录入表单，不需要再单独开发一套 App。上线前建议在手机上真机走一遍完整流程（尤其是拍照上传和数值键盘这两处），因为模拟器看不出车间手套操作的手感问题。

能延伸到哪里

点检跑顺之后，同一套数据结构可以往外长：

• 接保养计划：检查项之外加保养项（润滑、更换滤芯），保养工单复用整改单的派工与验证机制，形成"点检—保养—维修"三层
• 接备件消耗：整改单完成时记录用了哪些备件，于是每台设备的耗材成本自然可算，也为"该修还是该换"提供依据
• 接报修入口：让非点检人员也能用手机提报故障，走同一张整改单表，异常来源多一路，闭环逻辑不用改
• 趋势预警：数值型读数的历史序列攒够之后，可以做劣化趋势图（比如振动值连续上升）。注意这依赖前面那条"上下限必须填"的功课，早期就要留好数据
• 交接与看板：班次交接从口头变成系统内确认；车间大屏展示当日完成率与未闭环异常，把管理压力放到明面上

这些延伸都不需要推翻重来，因为它们共用同一批主数据。这也是为什么建议一开始就把设备台账和点检标准做扎实——它们是后续所有能力的地基。

一句收束

设备点检巡检的价值不在于"把纸搬到屏幕上"，而在于让每一次检查都变成一条带时间戳、带执行人、带判定依据的记录，并且让异常必然走向一个结果。做到这一点，漏检率、重复故障、保养超期这些问题才第一次变得可讨论——因为你终于有了可以讨论的东西。