从 AI 写固件
到 嵌入式 AI 工作流

事实先查，关键取舍明确到人

AI 应先阅读链接脚本、当前固件的 map 文件、BSP 与启动配置，查明镜像大小、存储布局、看门狗和配置写入路径。需要核对器件手册的内容，应记录型号与文档版本。

下载期间允许增加多少抖动、重启能否暂停采样、断网是否影响健康确认、现场失败由谁恢复，这些需要产品、固件和测试负责人共同确认。已经确认的决定进入记录，未知项保持显式状态。

R3 与维护窗口必须一起写。本案例要求下载期间保留采样；安装和重启允许在维护窗口暂停采样。如果硬件擦写限制使下载目标不可达，需要调整存储方案或重新约定行为，并将决定回写需求。

最小 Skill：grilling 的嵌入式用法

沿着决策依赖澄清：先确定设备和存储事实，再讨论采样与停机，最后确定健康条件和现场恢复。每个问题带上已有证据与建议，避免把代码检索工作转交给负责人。

先检查目标板、链接脚本、Bootloader、现有固件大小与配置路径。
区分：已证实的事实 / 待验证的假设 / 需要负责人的取舍。
按依赖顺序澄清下载时序、维护窗口、健康确认与恢复责任。
对每个尚未决定的关键取舍给出建议和依据，再等待对应负责人确认。
把结论写成带编号的可观察规则，保留未知项和范围外事项。
已有决策直接复用；关键取舍未解决的部分，不进入依赖它的实现。

先核验平台，再决定升级模式

核对可用 Flash、擦写粒度、地址对齐、执行与读写限制，以及候选镜像的最大容量。分区预算必须覆盖镜像头、签名或校验元数据、状态尾部和实际算法需要的临时空间。检查链接脚本与打包工具是否使用同一份布局。

本案例选择已经验证支持试启动与失败回退的启动方案作为前提。双镜像存储本身不能证明具备回退能力，单纯覆盖原镜像的策略也不能凭空保留旧镜像。以 MCUboot 为参考时，应按实际模式核对试启动、确认和复位后的行为。见 MCUboot 启动与试启动设计。

板型判断需要自己的可信约定：把硬件标识纳入受签名保护的元数据，明确由哪一层强制核验。选择了某个 Bootloader，并不自动获得项目特有的板型、网关或配置兼容策略。

状态表必须写出复位后的行为

1. 01 下载中写候选区
2. 02 候选已验证等待维护窗口
3. 03 待试启动受控切换
4. 04 试运行健康检查
5. 05 已确认正常运行

持久化顺序需要写清“写数据、验证数据、提交进度”的完成点，并考虑提交记录本身被掉电打断的情形。根据存储介质选择校验、版本号或冗余记录，启动时只相信可验证的状态。

健康检查也要有具体定义：关键采样任务是否持续推进，必需外设是否可用，配置是否能读写，必须的通信功能是否正常。是否要求远端在线属于产品决策，不能让一次普通断网无意中触发持续回退。

最小 Skill：to-spec 的嵌入式用法

1. 目标与范围：R1–R5、板型、现有固件和明确不做的事项
2. 平台约束：Flash 布局、链接地址、擦写限制、RAM 与镜像预算
3. 模块与接口：责任、参数、错误码、任务/中断上下文
4. 状态与恢复：触发条件、持久化点、复位后的允许状态
5. 兼容策略：Bootloader、板型、配置版本与允许回退的组合
6. 测试入口：主机状态测试、构建检查、目标板与 HIL
7. 关键决策：方案依据、验证证据、未知项与负责人

从已经确认的需求综合设计，把尚未解决的选择列为待决项。为每条 R 规则标出负责模块和观察入口，后面的任务才能引用同一份契约。

按行为拆分时，一个切片可以跨越多个文件，但它必须交付一个能观察的结果。先建立最小的正常升级链路，再沿着风险补齐异常路径，每个切片都关联验收规则。

T1 的演示只说明主路径已经接通。T2–T5 负责补齐产品验收，它们仍可能改动同一段状态逻辑。共享接口和配置结构变化时，要同步更新任务依赖。

一张能直接执行的任务单

输入
  R2、R4，启动状态表，T1 的目标板验证记录。
范围
  健康确认条件、启动接口适配、超时与复位诊断。
  不包含生产公钥更换和硬件改版。
前置
  旧固件有效，新镜像以“待试运行”方式安装。
场景
  当新固件未完成健康检查，并由看门狗触发下一次复位，
  应恢复到允许的旧固件，保留可读配置并记录复位原因。
证据
  提交号、板卡编号、硬件版本、Bootloader 版本、固件哈希、
  注入脚本、完整日志、结果断言，以及尚未覆盖的板型。

