最近圈子里面聊得很热一件事，越来越多嵌入式小伙伴直接把 HAL 层、驱动代码全部甩给大模型生成。不少新手图省事，prompt 敲完，复制 C 代码直接编译烧录，编译一过就以为万事大吉，结果板子反复随机死机，偶发看门狗复位，排查几天找不到根因。不知道有没有 Comake 社区做 BSP、固件开发的朋友踩过同款坑。

先说个自己踩过的小故事。前段时间调一块开发板外设，想快速写一段 I2C 从设备读取逻辑。Cursor 生成的代码语法看着漂漂亮亮，没有任何编译报错。下载跑起来之后，大部分时间工作正常，但高负载场景下时不时死锁。单步调试又复现不出来，属于典型偶现非必现 bug。

折腾大半天定位到问题：大模型生成代码漏掉信号量保护，中断上下文与主循环共享缓冲区产生竞态条件。没有做临界区保护，RAM 缓冲区读写发生撕裂。这种问题编译器是不会给你告警的，静态分析不打开也很难揪出来，等到硬件上面跑压力测试才会暴露。

很多人会有一个误区：能编译通过等价于固件逻辑正确。做应用层业务可以稍微放飞一点，但嵌入式固件完全是另一套逻辑。这里面要考虑寄存器时序、DMA 缓存一致性、任务优先级反转、栈溢出、RTOS 下重入问题。大模型经常会出现硬件层面的幻觉：编造不存在 SDK 接口、省略芯片勘误 workaround、对中断回调做错误假设，这些坑不会体现在编译日志里面。

尤其我们玩星宸这套 SDK 做 BSP 开发、IPU 模型部署的时候更要留心。很多小众 API、padmux 配置、时钟树初始化，公开互联网样本少，大模型训练素材不足，幻觉概率进一步拉高。你让 AI 生成 pinmux 配置，它有可能给你一套别的 SoC 的参数，编译没问题，外设直接哑火。运气差点直接端口短路，板子直接变砖。

现在行业现状，8 成以上嵌入式开发者日常都会开 AI 编码助手，但真正建立完整校验链路的团队其实不多。很多工程师慢慢变成所谓prompt jockey，调 prompt 复制粘贴，Datasheet 反倒翻得越来越少。AI 可以帮你写模板代码、简单工具函数、注释文档，但是不能替代你读手册、做压力测试、跑静态检查。

结合自己日常开发，分享一套我现在在用的工作流，没有什么高大上方案，属于踩坑踩出来的土办法：

1. 模板类代码交给 AI，底层驱动、中断服务函数尽量少直接生成。像工具函数、工具脚本、简单的应用业务逻辑，可以丢给大模型；涉及共享资源访问、DMA 操作、ISR 中断回调，生成出来之后，逐行对照 datasheet 过一遍每一处行为。
2. 打开静态代码检查工具，开启 MISRA 规则校验。不要只依赖编译器 warning，很多内存越界、未初始化变量，编译器直接选择无视。
3. AI 产出固件，不要只做单元测试，一定要上长时间压力拷机测试。很多问题只有连续跑几个小时才会浮出水面，短时间看起来一切正常。
4. 涉及 SDK 特有逻辑，生成完代码，对照原厂 demo 做差异比对。像 Comake 这边星宸 SDK，很多隐性约束文档不会全部写全，官方示例代码才是第一手真相。

AI 工具确实拉高了开发效率，写代码的速度快一大截。但固件这东西，软件 bug 最坏情况是设备挂死，没有云端服务那样随时热更新回滚的便利。一旦量产版本藏了这类隐性 bug，后面维护的苦果全是开发自己吞。

当然我也不是否定 AI 辅助开发，日常写代码我照样天天开 AI 工具。只是心里要绷一根弦：大模型输出是草稿，不是可以直接 merge 进版本库的成品。草稿可以拿来参考，但是决策权，必须攥在开发者自己手里。