这篇是这个“第一个AI协同开发项目”系列的第三篇。前两篇我把一个STM32温控小系统从需求拆解推到了第一版固件开发环境搭好了main框架和GPIO初始化是AI生成的ADC温度采集和串口打印也跑通了当时已经能一边测室温一边在串口助手看到数据。但说实话那个阶段的项目还只是个“能编译、能打印”的半成品离一个真正的嵌入式产品还差得远。这篇我按计划把项目推进到第三阶段闭环控制、协议联调和真机可靠性验证。这个阶段正好赶上9月27日前后那几天我用了一个周末集中调板子踩进去的坑一个比一个真实。如果你也在用AI编程工具开发嵌入式软件这篇里的大部分问题你大概率也会撞上。我先把话说在前面嵌入式软件用AI协同开发前期的“生成代码”效率提升只是开胃菜真正见功夫的地方在——AI生成的代码能不能过得了硬件那一关以及你在审查和实测时能不能一眼看出它埋了什么雷。这一篇就是围绕这两点展开的。1. 项目推进到第三阶段目标已经不只是“能编译通过”先交代一下这个项目的最终形态免得后面看得一头雾水。这是一个两路温度采集加一路PWM风扇控制的小系统STM32F103C8T6作为主控两个DS18B20传感器负责采集一个N型MOSFET驱动12V风扇通过串口与上位机交互支持查询温度、设置目标温度、切换手动/自动模式。核心工作模式是自动温控当两路温度的平均值超过目标温度时PID输出占空比控制风扇转速让温度稳定在设定值附近。前两篇完成后这个系统的骨架已经在了但控制逻辑、联调协议、异常处理这些核心功能全是空的。所以第三阶段的任务拆分很明确阶段任务具体内容我关注的核心指标闭环控制位置式PID、PWM输出、手动/自动切换不超调、不振荡、响应时间可接受协议联调串口命令解析、应答帧构造、CRC校验粘包不掉帧、错误指令不引发死机可靠性验证长时间上电、异常输入、传感器拔插不死机、不误动作、能自恢复代码审查控制流、边界条件、编译告警清零无UB未定义行为、栈底不踩穿我一开始就把这四块同时列出来有一个很实际的原因嵌入式项目里很多问题不是单一模块的问题而是模块之间配合出来的问题。比如PID输出给到PWM之后占空比映射是否正确只靠仿真看不出来串口协议如果不规范上位机稍有异常发送就会让解析状态机错乱。所以第三阶段我没有再按“先写代码再调板子”的顺序推而是“边写、边审、边测”让AI生成的每一段代码都尽快落到硬件上验证。这个思路本身也是前两个阶段踩出来的教训。第二篇里我让AI一次性生成了一个较大的驱动文件结果编译过了但下载到板子上之后GPIO复用配置是错的折腾了好几个小时才发现是HAL库的AlternateFunction设置不对。那次之后我的原则就变成了AI生成代码的颗粒度要控制在一个功能点以内写完立刻上板验证别攒一堆再查。2. PID算法写完后AI代码最需要人工复核的三个点第三阶段第一个大头是PID。网上关于AI生成PID代码的教程不少但大多数都是直接Copy一份纯粹的算法函数注释写得漂漂亮亮看起来天衣无缝。实际用下来会发现AI写PID算法本身确实不怎么犯错犯错的地方全在“和硬件相关的接口边界”以及“嵌入式特有的数值语义”上。2.1 位置式还是增量式AI默认选型的隐含差异我要求AI生成的是位置式PID因为这个小系统的执行机构是风扇转速需要的输出量就是当前时刻的占空比绝对值用位置式最直观。AI返回的代码结构很标准结构体定义、三个系数、一个Compute函数读一遍逻辑没有毛病。但这里我要提醒一个容易忽略的点位置式PID的积分项是累积误差如果上下限处理不好就会出现“积分饱和”温度一直偏高风扇却不会继续提速。AI生成的代码里其实做了输出限幅static float PID_Calc(PID_TypeDef *pid, float setpoint, float measurement) { float error setpoint - measurement; pid-integral error; float output pid-Kp * error pid-Ki * pid-integral pid-Kd * (error - pid-prev_error); pid-prev_error error; if (output pid-max_output) output pid-max_output; else if (output pid-min_output) output pid-min_output; return output; }但这里有个隐患输出被限幅了积分项却还在继续累加。一旦误差持续为正比如传感器探头被胶带裹住了温度迟迟到不了目标值积分项会一路狂奔到很大的值等误差反转时PID要花很长时间才能“还债”现象就是风扇转速骤降或者温度大滞后。这个坑在控制理论教材里反复讲过但AI生成代码时很少会主动做“积分分离”或者“积分限幅”因为提示词里没给这个约束。我采用的修正方案是加积分限幅同时把积分累加条件从“只要误差就加”改成“仅在未饱和时累加”if (output pid-max_output output pid-min_output) { pid-integral error; } if (pid-integral pid-integral_limit) pid-integral pid-integral_limit; else if (pid-integral -pid-integral_limit) pid-integral -pid-integral_limit;这个改动在提示词里如果写了AI也能直接给你一份带抗饱和的版本。关键是你在需求描述阶段就要意识到“我的执行机构存在输出饱和特性”不要默认AI能猜到。嵌入式场景里这类“隐含的物理约束”AI猜中的概率并不高。2.2 float和int混用编译通过不等于数值正确PID计算用float在STM32F103上没问题M3内核有FPU的型号算起来更快F103C8没有硬件FPU但几十微秒算一次PID也完全能接受。真正让我意外的是AI生成PWM占空比映射代码时的数值错误。我要的是把PID输出范围映射成CCR寄存器值。PI输出设定在0.0到100.0表示占空比百分比定时器ARR是999CCR范围0到999。AI第一版代码是这么写的uint16_t duty (uint16_t)(output / 100.0f * 999.0f);看公式没问题但AI没有在入口做限幅。如果output因为某些极端情况变成了105.0这个表达式结果会超过999CCR被赋了一个大于ARR的值。在一些STM32定时器配置里CCR大于ARR并不会报错但输出行为会变得很诡异——通道输出可能一直是无效电平你以为是电路接错了其实是寄存器给了一个“溢出”值。我在审查时给这段加了保护if (output 100.0f) output 100.0f; if (output 0.0f) output 0.0f; uint16_t duty (uint16_t)(output * 9.99f);同时把除法和乘法的顺序换了一下规避了一次多余的浮点除法。这里有一个数值细节output / 100.0f * 999.0f是先除后乘精度会稍稍损失改成output * 9.99f是先乘结果在1023以内保留的精度更高。对风扇控制来说这点精度差别无感但养成这个习惯以后做精确控制时会省掉不少麻烦。2.3 手动/自动切换的瞬间最容易忽略的bumpless系统支持手动模式和自动模式切换手动模式下直接给定占空比自动模式下由PID输出。这个切换逻辑如果没处理好会出现一个很恼人的现象手动模式下PID还在后台偷偷累计积分、刷新prev_error切回自动的瞬间输出值跳到PID当前计算值上风扇转速“咯噔”一下猛变。AI生成的第一版切换代码就没有做任何平滑处理。我在代码审查时加了bumpless transfer逻辑切换瞬间把PID积分清零、把prev_error重置为当前误差并且让PID输出从“当前手动占空比”开始递进。实现要点是提供一个初始化接口void PID_Reset(PID_TypeDef *pid, float current_output, float setpoint, float measurement) { pid-integral 0.0f; pid-prev_error setpoint - measurement; pid-output current_output; }然后在模式切换的case里调用这个接口。这一步做完了手动转自动后风扇转速几乎无感过渡。我建议所有做嵌入式AI协同开发的人在审查AI生成的代码时“切换”“使能”“复位”这三个词出现的代码块都要特别仔细看一遍因为AI生成的代码强项是稳定状态的逻辑弱项恰恰是这些瞬态和边界场景。3. 真机实测协议解析和延时逻辑把我按在地上摩擦PID和PWM这部分在板子上调通之后我进入第三阶段的第二个大头串口协议。这个系统的上位机是我用Python写的简易控制台发送类似TEMP_QUERY、SET_TARGET:35.0、MODE:MANUAL:70这样的ASCII命令。下位机需要做的关键事情是正确解析命令、执行动作、返回带CRC的应答帧。3.1 粘包断帧问题AI的解析代码根本扛不住AI生成的解析代码是典型的“简单粗暴”风格串口中断收到一个字节就往环形缓冲区里塞主循环里检测到帧头0xAA 0x55就开始按固定协议解析。这套逻辑在“随时只有一帧完整数据”的假设下没有任何问题但真实上位机发送时数据是连续的帧与帧之间可能没有间隔也可能因为系统调度导致接收被中断打断于是出现了两种经典问题第一种是粘包。上位机连续发两帧命令下位机的解析状态机处理完第一帧后缓冲区里还残留着第二帧的尾巴下次状态机被触发时从错误位置开始找帧头整体错位CRC校验失败命令失效。第二种是断帧。一帧数据被拆成两段到达第一段的CRC根本不够长度直接被丢弃等第二段到达时帧头已经不完整了。我把实际情况和复现步骤发给AI问它怎么改。它的第一版建议是“加大环形缓冲区”这个方案治标不治本。真正问题的根因是解析逻辑没有做成“边收边解析”而是“攒够了再解析”。我后来改成逐字节状态机每收到一个字节就喂给状态机状态机自己判断帧头、长度、CRC这样天然解决了断帧问题。粘包也在这个思路下直接消解——状态机只需关心当前帧后面的字节会自然触发下一帧解析。void UART_ByteFeed(uint8_t byte) { switch (state) { case FRAME_IDLE: if (byte 0xAA) { state FRAME_HEAD1; } break; case FRAME_HEAD1: state (byte 0x55) ? FRAME_LEN : FRAME_IDLE; break; case FRAME_LEN: frame_len byte; crc_calc 0; idx 0; state (frame_len MAX_FRAME_LEN) ? FRAME_DATA : FRAME_IDLE; break; case FRAME_DATA: crc_calc ^ byte; // 建议用查表CRC而非逐字节异或这里示例是简化版 if (idx frame_len - 1) { idx; } else { state FRAME_CRC; } break; case FRAME_CRC: if (byte crc_calc) { Frame_Dispatch(); } state FRAME_IDLE; break; default: state FRAME_IDLE; break; } }一个笨办法但有效状态机所有的if-else路径最终都必须回到IDLE状态否则解析逻辑必然有死角。这是我在这次改代码过程中最深的体会。3.2 AI推荐“加延时”抗干扰这是我这几年见过最致命的一条建议在我反馈“串口数据偶发乱码”之后AI给出的一条建议是“在接收字节之间加一点小延时比如10毫秒等一帧收完再处理”。这个建议我看了之后后背发凉。在嵌入式实时系统里用延时去“等数据”是最典型的反面教材串口接收本身就靠中断保证不丢字节你在解析线程里加一个10毫秒延时意味着主循环的响应周期从微秒级直接退化到毫秒级PWM控制、按键扫描、看门狗喂狗全部被拖慢。我后来排查乱码发现真正的凶手不是时序而是参考电压噪声。这块板子的模拟部分和数字部分共地走线不太好风扇启动瞬间电流波动导致VDDA纹波偏大USART的采样点被干扰。解决方式是软件层面加强了帧格式的健壮性帧头多校验一个字节硬件层面在风扇供电处加了一颗100uF电解电容。这件事让我再次确认AI给出的“建议”只能当思路参考绝不能当解决方案直接落地尤其是涉及实时性和电平时序的建议一定要自己想清楚机制再决定动不动手。3.3 异常输入的压力测试这件事别偷懒协议联调快完成时我顺手做了一轮异常输入压力测试这也是这次项目里我觉得最有价值的一次测试。我把串口调试助手的“定时发送”功能打开每隔30毫秒自动发一组乱码长度从1字节到80字节不等同时把风扇切换到自动模式观察板子会不会死机、PWM输出会不会乱跳。结果发现两个Bug。一个是解析状态机在收到超长帧时frame_len被限制在了一个范围内但数据域的索引没有做边界检查如果帧头后跟的长度字段超过了缓冲区实际大小字节会被写到缓冲区外造成栈破坏。这个Bug是标准的“经典缓冲区溢出”AI代码里出现了我的审查也没第一时间发现直到压测时程序进HardFault_handler才定位到。修复很简单idx递增前判断是否到达frame_len - 1同时对frame_len做一个严格上限判定。另一个Bug是热敏传感器的读取函数在传感器被拔掉时会卡死。DS18B20是单总线协议时序要求比较严格AI生成代码里用了while (GPIO_ReadPin(...) ! RESET);这种死等循环传感器不响应时这个while永远不退出整个控制循环都被吊住。改成带超时退出的机制后传感器拔掉时系统能报告“传感器错误”而不是死等。这两个问题几乎都是“AI生成边界处理盲区”的典型标本强烈建议读者在信任AI代码前专门做一轮这种“往死里折腾”的测试。4. 反编译与对照分析AI生成代码里看不见的优化真相这个部分我本来没打算写但实测过程中遇到一个性能问题追问到汇编层面才找到答案觉得对做嵌入式的人特别有参考价值就一并记录。现象是这样的在自动温控模式下风扇转速变化有一种“一卡一卡”的感觉不是平滑过渡。从控制逻辑上检查PID输出确实是逐步变化的PWM也不需要频繁更新CCR理论上不应该出现卡顿。我最初怀疑是上位机刷新率问题后来排除。然后用逻辑分析仪抓PWM输出波形发现CCR的更新间隔居然出现了几十毫秒级的毛刺。定位到最后问题出在AI生成代码里的一个“低通滤波”函数上。AI用了一个很取巧的低通写法static float filtered_value; float filtered filtered_value alpha * (raw - filtered_value);alpha是编译期常量0.1f。这个写法本身没问题计算量小效果也不错。但关键是这个函数被放在了主循环里而且它依赖的filtered_value是全局变量。编译器在默认优化等级-O0下每次读取全局变量都会重新从内存加载这个成本不算大但有一次我为了减小固件体积开了-Os优化编译后功能居然出现了温漂同一温度下滤波结果的偏差明显变大。4.1 用反编译工具看AI代码的真实执行路径我把优化后的固件用反编译工具打开找到那段滤波函数的汇编代码立刻发现了问题在-Os下编译器把这个函数的alpha计算改成了一系列移位和加法近似精度下降了。这不能全怪AI任何写alpha 0.1f的代码在高度优化时都可能被激进地近似。但AI生成代码时往往是“最好的平台无关伪代码”完全没考虑目标MCU的寻址方式、优化等级和浮点行为差异。这里我想给一个非常实用的建议当AI生成的算法代码在改动优化等级后出现行为差异时别急着改算法先用反编译工具比如免费的Ghidra或者商用IDA只要不涉及破解别人固件用于分析自己编译的产物完全合规看看汇编确认是不是编译器做了“聪明”的变换。很多时候你会发现不是逻辑错而是浮点近似被优化变了。修复方式可以是把那个函数的alpha定义改成volatile const或者单独给那个文件指定较低的优化等级。4.2 栈深度的分析也是反编译能帮上忙的这个项目的代码里有一处递归调用是用二分查找法在表格数据里查温度补偿表。AI生成这段代码时我没有在意因为递归深度很浅最多三四层。后来有一次我把告警阈值改大了一倍程序开始不定期跑飞。用map文件查栈段才发现每层递归要消耗约120字节的栈空间加上中断嵌套的消耗默认1K的栈很容易就顶穿了。我最后用反编译工具确认了每层调用的实际栈帧大小然后把递归改成了非递归的二分查找实现栈消耗降到几十字节。这类问题在PC上完全不是事在MCU上就是摔得鼻青脸肿。反编译工具在这个场景下的作用不是“破解”而是让你直观看到每一行C代码在目标平台上的真实开销——这对嵌入式开发来说比优化等级数据可靠得多。5. 嵌入式场景的提示词工程不是“写代码”而是“写约束”项目走到这个阶段我对“AI协同开发”应该怎么分工已经比较有数了。很多做嵌入式的人一上来就问“什么AI编程软件好用”实际上工具差异没有想象中大真正拉开差距的是提示词的写法。我用的主力是Codex的命令行模式但下面这几点方法换到其他流行AI编程工具同样适用。5.1 给AI一个“硬件边界”清单而非抽象需求最典型的错误提示词是“写一个串口解析函数能处理数据帧”。这在小项目里勉强能跑但换到嵌入式环境就漏洞百出。我会把硬件边界直接写进提示词请为STM32F103C8T6编写一个串口帧解析状态机。 约束 - 使用HAL库串口句柄为huart1。 - 帧格式帧头0xAA 0x55长度字段1字节数据N字节CRC校验1字节。 - 缓冲区长度为256字节收到超过长度上限的帧时丢弃并重置状态。 - 不得使用阻塞延时必须在中断回调函数中逐字节调用ByteFeed。 - 对无效帧头、CRC错误、长度超限必须做静默丢弃不得影响下一个帧的解析。 - 需满足在连续高频发送时每帧间隔小于1ms不丢失正确帧。这看起来像是“多写了几行字”但实际上是把可能出问题的所有边界条件全部前置声明AI生成出来的代码会从源头上就处理掉这些分支而不是让你写完再一个个补。5.2 用“错误模式预埋”缩小AI的胡猜空间AI生成代码时的一大特点是你给它一个模棱两可的需求它就会自己去“补全”而它补全的方式是从训练数据里统计出来的“最常见写法”不一定是你的硬件要的。这时候就需要预埋错误模式。比如我让AI写单总线读取DS18B20的函数时特别要求“对传感器无响应情况必须设置超时退出并返回错误码推荐超时时间为2ms”。AI在代码里果然按超时时间加了退出逻辑并在返回错误码的同时置了一个全局error标志。如果我没有在提示词里写这点它大概率只会写一个死等循环——它见过太多入门教程里的“标准写法”。同样重要的是指定“不要”什么。我经常在提示词后面加一句“注意不要使用HAL_Delay不要修改SysTick配置不要使用全局中断屏蔽。”这些限制看似苛求实际是因为在多数AI训练语料里简化示例经常直接调全局延时或开中断而这些在真实工程里都是雷。5.3 让AI换个角色做“代码审查”这个技巧是我这次项目后期才发现的。代码写完、跑通之后我不直接让AI“改进代码”而是让它以“一个只懂编译器行为的老工程师”的身份对代码做一轮严格的review。它不会只看逻辑会关注数据竞争、类型转换、未初始化变量、状态机死角、缓冲区边界这类让新手抓狂的东西。这个方法比“帮我优化一下”有效得多后者常常带来一堆不必要的抽象重构。给一个我常用的review提示词模板请审查下面代码。你的身份是嵌入式系统专家关注点包括 1. 所有变量在使用前是否都已初始化。 2. 是否有任何循环缺少退出条件。 3. 是否有任何类型转换可能导致数值错误。 4. 串口中断与主循环之间是否存在竞争条件。 5. 函数的最大栈消耗是否可能超过给定值。 6. 是否禁止使用浮点在中断处理中。 对每个问题给出严重等级和修复建议。这轮review帮我在PID控制循环里找出了一处未初始化局部变量、在PWM更新逻辑里找出了一处理论上可能写越界的索引计算。都是那种“运行一万次不出错第一万零一次出事”的问题。用AI“审”AI生成的代码本质上是利用大模型庞大的语料覆盖不同的错误模式这个思路在当下是性价比最高的用法之一。6. 复盘这个项目AI协同开发改变了我的哪些习惯如果只看代码生成速度这个项目的AI协同开发效率提升大概是三倍纯手写这些逻辑加调试我最少要两个整天这次压缩到了一个周末加两个晚上。但速度其实不是最关键的收获真正的变化在于我写代码的习惯和心态。以前我做嵌入式项目习惯是“先写完整份代码再上板调试”。痛点很明显一旦硬件有问题你根本分不清是代码逻辑问题、芯片配置问题还是电路问题。这次用AI协同开发反而把我推向了另一种节奏AI每次只产出一小块功能代码我立刻写完边界审查、编译、烧录、测试通过之后再让AI出下一块。每一块代码在板子上的行为都是可追溯的问题定位范围被压得很小。还有一点更微妙AI生成的代码“敢写”人也跟着敢折腾了。以前遇到DS18B20时序问题我可能就绕着走直接换一个I2C温度传感器。但这次因为AI几秒钟就能给出一个单总线时序实现我会愿意去实验它、修正它最终把单总线时序彻底搞明白了。这让我意识到AI编程最大的增量价值不是“代替我写代码”而是“降低试错成本”让我愿意去碰那些以前觉得“太麻烦”的底层细节。这对嵌入式工程师的能力成长来说反而是最值钱的部分。我另外想提醒的是AI用的好不代表你的基本功可以不要。这次项目里几次最痛苦的排查最后都落回到“我对MCU的启动流程、栈布局、外设寄存器行为是否足够熟悉”这个基础上。AI可以帮你生成90%的代码但剩下10%的排查、审查、硬件适配才是工程师真正的溢价所在。如果你看到这里正准备尝试第一个AI协同开发项目我的建议很直接挑一个你熟悉的硬件平台把AI当成一个“手速极快但没有硬件常识的实习生”你出边界和验收标准它出实现你们俩一起review然后上板验证。跑通一个完整闭环之后你会对这个工作方式有自己的判断。