现场调试救火：客户那边板子坏了，怎么远程用 AI 救回来？

凌晨客户电话打来，"你们这批板子全挂了，必须给个说法"。

这种场景的核心矛盾：

你人不在现场

客户没工程师或者工程师水平参差

出问题的板子不是你测试用的那台——可能改过电路、用了不同固件、装在不同环境

时间压力极大，每多一小时停产可能损失几十万

这是嵌入式工程师工作里心理压力最大的场景。

AI 不能替你飞过去看板子。但能让你在凌晨 2 点的电脑前多看到 10 倍信息、少走 5 倍弯路。

一、典型现场场景画像

我整理了远程救火案例，大致分四类：

场景	典型表现	频率
量产现场首发挂	装完产线发现板子起不来	月级
客户使用中故障	用了几周后开始报错	周级
批量异常	同一批次的多台板子表现一致异常	月级
环境相关	仅在客户特定温度 / 电源条件下挂	季级

每一种处理方式不一样。今天讲通用工作流 + 四种场景各自的特化。

二、通用工作流：远程救火的 5 个阶段

T0     接到电话
  ↓
T+15m  建立"数据链路"
  ↓
T+45m  AI 协助快速诊断
  ↓
T+2h   定位根因
  ↓
T+4h   推送修复 / 临时绕过
  ↓
T+24h  事后复盘

我们目标是 80% 的现场故障在 2 小时内有明确方向。

三、阶段 1：接到电话，先建立"数据链路"

这一步是整个救火的胜负点。

错误做法（90% 的工程师第一次都这样）

我：哪里挂了？

客户：板子起不来

我：dmesg 发我看一下

客户：怎么发？

我：（教 ssh）

客户：连不上 ssh，板子起不来怎么连

我：那串口呢

客户：没人会用串口

（半小时过去了，啥信息都没拿到）

正确做法：先建立 正向 数据链路

我们的实际做法：

Step 1.1 客户每个出货板子都预装 "远程救援 agent"

所有出货板子都预装一个 rescue-agent：

启动时尝试连一个 内网 隧道隧道里暴露 SSH（带客户预先签的 key）不依赖客户工程师做任何事

平时不连（ 默认关）。出事时一句话："请打开机柜门，长按按钮 5 秒"——客户的非技术人员都能做。rescue-agent 接到信号后自动建连。

Step 1.2 你这边的 MCP server 自动认识隧道那头的板子

跟 MCP server 那篇 的工具完全一样。

这一步如果做到了：客户按一个按钮，你能从凌晨 2 点的电脑前直接看到 dmesg。

如果没做到：你跟客户工程师远程电话指挥 ssh、复制粘贴 dmesg、几小时打底。

四、阶段 2：AI 协助快速诊断

数据链路建好之后，让 Claude 直接接管诊断：

我：客户的板子全部 boot 失败，看一下 dmesg

Claude：（read_dmesg）拿到 dmesg：

[ 2.341] mmc0: error -110 whilst initialising MMC card
[ 2.342] mmc0: tuning execution failed

是 eMMC tuning 失败导致 rootfs 挂不上。让我看一下相关 sysfs。

Claude：（read_sysfs /sys/class/mmc_host/mmc0/）信号强度记数显示 CRC error 占 30%——比我们出厂测试的典型值 (<1%) 高很多。

Claude：可能性排序：

eMMC 颗粒批次问题（这批板子用了 X 厂的颗粒？）板子供电不稳（PMIC 配置问题？）客户现场温度 / EMI 干扰

建议下一步：

让客户描述现场环境（温度、湿度、附近大功率设备）用 capture_serial 抓 boot log，看 PMIC 初始化时的 voltage 数值跑 mmc-utils 看 health 状态

15 分钟拿到这个分析 vs 自己肉眼看 dmesg 半小时——AI 的"快速排查"价值在这里。

关键 prompt 设计

我们救火专用 prompt 长这样：

