燃气入户安检管理系统：离线优先与隐患闭环的移动巡检实践

去年冬天和一支做城燃信息化的团队吃饭席间有人吐槽甲方验收时只提了一个硬性要求——“安检员站在老小区楼道里没信号也得把这一户给我录完”。这句话基本把燃气入户安检管理系统和燃气设备巡检系统APP的全部难点说透了。这类系统的本质是把安检员每天敲门、亮证、查管道、查软管、查灶具、拍照留证、让用户签字、开隐患整改单这一整套线下动作完整搬到移动端再在后台沉淀成台账、报表、考核数据和可追溯的电子档案。它要解决的不是“能不能记”的问题而是“记得全不全、人到底有没有真上门、隐患开出去有没有闭环、若干年后出了事能不能倒查”这四个问题。我参与过几个类似项目的方案设计和落地陪跑也见过不少花了几十万买回来、最后被安检员扔在抽屉里吃灰的系统。所以下面这篇不聊虚的从前端到后端、从业务建模到离线同步、从派单逻辑到现场防作弊把我认为真正决定这套系统成败的东西拆开讲。适合三类人看正在做这类项目需求的产品和开发、准备上系统的城燃企业运营负责人、以及接外包想少返工的技术团队。哪怕你只负责其中一块也能直接抄走对应章节的参数和表结构。1. 先把业务摸清入户安检到底在管什么做这类系统最容易犯的错是拿到需求文档就开画原型。燃气安检这门生意的业务复杂度远比“一个表单加几张照片”高得多你不把角色的动作顺序和利益关系捋清楚做出来的东西一定会在现场被推翻。我的习惯是先跟车跑三天看安检员怎么敲门、怎么跟用户沟通、遇到不配合的怎么办再回来定数据库字段。1.1 三类角色的真实诉求完全不一样安检员的核心诉求只有一个快。他一天要跑二十到四十户真正在用户家里停留的时间平均不到十分钟。任何多一次点击、多一次键盘输入、多一次等待加载的设计都会被他在实际操作中绕过去。所以APP的现场录入页面必须是“大按钮、少输入、能扫码就不手打、能默认就默认”。我见过一个把隐患描述做成自由文本框的版本结果安检员全填“正常”这个字段等于废掉。班组长/安检主管关心的是任务完成度和真实性。他要看今天派出去的三十单完成了多少、哪些户没人在家需要二次上门、哪些人定位轨迹明显不对、哪些人的单子全是“无隐患”。这类角色是系统使用频率最高的人看板设计要围绕“异常”做而不是围绕“总量”做——总量他自己心里有数他需要的是系统主动把可疑的单子挑出来。运营和安全管理部门关心的则是另外两件事隐患闭环率和数据可追溯。他们要在月度会上说清楚“本月发现重大隐患多少处、整改了多少处、还有多少挂账”也要在外部检查时能拿出某户某年某月的完整安检记录包括照片、签字和安检员信息。这类角色的诉求决定了后台必须有成熟的统计报表和电子档案归档能力而不是只有一堆原始记录。1.2 从纸单到系统价值链条到底落在哪很多甲方自己也说不清为什么要上系统只知道“同行都上了”。真正能说服决策层的价值点其实就三条方案汇报时把这三条讲透比堆一百个功能列表管用。第一是责任落地的证据链。传统纸单最大的问题是可代签、可补填、可事后编造一旦发生事故纸质记录的可信度极低。系统化之后每一条记录都带时间戳、GPS坐标、设备指纹、现场照片和用户电子签名形成完整的证据链。这不是为了追责安检员而是为了保护企业和安检员本人——按规程做了并且有记录和没做性质完全不同。第二是隐患闭环的可管理性。线下安检最大的漏洞是“开了单没人管”。安检员发现软管老化填一张整改通知单给用户用户说“好好好我明天换”然后就没有然后了。系统化之后每一条隐患都是一个带状态的对象从“已告知”到“已整改”到“已复核”全程可追踪超期未整改自动升级提醒这才是安检真正的价值所在。第三是计划与资源的匹配。一个中型城燃企业可能有几十万户居民用户行业通行做法是居民用户一年至少安检一次加上新开户、报修、二次上门工作量非常可观。没有系统排计划全靠人工拉表格哪个片区今年漏检了要到年底才发现。有了系统按片区、按楼栋、按用户类型自动生成年度计划和月度任务漏检率能压到很低。提醒需求调研阶段一定要拿到甲方现行的纸质安检单模板和隐患分级标准。不同企业的检查项、隐患等级定义、整改时限差异很大照着通用模板做出来的系统最后一定被要求大改。2. 系统整体设计与技术选型怎么定这类系统的架构没有太多花样但有几个关键取舍会直接影响后期的运维成本和现场体验。我一般把它切成端、云、管三层移动端负责现场采集和离线缓存服务端负责业务逻辑和数据沉淀管理端负责计划、监控和报表。三层之间的边界要划清楚尤其是“哪些计算放端上、哪些放云上”这个问题。2.1 端、云、管三层职责划分移动端承担的职责比很多人想象的重除了表单渲染它还要管本地数据库、离线队列、照片压缩、定位采集、NFC/扫码识别、签名绘制。核心原则是——凡是现场能算完的绝不留给网络。比如隐患等级判定完全可以在本地根据检查项结果直接算出来不需要请求服务端比如照片压缩必须在端上压完再传指望服务端压缩是给自己找麻烦。服务端负责的是权威数据和跨端协同用户与权限、设备台账、计划生成、工单状态机、同步仲裁、报表聚合。这里有个容易踩的坑——工单状态变更到底以谁为准如果端上和服务端都能改状态冲突处理会非常痛苦。我的做法是状态机只在服务端流转端上提交“动作事件”比如“完成安检”“提交整改”服务端校验后返回最新状态。管理端是给主管和运营看的技术上是独立的前端工程但和移动端共用一套接口。建议管理端的报表查询走独立的只读接口和只读库不要和业务写库混在一起否则月底出报表的时候会把整个系统拖慢。2.2 技术选型的取舍逻辑移动端选型是这类项目第一个要拍板的事。如果甲方只有安卓巡检机、功能集中在表单和扫码跨平台方案足够用开发效率高、一套代码两端跑如果涉及大量NFC读写、蓝牙打印机、深度定制硬件还是老老实实做原生。我经手的一个项目一开始图省事用了跨平台方案结果现场配的是带NFC模块的工业手持机插件兼容问题折腾了快两周最后把NFC那部分单独做成原生模块才解决。后端没有太多讲究关系型数据库MySQL 或 PostgreSQL 都行加内存缓存加对象存储是标配。照片和签名文件一定要放对象存储不要塞数据库也不要直接放应用服务器本地磁盘——前者会把库撑爆后者在扩容和迁移时会要命。消息队列看规模几万户的小项目可以不上几十万户、每天几万条工单的项目同步和报表任务建议走队列异步处理。选型维度推荐方案适用场景主要风险移动端框架跨平台方案纯表单、扫码、拍照类巡检深度硬件外设兼容性移动端框架原生开发NFC、蓝牙打印、定制手持机开发成本高、两端维护本地存储轻量关系型数据库需要复杂查询和统计大数据量下需定期清理文件存储对象存储照片、签名、附件需要单独做访问鉴权和生命周期策略报表独立只读库定时聚合数据量大、报表多聚合延迟需明确时效口径2.3 数据模型里最关键的几张表数据模型设计得好不好直接决定了后期加需求是“改个字段”还是“重构”。这类系统里有四组表是必须想清楚的用户与组织、设备台账、安检任务与工单、隐患与整改。用户和组织要支持多级企业—分公司/片区—班组—安检员。设备台账表要能表达“一户多表、一表多设备”的关系居民用户家里可能有燃气表、灶具、热水器、软管、报警器、自闭阀等多个对象如果按“一户一条记录”设计后面做设备生命周期管理就死路一条。-- 安检工单主表简化版字段按实际业务裁剪 CREATE TABLE inspect_order ( id BIGINT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, -- 工单号端上生成全局唯一 customer_id BIGINT NOT NULL, -- 用户ID plan_id BIGINT, -- 关联计划 inspector_id BIGINT NOT NULL, -- 安检员 order_type TINYINT NOT NULL, -- 1首次 2年度 3复检 4报修 status TINYINT NOT NULL, -- 0待接单 1已接单 2已完成 3已作废 plan_time DATETIME, -- 计划上门时间 arrive_time DATETIME, -- 到场时间 finish_time DATETIME, -- 完成时间 lng DECIMAL(10,7), -- 到场经度 lat DECIMAL(10,7), -- 到场纬度 result TINYINT, -- 1正常 2有隐患 3到访不遇 4拒检 sign_url VARCHAR(255), -- 用户签名文件 version INT DEFAULT 0, -- 乐观锁版本号 create_time DATETIME NOT NULL, update_time DATETIME NOT NULL, KEY idx_inspector_status (inspector_id, status), KEY idx_customer (customer_id) );隐患表要单独设计不能塞进工单的JSON字段里。原因很简单隐患需要跨工单跟踪状态一个隐患可能这周开单、下周整改、下下周复核挂靠在一张工单里就变成了孤儿数据。隐患表至少要有等级、类别、描述、照片、整改期限、当前状态、关联工单、复核记录这几个核心字段。3. 核心功能拆解与现场实操要点功能清单可以列几十条但真正决定系统好不好用的是下面四块计划派单、现场检查项、留证与防作弊、隐患闭环。这四块里任何一块设计得别扭安检员就会用脚投票。3.1 安检计划生成与工单派发的逻辑计划生成看着简单其实是门技术活。最朴素的做法是“按用户表全量生成年度计划平均分配到每个月”但实际操作中会遇到大量问题有的小区整栋楼空置、有的用户常年不在家、有的片区安检员离职导致任务堆积。我的建议是按“片区楼栋”做空间聚合再按安检员的日均产能做均衡。日均产能这个参数一定要让甲方自己填因为差异极大——老城区多层无电梯一天跑二十五户就顶天了新建高层小区电梯直达一天四十户也不稀奇。派单算法上我一般用“片区优先负载均衡”两步先按安检员负责的片区筛任务再按当前在手未完成单量排序取最少的那个。工单派发还有个细节值得说抢单和派单要留个开关。有些企业习惯主管指派有些喜欢安检员自己抢。做成可配置的验收时少扯皮。抢单模式要注意并发用数据库行锁或者带版本号的更新语句处理别出现两个人同时抢到一单的情况。3.2 现场检查项怎么设计才不会被绕过这是整个系统最容易被做废的部分。检查项设计有三条原则我是踩着坑总结出来的。第一能结构化就不要自由文本。比如“软管情况”不要给一个输入框让安检员打字而是给一组选项不锈钢波纹管、普通橡胶管、超长、穿墙、老化龟裂、无管卡。选项化之后数据可统计、可分析、可自动判级。第二选项要带默认值和智能跳转。安检员打开页面绝大部分项都是“正常”那就默认选中“正常”只有异常项才需要展开填写。一个页面从三十次点击降到五次点击体验差别是质变的。第三隐患等级由系统判定不由人判定。安检员只负责勾选现象系统根据预设规则自动给出等级。这样做的好处是标准统一不会出现同一个现象不同安检员给出不同等级的情况。下面这张表是我在实际项目里用的隐患判级参考具体阈值要按甲方标准调整。隐患现象常见判级建议整改时限处理要求软管老化、龟裂、超长超过2米一般隐患7日内告知用户更换留存照片软管穿墙、穿楼板、暗埋严重隐患3日内现场告知并下发整改单灶具无熄火保护装置严重隐患3日内建议停用跟踪整改热水器安装在浴室、通风不良重大隐患立即现场采取停气措施并上报管道私接私改、暗封暗埋重大隐患立即停气处理转稽查流程燃气表锈蚀、铅封缺失严重隐患3日内转维修工单报警器缺失或失效按当地要求一般隐患15日内告知用户自行加装注意涉及停气、限气的动作一定要在系统里做成独立的审批流不能由安检员一个按钮直接执行。这既是管理要求也是免责需要。3.3 拍照留证、电子签名与防作弊设计照片是这套系统里最有说服力的证据也是最容易被造假的证据。我见过最极端的案例是安检员在同一个楼道里连拍十几张不同用户家的照片。所以照片这块必须做三件事。一是压缩。现场拍照原图动辄三到五兆一天四十户、每户五张照片就是几百兆的上传量。端上压缩参数我一般设成长边限制在1280像素、质量75、目标文件大小控制在300KB以内。这个规格打印出来能看清表号和小字同时一天的数据量能压到二十兆左右弱网也能传完。二是加水印。水印内容不要只有时间要包含用户地址、用户编号、安检员工号、拍摄时间、经纬度。水印必须在端上烧进图片像素不能只是显示层的水印否则截个图就能伪造。三是采集约束。关键检查项必须现场拍照不允许从相册选。技术上实现不难调用相机而不是相册选择器即可。有些项目还会加“拍摄时必须有定位且与用户地址距离小于某个阈值比如200米”的校验这个校验要谨慎因为定位漂移在老小区很常见阈值设太小会大量误判我的经验是设500米更稳妥仅作为异常标记而不是硬拦截。电子签名这块用Canvas手写签名生成图片连同签名时间、设备信息一起存。签名前要有一个“本人已阅知上述检查结果”的勾选项这个细节在纠纷时很有用。3.4 隐患整改闭环的状态机设计隐患闭环是这类系统真正的业务核心也是最难做好的部分。核心难点在于整改的主动权在用户手里企业只能催、不能强制。所以状态机要设计得足够细才能表达现实中的各种情况。我的建议是按这几个状态流转已告知 → 待整改 → 整改中 → 已整改待复核→ 已复核关闭中间允许出现用户拒改 → 转稽查、超期未改 → 升级提醒、二次上门不遇 → 挂账这几个分支。每个状态变更都要记录操作人、时间、方式和附件。超期提醒的机制我一般做成三级到期前3天给用户发一次提醒短信或电话记录到期当天给安检员推一条待办超期7天自动升级到片区主管的看板。这个升级链路看起来繁琐但甲方非常看重因为这直接对应他们的安全管理考核指标。4. 移动端实现离线优先是这套系统的命门前面提到的“楼道里没信号也得能录完”说的就是离线能力。老小区地下室、电梯厅、高层设备间全是信号盲区。如果你的APP在这些地方转圈加载安检员当天就会放弃使用。所以移动端的架构必须是本地优先网络只是同步通道不是数据通路。4.1 离线缓存与增量同步的具体做法本地数据库选型上我的经验是数据结构复杂、需要多表关联查询的用轻量关系型数据库Room、SQLite这类只是简单键值缓存用偏好设置或者文件存储就够了。安检场景明显属于前者因为要按状态、按时间、按用户查本地工单。同步策略我一般分三种同步类型触发时机数据范围说明全量初始化首次登录、切片区本人近30天工单用户台账数据量大建议WiFi下进行带进度条增量拉取打开APP、手动下拉上次同步时间之后的变更只拉本人相关数据控制在几百条内增量上传网络恢复、定时任务本地待上传队列按时间顺序串行失败重试增量同步的核心是版本号或时间戳。我倾向于用服务端维护的单调递增序列号而不是时间戳因为时间戳在多服务器部署时容易出现时钟不一致导致漏数据。端上记录一个last_sync_seq每次拉取时带上服务端返回比它大的记录。// 增量拉取接口示例 // POST /api/v1/sync/pull { inspectorId: 10231, lastSeq: 88213, pageSize: 200 } // 返回 { code: 0, data: { nextSeq: 88401, hasMore: false, orders: [ /* 工单列表 */ ], customers: [ /* 关联用户台账 */ ], dicts: { hazardTypes: [], checkItems: [] } } }上传这块要特别注意幂等性。安检员在弱网下反复点提交很容易产生重复工单。解决办法是端上生成全局唯一的工单号设备ID时间戳随机数服务端以工单号做唯一索引重复提交直接返回已存在。4.2 设备标签绑定扫码、NFC 该怎么选燃气设备巡检里给设备贴标签是常见做法标签有两种二维码和NFC。二维码成本低、打印方便缺点是贴在户外容易磨损、被油污覆盖后扫不出来NFC读取快、不怕脏缺点是成本高且部分手机不支持。我的实际建议是户内表具用二维码户外立管、调压箱用NFC。户内环境相对干净二维码够用户外风吹日晒NFC更可靠。标签内容不要只存一个流水号建议存一个带校验位的编码比如前几位表示片区、中间表示楼栋单元、后几位是设备序号最后加一位校验。这样即使断网端上也能做基本的合法性校验。扫码这块有个小技巧老式燃气表上的钢印表号经常被油污糊住OCR识别率很低。与其硬做OCR不如让安检员扫二维码标签或者手输表号后做一次格式校验位数、校验位把错误拦截在提交前。4.3 定位与轨迹采集的策略权衡定位这块甲方的期望值和技术的现实之间经常有落差。甲方想要的是“实时轨迹误差不超过十米”实际能做到的是“关键节点打点精度几十米”。我的做法是不做连续轨迹只在几个关键节点采集坐标接单时、到场时、拍照时、完成时。这样既满足了真实性核验又不会因为持续定位把手机电量吃掉一半。具体参数上定位超时设8到10秒超时就用最近一次缓存位置并标记为“定位失败”定位精度大于100米的坐标不参与“是否到场”的判定只做记录坐标和用户地址的直线距离超过500米时标记为异常单进入主管复核列表而不是直接拦截。这个“标记而非拦截”的思路很重要现场情况复杂硬拦截一定会误伤。5. 后端实现与数据看板的关键点后端这块看起来是常规的增删改查但这类系统有两个地方特别容易出问题一是同步接口的性能二是报表的口径。前者影响现场体验后者影响甲方的信任度。5.1 同步接口设计与并发处理同步接口的特点是小请求、高频次、集中在早晚两个时段。早上八点到九点几十上百个安检员同时打开APP拉数据如果接口里每个工单都去关联查用户、查设备数据库直接就顶不住。优化思路有三条接口瘦身一次同步只返回渲染列表所需的字段详细信息等用户点进去再按需拉取加缓存字典类数据检查项、隐患类型、片区变化频率极低全部放缓存设置合理过期时间批量写入上传接口支持一次提交多张工单服务端用批量插入单条循环插入在几千条数据时会慢到无法接受。冲突处理也得提前想好。真实场景是主管在后台把一张工单改派给了别人而原安检员在离线状态下已经完成了这张单。这时候怎么办我的处理原则是“业务优先于技术”——已经完成的现场记录不能被丢弃所以服务端收到完成事件时即使工单已改派也接受这条记录同时生成一条异常记录推给主管处理。技术上的优雅不如业务上的合理。5.2 报表指标怎么定才有人看报表做了一堆没人看是这类系统的通病。原因往往是指标设计脱离了实际使用场景。我一般只做三层看板每层不超过八个指标。第一层是进度看板给主管看当天计划户数、已完成、到访不遇、待二次上门、完成率。这五个数字每天早上自动推到主管手机上比什么花哨的图表都管用。第二层是质量看板给运营看月度隐患发现率、重大隐患数量、隐患整改率、超期未整改数量、平均单户耗时、异常单占比。其中“异常单占比”这个指标特别能反映问题如果一个班组的异常单比例明显高于其他班组要么是片区特殊要么是数据有猫腻值得去看一眼。第三层是档案看板给安全管理部门用按用户查询历史安检记录、按设备查询全生命周期记录、按隐患查询整改轨迹。这层不需要图表需要的是查询快、导出方便、能打印成规范格式的档案。实践经验报表导出功能一定要做而且要支持Excel和PDF两种。甲方开会要用Excel接受外部检查要用PDF盖章版。这个功能看似小实际是验收时被点名的常客。6. 常见问题排查与上线推广实录系统开发完只是开始上线推广才是真正的考验。我见过太多功能齐全但没人用的系统最后变成“上报数据靠编”的面子工程。6.1 现场高频问题速查表现象可能原因排查与解决APP打开工单列表一直转圈增量同步接口慢或数据量过大检查接口耗时缩小同步范围改为分页照片上传失败率高图片过大、弱网、并发过高端上压缩到300KB内改为串行上传并重试定位坐标全部相同使用了缓存位置或模拟位置关键节点强制重新定位接入模拟位置检测同一工单重复出现上传缺少幂等控制端上生成唯一工单号服务端加唯一索引离线数据同步后丢失本地清理策略过早执行上传成功后再标记删除保留7天回收站隐患等级判定不一致判级规则写在前端规则收敛到服务端统一配置下发扫码识别率低标签磨损、光线不足、镜头脏污补光、清洁镜头、提供手输兜底入口用户签字图片模糊Canvas尺寸设置不当按屏幕密度设置画布分辨率最小800×4006.2 上线推广阶段真正会卡住的三件事第一件是老数据迁移。甲方系统里通常有十几万条历史纸质记录或者老系统数据格式五花八门。我的建议是先做数据清洗模板让甲方自己整理我们只负责导入和校验不要大包大揽。导入时一定要有校验报告把失败的行号和原因列出来否则后期数据对不上扯不清责任。第二件是安检员的抵触。这个必须正面应对。技术上能做的是简化操作、提高速度管理上要做的是让安检员看到好处——比如系统自动统计个人工作量月底结算有据可依再比如不用再手写纸质单、不用回办公室录表。我在一个项目里做过一个小改动APP首页显示“本月已完成XX户累计隐患XX处”安检员自己会看还会互相比较。这种正向反馈比开十次培训会有效。第三件是考核与系统脱钩。如果企业还是按纸质单考核系统里的数据就永远是“第二套账”。上线时必须同步调整考核办法把系统数据作为唯一考核依据这个动作必须由甲方管理层推动技术方推不动。我在方案汇报时会把这一条明确写进去既是提醒也是免责。7. 我在实际项目里的一些体会做了几个项目之后我对这类系统的理解有个明显变化早期我把它当成一个“移动端表单加后台管理”的技术活现在更愿意把它看成一个现场作业的管理工具。技术只占三成剩下七成是把业务规则想清楚、把现场动线设计顺、把考核机制配套上。有个细节我印象很深。某次现场测试安检员完成一单后发现要返回列表还得点两次他当场就说“这个我不录了”。后来我们把提交后的页面做成自动跳回下一单他一天下来多跑了三户。这种改动看起来微不足道但决定了一套系统能不能真正被用起来。还有个反复验证过的经验离线能力一定要在第一版就做进去不要指望“二期再优化”。因为一旦安检员形成了“这系统在楼道里不能用”的印象你后面做得再好他也不会再打开。这个东西没有循序渐进的空间要么一开始就好用要么就没人用。最后分享一个参数上的小建议。如果你的项目涉及几十万户、每天上万单的规模不要在设计阶段就把“实时性”当成硬指标。安检业务对实时的要求其实很低工单晚五分钟到手机完全不影响但若是为了这点实时性把架构做得复杂无比运维成本会翻好几倍。我现在的默认做法是同步间隔设为手动下拉加十五分钟自动触发照片上传走后台队列报表延迟一小时聚合。这套配置在多个项目里跑下来都很稳运维也简单。倒是有一次甲方非要“秒级”结果为了对接消息推送服务光联调就多花了三周最后实际用起来和定时同步没有区别。