举个典型场景：周五下午 4 点，温哥华一家商场的清洁机器人报「定位丢失」，停在走廊中间。这时北京是周六早上 7 点，固件组还没起床；客户的设施经理在电话里只问一句：今天能不能有人来？

派人，一趟上门加路上的时间就是半天工钱；不派，如果只是激光雷达窗口脏了，客户擦一下就好，可如果是雷达本体坏了，机器就要停到下周。更麻烦的是，每多一轮「麻烦客户导一下日志」，都要等对方下班再上班，一轮就是一天。

高仙在自家清洁机器人的服务指南里给过一个数：约 70% 的故障在远程排查阶段就能解决，不需要进入派工流程（原文）。这是一家厂商自己产品的数据，不是行业通用值，但方向很清楚：大多数故障能在远程解决，剩下的少数要上门，而那才是贵的部分。这篇讲两件在出海前、固件阶段就能定下来的事：怎么让大多数故障在远程解决，怎么让少数必须上门的一次修好。附可以直接复制的日志包 manifest 和故障码模板，最后回到周五 4 点那一单，看按这套规则怎么走。

一、日志包规格：让远程工程师第一轮就能下判断

远程工程师（厂商自己的，或者第三方服务商的）接手一台陌生的机器，第一件事都是要日志。下面这张表可以直接当需求提给研发：

字段	要求	为什么
设备身份	序列号、硬件版本、固件/软件版本、地图版本	同一个故障码在不同版本上原因可能不同
故障上下文	故障码 + 前后各 5–10 分钟的电机电流、编码器、IMU、雷达/相机状态	只给故障码，等于只给一个症状
定位与导航	定位置信度曲线、当前地图、上次建图时间	「定位丢失」很多时候是环境变了（货架挪了、装修了），不是机器坏了
电源	SOC、电压、温度、充电对接记录	电源问题涉及安全，先排除
网络	Wi-Fi 信号、AP 切换记录、云端连接状态	北美商业楼宇常做网络隔离，掉线 ≠ 机器坏
时间戳	全部 UTC	跨时区对日志，最常见的错就是时间对不上
导出方式	云端 + 本地（U 盘 / 局域网网页下载）	有的客户 IT 封出站端口或要求数据不出境

落到文件上，大概是这样一个包（数值是建议起点，按自己的传感器调）：

{
  "manifest_version": "1.0",
  "serial": "SN-XXXXXXXX",
  "hw_rev": "C2", "fw": "3.4.1", "map_version": "2026-10-01T18:22:00Z",
  "fault": { "code": "NAV-0312", "first_seen_utc": "2026-10-09T23:04:11Z", "count_24h": 2 },
  "window": { "before_s": 600, "after_s": 300 },
  "files": [
    { "name": "motors.csv",   "rate_hz": 50 },
    { "name": "imu.csv",      "rate_hz": 100 },
    { "name": "loc_conf.csv", "rate_hz": 10 },
    { "name": "lidar_snap/",  "note": "故障前后各 5 帧点云" },
    { "name": "power.csv",    "rate_hz": 1 },
    { "name": "network.log" },
    { "name": "actions.log",  "note": "客户做过的一级操作及结果" }
  ],
  "size_limit_mb": 50
}

压缩后控制在 50MB 以内，是为了能直接作为邮件或工单附件发出去，不依赖任何一家云盘。

设备端有三个细节决定这个包能不能做出来：

• 「故障前 10 分钟」从哪来：常驻一个环形缓冲区（RAM 或 eMMC 上的循环文件），故障事件触发时冻结并落盘快照，而不是事后再去翻全量日志。按上面的采样率估一下存储预算，留出至少 3 次快照的空间，防止连续故障把第一次的现场覆盖掉。
• 隐私脱敏：相机帧和客户地图（本质是楼层平面图）出境前要能处理：帧默认不进包或打码，地图可以只带局部栅格。北美客户的 IT 和安全部门很可能会问这件事，提前做好比现场解释省事。
• 一级操作留痕：客户按说明擦了雷达、重启了，要写进 actions.log，远程才知道「做过了，没用」。

故障码说明同样要英文、要写下一步。只写「请联系厂家」，每个工单都要绕回总部一次。一条故障码说明可以这样写：

