Vibe Coding这个词烧了大半年Web圈子里一群人用自然语言搓接口、搭后台半天出一套原型玩得飞起。可一旦把这套玩法搬到嵌入式开发这边画风立刻变没有谁敢拍胸脯说让AI把整个BSP生成完烧到板子上一次点亮。为什么因为嵌入式要面对的从来不是JSON和状态码而是寄存器位、时序、勘误表、上电波形还有那根说不清什么时候就接触不良的杜邦线。但这并不意味着Vibe Coding和嵌入式开发绝缘。过去大半年我一直在做一件事想办法把AI辅助编码的方法论一点点塞进嵌入式的工作流。踩了不少坑也沉淀出一些能直接落到工程里的套路。这篇博客就是这段时间的真实体验和思考聊聊哪些环节AI是真帮忙哪些环节它就是嘴硬的猪队友以及嵌入式开发者在这个时代到底该怎么重新定位自己的核心能力。1. Vibe Coding到底在干嘛嵌入式凭什么说“不”1.1 先搞清Vibe Coding的本质别把工具当软件Vibe Coding这个词最早是Simon Willison提出来的指的是一种工作方式开发者不逐行手写代码而是用自然语言描述需求让大模型生成代码人的主要工作变成审查、微调、来回敲打。它有个很形象的画面开发者像爵士乐手一样进入一种“氛围”状态顺着AI给的节奏走不是每个音符都自己弹但整首歌还是在自己把控之下。这里要先澄清一个误区网上有人搜“vibe coding下载”“vibe coding安装”以为它是个可以装到电脑里的软件。实际上它不是一个独立工具而是Cursor、Copilot、Claude这类AI编码产品背后的一种使用范式。理解了这一点才能理解为什么它到了嵌入式领域会水土不服——问题不在“工具不好用”而是“范式本身依赖的东西嵌入式环境给不了”。Web领域能让Vibe Coding迅速火起来背后的逻辑其实很清晰。反馈链路太短了写一个接口、起一个服务、浏览器里刷新一下结果立刻可见。出错了把报错贴回去AI马上改一版五轮之内往往能收敛。加上Web技术栈极其同质化Python、JavaScript、SQL、Docker这些语料可能占了模型训练数据的主力AI当然显得无所不能。而嵌入式开发是完全不同的环境。这里有一个很尖锐的错配Vibe Coding的核心是“模糊需求快速反馈大语料”嵌入式开发的核心却是“精确约束慢速反馈强专业语料”。1.2 嵌入式凭什么被认为和Vibe Coding八字不合第一个差异是反馈速度。Web那边写完一个函数几秒后浏览器告诉你行不行。嵌入式写完一个驱动你要交叉编译、烧录、上电、连串口、看波形一个循环快则几分钟慢则半天。AI生成十版代码你验证一版就得半天这一版还大概率是错的效率不升反降。第二个差异是硬件不可推理。大模型的文本知识再强它不知道你这块板子的上电时序是1.8V先于3.3V不知道这颗芯片的勘误表里写了DMA在某种条件下会丢数据。AI生成的代码语法上是对的编译也能过但放到硬件上就是跑不动而且是不稳定的那种跑不动今天行明天不行。这是最折磨人的。第三个差异是专业垂类语料稀缺。芯片手册、外设驱动、RTOS源码这些高质量语料很多不公开或者以PDF和私有代码形式存在大模型训练时接触得少。你会发现同一个AI写Python爬虫得心应手写STM32的SPI从机驱动却频繁出错本质上就是它“没见过”足够可靠的硬件代码资料只能靠泛化硬凑。所以嵌入式从业者对Vibe Coding的第一反应是警惕这很正常。但也没必要因噎废食。真正的态度应该是搞清楚AI在什么环节能帮上忙、什么环节会添乱然后把它放在一个合适的生态位上。2. AI在嵌入式开发里的真实表现哪些活它能干哪些活它翻车2.1 AI真能提速的四个环节我实践下来AI最靠谱的是生成“样板代码”和“中间业务逻辑”而不是核心硬件操作。先说最典型的几个场景。第一是外设初始化框架。裸机或者RTOS环境下SPI、I2C、UART、CAN这类外设的初始化结构网上语料极多AI见过成千上万遍。只要在prompt里明确芯片型号、库版本、引脚分配它给出来的初始化代码和中断回调基本八九不离十。这类工作过去至少得花半天查手册、翻例程现在十几分钟能出初稿效率提升明显。第二是纯软件逻辑。状态机、CRC校验、环形缓冲、协议解析、PID参数整定这类与硬件解耦的代码AI同样很强。我试过让它写一个带超时处理和错误重传的Modbus帧解析器把边界条件列给它它生成的版本比我自己敲的还干净。而且这类代码的验证不需要硬件本地就能跑单元测试反馈快正好契合Vibe Coding的优势区。第三是单元测试和mock。嵌入式圈子里很多人不爱写测试Unity、CMock这些框架配置繁琐、门槛高。让AI生成一个外设模块的mock或者生成一段测试桩代码能省很多重复劳动。我的建议是每个嵌入式工程都让AI帮你生成一个“日志分析小工具”把二进制串口日志转成可读的时序表格这个工具写一次整个项目周期都在受益。第四是交叉编译环境下的辅助脚本。构建脚本、烧录脚本、非阻塞式的日志过滤工具AI生成后往往能直接用这类胶水代码不太挑硬件又省时间。2.2 翻车实录寄存器补全、编译链差异和中断里的定时炸弹我也踩过不少大坑挑两个最典型的说。第一个坑AI自信地补全了寄存器位。某次让它配置STM32F103的ADC多通道扫描模式它很自然地补了一段初始化结构把某些保留位当成普通位给置了。代码能编译、能跑但采出来的数据就是不对。查引脚、查参考电压、查触发源浪费了整整一个晚上最后是一行行对着参考手册才发现问题。这个现象的本质是AI在“见过但不够精确”的知识上倾向于用一种自信的方式把空缺补上而寄存器手册里的保留位恰恰是它最不敏感的信息。第二个坑AI不顾编译环境差异。团队里有人用GCC有人用ARMCC还有人的工程挂在MDK里。AI有时候生成一个__attribute__((packed))或者特定编译器内置函数在你当前链路下根本不过它还坚持说是你环境配错了。这种问题不致命但非常消耗耐心。我后来的解决办法是每次提交需求时把编译器和编译选项明文写进prompt里并且要求AI不得使用任何项目中未出现过、且无法验证的编译器特性。还有更隐蔽的问题中断上下文里的动态内存分配。AI对软件工程最佳实践的理解多来自服务端应用服务端可以随便malloc、new但在嵌入式中断里这是大忌。如果prompt里没强调“ISR里禁止alloc、禁止阻塞”AI大概率会给你造出未来线上故障的定时炸弹。这种问题编译器发现不了代码review的时候也容易被“看着挺规范”给迷惑过去。总结下来AI在嵌入式里的靠谱程度严重依赖于你喂给它的约束有多具体以及你能不能形成一个快速的硬件验证闭环。3. 把Vibe Coding正确接进嵌入式工作流上下文、定位与验证闭环3.1 喂给AI的不是需求是项目级上下文很多人在Vibe Coding时代最容易犯的错是把AI当成搜索引擎上来就问“怎么写DMA传输”。这能得到通用答案但绝对得不到能直接用的代码。正确做法是给AI“项目级上下文”分几步走。第一步把芯片头文件和参考驱动喂进去。比如你用GD32F450就把它的外设寄存器头文件、官方固件库里相似外设的driver、以及当前工程的主配置头文件全部复制粘贴进入对话。AI看到真实寄存器宏定义之后生成代码的准确性会有质的提升因为它不用靠记忆猜地址了。第二步把编译链工具版本、优化级别、内存布局写清楚。我习惯在工程里维护一个CONSTRAINTS.md文件固定格式写上芯片型号、IDE或工具链、编译选项如-O2、-fno-strict-aliasing、RAM和Flash剩余空间以及几条硬性红线ISR内禁止malloc、禁止长时间关中断。每次让AI生成代码第一句话就是“请严格遵守CONSTRAINTS.md不得使用与当前工具链冲突的特性”。第三步让AI“先讲思路再写码”。强迫AI先输出一个实现大纲列出它打算怎么处理时序、怎么分配缓冲、错误怎么处理能提前拦截很多方向性问题。不要让它直接甩代码先审思路觉得没问题再让它展开成代码。多一轮交互少一次翻车。3.2 把AI当成能反复改稿的硬嘴实习生我的心态模型是这样的不要指望AI是无所不知的专家它更像一个知识面极广、但手特别生的实习生。它很容易写出“看起来对、用起来错”的东西还爱坚持己见。所以你要给它明确的任务拆解、验收标准并且Review每一份产出。具体拆分上我强烈建议一次只让AI做一个模块不要让它一口气生成整个BSP。比如这个prompt只解决“初始化SPI2时钟频率5MHz使用DMA方式收发错误回调打日志”另一个prompt只解决“Modbus从站状态机”。拆分的好处是每份产出都能单独编译验证出了问题能精准定位到某次对话而不是面对一大坨代码不知道从哪里开始排查。代码Review阶段我有两条硬规则。第一条是逐行审查寄存器操作。凡是看到AI直接写寄存器地址的必须回查芯片手册确认哪怕地址看起来合情合理。第二条是严格执行编译零告警。AI生成的代码如果带了warning我不会花时间去判断这个warning能不能忽略一律让它解释清楚并消除。嵌入式环境里warning往往指向未定义行为放过一个warning半夜就是一次偶发死机。3.3 验证闭环没有硬件回环的AI编码都是耍流氓Web端的Vibe Coding闭环是“写码-运行-看结果”嵌入式这边必须多一层硬件验证。我总结出一个必须做到的点AI每生成一版软件必须能在本地完成编译和基础静态检查然后烧到目标板上跑一个固定的自检用例。自检用例我建议设计成一个“硬件体检程序”把各外设跑一遍结果通过串口输出到自动化脚本脚本比对日志。这么一套下来每次AI改完代码流程就是改代码、本机编译、烧录、跑自检、比对日志。整个周期能被压缩到十分钟级别虽然比Web端慢但已经足以支撑Vibe Coding的迭代节奏。没有这个闭环AI生成代码的失误成本会高到无法承受这也是为什么很多嵌入式团队试了几天AI辅助就退回去的原因——他们只把AI嵌入了编码环节却根本没嵌入验证环节。另外多说一句工具链环境。很多做嵌入式Linux应用开发的朋友会问到底要不要在Ubuntu下开发。我的回答是如果你写的是Linux应用或驱动要么用Ubuntu主机交叉编译要么在Windows上开WSL总之不要让开发环境和部署目标存在语义割裂。AI完全不知道你的开发机长什么样它只会按“一般情况”来写你得负责把“一般情况”收敛成你的实际情况。4. 聚焦热门场景嵌入式Linux应用开发、汽车电子与应用层之争4.1 嵌入式Linux应用开发当前AI辅助收益最高的细分领域从我自己接触的项目来看嵌入式Linux应用开发其实是AI辅助收益最高的嵌入式细分方向。原因是应用层代码跟硬件耦合已经解耦得比较干净开发环境就是Linux跑着POSIX接口、socket、线程几乎和服务器开发混在一起。AI在服务器领域积累的语料足够多写出来的网络、文件、进程通信代码质量很高。举个例子我之前写一个车载网关的远程升级模块核心逻辑是从OTA服务器下载固件包校验签名解压写入双分区中的非活动区下次启动切换。如果用传统方式光是把代码组织、错误处理、超时重试想明白并且适配具体平台的接口封装至少两个工作日。我让AI先把整个模块拆成网络下载、校验、分区切换三部分每部分生成初稿我再逐段Review和修改。整个模块前后只用了一天AI贡献了至少六成工作量剩下四成是人肉确认安全边界和一些平台细节。顺带说一句嵌入式Linux开发要不要在Ubuntu下做答案其实是“要么在Linux主机上做要么在Windows上用WSL或远程开发环境”。原因不是“必须用哪家操作系统”而是工具链和部署目标要保持一致。AI生成代码时对系统调用和路径的假设默认是Linux语义你在Windows上直接编译往往跑不通来回折腾的时间比手工写代码还长。把开发环境逼到与目标一致AI反而能发挥得更好。4.2 汽车电子功能安全约束下的AI边界汽车电子是嵌入式里对“确定性”要求最高的一档AUTOSAR、功能安全标准、ASPICE流程每一步都在约束“代码是怎么来的”。逻辑上讲AI生成代码的“可追溯性”很难填进功能安全认证的材料里但不代表AI完全派不上用场。我的经验是汽车电子的工程师可以把AI用在两块。一块是需求分析和测试用例生成比如拿到一个软件需求条目让AI按AUTOSAR的结构生成对应的测试用例框架能显著减轻测试工程师的重复劳动。另一块是让AI辅助分析现有的MCAL或RTE配置找出配置不一致的地方而不是直接生成配置。这类辅助性用法不触碰认证核心边界却很实用。这里我必须泼一盆冷水别指望AI直接生成符合AUTOSAR标准的复杂SW-C代码也别拿它生成的代码去填“已实现”的勾。原因不仅是正确性更是流程。功能安全要求的是受控的、可证明的、可追溯的开发过程而当前大模型的黑盒机制在这块无法提供足够的证据链。你用AI写的代码可以落地但必须靠你自己补充完整的设计、测试和追溯材料而这些往往才是最花时间的部分。4.3 应用层开发到底算不算嵌入式换一个回答角度“应用层开发是不是嵌入式”这个争论由来已久。我个人的观点是没必要纠结“算不算”这个问题更有意义的判断标准是“你的开发对象是否直接依赖硬件约束”。如果一个人用C语言写Linux上的数据采集应用处理的还是网口、串口、GPIO设备节点那我认为它本质上就是嵌入式开发。变量名里没有“寄存器”不代表你不需要懂硬件。反过来如果一个团队用Qt写一个安装在工控机上的组态界面对硬件细节完全无感那更接近传统应用开发。两者没有高下之分只是知识栈和调试侧重点不同。Vibe Coding对这个话题提供了一个新的观察角度AI能帮你快速写出跟CPU、内存、IO解耦的“应用层业务代码”但它永远替代不了你对着数据手册、拿着示波器排查硬件问题的能力。这恰恰是嵌入式开发者应该重点打磨的地方不管你是上位机应用层工程师还是裸机驱动工程师“读懂硬件行为”都是最不会被AI替代的核心能力。5. 常见问题与AI辅助编码排查实录5.1 编译不过别急着甩锅给AI先做三件事编译不过的时候人会下意识把整个报错贴给AI让它修。这在Web开发里可行在嵌入式里不是最优解。嵌入式交叉编译环境本身就容易出“环境差异导致的报错”如果直接把报错丢给AI它往往会把责任推给工具链最后绕了一圈还解决不了。我建议分三步排查。第一步先隔离。把AI生成的文件单独放到一个最小工程里编译如果在最小工程里能过那问题就在原有工程的宏定义、链接脚本、头文件包含关系上。第二步把报错信息和编译环境都喂给AI并且明确告诉它“不要怀疑编译器配置只处理代码层面的问题”。第三步如果还不行对比官方demo工程看AI生成代码在哪些地方偏离了官方推荐的写法重点检查中断向量表、链接脚本修改、启动文件相关的位置。这里有个实战经验AI生成代码导致编译失败十个里面有六个是头文件路径问题两个是类型声明不一致一个是它用了C特性而你的工程是纯C剩下一个才是真正的逻辑错误。看到报错先别慌用编译器的**-I选项把头文件搜索路径摆清楚或者用-E展开预处理结果**看看宏定义是不是如预期把“找文件”这件事做扎实再谈其他。5.2 硬件异常而配置“看起来对”用寄存器写入日志定位前面提到过AI补全寄存器的翻车案例这里补充一个排查方法。如果现象是“代码能跑、功能不对”不要先去怀疑硬件先怀疑寄存器配置。拿官方例程作为基准把AI生成代码里所有寄存器操作列出来跟例程逐一核对。更高效的做法是做一个“寄存器写入日志”。在调试模式下把所有直接写寄存器的语句包一层带日志的写函数每写一个寄存器就记录地址和值然后跟官方例程在同样条件下记录的写入序列做比对。两者出现偏差的地方大概率就是问题点。我靠这个方法找回过好几次被AI“自信”写错的坑比拿着示波器瞎猜强得多。这个方法同样适用于AI配置DMA描述符、PLL分频系数、中断优先级表这类容易出错的地方。5.3 AI辅助嵌入式开发避坑速查表常见的坑我的对策为什么会踩AI生成代码编译不过隔离到最小工程先排查头文件和宏再喂报错给AI交叉编译环境差异被AI误判寄存器位被“自信”补全逐行对照手册开启寄存器写入日志大模型对保留位不够敏感ISR里出现malloc或阻塞调用CONSTRAINTS.md中硬性禁止Review重点检查AI的编程经验主要来自服务端场景编译器特性不兼容生成前明确工具链版本零告警是硬门槛AI默认“通用环境”而非你的实际环境整个BSP一次性生成无法定位问题一次只生成一个模块单独编译验证输出过大的代码段人肉审查覆盖不了功能安全场景直接使用AI产物只用于测试用例、辅助分析不进交付链路AI生成过程无法提供可追溯的证据链不跑硬件自检就合入代码强制每次改动都跑自动化自检和日志比对反馈慢导致问题延后暴露成本成倍上升这些条条都是实际踩过或者团队里反复验证过的不一定全面但能帮你在接入AI辅助时预先填掉一大半坑。6. 几点思考Vibe Coding时代嵌入式工程师的护城河6.1 门槛在降但能力分层会更明显肉眼可见地嵌入式开发的入门门槛在降。过去写一个驱动可能要在网上搜半天博客对着晦涩的数据手册硬啃。现在AI能帮你把初始骨架搭出来你只需要专注理解“为什么这个寄存器要这么配”。这对新人其实是个不错的环境它把大量重复劳动时间榨了出来让你能更快接触到硬件理解的核心。但门槛降低不意味着能力贬值。我反而觉得一个人能不能驾驭好AI正在迅速成为嵌入式工程师新的分水岭。会用AI的人把节省下来的时间投入到系统架构、硬件调试、安全设计这些高价值环节不会用AI的人可能还在跟寄存器纠缠。这个差距会在未来两三年内被拉得非常明显。6.2 最值钱的不是写代码是对硬件的因果直觉我越来越坚定一个判断嵌入式工程师最值钱的能力是“对硬件的因果直觉”。看到一个现象能快速在脑海里形成多条因果链的假设然后通过测量排错锁定根因。这种能力大模型暂时给不了你它只能提供“大多数情况下有效”的文本模式。比如你遇到一个偶发死机可能牵扯到看门狗、电源纹波、内存越界、中断优先级。AI能给你一堆常见排查方向但最终定位用的还是你脑子里对板子时序、对代码执行路径的建模能力。Vibe Coding时代代码生成已经不是核心竞争力但读懂硬件、定位问题、设计系统的能力反而更加珍贵因为AI释放了你的时间你有更多机会去打磨这些能力。6.3 我看到的未来形态AI是第二块示波器如果让我做一个比喻AI在嵌入式开发里就像第二块示波器。第一块示波器让你看见电信号第二块AI示波器让你看见“代码里的模式”你给它一个奇怪的现象描述它能给你列出一百种可能性给它一段代码它能快速指出不符合常规的写法。但示波器永远代替不了你理解电路AI也永远代替不了你理解硬件。未来的嵌入式工程师大概率会处于人机协同的状态AI负责广度快速生成、快速解释、快速排查线索人负责深度做决策、做验证、做安全兜底。谁能更早适应这种分工谁的项目交付质量和个人成长速度就会明显占优。我在实际项目里已经体会到“把AI当搜索引擎用”和“把AI当实习生带”是完全不同的两种产出水平。后者不是那么舒服要写约束、要Review、要一遍遍验收但恰恰是这种较真的方式才能把一个听起来很酷的Vibe Coding真正落地成嵌入式工程里靠谱的生产力。我后面还会继续在这个方向上做实践尤其是把硬件在环自动化跑得更顺一些到时候再跟大家分享新的心得。