1. 为什么我决定带AI一起干嵌入式项目，而不是让它替我干
先说个真实的感受：刚接触AI编程那会儿，我的心态是"终于可以偷懒了"，给AI丢一句"帮我写个STM32的串口驱动"，它噼里啪啦输出几百行代码，我复制粘贴进工程，编译一跑——全是乱码。那一刻我明白了，嵌入式开发里AI从来不是"替身"，它是一个"带过很多项目的老同事"，你要给它讲清楚需求、给它检查代码、给它擦屁股，最终拍板的还是你自己。
这篇就是我"第一个AI协同开发项目"系列的第二篇。上一篇我讲的是怎么选模型、怎么搭开发环境、怎么把代码仓库的上下文喂给AI。这一篇进入正题：拿着一个真实的嵌入式小项目，从头到尾走一遍AI协同开发的全流程，包括需求拆解、提示词设计、代码生成、编译调试、以及让我印象最深的几个坑。
如果你是做嵌入式软件开发的，不管是老手还是刚入门，这篇都值得看。老手可以看我是怎么把AI嵌进现有工作流的，新手可以看一个完整的AI协同项目长什么样。我尽量把每一步的操作细节和背后逻辑都讲透，不搞那种"AI帮你写代码"的玄学叙事，全部是实际干活的经验。
先说清楚这个项目是什么：我要做一个基于STM32G0系列的环境监测节点，用I2C接口接一个温湿度传感器，通过串口把数据发出来，同时支持一个简单的按键控制——按一下切一次采样模式。功能听起来很简单，但真正的嵌入式开发难就难在：硬件外设初始化、中断处理、低功耗逻辑、以及各种边界条件，这些恰恰是AI最容易写错的地方。
在动手之前，我先明确一件事：AI在这个项目里承担什么角色、哪些环节必须我来把关。这个分工决定了后面所有的工作节奏。
2. 项目起步：给AI写"入职说明书"而不是"一句话命令"
很多人用AI编程有个坏习惯，上来就是"帮我写个XX"，然后抱怨AI写得不行。这就像你刚入职一个公司，领导不给你看资料、不讲需求和规范，直接让你写代码，写出来的东西能看才怪。AI也是这样，它需要一份"入职说明书"。
2.1 AI协同的第一课：把项目背景讲清楚
在让AI写任何代码之前，我先组织了一份项目背景文档，内容包括：
- 芯片型号：STM32G030F6P6，Cortex-M0+内核，64KB Flash，8KB RAM
- 开发环境：STM32CubeIDE + HAL库，C语言
- 硬件连接：I2C1接SHT30温湿度传感器，USART1接串口调试，PA0接按键（外部中断）
- 关键约束：系统需要在待机模式下电流低于10uA，唤醒后5ms内完成一次采样并继续休眠
- 其他要求：代码风格遵循MISRA-C基本规则，关键函数需要注释
这份文档我大概写了四十分钟，但这四十分钟花得值。后面AI每次生成代码的时候，我都把这份文档的前几段贴进上下文，它生成的代码明显更贴合硬件实际，不会出现"随意找个引脚复用"这种外行操作。
提示：给AI的硬件上下文越具体越好。芯片型号、板卡版本、外设连接、时钟频率、Flash/RAM容量，这些信息直接决定了AI生成的HAL初始化代码靠不靠谱。缺失任何一个，它都可能给你编一个不存在的引脚定义。
2.2 提示词不是"越详细越好"，而是"越结构化越好"
我见过不少同行写提示词，恨不得把整个需求文档复制进去，结果AI输出一大堆冗余内容，真正要用的代码淹没在废话里。我的做法是把提示词拆成四层结构：
- 角色设定：告诉AI它是什么角色，比如"你是一名有10年经验的嵌入式固件工程师，熟悉STM32G0系列和HAL库"
- 任务目标：一句话说清楚要它做什么，比如"编写SHT30传感器的驱动模块，提供初始化函数和单次读取函数"
- 边界条件：硬件连接、通信速率、错误处理策略、不允许使用的API等
- 输出格式：要求它输出的内容形式，比如"提供sht30.c和sht30.h两个文件的内容，关键函数添加注释，禁止使用阻塞式延时"
举个例子，同样是让AI写I2C读取SHT30的功能，对比一下：
糟糕的提示词："帮我写个读取SHT30的代码。"
我实际用的提示词：
你是一名有10年经验的嵌入式固件工程师，熟悉STM32G0系列和STM32 HAL库。 任务：编写SHT30温湿度传感器驱动模块，支持I2C1接口通信。 硬件信息： - MCU：STM32G030F6P6（Cortex-M0+，主频64MHz） - 通信接口：I2C1，速率400kHz，PB6=SCL，PB7=SDA - 传感器地址：0x44（8位地址形式为0x88） - 工作电压：3.3V 功能要求： 1. SHT30_Init()：初始化I2C1外设和传感器 2. SHT30_ReadTemperature()：读取温度，返回float类型摄氏温度值 3. 错误处理：通信失败时返回错误码，不能阻塞系统 4. 时钟延展处理：SHT30在进行AD转换时可能需要时钟延展 5. 测量模式：使用周期测量的高重复性模式（0x2C06命令） 输出要求：提供sht30.c和sht30.h的完整代码，关键寄存器配置需要注释说明原因。这样写提示词，AI生成的代码基本在首次就能编译通过。这个结果是可复现的，关键就在于你给它的信息密度足够高、结构足够清楚。
2.3 提示词生成的第一版驱动代码长什么样
我让AI生成SHT30驱动后，它给出了一个约180行的实现。整个结构还算规整：Init函数负责MX_I2C1_Init和发送传感器唤醒命令，Read函数发送测量命令、读取6字节数据、计算温湿度。给我印象最深的是它自动处理了CRC校验——SHT30返回的数据最后两个字节是CRC8校验值，如果不校验，偶尔会出现一个离谱的湿度值。
但看完代码，我立刻就发现了两个必须改的地方：
第一，它的I2C读写函数用的是HAL_I2C_Mem_Read和HAL_I2C_Mem_Write，看起来没问题，但配合SHT30这种非寄存器式通信的传感器，更标准的是用HAL_I2C_Master_Transmit和HAL_I2C_Master_Receive。AI在这类细节上的选择有时候不会区分清楚。
第二，它的错误处理全是用HAL_I2C_IsDeviceReady轮询检测，虽然是可行的方案，但没考虑总线出错时的恢复机制，这在实际硬件上很常见。
这些不是AI"没写好"，而是"提示词里没提"，它按最常见的方式来。所以我说，AI协同开发的核心工作是"审代码"，而不是"写代码"。我花了大概五分钟把这两处改掉，顺便加了一个超时退出机制，整个驱动模块就足够稳了。
3. 关键环节拆解：AI在处理中断和状态机时，到底行不行
传感器驱动只是热身，真正考验AI功力的是两件事：中断处理逻辑和外设状态管理。这两个模块恰恰是最容易出"看似正常、实则崩溃"问题的地方。
3.1 按键外部中断的需求表达与AI实现
项目需求里有一个按键功能：按一下切换采样模式（从1Hz切换到10Hz），长按3秒进入低功耗模式。这个逻辑用文字描述很简单，但落到代码里涉及：外部中断引脚配置、防抖处理、事件标记、主循环消费事件、长按计时等模块。
我先让AI只负责"外部中断配置"这一小块，提示词里明确了：
- 使用PA0引脚，下降沿触发
- 中断回调函数里只做一件事：置一个全局标志位
- 禁止在中断回调函数里做延时、轮询、日志输出
AI给出的代码是对的——用HAL_GPIO_EXTI_Callback，在回调里置一个volatile uint8_t标志位。这部分没有任何问题。但它默认没把"防抖"写进去。这不算AI的错，因为很多硬件工程师的习惯是防抖在硬件电路用RC滤波解决，项目里确实加了RC，所以软件防抖可以省略。但如果你没有硬件防抖，提示词里必须让AI加上软件防抖，否则按键触发一次会确认好几次。
然后是长按检测。我把这个逻辑单独拎出来让AI设计一个简单的状态机，提示词里给了三个状态：IDLE（等待按下）、PRESSED（已按下）、RELEASED（已松开），并说明判断条件。AI用了经典的switch-case状态机，配合HAL_GetTick()做时间戳记录，实现得很干净。它的状态转移图直接在注释里画出来了，代码可读性反而比我之前自己写的版本好。
3.2 用10个问题"面试"AI生成的HAL初始化代码
有一类错误是编译器不报错、运行才崩溃的：GPIO复用配置错、时钟源选错、DMA通道冲突。这些问题的根因是HAL库的初始化代码和芯片实际的引脚定义不匹配。
我的习惯是在让AI生成初始化代码后，自己对照芯片手册一项项"面试"它。下面是一份我常用的核对清单，这次项目里也实际用了一遍：
| 核对项 | 核对方式 | 这次项目的结论 |
|---|---|---|
| 引脚复用是否正确 | 对照数据手册Alternate Function表 | AI正确选择了AF1给I2C1，OK |
| GPIO速度等级 | 高速信号需要HIGH，按键可LOW | AI默认LOW，串口需要HIGH，我改了 |
| 时钟源选择 | 需要确认APB1/APB2外设时钟 | AI选对了，它知道I2C1挂在APB1 |
| 中断优先级分组 | NVIC优先级不能随意 | AI默认给了0，我结合实际改成2 |
| 串口波特率计算 | 确认是否与上位机约定一致 | 我用的是115200，AI写成了9600，改了 |
| 上拉电阻配置 | 开漏I2C必须有上拉 | 芯片内部有上拉可开，AI配置了内部上拉，OK |
| SysTick中断冲突 | 如果用了HAL_Delay不能关 | 本次未涉及，但需要确认 |
| DMA外设请求 | 如果开了DMA必须开启对应中断 | 本次串口未用DMA，忽略 |
| 功耗模式相关外设 | 低功耗前必须关闭不必要外设 | AI在低功耗分支里关了ADC和I2C，我补了串口 |
这套核对流程花不了多少时间，但能避免大部分"启动即死机"的问题。不夸张地说，AI生成的初始化代码80%是对的，那20%的错误全在这种硬件细节上，必须有个人拿着手册一页页对照。
3.3 一定要让AI解释它写的每一行"非常规代码"
AI有时候会写一些让人看不懂的代码。我遇到过几次，它为了"优化"搞了一段位操作，编译通过了、运行结果也对，但没人知道为什么要这么写。这在大厂合规审查里是个大忌——代码必须有可维护性。
所以我在提示词末尾加了固定的一条："所有非常规的位操作和魔法数字，必须在行注释里解释含义。"这样一来，AI生成的代码里不会出现莫名其妙的0x7F或（1 << 8）之类的裸数字。这个习惯建议大家从一开始就养成。
4. 编译、烧录、调试：AI帮不了的那部分，才是项目成败的关键
说实话，AI协同开发最大的增量不在"写代码"，而在"改代码——编译——烧录——看现象——再改"这个循环里。AI能帮你把代码量压缩一半，但这个循环本身是省不掉的，而且循环里到处是坑。
4.1 首版编译：一次性通过的代码，我却高兴不起来
这是我的真实经历。第一次把AI生成的所有模块合进工程后编译，全工程只有两个warning，没有任何error，一次通过。我当时的反应不是"AI太强了"，而是"这肯定有问题"。
果不其然，上板实测后发现了三个实际问题：
第一，SHT30驱动读数异常，温度偏高15度。查了一圈，发现AI在计算温度时用了错误的移位方式。SHT30返回的16位数据是MSB在前，AI写的是（data[0] << 8）| data[1]，这本身是对的，但在HAL库接收数据时，它用了小端序数组存储，导致高低字节被颠倒了。这种"字节序"的坑在嵌入式里极其常见，AI很难从代码上下文里判断出来，只能靠你拿着逻辑分析仪或者串口打印去对比。
第二，串口输出经过USB转TTL模块时正常，但直接用杜邦线接TTL电平的调试工具就乱码。原因是AI配置了串口的硬件流控引脚，还启用了RTS/CTS。这个功能在开发阶段完全没必要，反而会把调试工具的电平搞混。
第三，也是让我最头疼的——低功耗唤醒后系统卡死。这个后面单独展开讲。
这几个问题都不是AI"写错了"，而是它在没有"光照"到硬件实物细节时，只能按"标准答案"来，而嵌入式里根本没有标准答案。代码能不能用，最终是板子说了算。
4.2 低功耗唤醒Bug的完整排查链路
这个Bug值得单独拿出来讲，因为它完美展示了嵌入式AI开发的典型形态：AI帮你缩小了排查范围，但定位问题的逻辑能力还得靠人。
现象是：程序进入STOP模式后，按按键唤醒，系统可以跑，但串口不再输出数据，LED也不闪。复现率100%。
我的排查思路分四步：
第一步，确认唤醒源和时钟恢复。用示波器测了PA0引脚，按键按下时电平有跳变，EXTI中断应该触发。进入STOP模式后，系统时钟默认切换到MSI，唤醒后不会自动恢复到PLL——这是HAL库和底层CMSIS的默认行为，所以我在唤醒后的代码里需要手动重新调用HAL_RCC_ClockConfig把时钟切回PLL。这步做了之后，LED恢复闪烁，说明CPU核和基本时钟已经恢复。
第二步，测串口引脚波形。发现TX引脚在唤醒后没有任何数据，但引脚电平正常，说明UART外设时钟可能没恢复。查代码发现，AI在进入STOP模式前把USART1的外设时钟关了，但唤醒恢复的函数里没有重新使能。这其实是HAL库的__HAL_RCC_USART1_CLK_ENABLE()调用问题，加一行就解决。
第三步，看I2C总线状态。唤醒后继续读传感器，第一次I2C通信超时。原因更隐蔽：I2C总线在STOP模式前是挂着的，唤醒后总线状态还停在"忙"，需要发送一个STOP条件来恢复。AI生成的代码没有这个处理，我是靠逻辑分析仪看到SCL在持续拉低才发现问题。
第四步，把所有恢复逻辑整理成一个System_Resume()函数，让AI基于"出错的完整日志"生成一版恢复流程的代码，最后实测通过。
这个过程里，AI唯一做得好的是"帮我查了HAL库里STOP模式相关的API怎么调用"，它省了我翻手册的时间。但定位"为什么唤醒后串口不工作的根因是外设时钟没恢复"这种判断，完全依赖我对STM32时钟树和HAL库执行流程的理解。所以，别指望AI替代你做根因分析，它只能做"加速器"。
注意：如果你在AI协同开发中做低功耗项目，一定把"唤醒后的时钟恢复"和"外设状态恢复"写进验收清单。AI默认代码里，至少有一半的概率不会处理这两件事。
4.3 给AI建立"错误反馈闭环"
我在这几轮调试里积攒了一个重要的经验：当AI生成的代码出现Bug时，不要直接把它修复后的结果贴回去，而是要把"错误现象、你的排查过程、最终定位到的根因"整理成一段话，放回AI的上下文里，让它基于这个反馈重新生成代码。
这么做有两个好处。第一，后续对话里AI不会再犯类似的低级错误，因为它"看"到过你给它纠偏的内容。第二，它生成的后续代码会更注重你在排查中暴露出来的薄弱点，比如字节序、外设时钟开关、总线状态恢复。我把这个过程叫"错误反馈闭环"，是AI协同开发里最有价值的操作。如果说提示词设计决定了AI的下限，那错误反馈闭环就决定了AI的上限。
一套完整的失败案例反馈模板大概是这样的：
硬件环境：STM32G030F6P6，I2C总线接SHT30 错误现象：系统从STOP模式唤醒后，第一次I2C读取超时 排查过程： 1. 确认时钟已恢复，LED正常闪烁 2. 用逻辑分析仪观察，SCL被拉低，总线呈忙状态 3. 对比进入低功耗前的总线状态，发现缺少释放总线的STOP条件 根因：进入STOP模式前，I2C外设未发送STOP条件，总线状态残留 修复方法：在唤醒后执行一遍I2C总线复位序列 请基于以上信息，重新生成低功耗模式的进入和退出代码。看完这段内容，AI生成的代码里自动加了一个I2C_Bus_Reset函数，还顺带处理了MCU其他外设的总线残留。效果立竿见影。
5. 软件架构层面的协同：当AI面对的是一整个工程，而不是单个函数
前面几章讲的都是"让AI写一个模块"的用法。但在实际项目中，AI的价值如果要最大化，它得能"看懂"整个工程的代码结构和模块间依赖。嵌入式软件工程的代码组织方式，决定了AI能不能在跨模块场景中帮上忙。
5.1 工程结构怎么划分，AI的"视野"才够大
这是我的一个体会：AI对单文件的处理能力强，但跨文件的理解能力弱。所以你的工程结构越清晰——头文件职责单一、源文件的函数聚集性越强——AI给出的跨模块建议就越靠谱。
我这次项目的模块划分如下：
main.c：只做系统初始化和主循环调度bsp_i2c.c：I2C总线初始化，总线恢复函数sht30.c：传感器驱动，依赖bsp_i2capp_task.c：应用逻辑，状态机，按键事件处理power.c：低功耗进入与唤醒恢复debug_uart.c：串口日志输出
每个模块的函数声明都在各自的头文件里，模块之间依赖关系明确。AI在收到"让SHT30的采样逻辑在低频/高频模式之间切换"这样的任务时，能准确找到该改哪些文件、不该动哪些文件，而不是把代码全堆在main里。
5.2 让AI生成跨模块调用关系图，再用自己的大脑复查
我没有让AI直接画架构图（项目小，画图意义不大），而是让它用文字描述"从系统启动到首次数据输出的完整调用栈"。它写出来的内容基本准确：Reset_Handler → SystemInit → main → HAL_Init → SystemClock_Config → MX_GPIO_Init → I2C_SHT30_Init → 主循环 → UART_Log → 定时器调度。
这个调用栈帮助我一眼就发现了SystemClock_Config里有一个时钟源初始化顺序的问题，然后提前改掉。这种"让AI描述、你来核对"的协作模式，比它输出一张流程图有用得多。
5.3 代码审查不能省：我的三层Review流程
最后一道工序是Review。AI生成代码我不敢直接用，必须走三层审查：
第一层，功能审查。把AI生成的代码在逻辑上"跑一遍"，模拟各种入参和边界条件，确认功能符合需求。这一层大部分靠读代码。
第二层，硬件审查。对照芯片数据手册核实引脚、时钟、外设配置。这一层AI做不了，必须人来。
第三层，规范审查。检查命名风格、注释完整性、是否存在无意义的宏定义。AI在命名上大多没问题，但它喜欢生成几百行的"一次性函数"，不利于维护，我会拆开。
三层review下来，单个模块的代码从生成到合入，大概会花我30到60分钟。一开始觉得慢，但实战几周后，我返工的次数大幅减少，整体进度反而比以前"自己硬搓代码、瞎改bug"快得多。
6. 实战中AI踩过的另外几个坑，以及我的应对策略
除了上面讲过的低功耗唤醒问题，这轮项目里还遇到过几个值得记录的坑，每个都代表一类常见问题，拿出来单独说说。
6.1 串口乱码的真相：不是波特率不对，是时钟频偏
项目里遇到过串口接收端显示的字符是乱的，起初以为是波特率算错了。用示波器量了TX引脚的波形，发现每位的时间确实有点偏差，但不大。后来查了SystemClock_Config里的时钟源，AI配置了MSI作为系统时钟，MSI在STOP退出后的精度不如HSI，而且MSI的频率校准值没有在初始化后写入，导致实际波特率偏差超过了串口容错的±2%。
这个例子说明，AI生成的时钟配置基本"能跑"，但不一定"跑得准"。真正做产品的话，时钟精度是必须验证的。我后来的做法是在提示词里固定要求"系统时钟源首选HSI，并注明校准流程"。
6.2 别让AI乱用"printf重定向"
嵌入式调试最喜欢在串口上重定向printf，AI对此也非常积极。问题是，如果你只让AI"写串口调试代码"，它很可能直接给你写一个fputc重定向到UART的思路，但这个重定向会引入__io_putchar的依赖，在某些IDE版本里会编译报错。而这种错误往往不是显性的，它藏在链接阶段。
我的建议是：串口底层函数自己写，不让AI代劳。因为这块代码非常稳定、各芯片之间差异大、而且一旦写好几年不用动，让AI写反而要花时间校验。AI的优势场景是"业务逻辑多变、方案多分支"的代码，这种"万年不变、写错就崩"的基础驱动，自己来最稳妥。
6.3 AI生成的宏定义，必须警惕"魔法数字"陷阱
AI在生成配置宏时，喜欢直接给出数值，比如#define I2C_TIMEOUT 1000。这个1000到底是毫秒、微秒还是HAL库循环的次数， AI不一定说得清。我遇到过把宏定义当成毫秒用，实际HAL库内部对它做了循环换算，导致超时时间短得离谱的情况。
解决方法是：所有这种宏定义，必须让AI在注释里写明物理意义和单位，同时我再结合HAL库的默认超时参数做一个大概的换算。这一步虽然烦琐，但能省掉不少"怎么跑一下就超时"的怪问题。
7. 这一轮项目跑下来，AI协同开发教会我的事
项目收尾时，我统计了一下时间投入：从零到全部功能跑通，总共花了大概三天，其中纯手写和调试的时间大约占一半。如果是以前，这种规模的项目我自己写大概要五到六天。AI确实帮我省了时间，但省的最多的是"代码初稿"和"格式化"的时间，而不是"定位问题"的时间。
我最大的体会是：AI协同开发的真正价值，不在于它能生成多少代码，而在于它强迫你用更清晰的逻辑去拆解需求、设计接口。因为提示词写不清楚，AI就一定给你写不清楚的代码——你在提示词上偷的懒，后面会用十倍的Debug时间还回来。
如果你正准备开始自己的第一个AI协同嵌入式项目，我给你几条掏心窝的建议：
- 从外设驱动开始练手，别一上来就让它写整个系统。先让AI写一个I2C驱动、串口驱动、PWM驱动，摸清它的代码风格和错误模式。
- 把提示词模板固定下来，反复微调。我有一套自己的模板，"角色+硬件信息+功能需求+输出格式"，每次写提示词只改核心内容，其他部分不变，效率高很多。
- 每遇到一个新坑，就把它记录成"错误反馈段"，放回AI的上下文里。久而久之，你手里的AI会越来越懂你的项目、越来越懂你的硬件、甚至越来越懂你的代码风格。
- 保留随时退出AI、自己动手重写的能力。AI不是这条开发链路上不可替代的一环，你才是。
最后补一个实操心法。我现在写嵌入式代码的习惯已经变成了："先让AI按我的思路出一版骨架，我逐行Review、补充硬件感知的细节，再让AI根据我的批注做修改，最后我自己写测试脚本验证边界条件。"这个流程走顺了之后，AI再也不是"偶尔帮我生成一段代码"的工具，而是真的像一个能帮我分担初稿工作的协作者。
下一步我打算把AI接进编译报错解析的环节，让它在每次编译失败后直接给出"错误原因+修改建议+影响面分析"。等跑完一个比较完整的闭环，我再回来写这个系列的第三篇。如果你也在用AI做嵌入式开发，欢迎在评论区分享你踩过的那些AI的坑，咱们互相借鉴。
