上个月调一块工业传感器板AI替我写了三页I2C驱动。编译零警告烧进去之后SDA电平死活不对示波器上应答位那一格始终是高电平从机像是被掐住了喉咙。我在板子前面蹲了一下午最后发现是GPIO复用模式配错了——I2C总线需要开漏输出加外部上拉AI配成了推挽复用一字之差物理上就是天亮和天黑的区别。那之后我开始认真拆这个问题Vibe Coding这个概念在嵌入式开发这个每天和示波器、逻辑分析仪、烧录器、勘误表打交道的领域到底意味着什么先说结论方向。Vibe Coding确实正在改变一部分嵌入式开发的节奏但它改变的不是你不需要懂硬件这个底线而是你把时间花在哪里这个分配问题。这篇文章我会把这几个月实测的适用场景、踩坑案例、工具链搭配和工作流调整一次性梳理出来给想尝试又怕翻车的同行一个参照。1. 到底什么是Vibe Coding从Karpathy那段话到验证者这个新角色1.1 概念起源不只是用AI写代码那么简单Vibe Coding这个词出圈基本绕不开Karpathy在2025年初做的一次分享。他的原意很形象你完全沉浸在编程的氛围里用自然语言把想法扔给模型模型生成代码你甚至都不需要去看代码长什么样跑起来不对就描述反馈让模型继续改。整个过程的核心是跟随氛围而不是逐行审视逻辑。这句话翻译成工程师听得懂的话就是从亲手实现变成描述意图验收结果。模型负责把手里的活儿干完你负责确认它干得对不对。这和GitHub Copilot那种补全下一个token是两代东西。Copilot是你在打字的时候帮你接下半句主导权始终在你指尖Vibe Coding依赖的是Codex、Cursor Agent、Claude Code这类Agent型工具——它们能自己读整个仓库、跨文件改代码、跑构建命令、看测试输出、甚至提交PR。这就不是自动补全了是一个真的在干活的同事只不过这个同事需要你持续提供指令和反馈。1.2 本质转变写代码贬值验收代码升值Vibe Coding最容易被误解的地方是以为它让人不用再懂编程。恰恰相反它把每一个开发者都推到了验收者的位置上。你可以想象一下施工队和指挥官的区别。以前你是施工队一砖一瓦自己砌砌歪了你立刻能感觉到手感和偏差现在你是指挥官你指挥一台高效但偶尔会自作主张的机器去干活你的价值在于——你能不能一眼看出墙砌歪了你知不知道这堵墙要承重多少你能不能在被问为什么这里用钢筋混凝土而不是砖的时候给出判断代码也一样。AI生成一段GPIO初始化语法和结构一定是对的但它是在给你砌一堵看起来正确的墙。这堵墙要不要承重、要不要防水、要不要留伸缩缝取决于你给它的描述和它隐含的假设。验收者如果没有专业判断力验收就只是走个形式。1.3 为什么嵌入式圈对Vibe Coding的讨论格外激烈嵌入式开发对代码正确性的容忍度极低。跑在服务器上的Python脚本出了逻辑错误顶多返回一个500跑在医疗设备控制器里的C代码出了时序错误那就是设备故障甚至安全事故。这种零容忍的特性让嵌入式工程师天然对黑盒生成代码充满警惕。但另一方面搜索引擎的数据又很诚实——嵌入式vibe codingcodex vibe coding这些词搜索量涨得很快。说明大家的心态是矛盾的一边觉得这玩意儿在玩具项目里确实好用一边又怕在量产项目里被坑。这种矛盾本身就是这篇文章想聊透的东西。2. 嵌入式开发的脾气为什么Vibe Coding在这里容易翻车2.1 代码和物理世界强耦合AI看不见你的硬件嵌入式代码和纯软件代码最大的区别是它直接和物理世界对话。你写的每一行寄存器操作、每一个中断使能位、每一次总线时序最终都会转化成引脚上的电平变化、芯片内部的状态切换。AI训练时见过的代码绝大多数来自GitHub上那些跑在通用操作系统上的项目——有MMU做内存隔离有malloc做动态分配有操作系统兜底处理崩溃。但嵌入式代码运行的环境是没有虚拟内存、没有用户态内核态之分、一个野指针就能让整个系统复位、一个ISR里不小心调了printf就能让实时性彻底崩塌。模型对代码应该长什么样的统计认知在通用软件开发里是优势在嵌入式里有时候恰恰是陷阱。它很容易按照通用习惯给你生成一个带malloc的函数而在很多MCU工程里堆根本就没初始化或者你明确要求过禁止动态内存。2.2 验证反馈闭环的成本差异Vibe Coding的发动机被物理世界掐住Vibe Coding这套玩法之所以在Web开发里能跑得飞起核心是反馈闭环极短。写一段代码浏览器刷新看到结果不行就继续改——一个循环可能只有一两分钟。嵌入式呢一个典型的调试循环改代码、交叉编译、烧录、断电上电、接上逻辑分析仪或者示波器、观察波形、猜测问题、再改代码——快则10分钟慢的话一个下午就搭进去。如果再遇上需要特定外部触发条件才能复现的bug一个闭环可能以天为单位。Vibe Coding的本质是生成-验证-再生成的强化学习回路反馈越快模型越能收敛到正确的输出。可物理世界偏偏不让你快每次验证都要付出真实的烧录和接线成本。这是嵌入式场景下Vibe Coding转不起来的根源——不是模型不够聪明是验证飞轮的物理成本太高了。2.3 交叉编译的隐形雷区宿主环境不是目标环境AI生成代码后最浅层的验证方式是编译通过。但在嵌入式里编译通过和能运行之间隔着整整一个太平洋。典型问题AI在x86 Linux主机上生成的代码里用了#pragma pack(4)在ARM Cortex-M的GCC工具链下实际对齐行为可能完全不同AI生成一个位域bit-field结构体来映射硬件寄存器编译器不同、字节序不同位域的分配顺序就是反的。这种问题不会让编译报错只会让你的板子在某个极其隐蔽的时机突然行为异常。我见过最无语的一次AI在一个RISC-V的工程里生成了依赖__ARMCC_VERSION的条件编译代码这个宏在GCC的arm-none-eabi工具链里根本不存在于是关键路径的代码被预处理器整个吞掉了。编译依然成功因为被吞掉的代码本来就不是语法错误只是不存在。这种低级但隐蔽的坑验证手段不够的人完全发现不了。3. 我把AI用进嵌入式项目的实战分类哪些交给它哪些绝对自己来3.1 放心交出去的任务边界清晰、验证明确经过几个月的折腾我总结出了一条判断标准输入输出边界越清晰、验证方式越明确的任务AI的产出质量越高。反过来说凡是依赖运行现场判断的任务AI的表现就断崖式下跌。我实际用下来成功率最高的几类配置代码与初始化模板。无论是STM32CubeMX生成的初始化代码迁移、ESP32的管脚配置、还是Linux设备树里的一段节点这类代码有极强的模板性AI看过海量实例产出的结构基本靠谱。我只需要对照数据手册确认引脚号和复用功能号。寄存器封装层。给AI一个外设寄存器手册的片段让它生成读写封装或者生成一个外设驱动的空壳框架它做得又快又好。这类工作本质是机械翻译AI是顶尖翻译官。协议解析代码。只要协议规范帧格式、校验字段、超时机制给得明确AI生成UART帧解析、Modbus从机处理、CAN报文拆包的代码都很扎实。这里有个前提你得先自己把协议的状态机画清楚再让AI去实现状态机的代码细节。构建脚本和测试桩。Makefile、CMakeLists的常见模式、单元测试用例、mock桩代码这些是AI的最强项。因为它训练数据里这类内容极其丰富而且失败反馈来得快——脚本能不能跑一执行就知道。3.2 千万不能完全交给它的任务依赖运行现场AI是盲人下面这几类我强烈建议哪怕让AI帮忙也必须全程人工主导中断上下文代码。ISR里的代码对延迟极度敏感一个函数是前导后导还是中导调用、是否被优化器改动顺序、访问的变量要不要用volatile都依赖你对硬件行为和编译器特性的理解。AI生成的ISR看起来逻辑正确但它不知道你的中断优先级、不知道这个ISR的触发频率、不知道临界区内能不能延迟这3个周期。内存布局和链接脚本。这属于构建系统的顶层设计AI对链接脚本的修改经常是看似微小、实则致命。改一个FLASH起始地址牵动的是中断向量表、启动代码、Bootloader跳转地址AI没有全局视野。低功耗状态机。进入Stop模式前要把哪些外设时钟关掉、哪些引脚保持什么电平、唤醒后从哪个中断恢复、恢复后要不要重新配置时钟树——这种代码的成败完全依赖芯片具体行为AI无法通过阅读常识代码来获得这些知识。时序敏感的外设驱动。比如单线总线的严格时序、SPI的片选时机、PWM的更新周期边界。AI缺乏波形直觉它生成的是逻辑不是物理。3.3 我实测的嵌入式任务适用度对照表下面这张表是我根据自己的实际项目整理的适用度是个人感受每个人的工程环境不同会有偏移但大致方向可以参考任务类型AI适用度主要风险点建议姿态验证手段寄存器封装/外设驱动模板高引脚号/外设基地址写错人工核对数据手册编译代码审查UART/SPI/Modbus协议解析高状态机边界条件遗漏自己画好状态机再交给它单元测试串口实测构建脚本CMake/Makefile高工具链参数不匹配对比本机工具链版本干净环境全量构建设备树/DTS配置中高属性名拼写/兼容字符串错误对照芯片手册复核内核启动日志单元测试与mock桩高断言过度宽松测不出真bug审查断言是否真实有效覆盖率工具RTOS任务设计与栈配置中栈尺寸估算偏差由人做资源预算栈水印检测中断服务函数低延迟、重入、优先级问题人写AI只做审查逻辑分析仪时间戳链接脚本/内存布局极低向量表偏移/地址错位人改AI只做解释反汇编启动日志低功耗流程极低状态切换细节遗漏人主导AI辅助查手册功耗仪实测硬件故障排查不适用AI看不到波形和现场人主导AI分析日志示波器逻辑分析仪一个有意思的现象AI适用度高的任务普遍有一个共同点——它们面对的是规则。协议、语法、模板都是明确规则AI是规则的集大成者。而适用度低的任务面对的是现场——哪个引脚此刻电平是多少、中断什么时候以什么频率来、编译器在某个优化级别下做了什么——这些是AI看不见的。4. 我的嵌入式Vibe Coding工作流工具选型、提示词配方与合入前检查4.1 工具选型Codex、Cursor、Copilot在嵌入式场景的真实表现先放结论嵌入式场景下我不建议把宝押在任何单一工具上我的主力组合是本地编辑器Agent终端自定义构建脚本。先说GitHub Copilot。它是补全型选手你在写代码时它帮你续写在嵌入式日常中表现尚可但只是提速工具撑不起Vibe Coding的完整工作流。它不读你的整个工程上下文也不执行构建验证。Cursor是我目前的主力IDE。它的Agent模式能跨文件理解整个仓库配合本地终端跑构建命令的能力在嵌入式工程里很实用。我习惯在Agent模式里先贴出目标芯片型号、工具链路径、工程目录结构让它自己读代码、改文件、然后调用我预设的build.sh脚本。实测下来对于填充实现细节这类任务靠谱率在七八成。Codex这几个月进步明显强在仓库级重构和自己跑验证闭环。如果你有一个纯软件的嵌入式辅助工程比如上位机配置工具、固件打包脚本、日志分析器Codex体验很好。但让Codex直接处理厂商IDE套壳的嵌入式工程时频繁踩坑——它很难理解IAR的.ewp工程结构也没法自动操作ST-Link烧录器在本地物理烧录这一步就断了。它擅长的是纯数字世界的闭环一旦涉及烧录器和硬件闭环就断了。Claude Code我也试过命令行Agent的交互方式对嵌入式任务其实有优势尤其是让它分析编译日志、定位告警来源的时候响应质量很高。但同样受限于物理烧录环节无法独立完成生成-烧录-验证的完整循环。所以我日常的真实工作流是用Cursir Agent模式做代码生成和跨文件修改写完代码后在本地终端跑我预设的交叉编译脚本把编译错误和告警丢回给AI迭代烧录和硬件验证一定回到工程流程里由我手动操作或者用自写的半自动烧录脚本如果目标是上位机工具、CI流水线、日志分析这类纯软件任务我会把Codex单独拉出来跑完整闭环。4.2 一套能显著降低幻觉率的提示词配方很多人觉得Vibe Coding翻车是因为AI笨其实很多时候是提问的人什么都没交代。我在嵌入式方向上总结了环境描述五要素每次让AI干活前这五条必须写全目标硬件MCU型号、内核架构、主频、关键外设。工具链与SDK编译器版本、HAL库/标准外设库版本、RTOS版本。硬性约束内存限制、实时性要求、禁止事项比如禁止动态分配、禁止在ISR里做阻塞调用。输入输出接口用哪个引脚、哪个外设、什么电平逻辑、跟谁通信。验证手段你打算怎么验证它写的代码对不对期望AI配合什么。一个实际可用的模板长这样我最近让AI写一个DMA接收不定长帧的需求目标环境STM32F407VET6168MHzHAL库1.27FreeRTOS 10.3arm-none-eabi-gcc 10.3。 工程路径firmware/app目录。请实现一个基于DMA的UART接收不定长帧功能。 约束使用HAL_UARTEx_ReceiveToIdle_DMADMA为循环模式。禁止在中断回调中使用任何阻塞调用或动态内存分配。串口配置115200-8-N-1。生成代码后请列出你认为最容易出错的3个点标注需要人工确认的内容。注意最后一条——要求AI自曝风险点。这一步极其关键。它逼着模型在生成完后重新以审查者的身份过一遍自己的代码很多幻觉会在这个环节被模型自己拦下来。实测这个自曝风险点步骤能把最终翻车率降低一个量级。4.3 合入前的类代码审查流程Vibe Coding不是说让你完全不看代码直接合入而是把看代码的方式从逐行读变成关键点审查。我给自己定了一个强制流程每次AI代码合入前必过引脚和外设编号逐一核对。凡是AI代码里出现的GPIO号、外设基地址、DMA通道号一律对照数据手册或者CubeMX生成的参考代码这个环节绝不能跳过。我的I2C翻车事件就是在这一步溜掉的。让AI解释它认为的硬件假设。比如我常问为什么这里用上拉而不是下拉这个延时是基于什么时钟算的如果AI答不出来或者答错了说明代码里有它自己都没意识到的假设必须深挖。自动化防线编译告警全开-Wall -Wextra -Werror视情况使用至少跑一遍静态分析clang-tidy或cppcheck关键模块挂单元测试。AI代码最怕静默潜伏而这些工具能把大部分静默问题暴露出来。5. 三次翻车实录AI代码在真实硬件上的崩溃现场5.1 案例一I2C应答位消失传感器永远读回0xFF这是我的真实经历也是这篇文章的引子。项目是一个温湿度传感器读取AI一次性生成了整个I2C驱动的框架。我检查了函数逻辑、寄存器初始化顺序、延时计算全部看起来很合理。编译零错误零告警烧录启动然后读回来的数据永远是0xFF。排查过程很长大概花了一个下午。我先是怀疑上拉电阻没焊拿万用表量了SCL和SDA都有3.3V排除。然后怀疑时序不对逻辑分析仪抓出来看主机发出的读指令完全符合协议帧格式但数据线的应答位一直高。从机明明在线就是不应答。最后一条条寄存器核对发现问题出在GPIO复用配置上。I2C的SDA和SCL引脚必须配置为开漏复用功能AF_ODAI写成了推挽复用AF_PP。推挽模式下主机输出高电平时是主动驱动SDA线被死死拉高从机想把总线拉低发应答位根本拉不动。硬件没问题、协议逻辑没问题就栽在一个GPIO模式上面。这个案例的教训是AI生成的外设驱动语法、结构、逻辑都可以完美但对物理行为的理解一旦偏差就是致命缺陷。所以现在我让AI写任何驱动前会先把对应外设的硬件行为约束明确写进提示词包括I2C引脚必须使用开漏模式必须配置外部上拉这类细节。5.2 案例二FreeRTOS任务栈的幽灵溢出另一个项目里我用AI生成一个数据上报任务的框架。AI写了一个从SD卡读取一批数据的函数函数内部声明了一个1KB的局部缓冲数组。我没多想就直接用了然后产品进入现场测试。问题很隐蔽系统不是一跑就崩而是每运行几十分钟到几小时随机地进入HardFault。刚开始我怀疑是外部干扰因为现场环境有电机电磁噪声不小。后来在实验室复现用手摸都有可能触发但又不是必然触发非常难定位。排查链拉得很长。先是想办法让HardFault的信息留下来在HardFault_Handler里写一个标志位用调试器读出故障时的PC值发现指向一个不确定的地址——典型的栈被踩烂之后的随机跳转。然后我开了FreeRTOS的栈水印检测功能用uxTaskGetStackHighWaterMark把所有任务的栈余量打印出来这才发现那个数据上报任务的栈余量是负数——栈底早就被捅穿了。原因也简单任务栈我配了512字节AI生成的函数里那个1KB局部缓冲一旦函数被调用就会立即击穿512字节的栈空间。平时不发数据没走那个分支现场一触发那批SD卡读取栈就爆了恰好爆在任务上下文的返回地址附近于是随机HardFault。这个案例让我把资源预算划进了人工专属区。AI只看到了一个函数需要一个缓冲区但它看不到这个任务在系统里的栈分配、其他任务的栈需求、总内存的余量。这类涉及全局资源预算的工作AI的视野天然不够必须人来兜底。5.3 案例三OTA双区切换链接脚本改出来的HardFault一次OTA升级功能改造我想把Firmware从单区改成A/B双区。这个工程涉及Bootloader跳转地址、App的链接脚本、中断向量表偏移三处联动修改。我偷了个懒把链接脚本的FLASH起始地址变更交给了AI指定了新旧地址让它生成修改后的.ld文件。AI很快给出了修改看起来只是把ORIGIN和LENGTH改了合情合理。编译链接全过Bootloader写入、跳转串口能看到App的启动日志。然后我按了一下按键触发了一个外部中断系统瞬间HardFault。排查过程比上一个案例清晰很多。串口日志显示App的main函数已经跑起来了说明跳转没问题。但是一进中断就崩这几乎是指向向量表的问题。我反汇编看了生成的.elf发现中断向量表还是按原始地址0x08000000布局的。原因很简单链接脚本修改后App的SystemInit里设置向量表偏移SCB-VTOR的那段代码还是老值HAL库启动文件默认向量表跟着Flash起始地址走但跳转过来的中断向量入口全都从老地址取取到的自然不是有效的处理函数。后面我查阅了整个启动链路把VTOR设置为新App区的起始地址并用代码检查向量表第一项初始SP是否在合法RAM范围如果非法就不跳转。问题才真正解决。这个案例给我的教训是AI擅长做局部修改但链式关联链接脚本→向量表→启动代码→Bootloader跳转条件是它的盲区。它看到的是要把地址从A改成B看不到藏在启动文件里的那一行向量表偏移设置。凡是这样跨模块、多层联动的改动我现在一律自己动手。6. Vibe Coding时代嵌入式工程师真正该练什么6.1 硬件直觉是最后一道护城河AI能生成SDRAM控制器初始化的完整代码但它不会在系统跑着跑着随机死机的时候帮你想到可能是DDR的tRCD参数在高温下不够裕量可能需要用逻辑分析仪去量一下时钟和命令线上的毛刺。这些诊断能力来自你在示波器前蹲过的无数个小时来自你反复翻勘误表形成的行为直觉。AI再强大它也没摸过那根探头。我觉得说硬件直觉是护城河有点科幻了更准确的说法是硬件直觉是最后一道阵地。当AI把所有人写代码的差距拉平之后你能不能让一块板子在恶劣环境下稳定运行、能不能在三天内定位一个偶发性HardFault、能不能在成本和性能之间找到那一个最优解——这些能力不会因为Vibe Coding贬值反而会因为AI把低端编码工作大量接管而变得更稀缺。6.2 把环境描述能力当成新的编程基本功过去我们衡量一个工程师看的是他代码写得漂不漂亮。现在你让AI干活最值钱的能力变成你能不能把环境和需求描述清楚。同一块板子、同一个功能一个人只丢一句帮我写个串口驱动另一个人给了芯片型号、工具链版本、外设编号、约束条件和验证手段——后者的产出质量和效率可能差三倍。我建议每个嵌入式团队都沉淀一份AI任务描述模板把上面的环境五要素固定下来。这不是限制AI而是最大程度消除AI的猜谜空间。你给它越少的自由发挥余地它给你的幻觉就越少。6.3 用AI加强验证闭环而不是加强代码输出这是我最近几个月调整最大的一个认知转变。以前我总想着让AI多写点功能代码现在我反过来了核心功能代码尽量自己写但让AI去生成测试、分析日志、检查覆盖率、审查差异。一个典型的分配方式我负责写关键的驱动逻辑AI负责——把HAL库的API差异整理成对照表、给关键函数生成单元测试用例、用脚本把串口日志里的错误码批量统计分析、在Git提交前帮我列出本次diff里所有涉及寄存器和引脚号的改动点。这样AI的强项快速处理海量文本、模式匹配、机械生成被用在验证环节而我的精力被释放出来去盯真正的物理现场和设计决策。说白了嵌入式开发里的Vibe Coding从来不是让AI替你写代码而是让AI替你跑掉那些重复的、机械的、确定性的工作把人的时间留给不确定性的战场。最后分享一个我目前仍在坚持的小习惯所有AI生成的代码合入前只靠git diff审查一遍凡是出现我解释不了的改动、我看不懂为什么这么写的片段、或者我知道AI八成会搞错的地方无条件回退或者拉懂行的同事一起过。这段时间尝试下来最深刻的体会就是AI真正适合当你的结对工程师而不是你的自动驾驶系统——方向盘和刹车一定得抓在自己手里。