Vibe Coding这个词最近在嵌入式圈子里讨论度肉眼可见地高了起来。身边不少做Linux应用、跑Qt界面的同事都开始试水AI辅助开发甚至直接丢给模型一个需求描述就把代码跑起来了。但做嵌入式底层、做板级驱动、做汽车电子的朋友普遍反应比较保守生成代码能不能过编译是一回事上板能不能跑、跑起来稳不稳、中断能不能进、时序会不会崩又是另一回事。这种分野很有意思也值得深入拆一拆。Vibe Coding强调随性、意图化、让模型去填大部分实现细节。嵌入式开发则一直强调确定性、边界、算力预算和硬件耦合。当这两种开发哲学撞在一起既不是简单的“底层不适合用AI”也不是“掌握新工具就躺赢”。真正值得聊的是怎么给这个老行业引入一套适合它自身约束条件的AI协作范式。1. 先搞清楚一件事Vibe Coding到底在“低于哪一层”工作“Vibe Coding”严格说不是一种编程语言也不是什么IDE插件它更接近一种人机协作的状态。Andrej Karpathy最早用这个词的时候说的就是“我完全拥抱误差我不逐行读代码我描述意图让模型写然后我跑、我试、我反馈”。本质上是把编程从“按语法精确表达”变成了“用自然语言描述预期行为再通过运行结果反向调节描述”。这套工作流在应用层确实跑得通原因很朴素反馈回路极短。写个网页、写个Python脚本、写个业务接口写完就能起服务报错信息就在眼前改一改重跑几十秒一个循环。哪怕生成的东西第一次不能跑第二次语法错第三次逻辑错第四次终于通了整体成本依然低得可怕。模型不懂业务没关系跑起来的行为就是最好的“老师”。但嵌入式场景完全不是这个节奏。你写的不是一串跑在通用操作系统上的逻辑而是跑在某个特定SoC或者MCU上的机器代码旁边连着传感器、电机、屏幕、总线。程序的行为不是只由你的代码决定还由电源时序、外设初始化顺序、时钟配置、中断优先级这些东西共同决定。更麻烦的是一次迭代的反馈成本是按“编译→烧写→上电→观察→调试”来算的遇到难缠的问题一次循环可能大半天。所以很多嵌入式工程师一开始接触Vibe Coding时会有一种错位感它看起来是为“无限低成本重试”设计的而嵌入式最贵的东西恰恰就是重试。于是自然产生一个疑问这工具到底能不能用在我的日常里我的标准答案是能用但用在哪里、用多深、怎么用边界非常清楚。这背后是两条完全不同的工程逻辑。2. 嵌入式开发的“确定性底色”为什么Vibe Coding天生和它有点别扭要理解什么场景能用先得说清楚为什么很多场景用不了。这不是保守而是嵌入式开发的物理底色决定的。2.1 硬件不重试生成代码没有“试错冗余”应用层开发最大的恩赐是错了重来成本低甚至上线出bug也能靠快速迭代补救。但嵌入式代码一旦烧进去面对的是实打实的外部世界。GPIO拉错了引脚可能烧掉驱动板PWM占空比算错了可能让电机过流Flash写时序不对可能把整个分区擦掉。硬件不给你“再来一次”的机会这是和Web开发最本质的差异。这带来的直接影响是模型生成的代码“看起来合理”是不够的必须“在特定硬件上、特定电参数下、特定时间要求内”都成立。而模型对硬件的理解是统计性的它见过很多相似的寄存器配置和驱动写法但没见过你的板子。你的电源纹波多大、晶振精度如何、外设有没有复用冲突模型一概不知。让一个统计模型去猜硬件行为然后把结果烧进Flash这个决定本质上超出了AI能担保的范围。2.2 资源预算不是风格偏好是物理边界做MCU开发的人都知道RAM不是按G算的是按KB算的。中断栈多个几百字节可能直接导致深嵌套时栈溢出。Flash空间不够再漂亮的代码也进不了片内存储。AI生成代码最常见的毛病是什么防御性代码泛滥。动不动就来两层if判断、各种结构体私有变量、冗余错误处理这在PC上是优雅在MCU上是慢性失血。我试过让模型生成一个I2C从机的状态机逻辑很清晰注释也漂亮但编译出来Flash增加了将近4KRAM堆了2K多的全局状态。就为一个从机收发逻辑这个代价在新唐和STM32的小容量型号上根本忍不了。Vibe Coding的“高冗余倾向”和嵌入式“以字节为单位的资源预算”天然冲突。2.3 实时性要求跑通不等于满足时序嵌入式系统里大量逻辑是受时间约束的。CAN报文错过了时间槽就丢帧控制环晚了几毫秒执行稳定性就崩了中断服务程序里多塞一个函数调用就可能破坏硬实时保障。AI生成代码擅长的是“状态转换正确”但不擅长“这个状态转换要在多少微秒内完成”。举个实际例子我之前让模型写一个电机编码器的正交解码读出逻辑。模型给了一个很好的状态机框架用查表法判断方向逻辑没毛病。但放上示波器一看花了将近30个周期才完成一次完整判断对于高频电机来说这个开销直接导致转速估算滞后。你让模型“优化”它可能给你换一个更聪明的查表算法但它意识不到瓶颈出在中断入口处的寄存器保护。换句话说Vibe Coding能帮你实现“什么”但很难帮你回答“多快”“多准”“多省”。后者恰恰是嵌入式系统量产之后真正要命的问题。2.4 调试链路太长单次反馈成本昂贵Web开发里一个bug从出现到定位往往就在IDE和浏览器之间。嵌入式调试呢交叉编译后烧录串口输出日志逻辑分析仪挂总线示波器量波形有时候还要JTAG单步。就算一切顺利一次完整的“代码改动→验证行为”周期也要以分钟甚至小时计。Vibe Coding的调参式迭代依赖的是高频反馈。反馈成本一旦上来自然语言对话的效率会断崖式下降。你在一个循环里让模型改了三次每次都要重新烧录验证时间消耗就非常可观了。这不是工具不好用是反馈链路本身的物理限制。所以结论很清楚越是靠近硬件的层纯“Vibe”的空间越小越是对确定性有严格要求的场景越需要人去给模型“画边界”。但这不等于嵌入式就不能玩Vibe Coding它只是要求我们把“Vibe”的颗粒度控制在一个合理的层。3. 哪些嵌入式场景实测真的适合引入Vibe Coding在说“不适合”的时候容易陷入另一个极端好像嵌入式就永远和AI辅助开发绝缘。我这一年半高频使用下来反而觉得有几个场景的收益非常显著。关键是它们都具备同一类特征反馈周期短、需求边界清晰、硬件交互弱。3.1 Linux用户态应用天然优质的Vibe区域嵌入式Linux里的用户态程序包括业务逻辑、协议解析、配置管理、日志处理、状态机调度这些东西跑在操作系统之上有完整的错误处理和调试手段。你对着一块开发板写一个MQTT上报逻辑和对着一个普通服务器写一个网络服务本质上没有太大区别。这一类开发我是重度使用Vibe Coding的。比如写一个串口协议解析模块我会直接把协议帧格式丢给模型告诉它按状态机实现要求正确处理帧头校验和超时。模型生成的帧解析逻辑在边界情况上往往比你手写骨架子时要细尤其是超时处理、半包处理这种细节它见过的模式比你多。更关键的还有UI层。现在嵌入式产品大量用Qt做界面用LVGL做屏显。这类工作的核心是把数据映射成呈现再处理用户交互。上一轮我在做一个车载仪表盘项目时整个显示逻辑框架就是靠对话搭出来的从控件布局到信号槽连接再到刷新策略AI全包了。我只需要把样式表、刷新率要求和状态转换约束讲清楚。串口、网口、CAN等通信协议的数据解析、分包、会话管理日志系统、状态上报、服务间通信的业务逻辑Qt / LVGL 界面布局、数据绑定、菜单状态机嵌入式Linux下的配置解析JSON / INI / YAML各种守护进程、超时重试、心跳机制这些场景共同的特点是问题边界清晰输入输出可观测出错了有运维手段兜底。和写一个普通后端服务没有本质差别全力Vibe没问题。3.2 测试桩与模拟器AI生成增量最大的区域嵌入式测试往往是整个行业最缺人的地方。板子还没回来要提前调上位机硬件不稳定要模拟外设行为自动化测试需要自动生成大量输入数据。这些事以前靠手写耗时巨大。现在模型天生适合干这个。我之前做传感器项目需要一个模拟三轴加速度计数据的PC程序用来提前验证算法模块。这个程序要求模拟不同运动模式下传感器输出波形带噪声偶尔产生丢帧异常。传统做法是手写一个带状态切换的数据生成器工程量两三天。这次我直接把需求描述给模型包括初始静止、直线加速、转弯离心、颠簸路况几种模式让它生成带噪声的数据流。一次对话搞定最后在PC上直接跑通了算法验证。测试桩代码的本质是什么是“看起来像硬件但不需要是真硬件”的替身。它的正确性检验标准是后面接的算法模块能否正确处理而不是它自身要满足任何物理约束。这个特点让AI生成的代码完全够用因为就算有微小逻辑瑕疵跑起来后马上能通过算法的输出反馈发现。更进一步QEMU这类仿真器环境也是极大受益者。你在x86侧模拟一个Cortex-M核板上外设全部抽象成模拟设备AI生成的代码在这里先跑通逻辑再移植到真板。逻辑性错误在仿真阶段就暴露了硬件相关的错误留给测试阶段验证能减少非常多的硬件返回迭代。3.3 驱动模板与初始化代码半Vibe半手写的最佳案例直接让AI写底层寄存器驱动我在很长一段时间里是拒绝的。后来发现问题的关键不是“让不让他们写”而是“让他们写到什么粒度”。现在很多SoC的寄存器映射、头文件定义、时钟树配置都是板上钉钉的网上资料也极其充分。模型读过的数据手册和驱动源码比任何一个工程师都多。你让它生成一个“基于STM32F407通过SPI读取外部Flash ID的驱动”它给出的骨架八九不离十芯片头文件定义、SPI初始化序列、Flash命令字这些都是标准答案模型完全有能力填对。但你要让它直接把这个驱动跑通在你自己画的板子上它做不到。因为板级排布、页大小、扇区划分、电源引脚的GPIO复位状态这些是项目私有的。所以我的用法是让模型生成驱动的初始版本包括寄存器配置、外设初始化函数、基本读写流程人负责修改引脚映射、中断配置、等待超时等硬件相关部分生成代码里涉及DMA和中断协作的部分从第一版就明确要求模型只在函数骨架层提供具体实现人自己填对生成的代码做资源审计确认RAM、Flash占用符合目标MCU空间这样做的实质是把“硬件事实”留给人来判断把“通用模式”交给模型滑铲。模型见过的外设驱动框架比人多它能从一个标准序列开始但最终细化到你的板子上人的判断不可替换。3.4 设备树与中间配置梳理一个被低估的高频收益区嵌入式Linux开发里最烦的事情之一是梳理设备树。一堆节点、属性、中断映射、时钟引用、GPIO复用关系信息极其琐碎而且经常散落在好几份文档里。AI在这里的收益特别高因为它是一个模式匹配问题。我有一次要适配一个新的Sensor模块到既有平台原来的设备树里完全没有对应节点。手写也可以但要翻半天参考文档确认中断号和时钟绑定的写法。直接把SoC参考手册的片段和类似模块的设备树块丢给模型让它按新模块的参数生成一份改动版五分钟就拿到了一版可编译的设备树补上GPIO和中断映射后直接使用。类似地还有外设配置的中间代码比如CMSIS配置、DMA描述符初始化、FATFS挂载参数、LWIP网络接口配置等。这些代码的共性是什么它们高度模板化但模板的具体参数跟芯片和板子绑定。模型不知道你的板子细节所以参数由人确认模板骨架交给模型生成。这也解释了为什么“应用层开发是不是嵌入式”这个热搜词会火——现在两边的工作方式越拉越近嵌入式工程师越来越像写复杂业务逻辑的应用开发者只是额外承担了硬件理解的责任。4. 我现在的嵌入式AI协作工作流强制约束短反馈循环聊应用场景得往落地走。这套工作流我从一开始的“什么都让AI写”调了好几个月现在逐渐固定下来直接分享当前版本。4.1 上下文工程是嵌入式Vibe的前提嵌入式项目跟Web项目最大的区别在于自然语言描述远远不够模型必须拿到足够多的“项目事实”才能生成可用代码。这里的“项目事实”不是泛泛的“这是一个F407项目”而是完整头文件路径和函数原型寄存器映射的关键字段定义外设配置的实际参数时钟频率、数据位宽、校验位网络抓包或数据手册里的协议帧格式编译环境的目标架构、优化等级、链接脚本概要我通常的做法是把项目关键的头文件、配置宏、协议文档直接粘贴进对话然后再描述需求。比如要写CAN报文接收解析我会先贴can.h里消息帧结构体的原型再把总线波特率、验收滤波器的配置宏发过去然后再说“基于这些实现一个解析器”。这个上下文给足了模型生成的代码贴合度完全不一样。它不再给你可移植的通用写法而是直接能用你的变量名、你的结构体的项目内代码。4.2 把编译反馈喂回模型做成半自动循环纯手动对话调参还是太慢。我现在的习惯是在命令行里把“make输出→错误定位→修正代码”做成一个小脚本编译报错直接喂给模型让它分析并给出修正。这样一次编译循环压缩到分钟级已经接近应用层Vibe的迭代体验。注意这里不是让模型帮你debug而是让模型做“编译器错误翻译器”。嵌入式编译错误极其晦涩经常是因为某个宏没定义导致了一连串连锁报错。模型对这种“错误语义还原”很擅长。它会告诉你这个宏在哪个头文件里定义、这个失配字段和结构体定义之间的关系省去大量人工溯源。4.3 强制使用的三个“信任边界”用AI写代码最重要不是让它“多干活”而是让它“在划定的圈子里干活”。我现在给自己定了三个强制边界任何生成代码跨过就要回退第一生成代码不允许直接操作物理硬件抽象之外的内容。也就是说模型可以生成通过HAL或驱动API访问外设的代码但直接寄存器操作的代码必须人审重点核对位域定义和时序约束。第二任何涉及中断上下文、关键区保护、并发资源竞争的代码模型只能生成第一版候选人必须重审并自行确定锁策略。AI生成代码对临界区的粒度理解经常不合理如果它自动加了关中断但没考虑上下文切换损失在硬实时系统里会出大问题。第三生成代码必须做资源审计。我会给模型设定明确的Flash和RAM预算它生成完第一版本我会用编译器的map文件确认占用情况。超标的直接要求重构而不是接受冗余实现。这三个边界不是不信任AI而是承认“AI生成质量平均不错但嵌入式要求的是极端情况正确”。极端情况恰恰是模型最容易翻车的区域。4.4 基于PC原型的前置验证嵌入式最大的痛是反馈慢所以一切能在PC上先验证的东西都不应该上板调。我现在养成的习惯是所有纯逻辑、无硬时钟依赖的模块先在PC的模拟环境里Vibe出来。状态机、协议栈、算法滤波、通信数据解析、帧格式转换通通先让AI生成在PC上编译、单测、调参。只有和真实硬件交互的那层再移植到目标板。我之前做过一个BMS项目的数据帧解析和告警判断逻辑整个模块是纯PC开发完的。AI生成逻辑框架我补充了阈值参数和告警响应策略PC上跑了几百轮测试。等板子回来这个模块一把烧录通过后面调的都是硬件层的事逻辑部分零返工。这也印证了“应用层开发是不是嵌入式”的火爆讨论。当一个嵌入式项目的核心壁垒越来越偏向“逻辑算法和系统架构”而物理硬件交互被标准化驱动和中间层屏蔽得越来越多时它能Vibe的部分就会越来越大。这趋势挡不住我能做的就是让这个占比可控地变大。4.5 代码审查的新方法不逐行看但要盯风险模式不逐行读代码不代表不审查。我现在的代码审查方式变了不再从第一个字符盯到最后一个而是带着风险清单去扫。这个清单是我半年用了不同模型写嵌入式代码后总结出来的是否有不合理的动态内存使用嵌入式开发严禁随意malloc是否有隐含的递归调用或过大栈变量是否有对宽度的隐性假设int到底按32位还是16位处理是否把同步逻辑放进了中断处理函数是否存在忽略返回值却影响数据完整性的路径是否有对时间开销的高估或低估比如函数里藏了循环体是否可能让外设进入不确定状态比如初始化失败后没恢复机制这个清单本质上是我从过往硬件产线事故里提炼的“高危模式”。AI生成代码的平均水平高但风险模式会集中出现在这几处。用这种风险导向审查法我能在一两百行代码里几分钟定位到需要修改的区域其他部分直接信任行为测试。5. 几个踩坑实例帮你绕开我浪费过的两三个月我不会说这些坑是AI独有的但它们以高概率出现边缘情况特别容易诱发。5.1 模型把“轮询”和“中断”两种模式拼在一起最典型的无意识错误。让模型写一个SPI从机接收逻辑它给出的代码里进去中断处理函数后又等了一个while循环轮询状态寄存器。这在低频测试下可能偶尔能跑通但中断上下文里阻塞直接导致CPU占用飙升其他实时任务全受影响。模型“知道”两种访问外设的模式却没有判断当前上下文的约束。这种错误在应用层几乎无感在中断处理里就是事故。5.2 生成代码里的时序假设不符合实际外设有一次让AI生成Flash擦写操作时的等待超时逻辑。它写了一个固定的大循环粗略算了算延时大约是毫秒级。但实际Flash擦除的典型时间是几十毫秒温度变化后会到百毫秒级。如果循环体太短Flash查状态时还在忙读取得到的结果是无效的。这种bug在正常室温测试下永远复现不了但一到高低温测试就暴露。根源就是模型生成时凭借的是典型值没有考虑环境边界。5.3 位域打包方式在大小端环境下的错位更冷门但致命。模型生成一个数据帧打包函数直接按结构体位域来。在ARM默认小端下编译没问题但如果你要跟一个x86上位机对数据或者另一端是大端CPU位域布局直接错位整个帧解析全错。这类问题需要懂存储布局的人在审查时主动盯。它不存在语法错误编译一定过甚至单一环境下跑起来数据完全符合预期直到跨平台联调才露馅。5.4 “看起来链表实际找半天找不到头”模型喜欢用链表表达动态数据结构。嵌入式里我们尽量少用链表更常见的是定长数组加标志位。有一次它生成一段内存池管理代码里面既保留数组又套链表结构逻辑倒了三层结果数组索引超界完全靠运气。后来我明确在需求描述里写“禁止动态分配使用预定义数组索引映射”生成的代码简洁不说错误面一下窄了很多。这些坑都不新鲜关键是有没有形成审查清单和边界声明。6. 工具链层面我目前实际在用的组合给想入坑的朋友一个当前可复用的环境参考。不是绝对最优但我用了半年以上稳定、顺滑。6.1 代码生成侧主力还是Claude和GPT系列写嵌入式代码的偏好差异不大关键是上下文工程。我会把Cortex-M的头文件、HAL库版本号、当前工程目录结构直接喂进去代码生成之前先让它总结一遍目标平台的约束相当于一个内部活化的外设知识库。这样生成的代码贴合度比直接描述要高一个量级。6.2 仿真验证侧QEMU能模拟一部分Cortex-M平台虽然不能完全替代真板但验证纯逻辑和中断处理流程的入口完全够用。很多“模型生成的代码是否真能挂在SysTick回调里跑完”这种问题在仿真环境里跑一次就清楚了。配合ARM GCC工具链把ELF直接丢进QEMU挂起调试比每次烧Flash省很多时间。6.3 编译驱动AI的循环脚本这里给个简单思路while true do make 21 | tee build.log if grep -q Error build.log then echo 喂给模型编译错误 # 将编译错误发送给模型获取修正建议 # 应用修正后重新编译 else echo 编译通过 break fi done这个脚本本身不复杂但能帮你把“编译错误→向模型解释→应用修改→重新编译”循环自动化。嵌入式开发最耗时间的就是来回看编译日志机器人干这事效率高得多。配合一个文件监控我甚至可以在编辑保存后自动触发构建改完代码三秒内就能知道是否引入新问题。6.4 硬件交互层的代码仓分层最后给一个提醒别让AI直接在你的pet项目分支上飞来飞去。我现在的仓库分了三层核心驱动层几乎全部人工维护业务逻辑层可以放宽让AI高频介入中间配置层设备树、链接脚本、启动文件允许AI生成但必须二次人工确认。这个分层既控制了风险也保住了人的核心能力。7. 长远看嵌入式工程师的能力模型正在悄悄变化聊了太多操作细节最后说点稍微远一点的思考。7.1 判断力高于记忆力以前嵌入式工程师的核心能力之一是记住大量寄存器地址、外设时序和芯片特例。这部分现在确实没有优势了模型记得比人全查得比人快。但它没法判断“这个外设在这个项目里是否应该这么用”也没法判断“时序异常时是先查电源还是先查配置”。这些判断力来自对硬件行为的深度理解而不是记忆表格。所以我越来越觉得未来嵌入式工程师的核心竞争力不是“写得好不好”而是“判断得准不准”。AI帮我们把代码生成的成本打到地板价但谁来定义正确的行为、谁来划定边界、谁来对量产负责这些事还是得人来而且更加值钱。7.2 硬知识反而更值钱了一个反直觉的现象Vibe Coding普及之后真正懂硬件的人反而更稀缺了。因为AI生成的代码量大但需要人判断哪些代码可以在硬件上跑、哪些不行。你越懂硬件就越能高效利用AI这个生成器你越不懂生成的代码就越像一个黑盒。模型不懂硬件不确定性真正掌握这种不确定性判断的人就掌握了协作里的定义权。7.3 嵌入式开发的“Vibe化”程度是由硬件抽象水平决定的未来嵌入式领域Vibe Coding能不能更大范围铺开不取决于模型本身的能力而取决于平台的标准化程度。如果某个SoC提供了很好的HAL把硬件差异和中断细节都抽象掉了那它上面的业务代码就能越来越“Vibe”。反过来裸寄存器开发的项目AI参与度永远会受限。这也解释了为什么Linux用户态嵌入式开发和中间件开发会成为Vibe友好的先锋——它们的硬件抽象程度已经足够高。FPGA和RTOS底层开发短期还是以人为主。7.4 团队协作的方式需要跟着变以前嵌入式团队里负责写底层的人往往成为“瓶颈”因为大家都依赖他来填中断、调时序。现在AI能生成初版底层代码这个瓶颈松动了但新的瓶颈是“谁来定义最后的架构边界”。我在团队里的做法是让所有开发都能用AI生成前期版本但核心的软硬件接口规范、资源预算、可靠性策略必须架构师给定。AI在前端发散架构师做后端收敛效率提升很快。8. 写在最后一些真实感受做嵌入式开发这十几年我经历过从汇编到C、从裸机到RTOS再到嵌入式Linux的转型。每次新工具出现圈子里都会有一波“彻底改变”和“完全无用”的两极讨论。Vibe Coding在嵌入式领域的落地大概率走的是中间路线它不会让一个不懂硬件的人突然变成嵌入式高手但可以让一个懂硬件的人用同样的工程时间完成以前两三倍的产出。我现在的实际体感是AI主要负责把那些“我已经知道怎么解决但懒得写”的部分快速消灭我集中精力去盯那些“只有对硬件有直觉才能判断对错的”部分。这种分工让我在推进项目时明显更从容不是因为它替代了我的思考而是它让我把思考用在了更需要人的地方。如果你做嵌入式开发也打算试试Vibe Coding我给的第一条建议是从一个纯逻辑模块开始最好是没有硬件依赖的状态机或协议解析。先把它在PC上跑通找到那种“写完就能跑、跑不通就看反馈”的节奏感再逐步扩展到设备树梳理、初始化代码和UI层。不要在第一天就试图让AI独立写一个驱动加中断管理模块那只会让你对这个工具彻底失去信心。工具在变但有一个原则不会变嵌入式系统的价值永远是建立在稳定可靠的基础上的。AI可以把代码生成得更好看、更快速但可靠性判断永远是人类工程师的职责。谁能把这种判断力持续打磨谁就能在任何工具时代都站稳位置。