Vibe Coding遇上嵌入式开发：AI写代码的边界与工程师的护城河

三个月前我花了整整一个晚上排查一块STM32板子上的串口乱码问题最后发现是波特率寄存器配置多算了2。也是在那一周我顺手把需求丢给AI让它给我写了一套ESP32的PWM风扇控制框架从寄存器配置到状态机梳理前后不过十分钟读代码加改配置反而花了半小时。这个反差让我认真想了一件事当“Vibe Coding”这个概念从Web开发圈子一路蔓延到嵌入式领域时我们这些每天跟寄存器、中断、Flash容量打交道的人到底该怎么接招Vibe Coding说白了就是你用自然语言描述“我想要什么”AI帮你把代码写出来你来审视、验证、改错。听起来很美但嵌入式开发从来不是一个“代码写得出来就能跑”的领域。代码只是冰山一角下面压着的是硬件时序、电源纹波、信号完整性、编译链接脚本、启动文件、内存布局。这篇文章不是来吹Vibe Coding多神也不是来唱衰它。我就是把自己这两个月拿AI做嵌入式项目的真实过程、踩过的坑、总结出的边界完整摊开聊一聊。适合谁看正在做单片机、Linux驱动、RTOS相关开发又好奇AI工具能用在哪、不能用在哪的工程师朋友。也希望给那些想“用AI替代嵌入式工程师”的非技术背景朋友泼一盆客观的冷水。1. 先搞清楚Vibe Coding到底改写了什么1.1 从“写代码”到“描述代码”的本质变化Karpathy在2025年初带火这个词的时候核心意思很简单不是你写代码而是你描述你想要的代码AI把它生成出来你来读、你来看、你来决定留哪段扔哪段。开发者从“敲键盘的人”变成了“审稿人”。在Web开发这种反馈极快的场景里这个模式简直如鱼得水。写个Python脚本、搭个React组件生成的代码跑一下页面出来了报错了也看得见。Vibe Coding成了主流工作流之一Cursor、Codex、Claude Code这些工具一堆人在用。但把同样的逻辑搬到嵌入式领域事情就没那么简单了。嵌入式开发面对的是一块具体的芯片、一组具体的外设寄存器以及一个看不见摸不着的物理世界。你在串口打印一行日志背后是GPIO复用、UART时钟使能、波特率分频、中断配置好几层东西叠在一起。AI生成代码的能力确实在飞速上升但它生成的东西边界往往停在“代码逻辑正确”这个层面。逻辑正确的代码放到真实硬件上可能因为一个上拉电阻没接就全线崩盘。这个过程里Vibe Coding的“vibe”——那种顺滑的、凭直觉产生代码的体验——很容易让人误以为自己已经掌控了一切。1.2 三层能力跃迁补全、对话、代理我在实际体验中把AI在嵌入式开发里的参与方式分成三个层次。第一层是智能补全就是Tab自动补全代码那种。这个层次对嵌入式的侵入感最弱它帮你写函数体、补头文件、生成重复性强的外设初始化代码风险很低收益稳定。第二层是对话式生成像ChatGPT、Claude这种你描述需求它给代码。这个层次开始出现风险了因为它给出的代码往往是“通用场景的正确答案”未必适配你的芯片型号、你的时钟树配置、你的编译环境。我遇到过好几次AI给出的初始化代码用了芯片根本不存在的寄存器看起来合理编译直接报错或者更阴险的是编译能过跑起来完全没有预期行为。第三层是代理式开发就是让AI自主完成一个任务闭环比如从编写驱动到编译验证它自己迭代修错。这个层次听起来最诱人但在嵌入式领域目前还是重灾区。因为编译通过不等于功能正确而功能正确又高度依赖你提供的硬件环境信息是否完整。AI没办法替你去量波形也没办法感知芯片温度。它迭代的依据只有“代码对不对”而不是“硬件跑没跑起来”这两者在嵌入式的世界里差距极为悬殊。1.3 为什么它在Web领域先火起来这不是偶然。Web开发的运行环境高度标准化浏览器就那几套Node.js版本也就那几个依赖关系清楚反馈回路短。代码写完浏览器刷新一下就知道行不行。在这种环境里Vibe Coding的“试错成本”极低AI生成一个不完美的版本开发者快速验证、快速修正整个循环很快。嵌入式开发完全相反。交叉编译、烧录、硬件复位、观测输出这个循环哪怕用上最好的调试器也比Web环境重得多。更麻烦的是嵌入式的问题往往是间歇性的、依赖时序的、只有在特定硬件组合下才复现的。这类问题AI根本看不到。所以我的结论是Vibe Coding不是不能用于嵌入式开发而是它的甜区比Web领域窄得多而且要求开发者本身具备更强的硬件感知能力。AI帮你写代码你帮AI校验“它在现实世界里成不成立”。2. 嵌入式开发为什么是Vibe Coding的硬骨头2.1 资源约束AI默认你“什么都有”写Web代码的时候内存不够加内存。CPU太慢换实例。这种思维模式深深烙在AI的训练数据里。但嵌入式世界里一切都有上限。Flash就那么大RAM就那么点CPU主频就那几十兆赫兹。AI生成代码的时候默认情况下不会替你考虑“这段代码编译完体积多大”“这个功能开出来功耗会不会超标”。它给你的可能是功能正确但资源完全不匹配的方案。我做过一个例子让AI生成一段Lua脚本在ESP32上做HTTP请求解析。它给了我一套非常优雅的方案用了标准库里的各种字符串处理函数逻辑清晰得可以当教材。但是这段代码的RAM峰值消耗在我这块板子上几乎要触发堆栈溢出。我跟AI说“请考虑ESP32的RAM限制”它调整后的版本直接砍掉了三分之一功能。原因是它并没有项目里真实的堆栈配置和外设占用信息只能靠猜。这类资源层面的约束是Vibe Coding在嵌入式里第一个碰壁的地方。AI需要你喂给它足够多的上下文芯片型号、Flash/RAM余量、已有的外设占用情况、操作系统的堆栈配置。你不说它就默认你是一个“内存无限的理想世界”。2.2 硬件耦合AI擅长抽象硬件拒绝抽象AI写代码有一个天然趋势就是倾向于使用高层次的抽象。它喜欢封装、喜欢通用的接口、喜欢可移植性强的写法。这套方法论在应用层开发里毫无问题但在嵌入式里经常适得其反。举个最常见的例子写一个GPIO控制。AI可能会给你写成调用某个抽象层接口逻辑上没什么毛病。但如果这个抽象层在你的项目里压根不存在或者存在但接口语义不一样麻烦就大了。你让AI生成的是STM32F103的代码它给你写了一段STM32F407的风格用到了只有F4才有的寄存器位定义细微到你扫一眼根本发现不了。更麻烦的是时序耦合。嵌入式代码的性能不只是逻辑复杂度决定的还跟中断响应、任务切换、总线访问延时密不可分。一段“逻辑上正确”的代码如果在一个中断优先级设置不当的环境里调用了一个长时间阻塞的函数整个系统的实时性就被拖垮了。这个因果关系AI看不到因为它没有示波器没有逻辑分析仪。所以在嵌入式里AI生成的代码更像是“一个起点”而不是“一个答案”。你需要像一个拿到半成品材料的工程师那样去确认这段代码在硬件上的真实行为。2.3 实时性与交叉调试反馈回路被拉长Vibe Coding之所以在Web领域爽核心在于快速反馈。写错了马上报错马上改马上再验证。嵌入式是一个反馈极其滞后的领域。我编译一段AI生成的代码烧进板子跑起来发现LED不亮。是GPIO配错了时钟没开还是电路板上焊点虚了这三大类可能性在Web开发里根本不存在。AI只能帮你分析代码层面的问题但代码之外的问题它无能为力。而这恰恰是嵌入式调试里最耗时的部分。加上交叉编译环境的因素很多AI工具根本没有接入你的工具链。你没法让AI直接帮你跑一次编译、跟一下寄存器、读一下trace数据。所有验证环节都得靠人工转译把报错信息贴给AI把数据手册翻给AIAI再给你下一个猜测。这个循环的效率跟Web环境下那种行云流水的体验完全两回事。所以如果你打算用Vibe Coding的姿势来做嵌入式我建议先把预期调整到“AI是加速器不是替代者”这个心态上来不然很容易被反馈链路折磨到心态崩溃。2.4 训练数据里的“暗区”还有一个很少被公开讨论的问题AI模型训练数据中嵌入式代码的占比和质量远不如Web、Python等主流领域。原因很现实高质量的嵌入式代码通常藏在企业的私有仓库里而公开的嵌入式项目尤其是涉及特定芯片、特定板级支持包的代码数量本来就少且良莠不齐。这就导致AI在生成嵌入式代码时的“知识支撑”不够厚。它能写出通用性的东西比如一个状态机的框架、一个环形缓冲区的实现但一旦深入具体芯片的寄存器级配置、具体BSP的接口约定AI的出错率就会显著上升。Gemini 2.5 Flash、DeepSeek V3这些模型我也都试过各家风格不同但共性都摆在那里对通用C语言语法掌握得极好但对特定MCU的专属外设库、特定版本的SDK接口经常出现混用。这一点对嵌入式工程师来说反而是个好信息AI越不擅长的越是我们的护城河。3. 我用Vibe Coding做嵌入式项目的完整记录光谈理论没意思下面分享我这两个月真实做的一个项目。不算大项目但很有代表性。一套基于ESP32的自动喂鱼系统包含水泵控制、灯光定时、水位检测、联网上报四个模块。我刻意用了一部分AI生成代码也刻意保留了一部分手写模块方便对比。3.1 项目定义与约束清单上手之前我先花了一个多小时把需求翻译成了一份“约束清单”。这是我认为在Vibe Coding工作流里最重要的一步也是很多人忽略的一步。你需要让AI充分了解它是在什么限制条件下工作。芯片型号ESP32-WROOM-32开发环境ESP-IDF v5.0操作系统FreeRTOS。RAM剩余约60KBFlash剩余约1MB。已占用引脚GPIO2接水位传感器GPIO18接水泵继电器GPIO19接LED指示灯。供电方式是5V USB供电但水泵启动瞬间会有电压跌落所以所有涉及ADC采样的代码都要注意滤波。我把这份清单直接粘给了AI让它基于这些条件生成水泵控制模块的框架代码。实际跑下来效果比我预期好得多AI生成的GPIO初始化和PWM控制代码基本可用只需要做少量修改。核心原因是这份约束清单让AI的“搜索空间”大幅度收窄了。反倒是那些我没写进清单里的信息比如“项目里已经有了一套自己的错误日志系统所有打印请走这个接口”AI就完全没考虑生成的代码里直接调用了printf。这就是AI工作流的常态你给多少约束它答多高水平的题。3.2 AI生成驱动代码的三层境界用AI写驱动代码我总结出来分三个境界。第一层是生成“模板代码”就是那种先从芯片手册里抄一段初始化流程再配上最简单的读写函数。这层AI完成得非常流畅尤其是UART、I2C、SPI这类通用外设的初始化框架它一次给出的正确率很高。我试过一次让它直接生成ESP32的SPI主机驱动配合DMA传输版本整体代码风格非常标准几乎可以无修改编译通过。第二层是生成“适配特定应用需求的驱动”比如要求驱动带有超时处理、错误重试、环形缓冲区、中断与轮询双模式切换。这层AI开始慢慢露馅它给出的方案往往逻辑正确但没有考虑你项目里已有的线程模型。举个例子它生成了一版带互斥锁的驱动代码逻辑上很完善但它不知道我这个项目里根本没有多线程并发访问这个外设锁反而引入了一个潜在的死锁风险。我给它补充说明后它去掉了锁代码清爽多了。第三层是生成“为具体硬件问题定制的驱动”。比如“这个传感器在时序要求上非常严苛读操作必须在500微秒内完成否则数据作废”。这层AI基本就是靠猜了。它没有硬件的实时反馈没法迭代调整。我能做的只是让它提供一个初版然后用示波器量着实际时序去改。这一层AI目前的用处反而不大。我给读者的实操建议是把AI定位在第二层偏下第一层到第二层之间它干得又快又稳。第三层还是老老实实人肉调试别指望它一锤定音。3.3 状态机AI真正发光的地方这次项目里AI最让我惊艳的部分不是驱动代码而是状态机逻辑的梳理。我这个自动喂鱼系统有两个工作模式定时投喂模式、手动远程模式。传统写法是if-else套来套去模块越写越乱。我尝试让AI帮我重新梳理成状态机的形式把“空闲、检测水位、水泵注水、投喂、等冷却、故障处理”这些状态全部描述给它要求它生成一份状态机框架并且把每个状态的进入条件、执行动作、退出条件都单独成函数。AI生成结果出乎意料地好。不是因为它写出了什么高深的东西而是它的组织能力极强。它给了我一版清晰的状态转换表用枚举定义了所有状态用一个二维数组定义了状态转换矩阵每个动作函数都留好了接口。这套东西几乎没有bug我只需要填充具体的硬件操作函数即可。这给我一个重要启发Vibe Coding在处理“逻辑结构清晰、规则明确”的任务时质量远超“依赖硬件上下文”的任务。状态机、数据处理流程、协议解析框架这类偏“逻辑密集型”的内容非常适合AI参与。而那些偏“硬件感知密集型”的内容比如时序调优、信号调试AI目前很难帮上实质性的忙。3.4 一次活生生的踩坑I2C和它的上拉电阻我想分享一次真实的踩坑经历让你直观感受一下Vibe Coding的边界长什么样。我在系统里加了一颗温湿度传感器用的I2C接口。我把这个需求丢给AI它非常流畅地给我生成了标准的I2C驱动代码包括初始化、读写、数据转换头头是道。编译通过烧录进板子你猜怎么着传感器读数永远是0xFF一根筋的那种。我花了很多时间去查代码。AI生成的代码里没有毛病地址对、寄存器对、时序在理论上也合理。但问题根本不在代码上而是硬件上——我这块板子的I2C上拉电阻焊盘是空的SDA和SCL根本没有被拉高。I2C协议在空闲状态下需要靠上拉电阻把总线拉到高电平没有上拉电阻总线浮空通信必然失败。这个问题的核心是AI写了正确的代码但代码放在一个不满足电气要求的硬件环境里一样跑不通。AI不知道你的PCB上有哪些电阻没焊不知道你的传感器模块是否自带电平转换不知道你的跳线帽有没有插对。这些信息它无法从任何训练数据里学到。反过来讲这块板子如果是来了一个看得懂原理图的嵌入式工程师他写代码之前扫一眼板子或者拿万用表量一下上拉点10分钟就能发现问题。而我在Vibe Coding的“顺畅体验”里待了太久下意识信任了代码逻辑层面的正确性结果在硬件层面栽了跟头。4. 嵌入式开发中哪些环节别让AI碰4.1 中断服务函数时序的命门AI生成的代码里我目前最不建议直接放进生产环境的就是中断服务函数。这个结论来自一次让我记忆深刻的经历。当时我让AI写一段外部中断触发的处理代码它给出了一个很优美的方案在中断里调用一个函数做数据处理。逻辑上完全没问题但它忽略了一个嵌入式的基础准则——中断处理函数要短小精悍绝对不能做耗时操作。AI给的函数里带了一个for循环用来等待某个外设的响应标志置位。这个循环如果等待时间超过几十微秒在高优先级中断嵌套的场景下系统的实时性会直接崩掉。AI不是不知道这个准则它只是没有感知到“这个中断到底有多紧急”这个硬件上下文。中断里放什么不放什么取决于中断频率、外设响应时间、系统整体实时性需求。这些信息全都是硬件的、物理的、具体场景相关的。AI在这个领域里表现得像一个记忆力很好但完全没有临场经验的新人。所以我的建议是中断服务函数永远只放最核心的操作比如清标志位、读数据到缓冲区、置一个信号量。剩下的事情全部交到主循环或任务里去处理。AI可以用来生成缓冲区管理的辅助代码但中断主体建议保留人工审查和修改权。4.2 电源与低功耗设计如果说中断是时序的命门那低功耗设计就是嵌入式里最容易让AI“翻大车”的领域。低功耗设计高度依赖硬件状态。芯片进入休眠之后哪些外设还需要供电哪些引脚要配置成什么模式才不会漏电唤醒之后系统状态如何恢复这些全都要看具体的硬件实现。AI在这个领域几乎没有感知它给出的代码往往在逻辑上正确但忽略了很多硬件细节。举个例子我让AI生成一个设备定时唤醒采集数据的方案。它给了我一套标准的ESP32深度睡眠加定时器唤醒的代码看起来毫无问题。但我知道这块板子上的一个传感器模块在深度睡眠期间如果没有通过一个MOS管彻底断电会在休眠状态下多消耗数毫安的电流。这个功耗细节在代码层面体现不出来。AI不会告诉你你的硬件方案在低功耗层面就埋着雷。这类问题从Vibe Coding的视角完全不可见因为它藏在原理图和PCB里。低功耗设计从来都不仅仅是代码问题而是硬件方案、软件策略、功耗测量三者联合调优的结果。AI目前只能负责其中“软件策略”的一小部分而且必须建立在硬件方案已经验证过的基础上。4.3 安全关键逻辑与内存布局如果你的项目涉及安全相关逻辑比如设备保护、异常急停、数据完整性校验这些代码我强烈建议百分之百人工编写和审查。这和技术能力无关这是责任边界的问题。AI生成的代码一旦出问题谁来对事故负责这个问题在非安全领域可能只是多费点时间排查但在安全领域可能意味着设备的物理损坏甚至人身风险。内存布局也是一个AI几乎完全无能为力的领域。链接脚本、内存分配、堆栈大小的设定、缓冲区对齐这些都需要对目标芯片的内存架构有深刻理解。AI可以帮你解释某个链接脚本指令的含义但你让AI自己给一块新板子配置内存布局它给出来的东西多半不能在真实环境中稳定运行。因为内存布局的最优解极度依赖具体项目的外设使用情况、中断嵌套深度、通信缓冲区大小这些数字只存在于工程师的测量和评估里AI不可能凭空猜准。4.4 硬件抽象层的接口一致性最后一块雷区是硬件抽象层的接口设计。AI很喜欢生成一套“看起来很完善”的抽象层接口但你项目里已有的代码风格、命名规范、错误处理约定它经常完全无视。我在一个项目里吃过这个亏。AI给我生成了一套新的传感器驱动接口命名风格是sensor_read_temperature()而项目里已有的驱动风格是drv_temp_get()。两套代码混在一起可读性低到爆炸。更麻烦的是错误处理约定不一致AI生成的代码返回标准错误码而项目里已有的代码用的是自定义错误结构体。整合的时候我得手工改十几个文件。这件事让我意识到HAL层的价值不只是“屏蔽硬件差异”更是团队代码风格和工程约定的载体。这些约定通常不会写进任何README只存在于老工程师的肌肉记忆里。AI再强也没法从你的代码库里提炼出这套隐性的工程文化。5. 在Vibe Coding时代嵌入式工程师该换哪种活法5.1 技能结构从“写”转向“审”我在用AI做了两个月嵌入式项目之后最大的感受是我的角色正在从一个“代码生产者”变成一个“代码审查者硬件验证者”。以前写驱动大部分时间花在敲代码、查手册、试错上。现在AI把第一版代码几乎瞬间生成我的时间转移到阅读它、分析它、判断它跟硬件环境的匹配度上。从工作量上看写代码的时间确实变少了但对硬件知识的依赖程度反而变高了。因为AI生成的代码越流畅你越需要有足够敏感的“异常感知力”。一个寄存器地址写错、一个初始化顺序颠倒、一个回调函数在错误的中断上下文里被调用这些在编译期根本看不出问题只有在实测中才会暴露。而发现这些问题的能力恰好就是我们这些天天跟硬件打交道的人最核心的竞争力。所以我不太认同“Vibe Coding会让嵌入式开发贬值”的说法。恰恰相反当编码本身被加速之后硬件知识、调试经验、领域判断力这些“编码之外”的东西会变得更有价值。5.2 团队流程的连锁反应Vibe Coding进入嵌入式团队之后一些流程细节也值得重新考虑。代码评审的权重明显上升。以前代码评审看的是“这段代码逻辑对不对”现在得额外审视“这段代码跟我们的硬件环境匹不匹配”。我甚至建议在评审清单里增加一项标注哪些代码是AI生成的审的人需要特别关注这类代码的边界条件处理。版本管理上也要更细致。AI生成代码往往喜欢批量改动一次对话里动了几十个文件。如果直接把AI的产出推入主分支而不做细致拆分后续的git回溯会非常痛苦。我的做法是让AI生成的每个模块单独提交注释里标明由AI生成便于后期追溯。5.3 对新手来说门槛是低了还是高了这个问题很难一句话答清楚。从表面看AI确实降低了嵌入式开发的门槛——你不用背那么多寄存器地址不用记那么细的APIAI帮你兜底。但实际上嵌入式的真正门槛从来不在“会不会写代码”而在于“能不能看懂硬件在干什么”。一个新手用AI快速生成了一堆驱动代码板子没跑起来他能做什么他如果不懂怎么看原理图、不知道怎么量波形、不知道I2C需要上拉电阻、不知道怎么排查电源纹波他就只能卡的原地。AI帮不了他。所以我的结论是Vibe Coding让嵌入式开发的“起步”变快了但“深入”的门槛反而更高了。以前新手至少是在一行一行敲代码的过程中慢慢建立起对寄存器、总线的直觉。现在AI直接跳过了这个阶段新手少了那层“笨拙但扎实”的积累过程。如果他自己没有意识地补充底层知识很容易变成一个只会描述需求、永远解决不了硬件问题的“伪嵌入式工程师”。这让我想起我自己刚入行的时候老师傅带我的第一句话“代码是死的芯片是活的。”在Vibe Coding时代这句话比任何时候都更重要。最后再分享一点个人体会做了这两个月实验我最大的收获不是AI帮我写了多少代码而是它让我更清楚地看到了嵌入式开发里“属于人”的部分到底在哪。AI可以帮你生成一个非常优雅的I2C驱动但不会告诉你传感器该不该接上拉电阻。AI可以帮你写一个逻辑完美的状态机但不会告诉你水泵启动瞬间电压跌落会导致重启。AI可以帮你整出一个干净的构建系统但不会告诉你在当前这个PCB布局下那条高速信号线可能会产生串扰。这些知识不在训练数据里只在现场里。在示波器的屏幕上在万用表的蜂鸣声里在深夜产线上那块怎么都不工作的板子里。所以如果你问我Vibe Coding时代嵌入式开发值不值得入我的答案是值得而且越来越值得。前提是你愿意让自己成为一个既懂代码、又懂硬件、还能跟AI高效协作的“复合型调试者”。最后送上一句话是我踩了无数坑之后自己总结的让AI替你写代码但永远不要让它替你做决定。决定权在谁手上谁才能真正驾驭这个时代。如果你也在嵌入式开发里试过AI工具欢迎分享你的经历。踩过的坑、总结出的心得、觉得AI好用的或不好用的场景都值得聊一聊。