最近这一年，我明显感觉到一个趋势：AI 编程工具已经大规模渗透进嵌入式开发。不管是 GPT-4o 这类通用大模型，还是 Copilot、Claude Code 这类 IDE 插件，你丢给它一个需求“帮我写一个 STM32 的 PWM 输出驱动”，它几十秒就能给你生成一份像模像样的 C 代码，甚至还能贴心地配上注释和初始化流程。
但问题恰恰出在这里。我身边不少同事，也包括我自己早期踩坑的经历，都验证了一件事：嵌入式场景下，代码生成越来越容易，真正困难的是验证。你把 AI 生成的代码丢进编译器和链接器，编译一次通过，心里还美滋滋的；等烧录到板子上，要么外设根本不工作，要么系统随机死机，要么功耗高得离谱。这时候你才会意识到，“能编译”和“能运行”之间隔着一道巨大的鸿沟，而“能运行一次”和“能稳定运行一千次”之间，又隔着一整套严谨的验证体系。
这篇文章我想聊的，就是我在实际项目中搭建这套验证体系的经验。不是讲 AI 工具怎么用，那太浅了；也不是讲代码生成本身有多神奇，那部分大家都懂。我想重点拆解的是：在嵌入式这个对资源、时序、硬件行为都极其敏感的场景里，AI 生成的代码到底该怎么验证？验证体系包含哪些层次？每一层用什么工具、什么方法、什么流程？如果你正在用 AI 辅助嵌入式开发，或者正准备在团队里引入 AI 编程，这篇文章应该能帮你少走不少弯路。
1. 嵌入式 AI 代码生成：为什么“生成”只是开始，“验证”才是主战场
1.1 AI 编程工具给嵌入式开发带来的真实变化
先说个实际的例子。之前我负责一个基于 Cortex-M4 内核的电机控制项目，需要用 PWM 输出驱动 MOS 管，还要配合 ADC 采样做电流环闭环。传统写法我大概需要半天到一天时间，要对着参考手册翻寄存器定义，要看中断优先级怎么配置，还要处理死区时间、互补输出这些细节。
后来我试着把这段需求丢给 AI，它几分钟就生成了完整的初始化代码，包括 GPIO 复用配置、定时器 PWM 模式设置、死区插入、刹车功能保护。乍一看质量相当高，注释也写得清清楚楚。但我没有直接烧录，而是先做了一轮交叉编译，结果发现它生成的代码里用了HAL_TIM_PWM_Start，却忘了在初始化时配置TIM_OC_InitTypeDef的脉冲宽度——也就是说，PWM 波形能输出，但占空比永远是 0。这种问题不用硬件验证根本发现不了，静态读代码又很容易漏。
这就是 AI 编程在嵌入式场景下的真实特征：它确实能大幅缩短从需求到初版代码的距离，但它生成的代码在硬件行为、边界条件、资源约束这三方面，存在明显的盲区。因为大模型学习的是海量代码仓库的“平均经验”，它知道你大概率会这么写，但它不知道你的具体芯片型号、你的时钟树配置、你的 PCB 布局导致的外部干扰、你的电源纹波特性。
1.2 嵌入式场景的验证为什么比普通软件难一个量级
如果 AI 生成的代码是跑在服务器上的 Python 后端，验证相对简单：单测、集成测试、压测，部署上线，出了问题看日志。但嵌入式不是这样。
第一，资源约束极其敏感。MCU 的 Flash 可能只有 64KB，RAM 只有 16KB。AI 生成代码最常见的毛病就是冗余——它喜欢把通用做法堆进去，一套初始化流程里包含了用不到的配置，或者定义了大数组却没注意到栈空间。这种问题在编译时完全看不出来，但烧进去就会出现栈溢出、堆冲突。
第二，硬件时序不可模拟。你写一个 I2C 读取传感器数据的函数，AI 生成的代码逻辑可能完全正确，但漏掉了上拉电阻初始化，或者 ACK 位检查的时序不对，结果传感器就是读不到数值。这种问题依赖的是示波器、逻辑分析仪，而不是单元测试。
第三，环境依赖复杂。有些代码要跑在 RTOS 上，涉及任务优先级、信号量、队列的交互；有些代码要配合中断服务程序，涉及临界区保护；还有的代码要直接操作寄存器，涉及 volatile、内存屏障这些底层的细节。AI 生成的代码往往对这类上下文一无所知，它只能根据你给的提示词做局部推断，一旦脱离真实环境，行为就可能失控。
我见过一个调了好几天的案例。同事让 AI 生成一个 Bootloader 的跳转代码，AI 给了一段标准的函数指针调用，逻辑看起来没问题，但跳转前没有关闭全局中断，也没有重置 SysTick，导致跳转过去之后应用程序跑起来直接 HardFault。这类问题靠“读代码”根本难发现，必须有体系化的验证手段才能兜底。
所以我的结论很简单：AI 生成的代码，必须按照“不信任任何一行”的原则来对待。验证体系不是可选项，而是必选项。它不只是为了找 bug，更是为了建立信心——让你的代码在交给硬件之前，已经过了一层又一层可追溯、可重复的检查。
2. 构建验证体系的底层逻辑：四层防线缺一不可
2.1 验证不只是测试，而是一条分层防线
我见过不少人的做法是：AI 生成了代码，自己大概扫一眼，然后编译烧录，看现象。运气好功能正常，于是默认代码没问题。这种“烧录即验证”的做法，其实是最危险的。
真正的验证体系，或者说我这两年逐步建立并打磨的方案，是分四层的：
- 第一层：静态检查。不运行代码，直接对源码做语法、类型、逻辑、规范层面的分析，用工具找出 AI 代码里潜在的问题。
- 第二层：单元测试与主机模拟。把代码编译成 PC 上的可执行文件，用测试框架做白盒验证，跑核心逻辑的分支、边界、错误路径。
- 第三层：仿真与模型测试。对整机行为建模，把代码跑在模拟器或者仿真环境里，验证系统级的交互逻辑，比如状态机迁移、任务调度、外设时序。
- 第四层：硬件在环与集成验证。把代码烧进真实硬件，通过外接测试设备、看门狗、日志系统等手段，验证代码在真实物理环境里的行为。
每一层解决不同的问题：静态检查解决“明显的低级错误”，单元测试解决“逻辑正确性”，仿真测试解决“系统级交互”，硬件验证解决“硬件适配与稳定性”。层层递进，每一层都能拦截一部分问题。如果设计得好，越靠前的层级发现问题越早、修复成本越低。
2.2 为什么不能跳过中间层直接上硬件
很多人会问：我把代码烧上去，用示波器看波形，用串口看日志，不也一样能验证吗？干嘛要费劲搭静态分析和单元测试？
道理很朴素：硬件验证成本高、周期长、且难以覆盖所有边界条件。
一个简单的例子。AI 生成了一个解析传感器数据的函数，里面有一段根据校验和判断数据有效性的逻辑。你在硬件上测试时，如果恰好传入的数据校验和都是正确的，这段错误判断逻辑就永远不会被触发。直到某一天传感器受到干扰，校验和算错了，你的代码才暴露出错误分支的 bug——而那时候产品可能已经批量生产了。但如果你在主机模拟环境里给这段函数写了一个单元测试，专门传错误的校验和进来，一秒就能发现这个 bug。
硬件验证还有个“不可复现”的问题。有些 bug 是偶发的，可能跑一百次才出现一次，你手拿示波器等两个小时都不一定触发。但在主机模拟环境里，你可以用确定性输入、循环压力测试，把潜在的边界条件和竞态条件放大出来，极大提高复现概率。
所以我一直强调一个观念：验证体系的效率，不是看哪一层“更真实”，而是看哪一层能更快、更稳定地发现问题。主机模拟虽然不如硬件仿真“真实”，但它快速、低成本、可重复，是性价比极高的一层。
3. 实操落地：分层验证体系的具体实施步骤
下面我按实际搭建过程的先后顺序，把每一步用到的方法、工具、配置和注意事项都过一遍。这不是理论推演，都是我踩过坑之后总结出来的可复现流程。
3.1 第一层落地：静态检查与代码规范扫描
AI 生成的代码，第一件事不是编译，而是过静态检查。我常用的工具组合是Cppcheck + Clang-Tidy + Compiler Warnings，再加上针对嵌入式场景的MISRA C 规则检查。
Cppcheck 是免费开源的，能查出数组越界、空指针解引用、未初始化变量、资源泄漏等常见问题。用法很简单：
cppcheck --enable=all --inconclusive --std=c99 --platform=unix64 --suppress=missingIncludeSystem ./src我通常会在 CI 的每次提交里自动执行这条命令。Cppcheck 对嵌入式代码的误报率不算高，但要注意它无法识别所有平台相关的头文件路径，所以建议加上--suppress=missingIncludeSystem和自己的头文件路径配置，避免一堆无意义的报错掩盖真正的问题。
Clang-Tidy 则更侧重现代 C 语言的代码质量和可维护性，比如隐式类型转换、未使用的变量、可疑的表达式优先级。在嵌入式上我常用它来查 AI 代码里的“看似正确但实际有隐患”的写法。比如它能把if (a = b)这种赋值和比较混淆的问题直接揪出来。
编译器自身的告警也要拉满。GCC 的话，建议至少加上这组参数：
-Wall -Wextra -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wno-unused-parameter我曾经让 AI 生成过一段 Flash 擦写驱动，它在函数里定义了一个参数叫data，同时又有一个全局变量也叫data，然后在函数体里用的是全局变量——带着-Wshadow编译时，告警直接把这个遮蔽问题暴露了。这种问题，不拉满告警根本扫不出来。
MISRA C 规则在汽车电子、医疗电子这类高安全领域几乎是强制要求。AI 生成的代码经常违反 MISRA 的规则，比如：
- 不允许使用
goto（AI 有时会为了处理错误分支生成 goto 代码） - 不允许隐式类型转换到更小范围（AI 经常把一个 int 直接赋给 uint8_t）
- 不允许使用无符号数和有符号数比较（AI 的循环里很常见）
我用的工具是CORTEX 的 PC-lint Plus或者开源的flawfinder。PC-lint Plus 支持定制 MISRA 规则集，Flawfinder 则专注安全相关的模式匹配。如果项目预算有限，先用 Flawfinder 做基础扫描，也能拦截一部分典型问题。
静态检查的核心原则是：机器能发现的，就不要靠人眼。AI 生成的代码量大、产出快，如果靠人一行行去看，视觉疲劳之后只会越看越漏。把静态检查做成自动化的流水线，是最低成本的护城河。
3.2 第二层落地：单元测试与主机模拟环境搭建
静态检查只能解决“低级错误”，逻辑正确性还得靠单元测试。很多人一听到“单元测试”就头大，觉得嵌入式代码和硬件耦合紧密，没法单测。这里有个关键技巧：在写代码时就把硬件依赖抽象掉，让核心逻辑可以脱离硬件编译运行。
我常用的单元测试框架是Unity + CMock + Ceedling。Unity 是极简的 C 语言测试框架，测试断言风格非常轻量；CMock 能自动生成 C 函数的 mock 版本，让你把 I2C、UART、GPIO 这类底层驱动替身换掉；Ceedling 则是把这些粘合起来的构建工具，负责管理测试工程和生成 Makefile。
举个例子。AI 生成了一段温度传感器数据处理逻辑，输入原始 ADC 值，输出温度值，内部有线性插值、滤波、报警判断。这段逻辑本身不依赖真实 ADC 硬件，只要把“读取 ADC 值”抽象成一个接口函数，单元测试时 mock 掉这个函数，给它喂不同的 ADC 值，就能验证数据处理的正确性。
Ceedling 的工程结构大概是这样的：
project_root/ ├── src/ # 产品源码 ├── test/ # 测试代码 │ ├── test_sensor_process.c │ └── mocks/ ├── lib/ # unity/cmock 等框架 ├── project.yml # Ceedling 配置 └── build/ # 构建输出在project.yml里，我会指定编译参数、头文件路径、以及哪些文件需要 mock：
:project: :use_exceptions: FALSE :test_file_prefix: test_ :setup_and_teardown: TRUE :release_build: :enabled: true :paths: :test: - test/** :source: - src/** :flags: :test: :compile: :*: - -std=c99 - -Wall - -Wextra写单元测试的时候，核心思路是“测试行为，不测试实现”。你不需要关注 AI 生成的代码内部怎么写的，只需要给它注入各种输入，断言它对外表现是否符合预期。比如传感器数据处理函数，你给它一个已知的 ADC 原始值，断言它输出的温度值是否在误差范围内；给它一个接近零点的值，断言是否触发了低温报警；给它一个中断标志位，断言是否进入了错误处理分支。
很多人以为 AI 生成的代码没法单测，因为生成逻辑千奇百怪。但反过来想：正是因为 AI 生成逻辑不稳定，才有必要用单测把它锁死。测试用例写得越全面，后续你再让 AI 重构、优化这段代码时，回归就越轻松。我一般在让 AI 生成代码的同时，就要求它一并生成一套单元测试框架下的测试用例，然后我在真实环境里补充边界情况。这样生成的代码和测试天然对齐，效率非常高。
3.3 第三层落地：仿真与系统级验证
单元测试验证的是“函数逻辑正确”，但嵌入式系统里很多问题是“组件之间交互错误”：任务调度死锁、中断抢占冲突、共享资源竞争、状态机跳转遗漏。这些问题很难在单测里发现，需要放到仿真的环境里跑。
我在实际项目里用过的仿真手段主要有三种：主机级仿真（软件在环）、QEMU 模拟器、以及 Simulink 模型在环（MIL/SIL/PIL）。
主机级仿真，就是把整个嵌入式工程编译成 PC 可执行文件，跑在同一套逻辑上。这个适合验证纯逻辑型的系统，比如通信协议栈、状态机、控制算法。我遇到过一个 AI 生成的数据帧解析模块，主机级仿真时用手工构造的十六进制报文做注入，发现它解析变长数据包时，长度字段的边界处理有漏洞，导致数组溢出——这个问题在硬件测试里可能要喂几十万个包才能偶发一次，但主机级仿真用几秒钟就复现了。
QEMU 适合跑完整的嵌入式 Linux 系统或带 MMU 的 MCU 仿真，能验证外设寄存器层面的部分行为，但对时序的模拟不够精确，不太适合验证裸机下微秒级的时序。它的价值在于快速跑系统级集成测试，比如验证启动流程、文件系统挂载、网络协议栈交互。
Simulink 模型在环（MIL/SIL/PIL）是电机控制、电源控制这类需要模型化设计的场景里常用到的。热搜词里提到了“simulink模型 c代码生成”，其实它的验证路径可以做得非常规范：
- 模型在环（MIL）：先在 Simulink 里把控制算法模型跑一遍，验证算法本身的正确性。
- 软件在环（SIL）：从模型自动生成 C 代码，然后在 PC 上把模型和生成代码分别跑，比对结果是否一致。
- 处理器在环（PIL）：在目标处理器上运行生成代码，和模型结果做一致性比对。
AI 生成代码进入这套体系后，PIL 环节的价值会被放大。因为生成的 C 代码如果只是在逻辑上“看起来”对，但位宽、定点数缩放、字节序处理上出了问题，PIL 比对会直接暴露不一致点。我通常会在 PIL 比对时设置一个容差阈值，比如控制量的误差不大于千分之一，一旦超出就判失败，自动输出差异波形。
3.4 第四层落地：硬件在环与集成验证
前面三层验证做的再多，最后也必须回到真实硬件。因为最终交付的代码跑在真实芯片上，外设行为、时序约束、电气特性，模拟环境没办法完全复刻。硬件在环验证，我的做法是分三步走。
第一步是烧录与冒烟测试。先把代码烧进开发板或者样机，上电后检查基本的系统运行状态：启动是否有异常、日志是否正常输出、外设初始化是否成功。这个阶段我一般会用板载 LED 或者串口打印来标记关键执行节点，比如“PWM 初始化完成”“I2C 总线扫描到设备”“传感器数据更新正常”。
第二步是功能测试与数据采集。针对每个外设和功能模块，写针对性的测试用例，通过精心设计的测试脚本对外设进行交互。比如 PWM 输出，我会用示波器量波形频率和占空比；传感器读取，我会打印原始数据和换算后的物理量，和参考值比对；通信接口，我会用上位机主动发报文，验证代码的响应是否正确。这个阶段是验证 AI 代码硬件适配性的关键，也是最容易暴露问题的环节。
第三步是稳定性测试与压力测试。嵌入式系统的问题往往不是“能不能跑”，而是“能跑多久不挂”。我一般会做 72 小时以上的长时间老化测试，同时加入各种干扰因子：温度变化、电压波动、外部电磁干扰。这个阶段重点观察的是系统是否有累计性错误，比如内存泄漏、任务堆栈溢出、通信丢包率随时间上升。测试过程中要通过日志系统完整记录系统状态，方便事后分析。
我遇到过最典型的场景：AI 生成的内存管理代码用了标准库的malloc/free，在主机模拟环境里一切正常，但到了 MCU 上跑了十几个小时后突然 HardFault。原因就是频繁动态分配产生了内存碎片，而主机模拟环境的堆空间大得多、分配策略也不一样。这种问题如果不做长时间硬件压力测试，很难暴露出来。
3.5 验证数据的可追溯性
最后这点很多人会忽略：验证不只是为了发现 bug，更是为了积累证据。尤其在工业、汽车、医疗这些需要认证的行业，验证的可追溯性是硬性要求。
我每一轮验证都会输出一份验证报告，包含以下内容：
- 代码版本和 Git Commit ID
- 验证环境配置（编译器版本、静态检查工具版本、测试框架版本）
- 验证用例清单及其覆盖范围
- 通过/失败情况统计
- 失败用例的问题分析和修复记录
- 关键性能指标（CPU 占用、内存占用、实时性指标）
这套报告体系在 AI 辅助开发的背景下尤其重要。因为 AI 生成代码的“不可解释性”容易带来审计风险，验证报告能证明你的代码是经过了系统性检查和测试的，而不是“拍脑袋跑一遍没问题就发版”。
4. 实操心得：AI 生成代码的验证中最容易踩的坑
这一节我整理几个自己在实际项目中真真切切踩过、或者看同事踩过的坑，算是经验清单。如果你按前面说的搭建了验证体系，这些坑大概率也会遇到。
4.1 只信编译，不信运行
第一类坑是把编译通过等同于代码正确。AI 生成的 C 代码很容易被编译器“放过”，因为语法正确、类型匹配，但逻辑上就是错的。
我印象最深的一次：AI 生成了一段用于系统时钟初始化的代码，里面有段while循环等待锁相环锁定。但 AI 忘了在循环之前写一句“启动锁相环”的寄存器操作，导致循环条件永远不满足，程序卡死在初始化阶段。编译时没有任何告警，烧录后直接用调试器才发现 PC 停在那条等待循环里。这种问题，静态检查发现不了，单元测试如果没覆盖时钟初始化流程也发现不了，必须靠硬件调试或者主机模拟中的“超时保护机制”才能捕获。
所以我后来在验证体系里加了一条硬性规定：每段 AI 生成的代码，必须至少有一个验证用例能覆盖它的执行路径。没有验证用例保护的生成代码，不允许合入主线。
4.2 忽略数据类型和编译选项的差异
嵌入式软件里，数据类型宽度、有符号数、字节序、对齐方式，这些细节一旦错位就是灾难。AI 生成的代码里，这类问题出现频率非常高。
典型例子：AI 写了一个从通信缓冲区解析温度值的函数，里面用了int16_t类型。但它在解析的时候直接做了memcpy，然后把结果强制转换成float，完全没考虑大小端问题。大端芯片上没事，小端芯片上解析出来的值就是反的。这种 bug 在主机模拟环境里也可能存在，但取决于你的主机字节序和目标芯片是否一致。
解决办法有两个：一个是要求 AI 在生成代码时明确标注数据宽度和字节序的假设；二是在验证阶段专门加一个“数据一致性测试”，构造边界值、负值、特殊浮点值，在主端和芯片端分别跑一遍，比对输出是否一致。
还有编译选项的问题。AI 生成的代码在你的电脑上编译正常，但你的电脑可能是默认的-O0优化级别，目标芯片用的是-O2甚至-Os。不同优化级别下，volatile 的处理、变量生命周期、浮点运算精度都会有差异。以前有同事让 AI 生成一个延时函数，用了nop空指令加循环计数，本地测试延时没问题，但开了-O2之后编译器直接把整个循环优化掉了，延时变成 0。这个问题在静态检查阶段就能发现——检查优化级别和延时相关代码的兼容性，但大多数验证流程根本不会把编译选项作为一个变量来测试。
4.3 验证环境与实际运行环境不一致
这是嵌入式开发最经典的大坑。你开发时用的是 GCC + Debug 配置，目标是 ARM-GCC + Release 配置；你开发时用开发板外接 USB 供电，目标设备用电池；你开发时传感器连接正常，目标设备可能有时序较长——这些差异都会导致“开发环境全绿，现场全是问题”。
AI 生成代码对环境差异的敏感度更高，因为它没有“环境约束”的概念。它会假设标准头文件路径、标准库行为、默认堆栈大小，但你的目标芯片可能裁剪了标准库，栈空间只有 2KB。这种“假设与现实的落差”，必须靠验证体系里的一环来兜底：就是必须在最接近实际运行的环境里做最终验证。
这里我的推荐做法是建立“验证配置矩阵”：至少包含两种配置，一种是开发环境的开发板配置，一种是目标量产环境的配置。每一版 AI 生成的代码，都要在两个配置上各跑一遍完整的验证流程。虽然耗时增加，但能极大降低“移机就挂”的风险。
4.4 过度依赖覆盖率数据
覆盖率是一个容易被误解的指标。很多团队把“覆盖率 90%”当作验证合格的标准，但 AI 生成的代码结构往往不够规整，容易出现大量冗余分支。覆盖率数字上去了，但关键分支没有覆盖到，数字就成了自欺欺人的工具。
我记得有一次，AI 给了一个状态机代码，包含五个状态、十三个迁移条件。单测跑完之后覆盖率报表显示 86%，看着挺健康。后来我手动检查了状态迁移覆盖矩阵，发现其中一个异常路径——从“初始化”状态直接跳到“错误处理”状态的迁移，从来没有人触发过，因为测试用例里没有构造这个场景。这个漏洞在高低温测试中才暴露出来。
所以我现在的原则是：覆盖率数据只做参考，人工检查验证用例的语义覆盖才是关键。对 AI 生成代码里过于复杂的逻辑分支，我倾向于要求 AI 补充用例覆盖，或者干脆人工精简逻辑，降低复杂度。毕竟验证的目的是保证正确，不是为了刷指标。
4.5 疏于管理 AI 回复的“幻觉代码”
AI 生成代码还有个特殊问题：大模型会出现“幻觉”，生成它自己“觉得应该如此”的 API、寄存器名、函数库调用，而这些在真实芯片上并不存在。这种错误在编译阶段大概率会被拦截，但有时候 AI 会在注释里写出完全虚假的寄存器说明，导致后续维护的工程师被误导。
我的处理办法是：绝不直接复制 AI 生成的代码进入工程。要求团队成员必须先把 AI 生成的代码抄到自己的编辑器里，过一遍注释，遇到不确定的 API 或寄存器名去查数据手册确认，然后再进入验证流程。这个过程不是为了“防 AI”，而是为了让自己真正理解这段代码在做什么——这是验证体系里最基础但是最不能省的一环。
5. 把验证体系嵌入团队流程：从个人习惯到工程文化
验证体系能不能真正发挥价值，光有工具和方法不够，还得看流程能不能落地。如果只是“我在开发时跑一下测试”，大概率会变成形式主义。
我现在的做法是把验证体系直接嵌进 CI/CD 流水线。每次代码提交到 Git 仓库，CI 会自动跑静态检查、单元测试、主机级仿真，单元测试不通过直接阻断合并请求。只有前几层都通过，才允许人工触发硬件在环测试。这样一来，AI 生成代码的“低质量”和“不可信”被验证体系挡在主线之外，不会污染主干代码。
当然，这套流程需要一次性投入不少精力去搭建，尤其要处理模拟环境里面各种硬件依赖的抽象工作。但一旦搭起来，后续受益是长期且稳定的。我这边的经验是：最开始搭建可能花了一周时间，但之后每接入一个新的 AI 生成模块，验证时间能从原来的几天缩短到几小时——因为大部分验证工作都自动化了，人的精力只需要放在解析验证报告、处理真正的异常上。
6. 写在最后：给正在用 AI 生成嵌入式代码的你几点建议
这几年 AI 编程工具迭代非常快，从 Copilot 到 Codex，再到能自动写测试用例的各类 Agent，嵌入式场景的 AI 辅助也从“帮你补全函数”走向“帮你生成整个驱动模块”。但无论工具怎么发展，核心逻辑没有变：生成只是起点，验证才是保证质量的关键路径。
如果你刚开始尝试用 AI 写嵌入式代码，我的建议是不要怕它生成得“烂”，而要怕你验证体系“缺”。哪怕一开始先从最基础的编译告警和静态检查做起，也比“烧录裸跑看现象”强得多。等你有了一份能快速执行的单元测试用例，再让 AI 帮你迭代优化代码时，你会体会到什么叫“放心大胆地改，测不过就自动挡下来”。
我自己现在的习惯是：任何 AI 生成的代码，先过三层关卡——静态检查、单元测试、硬件冒烟；三层全过，才允许进入正式开发流程。这个习惯救了我很多次，也让我对 AI 编程工具的使用从“兴奋”回归到“务实”。毕竟嵌入式开发这件事，考验的从来不是你写代码的速度，而是你交付的代码能不能在真实世界的干扰和边界条件下稳定运行。验证体系，就是连接“AI 生成”和“真实可靠”之间的那座桥。