你是 <公司名> 资深嵌入式调试工程师。
客户现场的板子出问题了，下面是收集到的信息。

你的任务：
1. 用 5 句话内总结你看到的关键信号
2. 列出可能性排序（最多 5 个），每个带"为什么这么怀疑"
3. 推荐下一步动作（具体到要调哪个 MCP 工具 / 看哪个数据）
4. 估计需要客户配合的事（如果有），用客户能听懂的话写

风格：
- 直接，不要"建议进一步排查"这种空话
- 不确定时明说"我不确定"
- 如果信息不够下结论，明确说"再给我 X 才能判断"

数据：
- dmesg: ...
- sysfs 关键路径: ...
- 客户描述: ...
- 板子序列号 + 出货批次: ...
- 历史 RMA 同类案例（如果有）: ...

关键是最后一项 "历史 RMA 同类案例"——这是出货监控数据的核心价值。AI 看到"过去有 3 例类似的最终是 PMIC 配置问题"，就会先怀疑 PMIC。

五、阶段 3：定位根因

诊断 → 假设 → 验证的循环。

循环示例（接上面 eMMC 案例）

我：让 capture_serial 抓一次冷启动的 boot log

Claude：（power_cycle + capture_serial 30 秒）

Claude：注意到 U-Boot 阶段 PMIC 配置时 LDO_2 (eMMC IO 电压) 设的是 1.85V，但 spec 应该是 1.8V±5%——1.85V 在边界。

Claude：cross-check 出厂测试数据：我们出厂时这台板子（unit_id=...）LDO_2 是 1.81V。现场漂到了 1.85V。

Claude：怀疑：客户现场环境温度可能偏高，导致 PMIC feedback resistor 温度漂移。

我：问客户现场温度

（客户回复：机柜内 42°C）

Claude：跟假设吻合。 我们的 PMIC feedback 电阻是 25°C TC=±100ppm/°C 的低成本档，42°C 漂移 ~0.7%，落在 eMMC IO 容限边界。

临时解决方案：通过 ssh 调整 PMIC 寄存器，把 LDO_2 target 改成 1.78V。 长期解决方案：换更低 TC 的 feedback 电阻，下一批 PCB 修改。

整个定位 1.5 小时。如果是自己排查：

让客户拍照传给我看（半小时）远程电话教客户拿万用表测电压（1 小时）自己 review schematic（半小时）各种猜疑链（几小时）

总共一个晚上是少不了的。

六、阶段 4：推送修复 / 临时绕过

定位出来之后，"修"的方式有几档：

选项 A：远程修配置（最理想）

我：把所有 5 台板子的 PMIC LDO_2 改成 1.78V
Claude：（每台板子依次 write_sysfs PMIC 寄存器，需要 approval）
       （需要 approval 5 次，因为破坏性操作）
我：批准 ×5
Claude：完成。重新 read_dmesg：5 台板子全部 boot 成功，eMMC CRC error 降到 <0.1%。
       建议保留这个 fix 30 分钟，观察稳定后再撤掉远程链路。

这是 MCP 在现场救火里最高光的时刻——5 台板子的临时修复用 10 分钟搞定，传统电话指挥客户做这件事至少半天。

选项 B：推送 OTA 固件更新

如果是软件问题，准备一个 hotfix 镜像，让客户的 rescue-agent 拉下来执行 OTA。

我们的设计：

hotfix-2026-05-13.tar.gz
├── manifest.json   # 元数据 + 签名
├── patches/        # 内核 / userspace patch
└── rollback.sh     # 失败回滚脚本

rescue-agent 验证签名 + 跑 patch + 跑 self-test + 不通过自动回滚。

选项 C：客户在现场拆板换件

实在不行只能让客户拆。这种情况 AI 帮的是写"拆装 SOP"——让 Claude 看着 schematic 和现场照片，写一份步骤化、有图示、客户能照做的文档。

选项 D：发工程师飞过去

AI 救不了的情况：

