1. 这病是怎么染上的先说清楚我口中的“AI病”是什么就是那种打开编辑器先跟大模型聊几句让AI帮你把寄存器配好、把状态机搭好、把协议栈写好自己只负责“审代码”和“点编译”的坏毛病。这事儿最早是在PC端写业务逻辑时染上的用AI生成了几段工具脚本效率确实高得吓人。于是某个周二的下午我在调一块模拟项目X的传感器采集板时顺手把AI生成的I2C初始化代码粘进了工程想着省点查数据手册的时间。那一刻我就把病带进了嵌入式世界。我估计不少同行跟我一样最初只是把AI当“超级搜索引擎”用——查函数签名、问某个外设寄存器的含义后来胆子越来越大开始让AI写中断服务函数、写低功耗状态切换甚至整块板子的启动代码都想让它包办。这篇东西不是劝你远离AI恰恰相反我是想把染病之后踩出来的经验教训摊开讲清楚哪些场景下AI是真提效哪些场景下它只会一本正经地给你挖坑。适合所有正打算在嵌入式项目里引入AI辅助开发的工程师也适合那些已经被AI坑过一回、有点怀疑人生的朋友。2. 嵌入式工程师的AI“幻觉”重灾区跟搞Web开发的朋友聊AI编程他们普遍感觉“八九不离十”改改就能跑。但到了嵌入式这边AI生成代码的可用性至少要打个对折。这不是AI变笨了而是嵌入式代码的验证回路太长了——最普通的Web代码错了能立刻在浏览器里看到报错单片机代码错了可能就是上电五分钟之后看门狗复位或者低温环境下偶发一次I2C死锁排查成本天差地别。2.1 寄存器与位操作的经典翻车我让AI生成过一段GPIO外部中断配置芯片是某款常见的Cortex-M0内核MCU。AI给出的代码从结构上讲完全没毛病开时钟、配模式、拉中断优先级、使能中断。但仔细一看配置上升沿和下降沿的位写错了把本该是第1位的写成了第2位。这种错误在代码评审时非常隐蔽因为语法完全正确编译也能过只是硬件行为完全不对。位操作更是重灾区。有个朋友接过一段AI生成的代码里面用GPIOA-ODR | GPIO_PIN_5;来点亮LED看似没问题但如果这段代码处在中断和主循环并发访问同一个端口的场景这种读-改-写就不是原子操作了轻则LED闪烁异常重则整个输出端口被打乱。最典型的是AI特别喜欢给你生成那种“看起来很规整”的位域结构体把一个寄存器的各个位声明成uint8_t位域这在ARM编译器下还好换到特定编译器就可能出现位域分配顺序不一致的问题板子在A环境跑得好好的换到B环境就全乱套。我总结了一个判断方法寄存器操作类代码AI生成的都不能直接信必须逐位对着数据手册核对。那种“使能”“配置”类的代码AI本质上是在凭空猜测寄存器地址和位含义它如果没被训练过这颗芯片的官方库生成的东西基本等于随机数。2.2 内存、编译与硬件的隐形陷阱嵌入式的内存布局跟PC程序完全是两个世界。普通的C程序在PC上跑了能出结果就行单片机程序要面对Flash容量、RAM上限、栈大小、对齐方式、大小端、volatile语义、编译器优化选项这些一大堆约束。AI不太能理解“这里为什么要加volatile”。我给过一个真实案例让AI检查是一个环形缓冲区生产者与消费者模型AI回复说这里可能不需要volatile建议去掉以提升性能。但那段代码的缓冲区是在中断里写入、主循环里读取的去掉volatile之后编译器开了O2优化读缓冲区内容的循环直接被优化成了死循环。这就是AI典型的“纯软件思维”它理解C语言标准里的未定义行为但理解不了硬件外设在中断里改内存这个场景的真实时序。还有个坑是内存对齐。有一次让AI帮忙设计一个通信协议解析结构体AI贴心地用#pragma pack(1)把所有字段都紧密排布了这让结构体读取外设DMA传来的数据时很方便。但后续代码里有个地方直接把这个结构体指针传给了某个需要四字节对齐的算法模块结果在启用FPU的芯片上触发了硬件错误。这些知识AI都知道但它不会主动问你“这个结构体之后要传给谁”它只会根据当前这句话的上下文把代码补完。2.3 实时性与并发带来的“软件病”AI的另一个通病是不把“实时性”当回事。它生成的初始化代码里喜欢放HAL_Delay(100)这倒还好但有一次它给我生成了一段中断服务函数里面居然调用了带阻塞等待的I2C读函数还煞有介事地处理了超时返回错误。表面看代码很健壮实际上在中断里做阻塞式I2C通信在低速I2C从设备场景下可能导致系统挂死因为中断服务函数拖着整个系统的调度跑。还有一次更离谱我让AI生成一个低功耗管理的状态机它从“空闲-采集-发送-休眠”搞了一套完整的状态转移看起来非常专业。但它的休眠唤醒方式是配置一个定时器中断而唤醒之后直接就进入下一个状态的代码在中断上下文中执行了压根没有退出中断低功耗模式的动作。板子实测就是睡下去起不来。做嵌入式的人都知道一条铁律中断服务函数里尽量只做标记、搬运、置标志这类短平快的事复杂逻辑丢到任务或主循环里。AI不理解这条铁律因为它在互联网语料里学到的编程习惯偏应用层。所以我后来给自己立了个规矩——涉及中断、低功耗、并发共享变量的代码AI只能用来生成“初稿框架”具体逻辑必须自己亲手重写。3. 治“病”的处方一套能落地的AI协作流程踩了足够多的坑之后我慢慢摸索出一套相对好用的协作方式。不是彻底不用AI而是给它划定清晰的边界同时给自己建立一套代码审查的流水线。3.1 让AI做它擅长的从问题到代码的合理切分我习惯把所有嵌入式开发任务分成四层每一层对AI的信任度完全不同。任务层次典型内容对AI生成代码的信任度建议工具链与脚本编译脚本、烧录脚本、日志分析脚本高可放心让AI生成人工检查逻辑即可业务逻辑状态机、协议解析、数据处理算法、UI流程中高可用AI搭骨架但边界条件和异常分支要特别检查芯片适配层寄存器配置、外设驱动、启动代码、链接脚本低只让AI做梳理和翻译不能直接抄硬件相关实时逻辑中断服务函数、低功耗切换、DMA描述符管理、并发共享访问极低核心逻辑自己写AI仅做Code Review的辅助实际使用中我发现把任务切得足够细AI的表现会明显变好。比如不让它写“一套完整的Modbus从站协议”而是让它写“一个CRC16校验函数输入为指定格式的字节数组输出为校验值附带一组测试用例”。这种小而明确的任务AI几乎不会犯错而且省掉了我手写查表的功夫。反过来那种“实现一个完整的低功耗传感器节点”的宏大需求AI给你的东西看起来五脏俱全实际上是定时炸弹最后你花在排查它埋的雷上的时间比从头写还多。3.2 设计一份“嵌入式专用”的提示词模板有意思的是很多嵌入式工程师用不好AI问题出在不会提需求。拿写代码来说你直接说“帮我写I2C初始化”AI只能给你一份平均水平的通用代码大概率跟你手头芯片的外设基地址对不上。但我把需求描述改成下面这样生成质量立马上一个台阶。请生成基于某公司某型号Cortex-M3 MCU的I2C1主机初始化代码要求 - 使用该厂商标准外设库版本号x.y.z或寄存器操作均可优先寄存器操作 - 时钟频率为外部晶振8MHz经过PLL倍频到72MHzI2C时钟目标为400kHz - 使用GPIOB的Pin6和Pin7作为SCL与SDA配置为开漏复用功能并使能内部上拉 - 不要使用阻塞等待初始化之后立即返回传输状态由中断标志位管理 - 请注明每个关键寄存器配置的依据数据手册的章节或寄存器位名称这么写的效果是天差地别的。你告诉它寄存器名称、引脚编号、时钟树结构、使用场景它才能从语言模型里检索出真正对应的配置逻辑。还有一个好用的技巧让AI把数据手册里的寄存器描述表格贴回给你让它逐行翻译成代码配置相当于让它做“卷积”而不是“推理”生成结果更精确。我的体验是提示词里至少要有这四样东西芯片具体型号、总线时钟来源与频率、用到的外设和引脚、代码运行上下文中断环境还是主循环、是否会被并发调用、对时延的要求。缺了任何一个AI就会用它在其他项目里见过的概率分布去补全而你无法控制这个分布跟你当前芯片是否吻合。3.3 把AI的代码当成外援代码来审查我不管AI生成的代码看起来多顺眼一律按照“外援代码”的标准来处理——也就是假设这里面有不知道多少雷然后有计划地排雷。具体走三遍第一遍编译和静态检查。把AI代码拿进来先用最严格的编译警告级别编译开-Wall -Wextra有警告就直接打回让AI重写。嵌入式编译器一般还有静态分析工具或者代码规范检查工具把AI的代码丢进去跑一遍能揪出不少未初始化变量、隐式转换、悬空指针这类低级问题。第二遍人工差异对照。这步不能省。我会把AI生成的代码跟数据手册里的寄存器描述表、官方示例代码、往期项目里验证过的代码做一次逐行对照。重点看三处寄存器地址和位定义对不对、波特率或时钟分频系数算得对不对、字节序和位序是否跟外设需求一致。这一步最枯燥但也是最能救命的一步。第三遍硬件实测验证。上板子跑不只是看功能对不对还要看边界条件。比如它生成了一段环形缓冲区的代码我会故意往缓冲区里塞满数据再继续写看看它有没有正确处理溢出生成了一段睡眠唤醒代码我会验证唤醒后外设状态是否完全恢复会不会有某个标志位残留导致行为错乱。边界条件AI最容易漏但恰恰是硬件上最难查的故障来源。注意任何AI生成的代码在合入主线前至少要跑过一轮针对边界条件的硬件测试。别相信“它看着没问题”实际上板就是另一套故事。4. 拆解一个真实病例某低功耗节点的一次完整调试光讲原则不够我拿一个完整的病例来复盘。这是我自己做的一个低功耗环境监测节点核心是一颗主流Cortex-M4 MCU外挂温湿度传感器用Sub-GHz无线模块周期上报数据目标功耗是平均电流小于某个微安级别。这个项目我刻意全程用AI辅助开发想亲眼看看它到底能帮多少、坑多少。4.1 项目背景与“病历”主控选的是某厂家Cortex-M4内核的低功耗MCU外设包括一个I2C接传感器、一个SPI接无线模块、一个RTC定时唤醒、一个低功耗串口用于调试输出。系统的工作循环是RTC定时器每5分钟唤醒一次MCU读取传感器数据通过无线模块发送然后重新进入停止模式。这个项目的难点不在功能本身而在低功耗状态的控制从进入停止模式到唤醒后恢复时钟再到外设重新初始化这中间任何一步出错都可能导致系统死机或电流异常。我当时把整体框架和初始化代码都丢给了AI生成自己专注做验证和集成。4.2 从生成代码到烧录跑飞的处理过程第一版AI代码烧录之后的现象非常典型系统能正常工作大约20秒然后电流突然飙升到正常工作时的若干倍之后没有任何输出。我用电流表观察发现MCU实际上是醒着的但外设时钟和低功耗模式配置乱了它一直在某个高频状态空转。排查过程从日志开始。我把AI代码里所有能加打印的地方都加了跑了一轮之后发现唤醒之后有一个外设注册失败的返回值但代码里根本没检查这个返回值直接继续往下跑了。这暴露了AI代码的第一个通病假设所有初始化都成功缺少错误传播机制。我继续在线调试停在唤醒后的第一行单步执行到进入停止模式前后的函数发现了问题所在。AI代码在进入停止模式前关闭了若干外设时钟但唤醒后只重新使能了其中一部分漏掉了一个关键的定时器模块。更隐蔽的是它在唤醒代码里重新初始化了一个DMA通道而这个DMA通道在进入停止模式前根本没有被释放或者复位唤醒后重启就直接挂在了某个等待完成信号的地方。跟AI对话复盘时它给自己辩解的逻辑很有意思它说“这个外设不需要每次唤醒都重新初始化因为进入停止模式不会丢失寄存器配置”——从芯片参考手册的角度讲这可能没错但工程实际中唤醒时序和时钟稳定时间会导致某些外设第一次访问就触发错误标志。这种“手册上没错实际上跑不通”的案例恰恰是AI最不擅长把握的。4.3 复盘哪一步省了时间哪一步是负优化我记了一下整个项目的时间账。整个开发大约花了两周其中AI参与的部分大约是生成初始化代码、生成协议解析框架、生成测试用例、辅助排查唤醒异常。环节手工开发的估算时间AI辅助实际花费评价外设初始化代码2天3小时生成 4小时核对寄存器小幅提效核对耗时比想象中多通信协议与数据处理3天1天生成测试提效明显低功耗状态切换与唤醒恢复4天6天含大量排查负优化AI把坑埋深了问题排查与调试3天4天负优化省下的时间都在排查中加倍还了回去综合算下来有经验的工程师在这个项目上可能只需要10天而我用AI辅助花了14天。真正让我省时间的只有协议解析和测试代码而低功耗部分不但没省反而因为AI生成的错误路径把排查引向了错误方向。最讽刺的是那些AI写得很“完美”的寄存器配置恰好是最需要花时间去验证的部分——因为完美的代码会让人放松警惕。5. 这病要不要彻底治我的最终建议做完这个项目我认真想过是不是彻底回归手写代码。我的结论是AI病不用根治但要学会跟症状共存。前提是把AI放在“辅助参考”而不是“主力编码”的位置上把验证放在心上而不是盲目相信生成结果。5.1 病态与共存的边界哪些场景我现在还会继续让AI写一方面是算法性和协议性的代码比如CRC校验、环形缓冲区、状态机框架这些语言层面逻辑清晰的代码AI生成质量高还自带边界处理的思路省心。另一方面是脚本和胶水代码比如编译辅助脚本、日志分析工具AI写出来的健壮性甚至比我自己写得还好因为这类需求在互联网上有海量语料可以学习。哪些场景我坚决不用AI中断服务函数和低功耗状态切换是两条红线这辈子都不会再让AI碰。还有一个容易忽略的场景和硬件时序强相关的代码比如某种特定传感器的上电时序、某个射频模块的冷启动等待时间这类时序参数既不在AI的知识结构里也不在它的推理能力范围内它写出来的时间参数纯属“文学创作”。如果要给一个信任分值的话我是这么排的代码场景信任分满分10说明工具脚本9基本可以直接用改改参数就行算法实现7逻辑没问题边界条件需自查协议解析6能用但对异常帧的容忍度太低外设初始化4寄存器位定义需逐位核对中断与低功耗2不自己重写不敢上板5.2 给同行的一些“抗病”建议第一给AI生成的所有代码打上标记。我在代码注释里统一用[AI-assisted]标注这样代码评审的时候大家对这段代码的关注度会自动提升相当于给自己设了一道心理屏障。别小看这个动作它能让你的审查效率提高不少因为你不用每次都提醒自己“这段要不要认真看”。第二任何AI生成的代码都要过一遍最小验证路径。再简单的功能也要单独写个测试在最小系统板上跑通。比如AI生成一个I2C读取函数你就写10行代码单独调用它读一次传感器寄存器别等整个系统联调的时候再发现不对那时根本分不清是哪里出的问题。第三千万不要在深夜信任AI。我发现一个规律白天精力好的时候AI生成代码里的错误我基本能一眼扫出来但凌晨犯困的时候我倾向于接受AI给出的“看起来合理”的答案把隐患放过去了。所以我的规矩是AI生成的代码要在精力最好的时候审审不过的第二天再审一遍。第四维持读数据手册的能力。这是最重要的一条。AI再强它能帮你查手册、翻译寄存器、生成代码但理解芯片行为和硬件时序的本事终究要长在自己身上。我在项目里用AI省下的时间最后都花在看书和写验证代码上这不算亏因为能力是自己的AI给你的东西永远是别人的。最后分享一个我目前一直在用的小技巧让AI生成代码之前先让它把“它准备怎么做”用文字写出来你确认思路没问题了再让它落成代码。这一步看着多花几分钟实际上能挡掉一半以上的返工。思路都不对代码写得再漂亮都是零。