让 AI 接上串口、电源和刷机口：一个嵌入式自动救援工位的落地设想

👁 349

1. 为什么不是做人形机器人？

一开始很容易想偏：既然要让 AI 进入物理世界，那是不是该做一个会走路、会拿电烙铁、会插线的人形机器人？

想法很酷，但对嵌入式救砖这件事来说，性价比并不高。

真正高频的问题通常不是”芯片烧了需要换料”，而是：

• 设备启动失败，看不到系统。
• 固件刷坏，卡在 Bootloader。
• SSH 连不上，只能看串口。
• 设备树、驱动、网络配置出了问题。
• 想进 USB 刷机模式，但需要断电、按键、上电配合。
• 修复前后需要反复看日志、重启、验证、回滚。

这些动作不需要一个人形机器人。更靠谱的形态是一个固定在桌面上的自动化工位：板子放进夹具，AI 通过串口、SSH、USB、电源控制、电流监控和摄像头来判断状态，再调用受控工具执行恢复。

简单说：

不要先做”会修板子的人形机器人”，先做”能稳定救一块板子的 AI 工位”。

2. 这个工位到底是什么？

它可以理解成三部分：

AI 大脑

负责读日志、分析故障、生成修复计划。

但它不能直接乱敲命令，也不能直接拿 root 权限乱刷机。AI 的输出必须经过本地工具层检查，危险操作还要人工确认。

受控执行器

负责真正操作设备，比如：

• 读取 TTL 串口日志。
• 执行 SSH 诊断命令。
• 控制继电器断电、上电。
• 触发 USB 刷机流程。
• 保存备份和操作审计日志。
• 在失败时执行回滚。

物理工位

负责稳定连接现实设备，比如：

• 固定开发板的夹具。
• Pogo Pin 探针接触 TTL、BOOT、RESET、JTAG/SWD 测试点。
• USB、电源线的导向插拔机构。
• 摄像头观察指示灯、屏幕、线材状态。
• 电流/电压模块监控上电过程。

核心原则是：AI 负责判断，本地工具负责执行，安全系统负责拦截。

3. 不要只靠 SSH 和 TTL，要做分层救援

如果系统正常启动，SSH 最舒服；如果系统没起来，串口最有用；如果 Bootloader 也坏了，就要考虑 USB 刷机模式；再往下才是 JTAG/SWD 或编程器。

所以第一版设计里，不应该把所有希望压在一条通道上，而应该按故障深度逐层下探。

T0：SSH 通道

适合系统还能启动的情况。

可以做：

• 查系统日志。
• 修服务配置。
• 检查驱动模块。
• 安装缺失依赖。
• 修改普通配置文件。
• 重启服务或重启系统。

这一层最安全，也最适合自动化。

T1：TTL 串口通道

适合系统启动失败，但 Bootloader 或内核还有输出的情况。

可以做：

• 读取 U-Boot 日志。
• 读取 Kernel Panic。
• 中断自动启动。
• 修改临时启动参数。
• 从 TFTP/USB 启动恢复镜像。

串口是嵌入式设备的救命线，但它不是万能的。如果 Bootloader 自己也损坏，串口可能只能看到很少信息，甚至完全没输出。

T2：USB 刷机通道

适合 Bootloader 损坏，或者需要进入芯片底层恢复模式的情况。

不同平台叫法不同，比如：

• Allwinner 常见 FEL。
• Rockchip 常见 MaskROM / Loader。
• Android 设备常见 Fastboot。
• 部分 Qualcomm 平台有 EDL。

这里必须强调：这些模式高度依赖芯片、板型、启动配置和工具链，不是所有设备都能无脑强刷。

所以第一版不要追求通吃所有芯片。选一块固定目标板，先把一种 USB 恢复链路跑通。

T3：JTAG/SWD/eMMC 编程器

这是更底层的恢复方式，适合启动链严重损坏时使用。

但它对接线、板型资料、权限和工具链要求更高，不建议放进第一版 MVP。可以作为后续增强。

