说实话第一次听到Vibe Coding这个词的时候我正在调试一块新拿到的工业传感器模组满脑子都是时钟树配置和中断优先级的问题手头那本寄存器手册已经翻了好几夜。当时对这个概念是一点都提不起兴趣——感觉那是搞Web和大模型应用的人玩的东西跟嵌入式这种动不动就要跟物理世界打交道的圈子不太可能搭上什么边。但后面几个月里AI辅助编程的浪潮还是不可避免地把我卷了进来。从用自然语言让AI给我生成一段I2C初始化代码到用聊天窗口解决一个交叉编译的环境问题再到让AI帮我解释一页晦涩的设备树节点含义我逐渐意识到Vibe Coding这种“顺着感觉写代码”的方式也许不能直接照搬到嵌入式开发里但它背后代表的那股生产力变革已经开始在这个领域产生真实的冲击。这篇文章我结合自己最近几个嵌入式项目的实操经历聊聊在Vibe Coding时代嵌入式开发到底哪些环节真正能用上AI哪些环节必须保持警惕以及我们应该用什么样的姿势来面对这次变化。1. 先把概念摆清楚Vibe Coding和嵌入式到底分别是什么1.1 Vibe Coding是一种编程方式的迁移不是偷懒Vibe Coding这个说法最早由Andrej Karpathy在2025年初提出指的是借助AI代码生成工具用自然语言描述编程意图让AI持续生成代码而你在过程中只负责“感受整体方向”不断验收、调整提示词、修正错误让代码在语义对话中逐渐成型。简单说以前是“面向编译器编程”现在是“面向AI描述意图再回来校对结果”。对这种模式我最初的印象是“这不就是让AI替自己写作业吗”。但认真用了几次之后我发现它的内核其实不是偷懒而是一种工作重心的迁移你把显式的编码操作交给AI把更重要的判断工作——界定需求、验证正确性、评估质量——握在自己手里。这在Web和纯软件领域尤其好用因为那些领域的反馈回路很短改完代码立刻可以编译、运行、看结果错误暴露得也很快AI可以快速迭代修正。但嵌入式开发有个天然的不利因素反馈回路长而且又长又痛。改完一个驱动交叉编译、烧片、看串口日志、抓波形这一圈下来可能半天就没了AI如果一开始就产生了带病代码代价是很高的。这个差异决定了我后面要聊的所有适配边界。1.2 嵌入式开发的全貌从哪里到哪里很多人聊嵌入式开发以为就是写MCU代码、操作寄存器或者顶多再加一个点灯。其实这个领域的链条长得很从底往上大概可以分为几层。底层是和硬件紧密相关的工作包括芯片选型、电源电路理解、时钟配置、GPIO复用、外设驱动、中断处理这一层最看重对数据手册和时序的理解。中间层包括各类协议栈、实时操作系统、文件系统、网络协议栈比如你用RTOS管理多任务用LwIP做网络通信用Flash组件管理掉电存储这些都算是中间层。再往上就是应用层负责业务逻辑、人机交互、数据处理比如用Qt5做嵌入式Linux设备的图形界面用MQTT协议把设备状态上报到云端平台或者实现某种业务算法。应用层以外还有大量工程化工作交叉编译环境的搭建、启动脚本和环境配置、CI/CD流水线、单元测试和硬件在环测试等等。这些层级在工程实践里经常是交织在一起的一个人在项目里往往要横跨好几层。1.3 应用层开发到底算不算嵌入式聊到这我觉得有必要说一个网上争论比较多的问题应用层开发是不是嵌入式开发。我的答案是只要你的应用是跑在嵌入式目标设备上的它就是嵌入式开发的一部分只是处于这个链条更靠上的位置。判断标准不在于你写的是不是C语言、有没有碰寄存器而在于你的代码是否仍然受嵌入式环境的约束处理能力有限、内存有限、功耗受限、需要交叉编译以及最终行为必须跟底层硬件可靠配合。比如你在STM32上写一个传感器数据滤波算法虽然不直接碰寄存器但它必须在没有MMU的MCU上跑得飞快这就是嵌入式应用开发。又比如你用Qt5在Linux开发板上做界面同样要考虑交叉编译、中文字体部署、内存占用这些约束让它跟桌面开发完全不一样。所以应用层开发不是不像嵌入式而是嵌入式链条里更平滑、更接近产品形态的那段。也正因为如此应用层也是Vibe Coding最容易被接受的切入窗口——这部分代码的反馈回路相对短AI生成的效果比其他层好得多。1.4 嵌入式Linux开发到底要不要在Ubuntu下搞经常有准备入行的朋友问我嵌入式Linux开发需要在Ubuntu下开发吗直接说结论不一定非Ubuntu不可但Linux环境几乎可以说是嵌入式Linux开发的默认选项。核心原因有三个。第一交叉编译工具链和绝大多数嵌入式Linux SDK都是以Linux优先的官方文档里的命令和步骤在Ubuntu上验证最充分。第二内核开发、设备树调试、构建bootloader这些工作很多工具在Linux下才运转得最顺畅。第三Linux环境下的脚本自动化、CI集成这些工程化能力比Windows舒适得多。但如果你是纯应用层开发比如用厂商提供的IDE和SDK在开发板上跑Qt应用那Windows也不是没法干用WSL2装一个Ubuntu子系统、或者直接用虚拟机跑Ubuntu镜像都是绕开双系统折腾的好办法。我自己现在的主力开发机就是Windows日常在WSL2里做交叉编译写代码用VSCode嵌入式工程文件放在WSL的目录下两边协同起来已经足够顺滑了。2. 嵌入式和Vibe Coding的适配边界哪些能干哪些要谨慎2.1 我最初为什么对嵌入式场景上的Vibe Coding悲观讲完了基础概念我想先坦白一下刚接触AI辅助编程时我对其在嵌入式领域的价值是持悲观态度的也不是没有理由。最直接的原因是嵌入式代码极端依赖具体硬件的细节。随便举个例子你需要配置一个I2C外设的时钟、引脚复用、时序参数每一个数值都来自几百页甚至上千页的数据手册每颗芯片还可能有细微差异。而AI大模型即使训练数据再多也不可能记得住市面上所有芯片的每个寄存器偏移量和时序约束。让它直接写外设初始化代码经常是“看着像那么回事对着手册一核对全是洞”。其次是调试周期太长。Web开发的反馈闭环可能只有几十秒编译、改、刷新页面就能看到结果。嵌入式开发呢交叉编译、烧录、串口输出或者逻辑分析仪抓波形一个来回动辄几十分钟甚至数个小时。AI如果提供的代码方向性错了你发现问题的成本比纯软件场景高一个数量级。再加上嵌入式系统普遍对时间和空间资源极其敏感。同样一段代码在PC上是优雅在MCU上可能就触发硬错误。AI很难帮你判断缓存命中的代价、中断服务函数执行时间的预算这些隐性约束。这些限制让我一开始觉得Vibe Coding在嵌入式里注定水土不服。2.2 试过之后我发现这几类场景真能提效但人的观点总要在实践里被修正。真正动手把AI工具融入到嵌入式项目后我发现有几个环节的效率提升是实实在在的。第一类是外设驱动的骨架代码。虽然AI常常写错具体寄存器配置但它能把整个驱动框架搭得很清楚从哪里初始化结构体怎样注册回调怎么和上层接口对接。这就好像有个熟悉项目模板的老同事帮你把脚手架搭好你再往里面填精确到位的细节。实测下来这个流程能把驱动的开发周期压缩到原来的一半左右。第二类是协议解析和状态机这类逻辑密集但和数据手册关系不大的代码。只要我给它一份清晰的协议描述比如帧头、帧长、校验方式、每条命令的语义AI写出来的解析函数往往相当扎实边界处理也比预想中细致。这部分工作以前是最磨人的现在反而成了我最愿意交给AI的任务。第三类是上位机、测试和辅助工具。用Python写串口调试脚本、用Qt5快速搭一个数据显示界面这类代码反馈闭环快语法模式和通用库熟悉度高AI基本上是“一出手就能用”。我的很多设备调试和流量测试脚本现在都是AI先出个八九成我再改细节。第四类是工程脚本。交叉编译命令、CMakeLists的组织、Makefile依赖关系、Dockerfile这类东西语法单调、模式固定AI生成后再人工审查比从头写省太多力气。第五类是文档与注释。生成寄存器配置说明、模块接口文档、代码注释AI的表现称得上优秀。特别是你写好一个模块代码后让AI对照你的实现生成一份详细的README简直像白捡了一个技术文档工程师。2.3 哪些环节绝对不能闭着眼Vibe Coding上面讲了很多可以的场景这一节讲不可以的我把这块看成整个话题里最重要的部分。第一安全关键代码。汽车电子里涉及刹车、转向、动力控制的功能安全模块或者工业设备里涉及人身安全的逻辑都不应该由AI主导生成后不经深度验证就上线。ISO 26262这类功能安全标准里对开发流程、代码溯源、测试覆盖率有极其严格的要求“AI生成代码”在不少审查环节里怎么定性都还没有公认答案。不是说AI必然出错而是责任边界完全没法落实。第二中断服务函数和实时性敏感的时序关键路径。在中断里多一句慢动作整个实时控制系统就可能在毫秒级出问题。AI生成代码的能力还不足以让它理解“这个函数必须严格遵守多少微秒的时延预算”这样的隐性约束。第三低功耗设计里涉及状态机切换、掉电保持、唤醒路径的代码。这类代码需要你对芯片的上电序列、引脚状态、外设掉电行为都有过硬的把握一旦交给AI就是引狼入室。第四涉及内存布局、位域对齐、DMA缓冲区管理的代码。这些地方错一个字节都会导致神秘的踩内存问题而且调试成本极高。我建议这类代码要么自己亲手写要么让AI生成初稿后你一字一句对着反汇编验证。我的整体原则是Vibe Coding在嵌入式里应该被看作一个可执行的建议来源而不是一个可以撒手不管的代码生产者。3. 实操记录用AI辅助完成一个嵌入式小项目3.1 项目目标与开发环境构建为了让上面的理念落在实地我专门搭了一个小项目来验证。项目目标很朴素在一块基于STM32F407的开发板上通过I2C读取一颗温湿度传感器然后把数据封装成MQTT消息通过以太网上报到本地MQTT broker同时在Ubuntu下用Qt5写一个简单的上位机实时显示设备上报的数据。开发环境的构建就是我前面聊过的工程实践我在Windows笔记本上装了WSL2在WSL里安装arm-none-eabi工具链用于STM32的裸机交叉编译还安装了arm-linux-gnueabihf交叉编译器用于Linux端应用开发同时装好CMake和Ninja。IDE用VSCode加Remote-WSL插件直接在WSL环境里编辑代码。这个项目分三条线底层是STM32的I2C驱动和MQTT客户端库中间有个透传网关负责把传感器数据从UART桥接到以太网上层是Qt5上位机。我在整个过程中都用AI工具辅助了部分代码生成接下来挑最有代表性的两段说一下。3.2 用AI生成I2C驱动的过程与修正先说我给AI的提示词大概长什么样。我告诉它我用的芯片是STM32F407VET6I2C外设1主模式速度400kHzSCL/SDA脚是PB6/PB7需要提供一个初始化函数和传感器SHT30的基本读写函数支持7位地址0x44返回错误码。AI生成的初稿里初始化函数的主要结构是有的基础的时钟使能、GPIO复用配置、I2C模式配置都带了。但问题出在一地鸡毛的细节上它把GPIO的模式配置写对了大半却漏了上拉寄存器的OTYPE和PUPD组合导致SCL实际是开漏没有正确上拉时钟频率的计算它给了一个公式框架但把系统总线时钟72MHz当成了APB1时钟36MHz来算导致实际SCL频率直接翻倍另外I2C的软件复位序列也漏了。修正过程反而是整个项目里最有价值的部分。我打开SHT30的数据手册和STM32F4的参考手册一个一个寄存器去核对AI生成代码涉及的每个字段把OTYPE、PUPD补上把时钟计算改成基于APB1的正确频率把软件复位序列加上。这看起来是多了很多排查工作但如果没有AI先搭好框架我写一遍驱动的时间大概是现在的两三倍。换句话说AI在嵌入式项目里正确的用法是让它把九成的结构性工作做掉你把剩下的一成关键细节打磨到位顺便把这一成理解透彻。3.3 AI在Qt5上位机与MQTT上报里的表现等到了Qt5上位机和MQTT代码这块AI的表现就明显上一个台阶了。我先让AI生成一个基于Qt Widgets的简单气象站界面要求有温度、湿度两个实时变化的数字显示控件和一个滚动日志框并用QTimer定时刷新。AI在几秒钟内给出了一份能直接编译运行的View代码框架信号槽的连接、布局管理、定时器的基本写法都是对的我只调整了一个文本控件的字体大小和布局间距。然后我又让AI帮我封装一个基于paho.mqtt.c的C MQTT客户端类包含异步连接、发布消息、订阅主题、自动重连。它实现得很稳错误处理也考虑到了。这部分的反馈闭环短我可以快速编译运行在Ubuntu宿主环境里直接用本机broker测试效果明显好于驱动部分。这件事本身就说明了一个分层逻辑同样的AI工具在嵌入式应用层工作得行云流水在底层驱动层就踢到厚铁板。原因完全在于反馈回路长度和知识密度差异。另外我也试了让AI帮忙写一个简单的设备树节点配置片段来说明某个外设的时钟来源效果只能说一般——AI能解释每个字段的含义但给出的具体数值还是需要你自己去内核源码和芯片手册里验证。这种辅助定位有价值但不能当作最终答案。3.4 交叉编译、部署与调试中的AI辅助交叉编译这步我也让AI参与了一把。我需要一个CMakeLists.txt来把Qt5的App交叉编译到ARM Linux设备上并链上paho-mqtt。AI给出的CMake文件在设置交叉编译工具链前缀、Qt5工具链位置、库路径这些核心要素上基本准确主要需要我补的是目标设备的sysroot路径以及几个库文件的链接顺序问题。好在CMake语法错误信息很明确改起来很快。真正让我觉得AI有用的是部署后的一个问题排查。我把编译好的Qt应用传到开发板运行程序直接段错误崩了。我先在Ubuntu主机的Qt环境里编译一个原生版本验证逻辑无误确认崩溃来自交叉编译环节。然后让AI帮我整理了一份快速gdb定位段错误位置的指引很快发现是某个结构体成员在32位目标平台上对齐方式不同导致的偏移问题。这类问题纯靠人肉在C和架构差异两头排查是很花时间的有一个逻辑清晰的外挂助手确实提速不少。3.5 碰到的两个典型性问题这个项目做下来最典型的两个问题值得记录一下。问题一是I2C读回来全零。排查完发现不是AI代码的问题而是我自己在接线的时候把SDA和SCL的上拉给忘了。这个教训跟Vibe Coding本身没有关系但恰恰提醒了我嵌入式开发的物理世界部分AI再强也帮不了你检查松掉的杜邦线。问题二是Qt应用在开发板上中文乱码。解决方法是把中文字体文件传到设备并加载Qt字体配置AI给出的方案很完整包括打包资源文件和调用QFontDatabase注册字体的代码段。这个纯属环境问题AI帮了大忙。这两个问题让我意识到项目做下来最重要的收获不是AI多么好用而是你怎样把AI的输出纳入你的质量流程。做完这个项目我自己把AI的定位从“代码生成器”更新成了“带审校机制的编码搭档”。4. 汽车电子这类高安全场景怎么理性看待Vibe Coding4.1 功能安全标准对AI代码的约束我身边有不少做汽车电子嵌入式的朋友聊到Vibe Coding的时候兴致勃勃又心存疑虑。因为汽车电子开发环境和通用嵌入式有一个很大的区别它受到ISO 26262之类的功能安全标准约束软件的开发流程、文档记录、验证活动都得有完整证据链。在这种环境里“AI生成了一段代码”本身不是什么问题问题是你的流程能不能证明这段代码经过了完整的需求追溯、设计评审、代码走查、单元测试、集成测试并且覆盖率达到要求。现实是目前大部分功能安全体系里都没有对AI生成代码的明确条款。讨论最密集的地方是MISRA C的规则及合规性分析怎么处理AI生成的代码。MISRA C是汽车电子C语言编码标准要求逐条规则排查AI生成的代码往往在可读性和安全防御方面欠佳审查起来反而是额外的负担。4.2 高安全场景下的正确姿势所以我给这类场景的建议是AI可以当提效工具但绝不能当代码作者。你可以用AI帮你写需求文档的初稿、整理模块接口说明、生成单元测试用例的框架这些属于辅助性很强的工作不碰最终安全代码。涉及安全关键逻辑的部分老老实实保持传统流程和审查路线。让AI帮你把非安全的工具代码搞定省下来的精力集中投入到最需要人类判断的核心里这才是理性姿势。顺便说一句汽车电子领域关注AUTOSAR的也不在少数。AUTOSAR那套配置工具生成代码本来就有一套严谨的流程AI目前很难插手进去因为配置项的来源和版本管理都被工具链锁死了。与其想着让AI改变流程不如把它用在解读配置工具报错、辅助维护配置文件这类周边环节上效果反而更好。我个人的体会是在汽车电子、医疗电子这类领域Vibe Coding不应该被理解为一个“无脑写代码”的工作流而是一个“无脑写辅助产物”的工作流。需求、设计、验证、追溯这条主线永远需要人来负责。5. 给嵌入式开发者和新手的实在建议5.1 基本功怎么也省不掉不管Vibe Coding这个词有多火对嵌入式开发者和准备入行的人来说基本功依然是绕不开的地平线。C语言和数据结构是底线数据手册的阅读能力和代码调试能力是真实竞争力这两点你用AI也替代不了。AI能告诉你模模糊糊“大概应该怎么写”但它不会替你理解“为什么你的板子上电后外设时钟没起来”。在工具链上我建议新手至少亲手完成一次完整的裸机开发不要去抄现成的SDK。自己用参考手册配置时钟树、GPIO、串口把串口打印出一个Hello再点亮一颗LED这个过程中你对硬件的理解会彻底上一个台阶。然后转RTOS、再看Linux驱动、再学设备树每一步都自己踩过坑再谈效率。还有一点容易被新手忽略的是硬件调试工具的使用。逻辑分析仪、示波器、万用表这些工具在排I2C时序、量电平、找接线问题时比任何AI都可靠。我见过太多人代码写得没问题最后栽在硬件细节上。嵌入式是软硬结合的活AI能补软件这块的短板但它不会替你把电路板修好。5.2 AI工具的评判标准与使用技巧谈到AI工具我的态度是别妖魔化也别神话。大部分主流的AI编程助手在嵌入式场景里最大的价值是帮你把脚手架搭好、把工程脚本生成好、把文档注释补好。我的一个实用技巧是给AI发提示词的时候尽量把芯片型号、系统时钟、引脚编号、总线频率、数据手册页码这些确定信息全部喂给它。AI的专长是根据结构化指令做结构化输出输入越精确输出越可靠。你甚至可以先把一个简易板卡描述和参考手册的目录粘贴给它再让它写具体代码效果会好很多。另一个技巧是永远不要接受AI给你的第一个版本代码。让它在你的审查下先过一遍把不确定的地方标出来让它给出设计依据和可能的风险点把它当成一个负责任的外包工程师来用。质量判断永远只能在你脑子里不在它的输出里。另外交叉编译环境里的报错信息经常是玄学把整段报错原封不动丢给AI分析有时比你自己盯着屏幕猜半天更高效。5.3 我的个人体会回到Vibe Coding这个词vibe原本的用法更接近“跟着感觉走”但我现在更愿意把它理解成“保持对整体的把握感”。Vibe Coding时代真正有价值的不是让AI帮你写几千行代码而是你愿意为了让AI写得更好把需求定义得越来越清晰、把接口设计得越来越合理——这个过程本身就是嵌入式工程师核心能力的体现。当你花时间把正确的问题问清楚AI给你的答案才会接近可用。这不是AI的魔法是我们自己把工程边界摸得更透了的成果。最后分享一个我反复用来提醒自己的细节吧。有一次我用AI生成了一段看起来很漂亮的低功耗状态切换代码逻辑完整、注释也专业我几乎就要直接放进项目了。还好留了一手先在示波器前面实测了一下唤醒时序结果发现从深度睡眠到外设重新就绪的时间比数据手册标注上限还大了两成整个调度就崩了。从那以后我给自己立了个规矩AI的代码永远要过一遍硬件测试特别是时序、功耗这一类跟物理世界强相关的功能。这不是保守是因为嵌入式开发的行规从来不是一个“生成代码会变得多容易”的问题而是“你敢不敢为每一行代码负责”的问题。Vibe Coding这个时代的到来对我们这个圈子没有人是旁观者。尽量去用它但记住哪些东西只能靠你自己用心。