过去做内核升级验证，我经常被反复断电、重启、刷系统和逐步与大模型交互困住。把这段流程自动化之后，最明显的变化是省下了大量需要守在设备旁的时间，终于能腾出手做其他事情。感谢小米提供的 Home Assistant 集成，让接入设备的控制能力能够被 AI Agent 调用。下面分享真实接线、执行步骤和踩坑经验。
最初的目标，是让大模型参与系统内核升级后的验证，并能根据真板结果继续推进下一轮迭代。卡住这件事的，常常是物理操作：手动断电、重新上电、进入烧录模式，再把启动日志和测试结果交给大模型。人不得不在电脑与开发板之间反复接力。我们通过 Home Assistant 与米家打通电源控制，再把串口、镜像写入和验证串入 Skill，让数字世界的指令能够控制真实硬件的通断，并接收硬件反馈。
这篇文章面向希望把大模型接入真实开发板验证流程的开发者。案例使用 Mac mini、RDK X5、独立 SD 卡、串口和米家可控电源。目标是减少频繁拔电重启和逐步向大模型下达操作指令，让已授权的内核升级验证流程连续执行。本文记录 2026 年 9 月 20 日的现场经验，区分已经完成的实测与可复用的迭代机制。
图：基于两张现场实拍制作的说明海报，AI 辅助排版。接口、器件细节以文末原始照片为准。
三根线，把执行和反馈接到真实硬件
板卡照片底边从左到右，是黑色供电线、白色 Type-C 闪连线和白色 Micro USB 串口线。
| 线路 | 连接到哪里 | 在闭环里做什么 |
|---|---|---|
| 黑色供电线 | 可控电源 | 给板卡供电，执行上电、断电和冷启动 |
| Type-C 闪连线 | Mac mini | 在 USB UMS 模式下传输系统镜像 |
| Micro USB 串口线 | Mac mini | 查看启动日志、拦截 U-Boot、输入命令、验证登录 |
Mac mini 是执行 Skill 的开发主机；RDK X5 是接收镜像并运行待验证系统的目标板。电源设备没有出现在这两张照片中，因此图中只标明控制关系。Home Assistant 和米家负责电源开关，镜像数据走 USB，两者承担不同任务。
Home Assistant 与米家：补上物理通断这一环
原来的操作记录来自 WorkBuddy：通过 Home Assistant 的 Xiaomi Home 集成，把米家设备的指定电源端口暴露为一个 switch 实体，再由 Agent 调用开关服务。新 Skill 保留这一结构，将账号、令牌和设备标识改为运行时配置。
首次搭建时，要先在米家中确认设备在线，再按 Xiaomi Home 官方集成说明完成 Home Assistant 接入。对于本案例的 macOS 主机，Home Assistant 运行在 Colima 提供的 Linux 容器环境中。完成后，先人工核对开关实体与物理供电端口，避免控制错设备。
开关操作使用明确的 turn_on、turn_off，并查询结果；不使用状态不明的 toggle。HA 显示 on 只是控制链路的一条证据，还需要串口出现启动日志，才能确认板卡实际启动。
正常断电也有步骤：Linux 能响应时，先执行 sync; poweroff，在串口看到 Power down 后，再关闭对应电源端口。只有 SSH 断开，不能证明关机完成。冷启动需要确认断电后等待至少 5 秒，再重新上电。写入和回读期间保持供电。
参考：Xiaomi Home 官方集成、Home Assistant REST API、Colima。
把镜像部署接入验证循环
本案例使用 115200、8N1 串口参数。打开串口后，在启动倒计时阶段中断自动启动，停在 Hobot>。先核对介质，再进入 UMS：
Hobot> mmc list
Hobot> mmc dev 1
Hobot> mmc info
Hobot> ums 0 mmc 1
这里的 MMC 索引 1 是本次 X5 的 SD 卡，不能直接套用到其他板型和介质。UMS 是 USB 大容量存储模式：它把板端 SD 卡导出为主机能访问的磁盘；这条命令本身还没有写入系统镜像。
Mac 识别到新磁盘后，使用 diskutil list external physical 和 diskutil info 核对：它必须是外部 USB 整盘，名称、精确字节容量与本次目标卡一致。磁盘编号会变，不能把历史的 disk4 当成固定目标。
写完还不够，要完整读回来
Skill 中的 flash_macos.py 默认只生成只读检查计划。正式写入需要明确的目标身份、可信镜像 SHA-256、写入参数和管理员权限。需要保留的数据应先完成备份；写入会覆盖目标卡上镜像覆盖范围内的数据。
执行阶段依次完成：核验镜像 → 重新核验磁盘 → 卸载目标已挂载分区 → 写入镜像 → 同步 → 按镜像精确字节长度完整回读 → 比较 SHA-256。
本次镜像约 10.39 GB。现场写入约 24 分钟，最终完整回读约 16 分钟；这是一次设备组合的实测耗时，不是速度承诺。
过程中还遇到了一个值得记录的问题：首次回读哈希不一致，观察到 Mac 在写入后自动挂载 CONFIG 分区。比对发现局部 FAT 区域发生变化。保存证据、卸载并恢复对应块后，再次全量回读才通过。不能因为系统“看起来能启动”就跳过不一致。
新脚本将这一经验收敛为可选、有限的恢复：只有捕获到写后挂载、全量差异均落在允许的 FAT 范围、重复读取稳定且差异量受限时，才允许单次恢复；随后仍须重新完整回读。条件不满足就停止诊断。
真实启动与功能结果，反馈给下一轮分析
完整回读通过后，确认没有读写进程，再退出 UMS。若验收要求冷启动，执行已授权的断电、等待、上电，用被动串口记录完整启动过程。
验收分三层：
- 镜像层：目标身份正确，写入与完整回读一致。
- 启动层：U-Boot 到内核再到 Linux 登录，检查内核版本、根分区、boot ID 和 LED 状态。
- 功能层：逐项测试网络、编解码、BPU 兼容路径及目标外设，保留失败与未测项。
本板启动到了 Ubuntu 22.04.5 / Linux 6.18.0，完成两次冷启动复核。串口、临时 USB 网络 SSH、heartbeat LED 亮度交替、H.264/H.265/JPEG 各 100 帧样例，以及文件读写和 CAN 内部环回等基础测试通过。
BPU MobileNetV2 跑通的是旧闭源模块兼容路径，记录为 PASS-WAIVER，不能据此宣称原生 Linux 6.18 支持或模型精度验证通过。现场仍有 3 个失败服务；Wi-Fi 联网、HDMI 实屏、摄像头和长期稳定性等尚未完整验证。因此结论是功能测试版的分项验证，不是全功能生产验收。
从一次操作，沉淀为大模型可复用的执行闭环
rdk-x5-usb-flash 包含入口说明、电源助手、串口 UMS 助手、macOS 写盘与完整回读助手，以及部署、恢复、验收和来源文档。它把“下一步做什么”与“凭什么进入下一步”写在一起。
把整个目录放入 Agent 的 Skill 目录，例如 ~/.codex/skills/，阅读 SKILL.md 后，可这样调用：
使用 rdk-x5-usb-flash，先核对我的电源端口、串口、SD 卡和镜像，再按已授权的范围完成 USB 烧录、完整回读和冷启动验证，保留失败项。
原现场流程已在真板执行；新封装助手通过了 19 项模拟/临时文件测试及串口伪终端冒烟测试，尚未用这套新助手在真板完整重跑。这两个验证范围需要分别记录。
完整目标是：大模型分析内核升级任务 → 形成待验证的内核与镜像 → Skill 控制物理通断、部署和冷启动 → 采集串口日志与功能结果 → 大模型据此分析问题、决定下一轮修改与验证。Home Assistant 和米家让电源操作进入软件流程，串口让真实硬件状态返回数字世界，二者共同连接起执行与反馈。已有授权和明确设备绑定后，不必每一步都让人拔电或重复发指令；发现无法解释的异常、新的破坏性范围或需要人工接线时再停下。当前 Skill 提供这条链路中的硬件执行与验收能力，内核修改、编译和镜像构建由上游开发任务承担；尚不能宣称已经验证了任意内核问题的无人值守自动修复。
图：开发主机原始照片。
图：板卡与三根连接线原始照片。供电线接电源，其余两根接 Mac mini。
下载与复现
下载 Skill v1.0.1（含操作手册、助手脚本与测试）
解压后先阅读 SKILL.md，再按 references/home-assistant-mijia.md 配置电源，按 references/usb-flashing.md 执行逐阶段检查。镜像、令牌、密码和个人 HA 配置不包含在包内。
版本 1.0.1 优化了内核升级验证闭环的定位与执行边界，脚本实现沿用前版。
ZIP SHA-256：db1aa6beec3b2e6241128bf4ddcc06dbdf7f12dfec3104d5fa09ba6beb8df84b