T4：人工维修

如果是芯片烧毁、PMIC 损坏、虚焊、断线、Flash 物理坏块严重，那就不是 AI 工位能直接解决的问题了。

这时系统应该停止自动操作，保存证据，提示人工介入，而不是继续瞎折腾。

4. 视觉和电流监控为什么重要？

只看串口和 SSH，AI 仍然是半个”盲人”。

现实中经常会遇到这种问题：

• 电源线没插好。
• USB 没枚举。
• 板子反复重启。
• 指示灯已经提示错误，但日志没记录。
• 屏幕卡在 Logo。
• 串口线接反或波特率不对。

所以工位需要给 AI 补上现实感知。

摄像头能做什么？

摄像头不是为了炫技，而是做二次确认：

• 看电源灯是否亮。
• 看状态灯闪烁规律。
• 看屏幕是否卡在启动画面。
• 看板子是否放歪。
• 看线材是否明显没插好。
• 看探针是否压到位。

这些信息不一定要全靠大模型判断。很多场景可以先用简单规则处理，比如灯亮/灯灭、画面变化、二维码/标签识别。

电流/电压监控能做什么？

电流曲线很有价值，因为设备启动时的功耗变化会暴露很多状态。

比如：

• 电流一直为 0：可能没供电、开关没开、线没插好。
• 电流瞬间冲高后掉下去：可能短路保护、启动失败或电源不足。
• 电流周期性波动：可能反复重启。
• 电流稳定但无日志：可能卡死、串口配置错或系统没有输出。
• USB 枚举出现又消失：可能在反复进入/退出刷机模式。

这里不建议一开始就”把波形图直接扔给大模型”。更靠谱的做法是本地先提取特征：

• 峰值电流。
• 平均电流。
• 上电到掉电的时间。
• 重启周期。
• USB 枚举时间点。
• 串口日志停止时间点。

然后再让 AI 把这些特征和日志放在一起分析。

5. 物理执行层：机械臂不是第一选择

自动插拔线是可以做的，但不要想成”机器人像人一样自由插线”。

更靠谱的方式是：机械做大动作，治具做精定位。

最适合第一版自动化的动作

• 继电器断电、上电。
• 舵机或小推杆按电源键。
• 舵机按 BOOT / RESET 键。
• 固定导向槽里的 USB 插拔。
• 固定导向槽里的 DC 电源插拔。
• Pogo Pin 下压接触 TTL、BOOT、RESET 测试点。

不适合第一版自动化的动作

• 临时杜邦线接小针脚。
• FPC 排线插拔。
• 小焊盘飞线。
• 精密焊接。
• 拆换芯片。

工业里更常见的做法是做测试治具：板子放进去，定位柱卡住，探针下压，所有调试点一次接通。

这比机械臂拿线去找针脚稳定得多。

6. 安全机制：不能让 AI 裸跑 root

这类系统最大的风险不是”AI 不够聪明”，而是”AI 太敢动手”。

所以安全机制必须从第一天就设计进去。

只读诊断模式

默认只能读取信息：

• 读串口。
• 读日志。
• 读分区信息。
• 读设备树。
• 读电流曲线。
• 读 USB 枚举状态。

只读模式下，AI 可以生成建议，但不能直接修改设备。

人工确认写操作

涉及以下动作必须确认：

• 刷固件。
• 改分区。
• 写 Bootloader。
• 改设备树。
• 删除关键文件。
• 重启到恢复模式。
• 切换启动分区。

工具沙箱

AI 不能直接执行任意 Shell。

它只能调用固定工具，比如：

• read_serial_log()
• power_cycle()
• enter_recovery_mode()
• backup_partition()
• flash_image()
• verify_boot()
• rollback_to_golden_image()

每个工具内部做参数检查、板型检查、路径检查和权限限制。

板型 Profile

每块板子都要有自己的 Profile，记录：

• 串口波特率。
• 电源参数。
• USB 刷机模式。
• BOOT/RESET 测试点。
• 分区布局。
• 固件版本。
• 允许操作的白名单。
• 禁止操作的黑名单。