最小 Skill：to-tickets 的嵌入式用法

任务单应写明输入、修改边界、前置依赖、验证入口和完成标准。测试板、调试探针、电源控制器也是资源依赖：代码可以分开实现，共享硬件的烧录与断电实验需要预约和互斥。

每个任务交付一个可观察的设备行为，并引用 R 编号。
一个任务应能独立演示；若需要“等所有模块都写完”，继续拆分。
区分代码依赖、测试数据依赖与板卡资源依赖。
对涉及启动和持久化的任务，同时列出失败场景与恢复入口。
把完成标准写在实现前，把未覆盖条件留在任务单中。

围绕一个失败场景缩短反馈

1. 先构造失败。让新固件在健康确认前停止推进，记录现有行为为何不满足 R4。
2. 做最小修改。补齐确认条件与失败路径，只改当前任务需要的模块。
3. 验证当前切片。先跑主机状态测试和构建，再到目标板核对启动与恢复。
4. 保存当次证据。日志、测试条件和固件哈希关联同一个提交。修改后重新验证受影响的行为。

把“确认固件”的时机写成可审查的逻辑

以下为接口层伪代码，函数名和时间来源需要由平台适配。它表达确认条件，不包含具体 Bootloader API 或 Flash 实现。

void trial_health_step(void)
{
    if (!boot_is_trial()) {
        return;
    }

    if (trial_elapsed_ms() >= TRIAL_WINDOW_MS) { /* 示例：30000 ms */
        record_fault(TRIAL_TIMEOUT);
        request_system_reset();
        return;
    }

    if (sampling_health_ok()
        && required_services_healthy()
        && rollback_config_ready()) {
        int rc = boot_confirm_current();
        if (rc != 0) {
            record_fault(CONFIRM_WRITE_FAILED);
        }
    }
}

这段任务代码无法处理“自己已经卡死”的情况。因此还需要独立看门狗或等效监督路径，且喂狗条件应反映关键任务的真实进展。确认写入被掉电打断时，也必须由启动协议恢复到定义好的状态。

开发用密钥不能作为生产密钥使用；相关说明见 MCUboot imgtool 文档。这里要求的是发布材料可追溯，生产私钥应留在受控签名环境中。

最小 Skill：implement 的嵌入式用法

读取当前任务、Spec、ADR 和已确认的平台约束。
围绕当前切片构造可复现的失败，进行最小范围修改。
按项目约定执行主机测试、编译、静态检查与目标板验证。
记录实际运行的命令、版本、结果和没有执行的验证项。
出现分区、时序或兼容性假设失效时，返回对应设计或需求环节。
没有目标板证据时，只报告已完成的逻辑与构建范围。

三层证据共同覆盖验收规则

真机故障注入矩阵

先固定可重现的边界用例，再按风险补充随机复位。断电时点、次数、负载、供电条件与覆盖板型都需要记录；仅写“断电测试通过”无法复核。

R3 的报告需要定义时间零点、采样触发位置、最大迟到量和对照基线，并保留原始时间戳。用 GPIO 与逻辑分析仪观察时，要评估埋点开销；如果还要求 ADC 转换精度或端到端上报延迟，应另列对应指标。

两条审查轴：规范与需求

最小 Skill：code-review 的嵌入式用法

固定基准提交与待审提交，并核对待发镜像哈希。
分别输出 Standards 与 Spec 两份结论，逐项保留依据。
每个缺陷给出：受影响规则、文件位置、触发条件和复现证据。
区分已通过、已失败、未测试和不适用；不把未测项写成通过。
核对板型、硬件版本、Bootloader、工具链和试验条件。
阻塞项修复后，对受影响规则重新取证并更新结论。

分批发布，每次扩大范围都有依据

发布记录应保留设备版本、硬件版本、升级阶段、失败原因、复位趋势和关键业务状态。观察周期和停发阈值依据项目风险确定，不用一个脱离现场条件的成功率代替验收。

发布包要能够追溯到同一次验证

最小 Skill：handoff 的嵌入式用法

交接写给没有参与本轮工作的人或新会话。用版本和证据链接定位事实，把“代码已改”与“哪些板型已验收”分别写清楚。

目标：完成 R2 / R4 的试启动失败恢复。
已完成：T3 逻辑与板型 A 的指定用例验证，记录见任务证据链接。
待验证：板型 B，以及配置迁移中的指定掉电点。
当前版本：填写真实提交号、板卡编号、Bootloader 版本和镜像哈希。
下一步：预约板型 B，按用例 P07 注入复位并比对运行版本与配置。
限制：未完成上述验证前，不扩大适用板型或发布批次。
恢复入口：引用已经核验的恢复操作说明及负责人。
敏感信息：只引用受控签名流程，不保存生产私钥或现场凭据。