前几天我在工位调一个I2C触摸屏驱动，改了快两天还是偶尔出现一次通信失败。后端组同事路过看了一眼说：“哥，这代码要不扔给AI试试？”我当场有点无语。后来我真的扔给AI试了——结果不是它写不了，而是它“能写”这件事本身，逼着我重新想清楚嵌入式开发里到底什么才是人的核心价值。
Vibe Coding这个概念是去年初开始在开发者圈子里热起来的。有人以为它是个新工具、新软件，还要搜“vibe coding下载”，其实它指的是一整套“让AI主导写代码、人来描述意图和审查结果”的工作方式。在Web、后台这类即时反馈很强的领域，这套方式已经相当成熟了。但在嵌入式开发这边，讨论一直两极分化：一拨人说AI碰不了底层，一拨人说全套交给AI省事到底。我的经验是，两边都不太对。这篇文章我想基于自己这一年多在真实项目里用AI做嵌入式开发的经历，把哪些场景好用、哪些千万别碰、以及工作流到底应该改成什么样，一次讲清楚。
1. Vibe Coding的“轻松感”和嵌入式开发的“硬约束”天生有摩擦
先说清楚Vibe Coding到底是什么。这个说法流行开来后，很多人把它误解成“随便写写提示词、躺着等AI出代码”。但真正用过之后你会发现，它的核心不是“偷懒”，而是一种工作重心的转移：你负责描述系统、定义行为、判断边界，代码生成这件事本身交给模型去完成。就像以前建筑师要亲自画每一张施工图，现在建筑师只需要把设计意图讲清楚，让制图员去画，然后自己审核图纸有没有违反结构安全。这种模式在Web开发里特别顺，因为反馈链路极短——AI生成一段代码，刷新浏览器，立刻就能看到结果，错了马上改。
但嵌入式开发完全是另一回事。代码只是“和物理世界对话”的中间层，真正的难点在于代码之外的无数隐含约束：时序、电平、中断优先级、电源状态、外设寄存器的上电默认值。你用AI生成一段看起来很合理的初始化函数，编译能过，但烧进板子里可能第一个while循环就卡死。这不是AI生成能力的问题，而是嵌入式领域的“结果验证成本”实在太高了。
所以嵌入式圈子里那两种极端声音，我都不太认同。一种说“AI根本写不了嵌入式”，这类人通常只试了一次，AI给了一段有瑕疵的代码，就直接给它判了死刑。另一种说“把整个固件需求丢给AI，自动生成完事”，这种更危险，因为AI特别擅长一本正经地胡说八道——它会把时钟树配错，会把GPIO的输出模式当成输入模式用，甚至会在ISR里放一个delay()，然后信心满满地告诉你这很稳妥。用过几次之后我的结论是：AI可以承担“手”的角色，但“脑”和“眼睛”还得是人。这也是“Vibe”这个词最准确的含义——你要对整个系统保持感知，只是不再把精力花在逐行敲键盘上。
2. 嵌入式真正的瓶颈不在“写不出代码”，而在“定义边界和排除故障”
在讨论怎么用AI之前，得先把嵌入式开发这件事拆开看。我们每天的工作构成大致是这样的：
- 理清硬件行为：读datasheet、看时序图、确认电平匹配
- 定义软件架构：模块怎么划分、接口怎么设计、错误怎么传播
- 资源规划：Flash够不够、RAM还有多少、CPU占用能不能压住
- 调试和验证：上板子跑、抓波形、看日志、定位那个“偶尔出现”的邪门bug
你会发现，真正吃掉项目时间的大头，很少是“把代码从0敲到1000行”。而是“为什么波形不对”“为什么概率性通信失败”“为什么上电偶尔起不来”。这些问题里，AI根本看不见硬件，它只能看到代码层的表面逻辑。代码，只是你把硬件约束翻译成处理器指令的一种形式。
这里必须指出三个天然矛盾，决定了Vibe Coding在嵌入式里不能照搬Web那套玩法。
第一个矛盾是反馈滞后。Web改一行代码刷新就能看到结果，嵌入式一个bug可能三四天才复现，而且复现条件跟温度、电压、甚至周围的电磁环境都有关。AI在生成代码时完全感知不到这些，它只会按照“大多数情况下最标准的写法”来输出。可嵌入式项目往往就死在这些“大多数情况”之外。
第二个矛盾是资源约束。AI生成代码默认走“通用、稳妥、健壮”的路线，典型表现是加一堆防御性判断、错误处理、日志输出。在拥有几个GB内存的服务器上这完全没问题，但在一个Flash只有64KB、RAM只有8KB的单片机项目里，AI生成的日志模块里一个sprintf就能把Flash吃穿，再带上动态内存分配还会引入碎片问题。资源约束体现在每一个代码决策里，这种“抠门式”编程思维，恰恰是大模型最不擅长的。
第三个矛盾是环境差异。交叉编译链版本、芯片厂商外设库的API演进、不同批次芯片的勘误表——这些东西在AI的训练数据里新旧混杂，它很容易用老版本库的写法生成新工程代码。我就遇到过AI用STM32标准库语法去写HAL工程的情况，编译报错不算最麻烦的，麻烦的是那种“能编译、能运行、但行为和你预期不一样”的代码，排查起来才真要命。
所以，纠结“AI能不能写嵌入式代码”其实是个伪命题。更准确的问题是：在代码之外的那些判断性工作里，AI能不能帮你减少重复劳动，让你把时间省下来去盯真正要命的部分。想清楚这一点，才能谈“哪些活交给AI是划算的”。
3. 实测最好用的一类：把嵌入式里的“翻译活”交给AI
我自己这一年试下来，AI在嵌入式开发里性价比最高的场景，其实都不是“从0帮你写出一个固件”。而是一批可以被归为“翻译”的工作。
3.1 场景一：芯片手册里的寄存器配置，翻译成C代码
单片机开发有一个很重但没什么技术含量的事：把datasheet里十几页的寄存器初始化说明，改写成工程里的C代码。以前我得照着PDF一行一行看寄存器地址、位域含义、默认值，再手工敲成宏定义和结构体。现在我的做法是：直接把寄存器表格的关键信息整理成文本喂给AI，让它生成结构体定义、初始化函数、读写接口，并且明确要求在生成过程的最终代码里保留寄存器地址原样、注释每条配置的作用。
这类任务AI完成得相当靠谱，因为它有明确的参考源和目标格式，而且错误容易暴露——寄存器地址错了编译能看出来，位域含义理解错了也可以对照手册快速复查。AI做这个事，和照着手册手抄在效果上没区别，但速度快一个数量级，我试过最顺利的一次，是我把TouchGFX的底层接口定义丢给它，让它生成一个移植层适配文件，本来要干一下午的活在半小时内完成，而且后续烧录验证确实没出问题。
3.2 场景二：临时脚本、上位机辅助工具、测试脚手架
嵌入式开发里还有一大片“周边代码”：解析串口日志的Python脚本、批量加校验和的烧录工具、从Excel器件表生成C枚举定义的小程序、给老模块补注释和头文件说明。这些代码和硬件没有直接耦合，或者耦合很弱，就算出错了也能很快发现并修正，所以让AI来生成特别合适。
举个例子，我经常需要维护一个firmware_version.h，每次发布要改版本号、编译时间、Git提交哈希。以前这事靠手工填，老是忘。我用AI生成过一个几十行的Python脚本，每次构建前自动读取最新的提交信息写入头文件。类似这种“一次性辅助代码”，AI几乎是零门槛就能做对，而且它做完后我再检查一遍也没什么成本。
3.3 场景三：算法移植前的框架搭建和模拟外设的测试桩
还有一个容易被忽略的好用场景：让AI先搭好一个传感器驱动的外围框架，核心算法留给你自己填，或者反过来，算法你写好了，让它生成配套的Mock层和单元测试。我来描述一下这个场景的实际操作：模块接口我已经在文档里定义好了，AIFill只是实现填充。比如我让它写一个BME280温湿度传感器驱动的框架，要求内部按“复位、读取校准参数、配置模式、读取原始值、校准换算”的层次拆函数。AI生成的代码往往结构非常干净，因为这种驱动在训练数据里实在太常见了。剩下的滤波、异常值剔除、动态校准逻辑再自己填。这么干的好处是，AI不碰核心算法，你对自己的业务逻辑保持完全控制；同时那些“模板化”的传感器寄存器操作，确实没必要人肉重敲。
做这些的时候，我慢慢总结出一个判断标准：交给AI的任务必须是“错误能被快速暴露、结果可被对照验证、不涉及硬件时序”的那一类。满足这三点，你就可以大胆用。反之，就要慎重。
4. 实测不能碰的一类：启动代码、中断、时序和低功耗
如果上一节是“哪里好使”，这一节就得说“哪里千万别硬来”。我自己踩过坑，也看过同事踩过更大的坑，这些领域到现在我基本不指望AI能一步到位。
4.1 启动代码和链接脚本：出错成本最高，AI偏偏最爱乱发挥
链接脚本、启动文件、向量表、堆栈和堆的大小划分——这类文件的特点是“隐含约束极多，而且错误不在编译期暴露”。Flash地址算错了、堆栈设太小、向量表偏移写错，烧进去以后的表现就是“上电不断重启”，或者“运行几分钟莫名其妙进hardfault”。最坑的是，这种问题你用调试器查，一开始根本不知道是链接脚本的问题，会先去怀疑GPIO配置、怀疑外设初始化。
我吃过一次亏。当时图省事让AI生成一个STM32H7的链接脚本，它给出来的布局看起来井井有条，但实际上把RAM区域的起始地址算偏了。烧进去以后板子疯狂重启，我用调试器跟了半小时，最后才灵光一闪打开.map文件看了下内存布局，发现某个段被放进了不该放的地址。那次经历的教训是：启动相关代码我从那以后全部走厂商官方模板，或者手工核对每一处地址，AI生成的只能当参考，绝对不敢直接烧录。
4.2 中断服务函数和DMA配置：AI容易忽略“上下文的世界观”
中断服务函数是嵌入式开发里最考验“时间敏感思维”的地方。要求在几微秒到几十微秒内完成关键处理，必须考虑共享变量的原子性，还要清事件标志。AI生成的ISR经常是什么风格？在中断里调用带延时功能的函数，或者调用了不可重入的库函数，更常见的是漏掉事件标志的清除。
我有一次让AI生成一个串口接收中断的处理逻辑，它写得洋洋洒洒，包括环形缓冲区的写入和回调通知，逻辑看着完美。但真到板子上，一旦收到大量数据就出现随机丢失。最后查出来，它在ISR里读取数据时切换了一次缓冲区索引，这个操作在单核裸机上本来没问题，但因为它把另一个外设的中断优先级改错了，导致两个中断之间发生了竞争。这类问题不是AI“写错”，而是它根本不了解你的系统里有几个中断、各自的优先级和调用关系。DMA配置也是重灾区——内存对齐要求、缓冲区生命周期、传输完成中断里还能不能安全访问数据，这些靠“通用代码”根本防不住。
4.3 低功耗设计和复杂时序控制：AI没有物理感知
低功耗是嵌入式里最看“物理功底”的方向。它要求你知道哪个外设的唤醒时间有几百微秒、哪个GPIO在深度睡眠模式下必须保持特定电平、哪个电压域要先于另一个电压域关闭。AI生成这种代码，多半是按“标准流程”给你一套看似完整的睡眠唤醒函数。但真跑起来，电流测量数据会告诉你它完全想多了。
再举一个时序控制的例子。我让AI写过一段等待传感器稳定后读取数据的代码，它在其中加了一个delay_ms(500)。看起来没问题，但在低功耗模式下我把主频从168MHz切到2MHz后，这个delay_ms的实际耗时直接翻了几十倍，整个系统的唤醒周期被拖得乱七八糟。这类问题的根源在于：延时函数依赖时钟源，而时钟源成了变量，AI不可能感知到这些动态变化。所以涉及低功耗、时钟切换、外设间时序配合的地方，我的态度很坚决：AI可以提供片段参考，但最终代码必须由人来逐行背过一遍，并且要在目标板实测验证。
我把这些总结成一张表，方便大家对照：
| 领域 | 主要风险 | 原因 | 建议 |
|---|---|---|---|
| 启动代码、链接脚本 | 启动即崩溃、内存布局错乱 | 隐含约束多，错误不易暴露 | 使用官方模板，手工核对地址 |
| 中断服务函数 | 竞争条件、标志未清、耗时失控 | AI不了解系统中断分布与优先级 | 人写核心ISR，AI只做外围辅助 |
| DMA配置 | 缓冲区生命周期错乱、对齐问题 | 涉及内存和硬件的动态配合 | 对着手册逐项核验，实测拷机 |
| 低功耗/电源切换 | 唤醒时间失控、外设状态丢失 | 物理行为AI完全无感知 | 电流实测为准，AI仅做参考 |
| 通信时序的微秒级控制 | 波形不对、偶发超时 | 反馈链路太长，AI无手感 | 用示波器/逻辑分析仪验证 |
5. 重构后的嵌入式开发工作流：契约先行、AI填充、人做验证
用好AI不是简单地“问一句让它写”，而是要把整个工作流重新组织一遍。我现在的做法可以归纳成一句话：先写契约，再让AI填充，最后人做验证。
5.1 从“写完再看”变成“先定接口再让AI实现”
以前我试过直接给AI说“写一个Modbus RTU从站模块”，结果它“自由发挥”了，代码结构确实完整，但接口命名风格跟我工程的现有规范完全对不上，数据结构也没用我预期的内存池方案，最后拆掉重来，浪费的时间比手工写还多。后来我把工作流改成了这样：
- 先写设计文档：模块职责、对外接口函数、数据结构定义、文件依赖关系、错误码定义
- 把设计文档喂给AI，明确要求“只能按文档的接口实现，不允许改接口、不允许新增全局状态”
- AI生成的代码进入Review，重点不是逐行看，而是对照设计文档检查有没有“越界”行为
- 硬件验证，覆盖正常路径和异常路径
改完之后效果完全不一样。还是那个Modbus RTU从站模块，接口和寄存器地址表我花了一晚上定义清楚，第二天上午把文档丢给AI，下午就拿到了可以上板跑的主体代码，剩下两个下午全部用来调通信时序和边界case。相比以前“通宵憋代码再花三天调兼容性”，这个节奏健康太多了。
5.2 硬性验证链：编译、测试、上板、抓波形，一步都不能省
我给自己定了一条死规矩：**任何AI生成或修改的代码，都必须走完完整的验证链，不能因为它“看起来没什么问题”就跳过某一步。**我的验证链是这样的：
- 编译阶段：开启
-Wall -Wextra -Werror，跑静态分析工具，确保零警告通过 - 单元测试：核心算法和协议解析用主机端测试框架跑一遍，桩掉硬件层
- 目标板测试：烧进板子跑功能用例，把正常流程、异常输入、反复上下电都测一遍
- 信号级验证：涉及时序的地方，用示波器或者逻辑分析仪看实际波形，对照设计文档确认
特别提醒一点：AI改了代码之后，不要只测它声称“改完”的部分，必须把关联模块的回归测试也跑一遍。我遇到过AI发现自己改的一段代码引入了一个小问题，然后“自作主张”改了另一处模块来“补偿”，结果新问题从概率性偶发变成必然触发，测了半天才发现是它自以为的修复。
5.3 给AI的结构化修改指令模板
为了让AI少犯“越权”的错误，我后来养成一个习惯：给它下修改指令的时候，必须包含几个关键信息。下面是我常用的一个模板：
| 字段 | 内容 |
|---|---|
| 修改目标 | 哪个文件、哪个函数、具体要改什么行为 |
| 约束条件 | 不允许改动哪些文件/接口/全局变量，不允许新增依赖 |
| 预期影响 | 预计会影响哪几个调用方，是否需要同步修改 |
| 验证要求 | 改完必须保证编译通过、相关测试用例通过 |
| 禁止事项 | 不要顺手“优化”其他代码，不要新增需求外功能 |
这种写法看起来很死板，但对AI非常有效。因为模型在面对模糊指令时会主动“补全”它认为合理的内容，而嵌入式工程最怕的就是这种自作主张的补全。把约束写清楚，实际上是在给AI划一道行为边界，告诉它：你的任务范围就到这里，多一步都别做。
6. 跟AI协作的实操注意事项：上下文、越权与验证边界
最后说几个在整个过程中积累的实操细节，属于那种常规文档里不会写、但真能决定项目成败的小事。
6.1 上下文管理：寄存器映射表要喂到“饱”
嵌入式项目的代码仓库往往是“好多文件+大量宏定义+层层封装”。AI的上下文窗口再大也有上限，你不可能把一个完整工程全丢进去。我的做法是：在仓库里维护一个AI_CONTEXT.md，专门用来给AI提供关键上下文——芯片型号、编译链版本、外设库版本、全局内存约束、当前模块的接口定义、以及“不要把哪些文件改坏”的警告列表。每次让AI做改动的时候，把这份文件连同具体的修改请求一起发过去。
比如你想让AI改一个ADC驱动，光说“把这ADC改成DMA模式”它大概率会犯错。你应该先给它看ADC寄存器映射表、当前DMA通道分配情况、中断优先级配置表，再告诉它改动范围。上下文喂“饱”了，AI生成代码的质量会提升一大截。这个习惯我养成了之后，返工率低了很多。
6.2 对AI的“越权行为”保持警惕：它真的会自作主张
这是我最想强调的一点。AI在生成代码时，经常会在你要求的范围之外顺手“加一点私货”。你让它实现一个CRC校验，它在main函数里给你加了个LED闪烁指示状态；你让它写一个字符串解析函数，它顺手把输入缓冲区的长度扩了一倍；你让它“检查”一下某段代码，它直接帮你把另一段函数的逻辑重构了。
处理这个问题的唯一有效手段，就是每次AI改动都用git diff逐块看，并且要求AI在提交时分批、小粒度提交，不要让改动糊成一坨。Review的时候重点不是看逻辑对不对，而是先看“这行是不是我要的改动”之外有没有“额外送”的东西。坚持这样子做几次之后，AI的“自觉性”也许会变得好一些——更可能的是，你已经养成了逐行把关的习惯。
6.3 “让AI解释代码”不是用来听讲，而是用来抓漏洞
很多教程会让你“让AI解释它生成的代码”，说这样能帮助你理解。这个说法没错，但我的用法不太一样。我让AI解释代码，不是为了听一个流畅的故事，而是要把它的解释和实际行为放在一起对照，找出矛盾和疏漏。
举一个真实的例子。我要求AI写一段SD卡初始化的代码，它解释得头头是道，什么CMD0、CMD8、ACMD41，流程分毫不差。但烧到板子上就卡在初始化超时。查到最后是它漏掉了SPI模式下的IO复用切换——芯片手册明确写着，要先把对应引脚从GPIO模式切换到SPI外设的复用模式，否则片选信号根本出不来。这类错误靠AI的自我解释是发现不了的，因为它解释的是“它以为它在做的事情”，不是“硬件上实际发生的事情”。真正有效的验证方式，还是把AI的代码放到目标板上，用逻辑分析仪去对照手册上的时序要求，一个时钟沿一个时钟沿地看。
这一点也可以延伸一下：Vibe Coding时代，嵌入式工程师反而更不需要“代码讲解师”，更需要“硬件侦探”。AI给了一个看似无懈可击的解释，你手上唯一的破案工具是示波器、逻辑分析仪、电流表，外加你对芯片手册的理解。这些工具和知识能力，不会因为AI会写代码而贬值，反而会变得更值钱。
回到开头那个I2C驱动的问题。最后我没有真让AI直接给出“修复后的整段代码”，而是把异常波形截图、I2C时序参数表和我的出错场景一起整理成上下文交给它，让它帮我分析可能是哪几个原因。它给出了三个候选方向，其中第二个——时钟延展导致从机卡住——正好对应我后来定位到的问题。代码层面的修复改动不大，重要的是定位思路被快速聚焦了。
这一年下来的一个体会，也想分享给还处在观望阶段的同行：Vibe Coding对嵌入式开发来说，不是“有没有用”的问题，而是“你怎么组织工作”的问题。代码本身的量产门槛在被AI拉低，但代码之外的硬件感知、系统判断、边界定义和验证设计，才是嵌入式工程师真正要守住、也值得花时间去积累的部分。
最后分享一个我自己的工作流改变：现在凡是让我写代码，我都不再直接写第一版，而是先在文档里把接口、约束、数据结构定义清楚，然后把“写码”这段直接扔给AI，自己转去做验证设计和用例规划。刚开始很不习惯，总觉得不亲手敲几行代码就不踏实，时间长了发现，那些以前耗在“敲代码”上的时间省下来之后，恰恰都变成了看波形、看datasheet和思考系统边界的时间。对一个嵌入式工程师来说，这才是最值得投入的地方。