硬件物理损伤（飞线断了、焊点裂了）环境舱 / EMC 测试需要的现场仪器客户那边谁都不让动

这种情况 AI 还能做一件事：写一份"派工程师过去之前必须带的工具 / 必须问清楚的事 / 必须准备的备件"清单。

七、阶段 5：事后复盘

复盘 1：让 AI 写事故报告

Prompt:

写一份事故报告。
事件：客户凌晨 5 台板子 eMMC tuning 失败 boot fail
处理时间线：见附件 MCP 操作日志
根因：PMIC LDO_2 在高温下漂出 eMMC IO 容限
临时修：远程改寄存器目标值
永久修：下一批 PCB 换 feedback 电阻

报告要求：
- 5 分钟内能读完
- 包含：现象 / 根因 / 处理 / 影响 / 后续
- 给 RD、QA、PM 三个版本（同一事件不同视角）

复盘 2：回灌到知识库

这次的故障模式（PMIC 温漂导致 eMMC 容限）要灌进数据库。下次出货验收的 AI 就能查到"曾经有过这类故障"。

复盘 3：更新出厂测试

加一个 case：在 45°C 测 PMIC LDO_2 输出电压。这次没测到，下次必须测到。

复盘 4：跟客户对齐

工程师飞过去会议（或视频会议），把"是什么 / 怎么修 / 下一步" 讲清楚。AI 帮你写讲稿。

八、四种典型场景的特化

通用工作流之外，四类常见场景各有特殊处理：

场景 A：量产现场首发挂

特征：客户产线刚开始装这批板子，第 1 台就挂或良率异常低。

优先怀疑：

装配工艺（焊接、装夹）测试夹具你这边和客户用的固件版本不一致出厂前 vs 客户场景的环境差异

AI 帮的：让 AI 对比"你出厂测试结果"和"客户产线测试结果"的差异，找出测了但你那边没测的指标。

速度要求：极快，因为产线停摆每分钟都是钱。目标 30 分钟内给方向。

场景 B：客户使用中故障

特征：板子已用了几周/几个月，开始报错。

优先怀疑：

元件老化（电解电容、连接器）软件 bug 在长期运行后暴露（内存泄漏、文件系统满）客户环境变化（季节温度、电源波动）

AI 帮的：让 AI 看长期日志（不是这一刻 dmesg，是过去 N 天的日志）找 trend。

速度要求：中等。客户能等几小时到一天。

场景 C：批量异常

特征：多台板子同时挂，或同一型号挂的占比异常高。

优先怀疑：

同一 PCB 批次的工艺问题同一元件批次的来料问题同一固件版本的软件 bug

AI 帮的：交叉查 batch_meta，找出"挂的板子有什么共同点"。

速度要求：1-4 小时。关键是控制扩散——可能要紧急召回未发出的同批次。

场景 D：环境相关

特征：实验室测好好的，到客户现场就挂；客户高温/低温季节性故障；特定客户挂别的客户不挂。

优先怀疑：

温度漂移（PMIC、晶振、电阻）电源质量（输入波动、地噪声）EMI / EMC 干扰海拔 / 湿度

AI 帮的：让 AI 对比"实验室测试条件"和"客户现场环境"的所有差异，按"可能影响哪个芯片"的方式排序。

速度要求：低，因为这类问题往往是顽固的、需要工程师到现场。目标是"派去的工程师带对工具"。

九、几个案例

案例 1：凌晨救火

凌晨客户电话：8 台板子 boot fail。

工作流：

02:47 接电话02:55 让客户按 SVC 按钮，rescue-agent 上线03:10 Claude 看完 dmesg + 出厂测试对比，怀疑 eMMC03:30 power cycle + 抓 boot log，怀疑 PMIC LDO_2 高温漂移03:50 客户证实机柜内 42°C04:05 远程改 PMIC 寄存器，8 台板子全恢复04:20 跟客户对齐"这是临时方案，下批 PCB 会改电阻"04:30 写事故报告04:35 睡觉

