我们扫码报修系统上线之初，只开放了拍照功能。用户扫码后拍张现场照片，配上文字描述，提交工单。当时觉得这够用了——照片比纯文字直观得多，维修工看图就能大致判断问题。

但跑了几个月，发现一个反复出现的问题：照片不够。

照片解决不了的场景

有用户报修说电梯运行时有异响。照片拍了三张，都是电梯门和轿厢的外观，看不出任何异常。维修工到场后，让用户描述声音，用户说"就是嗡嗡响"，具体什么频率、什么时候响、运行到哪一层响，说不清楚。

维修工白跑一趟，第二次带了仪器来测，才定位到导轨润滑不足的问题。

类似的情况还有不少：

  • 设备启停异常：空调压缩机启动时抖一下，照片拍不出来这个"抖"的动作
  • 动作执行不到位：门禁闸机开到一半卡住，照片只能拍到一个半开的状态，看不出卡顿过程
  • 声音类故障：水泵运行噪音变大、风机有周期性异响，这类故障纯靠照片完全没法传
  • 指示灯闪烁：设备面板指示灯闪红灯报错，照片拍出来就是"亮着红灯"，但看不出闪烁频率和模式

这些场景的共同点是：故障信息是动态的，不是静态画面能表达的。

为什么是录像，不是语音或文字补充

有人可能会说，用户多打几行字描述一下不就行了？实际操作中不太现实。

报修场景的用户大多不是技术人员。让他们用文字描述"电机启动时的声音特征"或者"机械臂回零位时的卡顿幅度"，写出来的东西参考价值很有限。语音描述也类似——"嗡嗡嗡""哐当哐当"，维修工听了还是一头雾水。

视频就不一样了。10秒钟的视频能同时携带画面、声音、动作时序三重信息。维修工看到电机启动那一瞬间的抖动幅度，听到异常声音的频率和节奏，基本就能判断是轴承磨损还是联轴器松了。

录像带来的实际好处

减少无效派单

以前只有照片时，维修工看到一张外观正常的设备照片，不确定问题严重程度，往往选择到场查看。结果有三分之一的工单到场后发现是小问题，现场5分钟搞定，来回路上花了一个小时。

有了视频之后，维修工提前看完录像，心里有底了：这个是润滑问题，带个油枪去就行；那个是电路故障，得带万用表。一次带对工具、一次解决的比例明显提高。

支持远程初步诊断

有些单位维修人员有限，不是每个站点都有驻场工程师。遇到故障，先让现场人员拍段视频发过来，远程的工程师看一眼就能判断：这个不用急，下周排计划修；那个得马上处理，有安全隐患。

没有视频之前，远程判断只能靠电话沟通，效率低不说，还容易误判。

留档追溯

视频记录的是故障发生时的真实状态。维修完成后，这段视频就是故障档案的一部分。下次同类设备再出类似问题，翻出历史视频对比一下，很快就能锁定方向。

特别是那些间歇性故障——时好时坏，维修工到场时偏偏正常了。有段故障发生时的录像在手，排查方向就明确多了。

技术实现并不复杂

微信小程序端，拍照用的是 wx.chooseImage，录像用的是 wx.chooseVideo，都是原生API，调起系统相机就行。

主要的考量是文件大小。照片压缩后通常200-500KB，但视频一段10秒也有2-5MB。我们在前端做了两件事：

  1. 限制时长：录像最多15秒，够用就行，避免用户录太长的无效内容
  2. 前端压缩：用 wx.compressVideo 压到720p，文件体积控制在3MB以内

上传走分片逻辑，网络不稳时自动重试。服务端用MinIO存储，数据库里记录文件路径和工单的关联关系。整个链路和图片上传复用同一套基础设施，改造成本不高。

扫码报修系统目前已同时支持拍照和录像：智汇报修