夜雨聆风
点击上方蓝色字体，关注我们
这两年大家都在聊 AI 写代码，但嵌入式工程师听起来多少有点别扭。
因为我们的 bug 不只在屏幕里。
板子上电不起来、I2C 偶发 NACK、DMA 搬了一半数据就进 HardFault、低功耗唤醒后外设状态不对，这些问题不是让 AI 多生成几行代码就能解决的。
我自己的感受是：AI 不是“替你写完整项目”的工具，更像一个反应很快的初级同事。
它适合帮你查资料、整理思路、写样板、做 code review、补脚本。
最后能不能上板，还是要靠工程师自己对手册、时序、内存和现场现象负责。
如果把这个边界想清楚，AI 对嵌入式开发的效率提升还是很明显的。
1
不要一上来就让 AI 写完整驱动
很多人第一次用 AI，喜欢直接问：帮我写一个 STM32 的 SPI Flash 驱动。
这种问法大概率会得到一份“看起来挺像”的代码，但里面可能有几个问题：
芯片型号没说清楚，AI 会默认一个它熟悉的系列； HAL、LL、裸寄存器风格混在一起； 擦除等待、超时、页边界处理不完整； 忙等待放在了不该阻塞的地方； 有些寄存器位甚至是编出来的。
更靠谱的方式是把任务拆小：我现在用 STM32G4，工程里用 HAL，不使用动态内存。请只帮我写 W25Qxx 的页写入函数框架，要求处理页边界、超时、错误码返回。底层 SPI 发送接收函数已经存在，接口如下……
这时 AI 的价值就出来了。它不需要替你决定所有事情，只需要把一段重复、容易漏边界的逻辑先铺出来。你再对照 datasheet 和项目代码改。
一句话：别让 AI 当主程，让它先当“代码草稿机”。
2
最适合 AI 的第一类活：读手册，整理清单
嵌入式开发里很耗时间的一件事，是在参考手册里来回翻。
比如配 ADC、CAN、USB、低功耗模式，真正写代码前，先要确认一堆前置条件。
我现在常用的做法是，把手册里的相关段落贴给 AI，然后让它只做整理，不让它自由发挥。
可以这样问：下面是某 MCU 参考手册里关于 ADC 校准和启动流程的段落。 请你整理成初始化检查清单。
要求：
1. 只使用我提供的内容，不要补充手册里没有出现的寄存器位；
2. 每一项标注“必须做 / 建议做 / 需要结合项目确认”；
3. 如果有不确定的地方，直接写“需要查手册确认”。
这个提示词的关键不是“帮我配置 ADC”，而是“整理成检查清单”。
AI 在归纳文字方面很强，但在凭空判断寄存器细节时不可靠。
整理出来以后，你再对照手册确认。
这样比自己从头啃文档快很多，也不容易漏掉类似“先关 ADC 再校准”“某个位需要等待硬件清零”这种细节。
3
写代码时，让 AI 处理“结构”，不要让它替你决定“事实”
嵌入式代码里有两类东西。
一类是结构性的，比如状态机、错误码、超时重试、参数检查、日志格式、单元测试框架。这些很适合 AI。
另一类是事实性的，比如寄存器定义、时钟树、DMA 通道映射、引脚复用、电气限制、外设 errata。
这些必须由工程师确认。
举个例子，如果要写一个传感器采集任务，我不会让 AI 直接写最终代码。
我会让它先写状态机：
请根据下面的约束，设计一个非阻塞传感器采集状态机。背景：MCU: STM32F407RTOS: FreeRTOS传感器通过 I2C 读取采样周期 10ms不能在任务中长时间阻塞I2C 底层接口已经封装为 async_read / async_write请输出：1. 状态枚举；2. 每个状态的进入条件和退出条件；3. 超时和重试策略；4. C 语言代码骨架；5. 需要我人工确认的点。
这个问题问完，AI 通常能给出一个还不错的框架。
即使代码不能直接用，也能帮你把状态拆清楚。
尤其是调试一些“跑一晚上才复现”的问题时，状态机比散落在各处的 if/else 更容易定位。
AI 在这类整理工作上，确实能节省不少脑力。
4
Code review：让 AI 专门盯嵌入式常见风险
AI 做 review 也有用，但不能只问“这段代码有没有问题”。
这个问题太大，它容易给你一些没什么价值的建议，比如命名可以更清晰、注释可以更多。
我更喜欢让它从几个固定角度看：
请只从嵌入式软件风险角度审查下面这段 C 代码。
重点关注：1. 中断上下文是否调用了不安全函数；2. 是否存在数组越界、整数溢出、未对齐访问；3. 是否有竞态条件或 volatile 使用问题；4. 是否存在阻塞等待导致实时性变差；5. 错误分支是否会造成资源状态不一致。输出格式风险等级：高 / 中 / 低触发条件可能后果修改建议
这类 review 对老工程尤其有帮助。
很多项目里都有一些历史代码，大家只敢小心翼翼地改。
让 AI 先扫一遍风险点，再由你判断是否真的要动，可以降低阅读成本。
我遇到过几次比较有价值的提醒，
比如：
ISR 里调用了可能拿锁的函数； DMA buffer 没有考虑 cache 一致性； 16 位长度字段参与计算时可能溢出； 超时计数用有符号整数，长时间运行后边界不清晰； 共享变量没有 volatile，或者只加了 volatile 但没有解决原子性问题。
这些问题 AI 不一定每次都抓得准，但它能帮你多一轮视角。工程师最后要做的是判断，不是照单全收。
5
调试时，把 AI 当“现场记录整理员”
嵌入式调试最怕现场信息散。串口日志一堆，Fault 寄存器一组，map 文件一个，调用栈半截，脑子里还记着刚刚改过哪个宏。
这时 AI 可以帮你整理线索。
比如 HardFault，可以把这些信息丢给它：
CFSR、HFSR、MMFAR、BFAR； PC、LR、SP； 反汇编附近几行； map 文件里对应地址； 最近一次改动； 是否开了优化、是否用了 FPU、是否有中断嵌套。
提示词可以这样写：
下面是一次 Cortex-M HardFault 的现场信息。请不要直接下结论，先按证据链分析。请输出：1. 每个寄存器值可能代表什么；2. 当前最可能的 3 个方向；3. 每个方向还需要补充什么信息；4. 建议我下一步在代码里加哪些断点或日志。
这样得到的结果通常比“告诉我为什么 HardFault”靠谱。
它会先帮你把问题分成几条线：空指针、栈溢出、非法地址、未对齐访问、总线错误、FPU 上下文等。
真正的结论还是要靠调试器和现场复现，但 AI 能把排查路径整理得更清楚。
6
小脚本是 AI 提效最明显的地方
如果只能推荐一个最容易见效的用法，我会推荐：让 AI 帮你写脚本。
嵌入式项目里有大量“不是主业务，但天天要用”的小工具：
解析串口日志，统计错误码出现次数； 从 map 文件里提取 RAM / Flash 占用； 批量比较两个固件版本的符号变化； 把寄存器 dump 转成表格； 从 Excel 配置表生成 C 头文件； 扫描工程里所有 TODO、FIXME、裸延时和魔法数字。
这些脚本让人自己写也能写，但经常懒得动手。AI 最大的好处是把启动成本降下来了。
比如你可以直接说：
帮我写一个 Python 脚本，解析 Keil 生成的 map 文件。输出：1. Flash 总占用；2. RAM 总占用；3. 占用最大的前 20 个符号；4. 结果保存成 csv。要求脚本可以通过命令行传入 map 文件路径。
这种任务不涉及硬件事实，反馈也快，跑一下就知道对不对。
用 AI 写脚本，是我认为最稳的提效方式之一。
7
提示词不用玄学，讲清楚四件事就够了
很多文章会把提示词讲得很玄。
我的经验是，嵌入式场景里不用复杂套路，讲清楚四件事就够：
背景：芯片、RTOS、编译器、代码风格、已有接口； 约束：不能阻塞、不能动态分配、ISR 限制、内存限制； 任务：只生成框架、只 review、只整理清单、只分析日志； 输出：表格、diff、检查项、风险等级、待确认列表。
我常用的结尾是这一句：不确定的地方请明确标注“需要人工确认”，不要自行假设。
这句话很重要。
因为 AI 最大的问题不是“不知道”，而是“不知道的时候也会说得很顺”。
8
我现在的实际工作流
现在我在项目里用 AI，大概是这个流程。
第一步，先自己读一遍需求和关键手册，知道问题的大方向。
第二步，把局部上下文给 AI，让它整理清单、生成骨架或列风险点。
第三步，自己对照手册、工程代码和硬件设计确认关键事实。
第四步，编译、静态检查、上板测试。尤其是时序、功耗、异常恢复，必须实测。
第五步，把这次有用的提示词和排查过程沉淀下来。
下次遇到类似外设或类似 bug，可以直接复用。
这个流程不炫，但很实用。
AI 负责把重复劳动做快一点，工程师负责判断哪些东西能进代码库。
9
几个我会刻意避免的用法
有些用法看起来省事，实际风险很高。
第一，不让 AI 凭空写寄存器配置。尤其是小众 MCU、国产芯片、特定外设，模型很容易把别的系列经验套过来。
第二，不直接复制 AI 生成的中断代码。ISR 里的阻塞、锁、日志、内存分配，都可能带来很隐蔽的问题。
第三，不让 AI 直接改大段历史代码。老工程里很多写法看着奇怪，但可能是为了绕硬件问题、兼容量产版本或规避 errata。
第四，不把 AI 的解释当结论。它可以给方向，但不能代替示波器、逻辑分析仪、调试器和压力测试。
嵌入式工程师用 AI，最重要的不是“会不会写提示词”，而是有没有边界感。
让 AI 帮你读资料、搭结构、补脚本、查风险，它会很好用。让它替你确认寄存器、替你理解硬件、替你背质量责任，那迟早会出问题。
真正有价值的用法，是把 AI 放进原来的工程流程里：需求还是要拆，手册还是要看，代码还是要审，板子还是要测。只不过那些重复、琐碎、容易分心的部分，可以交给 AI 先跑一遍。
这样用下来，它不像一个“神奇工具”，更像一个随叫随到的工程助手。
它不替你上板，但能让你更快走到上板那一步。