code:            NAV-0312
meaning:         Localization confidence below threshold for 30s
customer action: 1) Wipe lidar window with dry cloth  2) Check for moved shelving/obstacles  3) Restart
escalate if:     Recurs twice within 24h after steps 1–3
triage:          self-service → remote → onsite

二、分流规则：给故障树每个分支贴标签

就是上面模板里那行 triage：在故障码表里给每一条标上三种标签之一：远程 / 客户自助 / 需上门，可以是升级链（先自助、不行再上门）。常见要上门的情况：

类别	例子	远程为什么不行
机械磨损	驱动轮、减速器、刹车、关节	要拆装、测间隙
线束与接插件	间歇性断连、接触不良	要现场摇线、测通断，日志里只会看到随机报错
传感器硬件	雷达、深度相机损坏或偏移	要换件并重新标定
电池与电源	充不上电、电池鼓包	安全问题，必须现场判断
环境集成	电梯、门禁、Wi-Fi 漫游	问题在客户楼里，不在机器里

最后一类最容易被低估。电梯对接失败，远程只能看到「呼梯超时」，真正的原因可能是楼宇那边换了网关、权限没迁移。

一条我们建议直接写进 SOP 的规则：同一故障码 24 小时内复现两次，且客户已经做过一级操作 → 直接派工，不要再来一轮远程。

三、派工单：让上门的人第一次就修好

第三方工程师第一次到现场最怕两件事：不知道带什么件，不知道哪些不能拆。派工单至少要有：

1. 序列号、版本、故障码、远程已做过的排查和结果（直接附上面的日志包）；
2. 怀疑部件 + 要带的备件清单（易损件最好已经寄存在客户附近）；
3. 拆装边界：哪些密封件、模块不允许现场拆，拆了影响保修或认证；
4. 修后验收步骤；
5. 回传格式：照片、换下件的序列号、修后测试结果、新的日志包。

第 5 条最常被漏掉。现场回传的数据回到总部，就是下一版硬件和固件最好的输入。

四、故障码表里再加一个标签：射频相关

分批推送、可回滚、作业中不升级、升级前查电量，是 OTA 的基本功。在美国还要多想一步：FCC 2026 年 7 月 28 日的 DA 26-786 把境外生产的先进机器人设备列入受控清单，新型号拿不到设备授权；同日的 DA 26-789 允许 07-28 前已获授权的设备，为「减轻对美国消费者危害」做软件/固件更新（走 Class I/II 许可变更），豁免至少到 2029-01-01；硬件变更仍不允许。落到工程上：在 OTA 发布流程和故障码表里，给涉及射频参数的项单独打一个 rf_related 标签。远程修复如果要改这类参数，先过一遍合规确认再推，不要让售后工程师在现场临时决定。（DA 26-789 原文，以 FCC 原文为准，本文不构成法律意见。）

回到周五下午 4 点

按这套规则，那台「定位丢失」的机器会这样走：故障码说明让设施经理先擦雷达窗口、看看走廊是不是新摆了东西；做完之后日志包自动带上 actions.log 和故障前 10 分钟的定位置信度曲线，第二天早上国内工程师醒来，第一眼就能看出是环境变化还是雷达本体问题。如果是前者，远程更新地图就结束；如果周末内又复现一次，按「24 小时复现两次」直接派工，派工单上写着要带的雷达备件和标定步骤。没有任何一轮「麻烦再导一下日志」。

一页带走

• 日志包：设备身份 + 故障前后上下文 + UTC + 本地导出，≤50MB；
• 故障码：code / meaning / customer action / escalate if / triage；
• 设备端：环形缓冲 + 事件快照，相机帧和地图出境前脱敏；
• 故障树：每条标「远程 / 自助 / 上门」，24 小时复现两次直接派工；
• 派工单：带件清单 + 拆装边界 + 回传格式。

---

作者 KeepRobots，温哥华的机器人现场服务公司，为其他厂商的机器人做北美现场部署、按小时计费的上门维修、预防性维护和备件存放，工程师能读中文技术文档。本文是我们《2026 机器人出海北美：现场服务与售后现状报告》（只用公开资料，每个数字附来源）里「远程 vs 上门」一节的技术展开，报告里还有 5 种北美现场服务模式的对比：https://keeprobots.com/zh/reports/robot-north-america-field-service-2026/