1 小时 48 分。

案例 2：AI 误判导致弯路

客户报 4G 模组不上线，AI 看完一堆数据后判断"是 modem 固件 bug"，建议升级模组固件。

升级完没好。

再排查发现是客户机柜屏蔽过度，4G 信号收不到。AI 看不到电磁信号。AI 的诊断只在它能拿到的数据范围内可靠。物理世界的事，永远要先排除物理因素。

案例 3：客户工程师水平参差

凌晨救火时跟客户工程师电话，对方水平不一定够。

让 AI 用客户能听懂的话写指令：

Prompt:
我需要客户工程师做：
1. 打开机柜门
2. 长按 SVC 按钮 5 秒
3. 等 60 秒
4. 告诉我板子上 LED 的状态

请你写一份对方一定能听懂的指令。客户工程师水平：高职毕业、能开电脑、不熟 Linux。

AI 写出来的指令往往比工程师自己说的清楚——因为工程师习惯用术语。

案例 4：客户不让动板子

高保密客户：板子在他们机房，rescue-agent 都不让装。

这种情况我们的做法：让 AI 写"现场操作 SOP"，客户工程师照做、把每一步的输出发我们。

不如 MCP 直连快，但比啥都没有强。一次客户拍照、传 dmesg 截图、跟我们 AI 配合 4 小时定位问题，对方很满意。

十、几条绕不开的红线

红线 1：客户授权之前，永远不要动客户的板子

哪怕 rescue-agent 在跑、哪怕你有 ssh 权限，操作之前必须客户口头授权。

红线 2：救火操作必有审计日志

每个 MCP 调用记录："谁、在哪台板子、什么时间、做了什么、结果"。

万一事后客户那边有问题，你能拿出完整的操作记录证明你的行为。

红线 3：临时 fix 必有过期日期

远程改 PMIC 寄存器属于临时 fix。不能让这个 fix 永远在那儿——必须写明"30 天内必须有永久 fix"。

我们的做法：rescue-agent 里加一张"临时 fix 清单"，每天提醒 RD 还没销账的 fix。

红线 4：救完火必须复盘

救火只解决"症状"，不解决"系统问题"。复盘解决系统问题。

硬性规定：重大救火事件不复盘，下次出货评审不签字。

红线 5：AI 不能代替人跟客户对话

AI 帮你写脚本、写 SOP、写事故报告。但跟客户的关键对话必须人来——尤其是"这是我们的责任"、"我们会赔"这种话。AI 不能担责。

十一、把救火能力做成"基础设施"

远程救火不应该是"靠某个 senior 工程师 24/7 守着"，应该是团队级的基础设施。

具体包括：

件套	投入	价值
rescue-agent（板子端）	1 人月开发 + 持续维护	出货板子默认能远程救
MCP server + 救火 prompt	1 人月 + 前面文章 已有	救火操作快 5-10x
数据湖 + RMA 关联	出货验收 那套	AI 诊断有历史依据
现场 SOP 模板库	持续积累	客户工程师能自助处理简单问题
oncall 轮值 + 培训	持续	不靠某一个人
复盘机制	每次救火 + 季度总结	救火越救越少

做齐这 6 件，救火响应时间从"几小时到一天" 降到 "半小时到 2 小时"。客户满意度直接翻倍。

十二、写在最后

AI 是把嵌入式工程师的工作"系统化"的杠杆。

整个团队的工程能力变成"复利累积"——而不是过去那种"靠老师傅经验、人一走全归零"。

这才是 AI 时代嵌入式工程的真正变化：不是"AI 写代码"，是"AI 让团队的知识可累积"。

会用 AI 的工程师值钱。会把团队改造成 AI 友好的 leader 更值钱。

凌晨 2 点接电话救火，是嵌入式工程师的常态。但有没有这套基础设施，决定你是 1 小时搞定还是熬通宵。