没有 Profile 的板子，默认只能只读诊断，不能自动写入。

备份与回滚

任何写操作之前，都要先备份。

如果重启后在规定时间内没有看到成功启动标志，系统应该自动判定失败，然后：

• 停止继续写入。
• 保存日志。
• 切回 Golden Image。
• 或等待人工确认。

不要为了”自动化”牺牲可恢复性。

7. 第一版 MVP 应该怎么做？

不要第一版就做全平台、全芯片、全自动。

最靠谱的 MVP 是：

只选一块固定开发板，跑通一条完整救援闭环。

阶段 1：基础网关

目标：让 Agent 能看见设备、控制设备。

实现：

• TTL 串口采集。
• 电源继电器控制。
• SSH 连接。
• 日志保存。
• 简单 Web 界面或命令行界面。

这一阶段先不追求 AI 很聪明，先把数据采集和控制链路做稳。

阶段 2：单板型恢复

目标：选一块固定板子，跑通救砖流程。

实现：

• 建立板型 Profile。
• 准备 Golden Image。
• 接入 USB 刷机工具。
• 支持断电、按键、上电组合。
• 支持刷写后自动验证启动。

这一阶段做出来，就已经有实际价值了。

阶段 3：安全 Agent

目标：让 AI 参与诊断，但不越权。

实现：

• AI 读取串口和系统日志。
• AI 生成修复计划。
• 本地工具检查计划。
• 高风险动作人工确认。
• 执行后生成审计报告。

阶段 4：多模态增强

目标：让系统不再只看文本。

实现：

• 加电流/电压监控。
• 加 USB 枚举状态记录。
• 加摄像头。
• 把电流特征、画面状态、串口日志按时间线对齐。

阶段 5：治具化

目标：减少人工插线，提高重复性。

实现：

• 设计板子固定夹具。
• 使用 Pogo Pin 接触测试点。
• 用舵机/步进电机完成压合。
• 用导向槽完成固定方向的 USB/电源插拔。

8. 一个实际工作流程

假设有一块开发板启动失败。

工位可以这样工作：

1. 用户把板子放入夹具。
2. 工位压下 Pogo Pin，接通 TTL、BOOT、RESET。
3. 工位上电，开始记录电流和串口日志。
4. AI 判断系统卡在 U-Boot 还是内核阶段。
5. 如果系统能进 SSH，优先走 SSH 修复。
6. 如果 SSH 不通，但串口可用，尝试 U-Boot 恢复。
7. 如果 Bootloader 异常，提示进入 USB 刷机模式。
8. 用户确认后，工位断电、按住 BOOT、上电。
9. 检测 USB 是否枚举为刷机设备。
10. 备份可读分区，刷入 Golden Image。
11. 重启后验证串口成功标志和电流曲线。
12. 成功则生成报告，失败则回滚或停止等待人工介入。

这就是一个最小但完整的闭环。

9. 这东西真正有价值的地方

它不是替代硬件工程师。

它更像一个不嫌烦的工程助理，帮你做这些重复工作：

• 反复上电断电。
• 抓启动日志。
• 比对错误信息。
• 执行标准恢复流程。
• 记录每一步操作。
• 失败后回滚。
• 把过程整理成报告。

真正值钱的不是”AI 会说话”，而是它把工程师脑子里的救砖流程变成了一个可重复、可审计、可回滚的自动化系统。

10. 结语

这套方案不需要一开始就做成人形机器人，也不需要堆一堆听起来很玄的 AI 名词。

它的核心很朴素：

给 AI 一个受控的工作台，让它能看日志、看电流、看画面、控电源、进刷机模式，并且在安全边界内执行恢复。

第一版只要能稳定救一块固定开发板，就已经不是 PPT 了。

后面再慢慢扩展更多板型、更多刷机模式、更多传感器和更完整的治具。

别先造钢铁侠实验室。

先造一个能救活一块砖的 AI 小工位。