嵌入式软件工程师，怎么把 AI 工具用顺手？

目录

[1、不要一上来就让 AI 写完整驱动](#1、不要一上来就让 AI 写完整驱动)

[2、最适合 AI 的第一类活：读手册，整理清单](#2、最适合 AI 的第一类活：读手册，整理清单)

[3、写代码时，让 AI 处理"结构"，不要让它替你决定"事实"](#3、写代码时，让 AI 处理“结构”，不要让它替你决定“事实”)

[4、Code review：让 AI 专门盯嵌入式常见风险](#4、Code review：让 AI 专门盯嵌入式常见风险)

[5、调试时，把 AI 当"现场记录整理员"](#5、调试时，把 AI 当“现场记录整理员”)

[6、小脚本是 AI 提效最明显的地方](#6、小脚本是 AI 提效最明显的地方)

7、提示词不用玄学，讲清楚四件事就够了

8、我现在的实际工作流

9、几个我会刻意避免的用法

---

这两年大家都在聊 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: STM32F407
- RTOS: 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、提示词不用玄学，讲清楚四件事就够了

很多文章会把提示词讲得很玄。我的经验是，嵌入式场景里不用复杂套路，讲清楚四件事就够：

1. 背景：芯片、RTOS、编译器、代码风格、已有接口；
2. 约束：不能阻塞、不能动态分配、ISR 限制、内存限制；
3. 任务：只生成框架、只 review、只整理清单、只分析日志；
4. 输出：表格、diff、检查项、风险等级、待确认列表。

我常用的结尾是这一句：

不确定的地方请明确标注“需要人工确认”，不要自行假设。

这句话很重要。因为 AI 最大的问题不是"不知道"，而是"不知道的时候也会说得很顺"。

8、我现在的实际工作流

现在我在项目里用 AI，大概是这个流程：

第一步，先自己读一遍需求和关键手册，知道问题的大方向。

第二步，把局部上下文给 AI，让它整理清单、生成骨架或列风险点。

第三步，自己对照手册、工程代码和硬件设计确认关键事实。

第四步，编译、静态检查、上板测试。尤其是时序、功耗、异常恢复，必须实测。

第五步，把这次有用的提示词和排查过程沉淀下来。下次遇到类似外设或类似 bug，可以直接复用。

这个流程不炫，但很实用。AI 负责把重复劳动做快一点，工程师负责判断哪些东西能进代码库。

9、几个我会刻意避免的用法

有些用法看起来省事，实际风险很高。

第一，不让 AI 凭空写寄存器配置。尤其是小众 MCU、国产芯片、特定外设，模型很容易把别的系列经验套过来。

第二，不直接复制 AI 生成的中断代码。ISR 里的阻塞、锁、日志、内存分配，都可能带来很隐蔽的问题。

第三，不让 AI 直接改大段历史代码。老工程里很多写法看着奇怪，但可能是为了绕硬件问题、兼容量产版本或规避 errata。

第四，不把 AI 的解释当结论。它可以给方向，但不能代替示波器、逻辑分析仪、调试器和压力测试。

嵌入式工程师用 AI，最重要的不是"会不会写提示词"，而是有没有边界感。

让 AI 帮你读资料、搭结构、补脚本、查风险，它会很好用。让它替你确认寄存器、替你理解硬件、替你背质量责任，那迟早会出问题。

真正有价值的用法，是把 AI 放进原来的工程流程里：需求还是要拆，手册还是要看，代码还是要审，板子还是要测。只不过那些重复、琐碎、容易分心的部分，可以交给 AI 先跑一遍。

这样用下来，它不像一个"神奇工具"，更像一个随叫随到的工程助手。

它不替你上板，但能让你更快走到上板那一步。