这一期是接着第17期往下写的。上一期我们把STM32F103C8T6的CubeMX工程建好，点亮了板载LED，串口也能看到输出，算是把一个AI协同开发项目的底子打好了。今天要做的，是把一个“只会点灯”的板子，升级成一个真正有感知、有显示、有交互的小系统——I2C总线上挂一颗SHT30温湿度传感器和一块SSD1306 OLED屏，用AI编程助手生成驱动，再逐行把代码审到能跑。
写之前先说个判断：嵌入式软件+AI编程，和互联网行业里“让AI写个网页”完全是两回事。网页写错了，最多编译失败；嵌入式代码错了，可能I2C总线直接锁死，传感器读数永远飘在95℃。所以这一篇我不会只贴“AI生成代码多好用”，更想讲清楚整个流程里人该怎么拆需求、怎么问AI、怎么核对AI给的代码、怎么在现场把问题解决掉。如果你是刚入门嵌入式的兄弟，手上一块F103板子，想看看AI能不能帮你写驱动，这篇建议从头到尾跟一遍。如果你已经会写C代码，只是想评估“AI生成的东西靠不靠谱”，可以直接跳到第5章的审查清单。
1. 项目复盘与分工：这次到底让AI干什么
1.1 需求先冻结，别让AI替你做产品决策
很多兄弟拿到AI编程工具之后，第一件事就是把需求扔给AI：“帮我做一个温湿度计。”结果AI回了一堆DHT11代码，用的还是Arduino语法，放STM32CubeMX工程里根本编译不过去。问题不在AI，在需求压根没冻结。
我这次的项目目标，是先在纸上写死：
- 主控：STM32F103C8T6，HAL库工程，CubeMX生成模板；
- 传感器：SHT30温湿度传感器，挂在I2C1总线上，地址0x44；
- 显示：0.96寸SSD1306 OLED，128x64分辨率，同样挂在I2C1总线上，地址0x3C；
- 交互：PA0、PA1两个按键，一个短按切换显示界面，一个长按清零累计数据；
- 输出：USART1每秒打印一条温湿度记录，方便在电脑上看曲线；
- 约束：不跑RTOS，主循环轮询，驱动代码放到独立目录，不允许和CubeMX生成的Core目录混在一起。
选这个项目是有讲究的。I2C是嵌入式世界里最高频的总线之一，SHT30和SSD1306这两个器件在AI训练语料里出现次数非常多，AI大概率能写出“看起来合理”的代码，但又在细节上暴露一堆问题。拿它做第一个AI协同开发项目，正好把AI的长处和短处都看明白。硬件连接简单、风险低，就算烧了代码也不会坏板子，适合练手。
需求表写完后，思路就清晰了：AI只负责“按已定好的接口去实现驱动”，而“产品该是什么样”永远由人来定。产品决策交给人，代码生成交给AI，这是整个协作模式的基石。
1.2 人和AI的分工，比写代码更值得花时间
我见过不少人让AI直接生成一整个main.c，然后对着几百行代码发呆，最后花三个小时删冗余逻辑。正确的玩法是先把任务拆成模块，再逐块让AI实现。
我自己习惯的分工大概是这样的：
| 交给AI做的事 | 人必须亲自做的事 |
|---|---|
| 生成SHT30、OLED这类常规器件的驱动骨架 | 硬件拓扑、引脚定义、器件地址确认 |
| 按HAL库风格补全I2C收发函数 | 核对数据手册里的时序、命令字、CRC算法 |
| 给已有代码补注释、解释报错 | 设计按键状态机、显示刷新策略、异常处理流程 |
| 生成串口打印、数据格式化、简单校验函数 | 做边界测试、异常情况验证、硬件排障 |
| 把一段代码翻译成另一种风格 | 决定哪些代码绝不能让AI碰（第5.3节会展开） |
这个分工表看起来简单，实际上决定了项目能不能按时跑通。可以把AI当成一个基础不错、但不了解你手头硬件细节的实习生。你负责把“硬件真相”梳理清楚，比如晶振是多少、I2C速率配多少、器件地址要不要左移一位；AI负责把它变成函数和代码。它一定会在细节上犯错，但只要你给的约束够清楚，返工率就低得多。
特别是“人必须亲自做的事”里，需求拆解和硬件核对这两项，AI目前还没法替代。你在提示词里写错一个引脚，AI会照着错引脚帮你写代码，最后板子不亮你还得反过来怀疑设备有问题。先花半小时把硬件环境描述清楚，比让AI瞎猜一小时高效得多。
2. 让AI写出能用的驱动：提示词工程在嵌入式里的落地
2.1 和AI描述硬件环境，越具体越好
同样的芯片、同样的传感器，用两种提示词问AI，得到的结果差距很大。
| 模糊提示词 | 精确提示词 |
|---|---|
| “帮我写一个温湿度传感器驱动” | “STM32F103C8T6，STM32CubeMX生成的HAL库工程，I2C1接SHT30，SCL=PB6，SDA=PB7，器件地址0x44，请生成SHT30_ReadOnce函数” |
| 结果：大概率是DHT11的Arduino代码 | 结果：基本能用的HAL库风格C代码 |
为什么会有这种差异？AI是概率模型，它在海量公开代码上训练过。你只说“温湿度传感器”，它按统计频率选择最可能的器件，而互联网上DHT11的代码量远大于SHT30，所以它默认给你DHT11。这就像你跟一个外包说“做个网站”，他可能给你做个博客；你说“做一个带购物车、支付回调、商品库存管理的电商后端”，他才可能给你真正要的东西。
在嵌入式领域，提示词里必须包含五类信息：芯片型号、工程框架、外设和引脚、器件型号与地址、接口约束。其中“接口约束”很关键，比如要求用HAL_I2C_Master_Transmit/Receive，还是用寄存器版；返回int8_t错误码还是直接用float；要不要加CRC校验。这些信息直接影响代码能不能无缝合入现有工程。
另外一个容易被忽视的点是“输出格式约束”。我通常会在提示词末尾加一句“请输出sht30.h和sht30.c两个文件的内容，头文件包含宏定义，C文件包含实现，注释用中文”。这样AI返回的结果可以直接拆成两个文件扔进工程，不用再手工裁切。
2.2 一次完整的AI驱动生成实例
拿这期项目的SHT30驱动来说，我实际给出的提示词是这样的：
角色：资深嵌入式软件工程师 环境：STM32F103C8T6，STM32CubeMX生成的HAL库工程，I2C1速率400kHz 外设：I2C1，SCL=PB6，SDA=PB7 器件：SHT30温湿度传感器，I2C地址0x44 要求： 1. 使用HAL_I2C_Master_Transmit/Receive完成单次测量 2. 函数签名：int8_t SHT30_ReadOnce(float *temp, float *hum) 3. 温度单位摄氏度，湿度单位%RH 4. 加中文注释，不修改main.c 5. 输出sht30.h和sht30.c两个文件内容AI很快给了下面这段代码，结构看着挺规整：
// sht30.h #ifndef SHT30_H #define SHT30_H #include "stm32f1xx_hal.h" #define SHT30_ADDR 0x44 int8_t SHT30_ReadOnce(float *temp, float *hum); #endif // sht30.c int8_t SHT30_ReadOnce(float *temp, float *hum) { uint8_t cmd[2] = {0x2C, 0x06}; uint8_t buf[6] = {0}; if (HAL_I2C_Master_Transmit(&hi2c1, SHT30_ADDR << 1, cmd, 2, 100) != HAL_OK) return -1; HAL_Delay(15); if (HAL_I2C_Master_Receive(&hi2c1, SHT30_ADDR << 1, buf, 6, 100) != HAL_OK) return -2; uint16_t rawT = ((uint16_t)buf[0] << 8) | buf[1]; uint16_t rawH = ((uint16_t)buf[3] << 8) | buf[4]; *temp = -45.0f + 175.0f * ((float)rawT / 65535.0f); *hum = 100.0f * ((float)rawH / 65535.0f); return 0; }这段代码第一眼看上去没什么大问题，HAL库调用、地址左移、单次测量命令都对。但深入核对数据手册和工程上下文，能发现至少三个坑：
第一个坑，&hi2c1这个句柄名是硬编码的，如果CubeMX工程里I2C1生成的句柄不叫这个，编译直接过不去。第二个坑，AI没有校验CRC。SHT30返回的6字节数据里，第2字节是温度数据的CRC、第5字节是湿度数据的CRC，忽略校验在总线受干扰时会读到跳变的错误值。第三个坑，命令发完到数据准备好之间需要时间，数据手册说高可重复性单次测量典型时间约14ms，HAL_Delay(15)能用，但如果换成慢速I2C或加了长走线，这个时间就可能不够。
这些不是AI“不聪明”，而是它没法知道你手上的实际硬件情况。它能给的是一份基于统计的“平均答案”，真实世界的约束需要人去补。所以我拿到AI代码后会做一次修正：补上CRC校验函数、把延时加到20ms留余量、确认句柄名和宏定义。这个过程通常只需要十分钟，但比让AI反复重试可靠得多。
2.3 提示词模板：以后都能用的六要素
如果你不想每次写提示词都靠临场发挥，可以套下面这个六要素模板：
- 角色定义：让AI进入嵌入式工程师角色，减少通用编程风格的漂移；
- 芯片与工程：CPU型号、HAL库还是寄存器、CubeMX生成与否；
- 外设与引脚：I2C/SPI/UART实例编号、SCL/SDA/CS/INT对应到具体引脚；
- 器件与地址：具体型号、I2C地址、SPI模式、命令字来源；
- 约束条件：函数签名、错误处理风格、是否用RTOS、内存限制、不允许修改的范围；
- 输出形式：文件名、头文件/源文件分离、注释语言、是否给出调用示例。
用这个模板去问AI，哪怕换一个项目、换一颗芯片，都能稳定拿到可用的初稿。核心原因在于，AI的输出是被输入“锚定”的，你把可能性空间从整个互联网缩到“STM32F103 + HAL库 + 单次测量”这个小领域，它犯错的范围就大大缩小。
3. 代码合入与联调：I2C总线上跑代码的那些坑
3.1 工程文件组织：别让AI代码污染CubeMX生成区
代码生成出来，第一步不是直接复制进main.c，而是先组织目录。STM32CubeMX有一个坏习惯：在CubeMX里重新生成代码时，会覆盖Core/Src下的文件。如果你把AI生成的驱动塞进main.c或者Core目录，下次调整引脚配置重新生成，代码就没了。
我建议把所有自定义模块放进独立目录，比如：
Project/ ├── Core/ # CubeMX生成，尽量不手工改 │ ├── Inc/ │ └── Src/ ├── Driver/ # 器件驱动，由AI参与编写 │ ├── Inc/sht30.h │ ├── Inc/oled_ssd1306.h │ ├── Src/sht30.c │ └── Src/oled_ssd1306.c ├── App/ # 业务逻辑，人主导 │ ├── Inc/app_screen.h │ └── Src/app_screen.c └── MDK-ARM/ # 工程文件然后在Keil或者IAR里把Driver和App目录加进include路径。这样CubeMX生成区、驱动区、业务区三者隔离，谁改动都不影响谁。AI生成的驱动就当第三方代码对待，即使要改，也只在Driver内部改接口。
这个过程AI帮不上什么忙，但它是嵌入式工程的基本功。很多AI生成的代码风格很不错，但工程结构一乱，后续维护就是地狱。尤其是当你做第二个、第三个项目时，好的目录结构能让你把以前的驱动代码直接复制复用，这才是效率的来源。
3.2 打通第一路数据：SHT30读数的正确姿势
把修正后的SHT30驱动编译进工程，然后写一个简单的轮询调用：
float temperature = 0.0f; float humidity = 0.0f; if (SHT30_ReadOnce(&temperature, &humidity) == 0) { printf("temp: %.2f C, hum: %.2f %%RH\r\n", temperature, humidity); } else { printf("SHT30 read error\r\n"); }第一次跑的时候，我习惯在main循环里每500ms读一次、打印一次，不看OLED，先确认传感器数据是活的。如果串口能稳定打印出25℃左右的室温，说明I2C通信链路基本通了。之后再看显示部分，这样出错时能快速缩小排查范围。
这里有个细节值得单独说：SHT30的单次测量流程是“发命令→等转换完成→读6字节→校验CRC→换算物理量”。转换公式本身很简单，温度是-45 + 175 * (raw / 65535)，湿度是100 * (raw / 65535)。容易搞错的是字节序，SHT30输出的是大端数据，buf[0]是高位，所以必须写((uint16_t)buf[0] << 8) | buf[1]，反过来就是读成300多度的原因。
CRC校验函数也一并补上，这段代码不复杂，但AI很容易漏：
static uint8_t SHT30_CRC8(const uint8_t *data, uint8_t len) { uint8_t crc = 0xFF; for (uint8_t i = 0; i < len; i++) { crc ^= data[i]; for (uint8_t bit = 0; bit < 8; bit++) { crc = (crc & 0x80) ? (uint8_t)((crc << 1) ^ 0x31) : (uint8_t)(crc << 1); } } return crc; }加上CRC判断后，每次读取都校验buf[2]和buf[5]，一旦发现错误就返回负值，主循环收到错误就跳过这次显示更新。这样即使总线上偶尔有干扰，屏幕上的数据也不会跳出一个怪异的温度。
3.3 OLED显示：像素点、坐标、刷新与闪烁
SHT30的数据调通，接着就是OLED显示。SSD1306是一个很成熟的显示控制器，AI对它的了解程度相当高，生成初始化和驱动代码并不难。但它有一个常见问题：AI不一定知道你用的是0.96寸128x64还是1.3寸128x64，也不一定知道你想要的初始序列是哪一版，容易给出一份新旧版本混用的命令。
我的处理方式是提示词直接限定：“SSD1306，0.96寸，128x64，I2C地址0x3C，页地址模式，生成oled_ssd1306.h和oled_ssd1306.c，包含初始化、清屏、显示缓存函数。”限定完，AI给出的初始化序列基本就能用了。
显示逻辑上，这期项目我会用一个全局显存数组来组织画面：
static uint8_t oled_buffer[8][128]; // 8页 * 128列程序要显示什么，先往oled_buffer里写字、绘图，最后一次性把整个buffer通过I2C写入SSD1306。注意这里不能每改一个字符就全屏刷新一次，否则OLED会闪得厉害，而且I2C数据传输也会占用大量时间。正确做法是：
if (data_changed || button_pressed) { Oled_DrawTemperature(temperature, humidity); Oled_Update(oled_buffer); // 整屏刷新 }刷新频率控制在10Hz以内足够。像这种“显示缓冲+脏标记”的思路，AI一般不会主动想，它只会机械地生成“写像素→刷新”的直逻辑。你需要在需求里明确提出来，或者在拿到代码后自己加状态控制。这也是为什么说，AI协同开发不是“让AI全写了”，而是“你知道怎么写，让AI帮你实现一部分”。
3.4 按键消抖和状态机：AI最容易忽略的一层
按键逻辑是这个项目里最有“嵌入式味道”的部分。AI生成的按键代码基本都是一个HAL_GPIO_ReadPin加上HAL_Delay延时消抖，这在简单的单键场景下能用，但一旦涉及短按、长按、双击组合逻辑，就必须上状态机。
我的建议是设置一个10ms的时基，在主循环或SysTick中断里调用按键扫描函数。按键状态机分为四个状态：
typedef enum { KEY_IDLE, KEY_PRESS_DETECT, KEY_PRESS_CONFIRM, KEY_LONG_PRESS } key_state_t;在KEY_IDLE状态检测到引脚低电平时，记录当前时间并切到KEY_PRESS_DETECT；在KEY_PRESS_DETECT状态里，等待50ms后再读一次引脚，如果还是低电平才确认是有效按下；如果按下的时间持续超过阈值（比如800ms），就进入长按状态。
这里有一个特别重要的原则：消抖不能用HAL_Delay(50)，因为在主循环里一卡就是50ms，I2C读取和显示刷新全被阻塞，整个系统响应都会变慢。正确做法是用HAL_GetTick()做非阻塞时间判断。AI生成的代码里很少有这种系统级思维，它会为了简单把阻塞放在最顺手的地方，结果整个系统被一个按键拖累。
4. 联调现场实录：三十分钟解决了三个问题
4.1 I2C总线被锁死，OLED白屏
第一次把SHT30驱动和OLED驱动合到一起跑，我遇到的现象特别经典：OLED白屏，SHT30返回值始终是-1，串口每隔500ms打一个“read error”。我第一反应是AI生成的I2C代码有问题，查了半天HAL_I2C_Master_Transmit参数，都没毛病。
后来拿逻辑分析仪夹在SCL和SDA上看波形，发现总线直接拉低锁死了。问题不是代码，而是硬件接线：两个I2C设备模块都自带或者依赖外部上拉电阻，合到一起之后上拉电阻缺失，SCL线上一旦出现一个错误的停止位，总线就再也释放不了。我把逻辑分析仪撤掉，在SCL和SDA上重新焊了两个4.7kΩ上拉电阻到3.3V，问题立刻消失。
这个案例说明：Embedded开发里，莫名其妙的问题有一半是硬件问题，AI代码只是背锅侠。遇到I2C相关的诡异现象，先看波形、先查上拉、先确认器件供电，再怀疑代码。
4.2 SHT30温度读成87℃，字节序与数据手册
总线问题解决后，SHT30能读回来了，但温度稳定显示在87℃。一开始我觉得是传感器坏了，换了一块板子还是87℃。手摸一下传感器，温度波动一点，说明数据确实来自传感器，只是转换有误。
后来翻AI生成的代码，发现它把字节序写反了，rawT变成了(buf[1] << 8) | buf[0]。SHT30输出的高位在前，这样组合出来的数值当然离谱。打开SHT30数据手册的时序图一核对，5分钟就定位了。改回正确的组合方式，温度立即落到27.3℃。
字节序是个很典型的AI幻觉高发点。因为AI在训练时看过大量小端字节序的代码，遇到这类大端传感器就容易按错误模式预测。这类问题靠人眼审代码确实能看出来，但更快的方法是直接把“高位在前”写进提示词，或者用文档明确描述字节的存储顺序。
4.3 长按功能总是误触发，补消抖
按下按键一松手，系统却判断成了长按清零操作，把累计时间清零了。这个现象一看就是消抖逻辑不对。AI生成的按键逻辑写的是“只要引脚检测到低电平超过800ms，就触发长按”，但没有区分按下瞬间的抖动和“真的按住了800ms”。
我调整了状态机：按下确认需要50ms稳定，进入KEY_PRESS_CONFIRM后再累计时间，同时要求在持续按下期间每10ms扫描一次，如果中间任何一次读到的电平不是预期值，就退出长按判定。这样修完，误触发现象消失。手感这东西AI没法调，短按阈值、长按阈值、重复触发周期都因人而异，必须实机测试人定参数。这个案例很适合用来提醒大家：交互逻辑的“最后一步”永远要落在人的手感校准上。
5. AI代码的“可信度”审查：嵌入式工程师的核心技能
5.1 拿到AI代码，先过这五道关
AI生成的代码，我不管用起来多顺手，都要先过下面这张审查表：
| 审查项 | 具体查什么 | 常见翻车情况 |
|---|---|---|
| 可编译性 | 头文件路径、宏定义是否齐全、句柄名与CubeMX一致 | 使用未定义的宏、句柄名臆造 |
| 器件匹配 | 芯片型号、寄存器名、I2C地址、命令字 | 把SHT30命令字写成SHT31的、OLED从机地址0x3C/0x3D混用 |
| 时序正确性 | 延时时间、超时时间、转换时间、时钟极性 | 命令发完立即读、SPI的CPOL/CPHA配反、I2C速率超过器件极限 |
| 资源开销 | 局部数组大小、栈占用、DMA与中断冲突 | 在函数里定义大数组、ISR里调用阻塞函数 |
| 异常处理 | 是否有返回错误码、失败重试、看门狗喂狗位置 | 只有成功路径，设备异常时程序卡死 |
这张表不需要打印出来贴在工位上，只要脑子有这个意识。每拿到AI代码，按这五关过一遍，绝大多数坑都能在编译之前发现。
5.2 让AI自己审自己，再做交叉验证
有一个很好用的方法，好多人都没试过：把AI生成的代码原样贴回去，让它扮演“代码评审专家”。我自己实测下来，同一个模型在“生成模式”下容易忽略的细节，切换到“审查模式”后反而能列出一堆风险。
比如把第2章那版SHT30代码灌回去问它：
请检查这段SHT30驱动代码，重点关注I2C地址、命令字、字节序、超时处理和CRC校验，列出所有风险和修改建议。它给的回答通常会包含“未定义SHT30_ADDR”“缺少CRC校验”“延时可能不够”这几项。这些点我前面已经靠自己看出来了，但AI自己指出来的过程，可以帮你确认思路。
交叉验证还不止于此。同一个问题，可以换个模型再问一遍，或者直接搜索芯片的数据手册/示例代码。我的原则是：器件关键参数（地址、命令、时序）以数据手册为准，不盲信任何AI输出。AI是强力辅助，不是最终真相。
5.3 哪些代码坚决不能闭眼让AI写
AI再强，有些嵌入式代码我仍然坚持人肉审查，甚至不让它碰。这些区域包括：
- 看门狗配置和喂狗逻辑：喂狗位置错了系统会不断重启；
- 时钟树和PLL配置：配错意味着整个系统频率漂移，串口波特率全乱；
- Flash擦除写入：时序擦除逻辑有错，可能把固件擦坏；
- 电机/PWM输出逻辑：方向、占空比、死区设置错的代价是硬件损坏；
- 中断服务函数：ISR里做耗时操作、调用HAL_Delay，会毁掉系统的实时性；
- 加密和安全相关代码：这个不用解释，必须人来验证。
道理很简单：AI写菜谱，做糊了最多倒掉重做；AI写电机控制，写反了可能是炸板子。嵌入式的出错成本比纯软件高得多，所以这些区域的代码，AI可以帮你生成草稿，但最终合入的版本必须由人一行行确认过。
6. 从第一个项目往后走：AI协同开发还能怎么用
6.1 免费的AI编程写代码怎么选
最近总有人问我，免费的AI编程写代码工具到底行不行。我的实测结论是：看你任务颗粒度。如果你的任务很聚焦——写一个CRC8函数、整理一段串口解析逻辑、给旧代码补注释，免费的工具和本地部署的开源代码模型完全够用。但如果你指望它独立完成一个包含外设驱动、状态机、低功耗策略的完整嵌入式工程，现阶段所有工具都会在芯片寄存器细节上翻车。
本地跑开源模型还有一个额外好处：代码不用出本机，适合公司内部有保密要求的项目。不过本地模型参数量有限，遇到很偏门的芯片手册细节，还是需要对着官方文档人工确认。免费的方案不是我这里要推荐的重点，重点是别被“免费”两个字冲昏头脑，该你还得是你。
6.2 让AI读老代码、补注释、写测试
AI协同开发不只是“AI写新代码”，还有很大一块价值在“读老代码”。接手一个祖传项目时，把一段没有注释的USART驱动贴给AI，让它用文字描述调用关系、全局变量、中断处理流程，通常几十秒就能得到一份不错的调用说明。这个用法比让它写新功能更稳定，因为老代码本身就是“事实”，AI要做的是解释而不是创造，幻觉少很多。
另外一个我很推荐的场景是让AI生成串口测试命令。比如这个环境监测项目，我会让AI生成一个简单的串口指令解析器：上位机发“get_temp”，设备回一条温度数据；发“reset”，设备清零累计信息。这种小功能在互联网项目里不值得一提，但在嵌入式里它能帮你快速验证整个数据链路是否还活着。
6.3 保持“AI能写、我能验”的平衡
很多人担心学了嵌入式软件之后被AI取代，这个问题我想说点实在的。回到这期项目的经历，AI确实帮我省了敲代码的时间，但真正把这个项目压低到能跑通的，还是人对硬件、时序、协议的判断。AI降低了“从空白到草稿”的门槛，但没有降低“从草稿到能交付”的门槛。
我现在给自己定的习惯是：小函数放心让AI写，驱动框架让它搭，模块接口让它们之间用标准的返回码协作；但涉及到芯片地址、时序延时、异常恢复、硬件安全这些“板级硬约束”，一定回到数据手册和人脑复核。AI可以很快，但人得知道自己在干什么。
最后再分享一个小技巧：当你问AI嵌入式的某个具体问题时，不妨先喂给它一段“别人写错”的实现，让它指出错误。同一个模型从“生成模式”切到“审查模式”时，往往能发现很多连你自己都没注意到的细节。这件事我吃过几次亏之后才意识到，现在每次让AI干活，都会顺手让它把代码重新审一遍，权当多一个不嫌烦的结对程序员。
