这几年“Vibe Coding”这个词在开发者圈子里火得很快从Web前端到后端开发都有不少人在用。但在我们嵌入式开发这个行当里情况要复杂得多——有人觉得AI写代码解放了生产力也有人觉得这玩意儿在嵌入式领域就是个定时炸弹。我自己是一名做了十多年嵌入式开发的工程师从8051玩到Cortex-M从裸机开发到LinuxQt5的应用层都搭过这段时间把Vibe Coding的工作方式引入到嵌入式项目里试了一遍有不少心得体会。这篇文章不聊空话就讲清楚Vibe Coding在嵌入式开发里到底能干什么、不能干什么以及我踩过的坑和总结出来的可落地方案。先说清楚Vibe Coding本身是个什么概念它是由前Tesla AI总监、OpenAI创始成员Andrej Karpathy在2025年初提出的一个说法描述的是你用一种比较随意的自然语言表达想要的代码让AI模型生成一整个模块或者文件然后你在测试和运行的过程中通过反馈不断调整直到功能看起来符合预期这种开发方式。它和传统的AI辅助编程不一样——早几年的Copilot是自动补全帮你接下一行而Vibe Coding是人跟AI在一个对话窗口里反复沟通AI给你整块整块的代码你负责感觉这个对吗的判断然后把跑不通的地方再丢回去让它改。本质上你变成一个评审者和调试者写代码的体力活让模型干。在嵌入式圈子里大家对Vibe Coding的态度非常分裂。有人说我让AI写了一百多行的寄存器初始化一次就对了比我手敲快多了。也有人直接怼回去它写过一个能过编译却在真机上把电机干烧的PWM驱动。这两种声音其实都是对的。嵌入式开发的特殊性决定了Vibe Coding不能直接用互联网圈那套能跑就行的逻辑但也没必要因噎废食。这篇文章就是想把能用和不能用的边界划出来再给出我实测过的一套工作流让想在嵌入式项目里用Vibe Coding的人少走弯路。1. Vibe Coding到底适合嵌入式开发的哪一层1.1 嵌入式开发的四层结构要讨论Vibe Coding能不能用先把嵌入式开发的工作内容拆开看。我习惯把嵌入式工程分成四个层级每一层的代码特征、失败代价和测试难度差别巨大最底下是硬件层原理图、PCB Layout、芯片选型这一层跟软件代码没关系但决定了上层代码怎么写。什么引脚复用什么外设中断优先级怎么分配这些在画板子的时候就定死了。往上是驱动层寄存器操作、中断服务程序、DMA描述符管理、时钟树配置、Cache一致性处理。这一层的代码离硬件最近编译器行为、芯片勘误表、信号完整性问题都会在这里炸雷。代码量通常不大但每行都是用命写出来的。再往上是中间层实时操作系统RTOS的移植和配置、通信协议栈TCP/IP、CAN、Modbus、EtherCAT、文件系统、日志框架、电源管理策略。这一层对时序敏感任务优先级和资源竞争是主要矛盾。最上面是应用层业务逻辑、人机交互界面比如Qt、LVGL、数据采集与处理、状态机、参数管理。这一层跑在操作系统之上资源相对宽裕crash了也能重启测试手段也丰富。为什么要分这么细因为Vibe Coding在这四层里的可用程度是断崖式下降的应用层最好用驱动层基本不能用中间层要挑场景用。很多人问应用层开发是不是嵌入式我从工程组织的角度看应用层开发当然属于嵌入式开发流程的一部分但它更接近运行在嵌入式系统上的应用软件开发。如果你干的活主要是Qt界面、业务状态机、通信服务器对寄存器、时序、内存布局完全不敏感那你的开发体验跟做桌面应用非常接近Vibe Coding的适用性自然就高。这不丢人每个团队都需要人把上层逻辑理清楚。反过来如果干的是驱动层和硬实时中间层那Vibe Coding得小心再小心。原因不是AI写不出代码——它能写出看起来完全正确的驱动代码而是它写出来的代码无法通过它自己的逻辑推演来验证。Web端的代码错了页面报错信息怼在你脸上嵌入式驱动错了可能是上电三秒后系统跑飞也可能是在零下二十度、跑了两千小时才偶发一次故障。这种反馈延迟和故障隐蔽性让Vibe Coding最核心的边聊边调、跑一下看看循环完全失效。1.2 为什么Vibe Coding在嵌入式领域会过拟合到错的答案上我们得明白大模型写代码的本质它是在海量代码样本上学习到的条件概率分布预测给定这个需求描述和上文接下来最可能出现的token序列。问题在于嵌入式的训练样本占整个程序员社区产出的代码总量比例非常低。GitHub上公开的代码绝大多数是Web后端、数据处理、DevOps脚本和算法题解。真正躺在NXP官方SDK、ST的HAL库里、汽车电子BSP里的嵌入式代码大部分是私有仓库或者半公开状态。所以模型在生成嵌入式代码时它其实是在用Web开发的那种代码感来猜嵌入式怎么写。最典型的现象就是它默认你会用malloc随意分配内存、默认你有无限长的栈、默认你的中断服务函数可以调用任何库函数、默认整型是32位且小端——这些在x86 Linux上成立的假设在嵌入式环境里可能全错。我让AI写过一个STM32的ADC采样任务它给我生成了一段非常漂亮的DMA双缓冲代码逻辑完整注释齐全但我一眼就看到它没有处理DMA传输完成中断里的半传输标志位这是ST官方的经典坑——如果你不在半传输中断里切换buffer数据会在覆盖写的时候被CPU读到乱七八糟的值。模型不知道这个坑因为它的样本里关于这一点的高质量解释太少了。另外嵌入式项目还有一个隐藏约束芯片勘误表。很多芯片在特定条件下有官方承认的硬件bug需要软件规避。比如某款MCU的I2C外设在某些时钟配置下会产生假START信号官方勘误表里明确要求软件增加一个高电平脉宽检测。这种知识存在PDF里、存在老工程师的脑子里根本不在模型的训练语料里。Vibe Coding再厉害它也没法写出它没见过的东西。但反过来数据层和应用层的代码就不一样了。这类代码的规则高度公开、语义高度标准化Modbus协议帧格式是公开的Qt的信号槽机制是公开的JSON解析、SQLite操作、Modbus CRC校验算法、命令行参数解析……这些是海量训练样本模型见过无数遍写出来的质量甚至比平均水平的人类工程师还稳。Vibe Coding在嵌入式里的正确姿势不是让它写全部代码而是把工程里属于确定逻辑的那一大块外包给它剩下的硬骨头自己啃。2. 实操前先搞明白环境、工具链和开发平台的选择2.1 嵌入式Linux开发必须在Ubuntu下做吗很多刚入门的朋友都在问嵌入式Linux开发需要在Ubuntu下开发吗尤其是Windows用户看到热词里还有windows18-hd19嵌入式开发这种课程名更困惑了。直接说结论不一定必须用Ubuntu但Ubuntu或Debian系是最省心的选择没有之一。为什么这么绝对不是Linux系统高深而是嵌入式工具链的历史包袱决定的。交叉编译工具链比如arm-linux-gnueabihf-gcc、aarch64-linux-gnu-gcc在Windows下能用但你要处理各种路径分隔符、环境变量、DLL依赖Buildroot和Yocto这两个最主流的上层构建系统官方文档里的步骤全是基于Linux脚本写的虽然Yocto在Windows下能跑在WSL里但WSL环境有一堆坑:文件系统IO慢、串口和USB转接设备映射麻烦、Qt交叉编译时的图形依赖经常出奇怪问题。我自己试过在WSL 2里编译Yocto一个小时的构建任务比原生Ubuntu慢了接近一倍后来果断在双硬盘上装了双系统。要区分两个需求如果你的工作是纯应用层的写代码、调Qt界面、交叉编译一个可执行文件放到板子上跑Windows VS Code远程连到Ubuntu服务器或者开个WSL都能应付。但如果要碰内核模块、设备树、根文件系统裁剪直接上原生的Ubuntu环境实测下来最稳。Ubuntu LTS版本用22.04或者24.04都行注意老一点的工具链在24.04上有时有libc兼容问题不够省心就换22.04老牌稳定。工具方面我把常用的列个表方便新手直接照抄工具用途我的建议VSCode Remote SSH日常代码编辑、远程到Ubuntu编译服务器最主流插件Marketplace里搜remote-ssh即可QEMU用户态模拟x86主机上直接跑ARM可执行文件做冒烟测试装qemu-user-static验证基础逻辑够用交叉编译工具链编译目标平台二进制apt install gcc-arm-linux-gnueabihf即可Buildroot生成定制根文件系统、交叉工具链、bootloader、内核建议用国内镜像或本地缓存因为网络下载量大Device Tree Compiler编译设备树blobapt install device-tree-compiler关于Vibe Coding工具的安装和下载问题也顺带说一句现在主流的Vibe Coding工具不是一个单独的绿色软件大多是IDE插件加上云端模型服务的组合。VSCode上装好对应插件配置好模型API让它能读取你的工程文件这就完成了基础环境搭建。这里有一个嵌入式的独家建议不要只把代码文件喂给模型要把你的编译出错信息、串口日志、芯片数据手册的PDF片段一起丢进去。大模型对上下文非常敏感你给的约束越多它生成的东西越靠谱。而且现在的模型普遍支持markdown和代码块你把Buildroot的defconfig贴在对话里把报错贴在后面让它给出修复建议这个循环比我手动查文档快太多了。2.2 一个可复用的Vibe Coding 嵌入式工作基线我用了大概三个月的时间在真实开发流程里反复调整最终固定下来一套基线工作流分享给各位参考。这套流程的前提是你已经有一个跑通的编译环境和能启动的基础板级工程不是从零开始点灯。第一步把大工程拆成模块把模块的文件范围喂给AI。不要让AI看整个项目的全部代码它上下文窗口有限喂太多它抓不住重点。我一般会提供一个project_tree.txt用tree命令生成的目录结构然后在对话里指明本次只修改src/protocol/can_parser.c这一个文件其他文件不要动。第二步用文档化的方式描述需求。Vibe Coding的Vibe不代表你可以只说给我写个串口解析你要把完整约束写清楚。我习惯给AI一个模板输入是什么、输出是什么、依赖哪些头文件、目标平台的字节序和编译选项、错误怎么处理。例如我让AI写一个CAN报文解析器时给出的描述是STM32F407平台小端字段定义见文件can_proto.h解析结果存入结构体CanFrame返回值表示校验状态不允许使用memcpy直接转换结构体。这个描述包含了平台、字节序、接口、安全约束四类信息AI生成的代码就很少跑偏。第三步强制让它产出单元测试。这是很多嵌入式开发者用Vibe Coding容易忽略的一点。不要让它给你一个函数就完事让它同时写一个能在PC上跑的测试桩——输入一组十六进制字节验证解析字段是否正确。因为嵌入式代码最终要交叉编译上板子但逻辑测试可以在主机上先跑。这一步能把很多愚蠢的错误挡在编译之前。第四步代码审查不留死角。我不管AI生成的代码看起来多漂亮最终merge前必须逐行review。审查的重点是内存分配是否有界、循环是否有退出条件、中断上下文里有没有调用阻塞函数、有没有隐式的字节序假设。这个过程不可替代。这套基线流程跑下来我体感开发效率提升最大的是三件事Modbus和CAN协议解析、Qt界面状态机搭建、以及Buildroot的包配置调整。这三类工作的共同特点就是逻辑繁琐但有明确规范、重复性高、又有大量可参考样本。太适合Vibe Coding了。3. 具体实操让AI写LinuxQt5应用层的一个完整范例3.1 从需求到成品传感器数据采集界面我们团队的一个项目是在NXP i.MX6ULL板子上开发一个温湿度监控系统Qt5做界面数据来自一个Modbus传感器。换成Vibe Coding工作流以前我的做法是自己拉一个QMainWindow加两个QLabel再写一个QModbusClient的子类代码量不算大但琐碎信号槽连接、定时器刷新、异常分支处理写多了也烦。这次我故意让AI全程主导看看效果。我先准备了一个需求包里面包含三样东西项目目录树、Modbus传感器寄存器地址表、设计要求每500ms刷新一次数据异常显示红色日志写入本地文件。然后我把这几项内容作为prompt发给AI要求在本项目架构下新增数据采集与显示功能不改变原有工程结构。AI在几分钟内给出了一个可以编译的框架代码一个SensorWidget类负责界面显示一个ModbusWorker类用QModbusDataUnit读保持寄存器通过Qt信号把数据传回主线程更新界面日志用QFile追加写。整体结构干净线程边界清晰还自动处理了Modbus设备断线重连用了一个简单的重试计数器。这个输出质量比我预期的要好核心原因是传感器值读取和界面刷新是标准场景模型在训练时见过大量同类模式它甚至能正确选择Cadence和ReconnectDelay这类常见参数。我做了两处调整把重试计数器的上限从默认的15次改为可配置值把日志文件路径改为从配置文件读取——这是项目特有的需求它不可能知道。你看这就是我在前文说的让AI写模块不写架构。整体架构是我定义的模块边界是我划的AI在边界内自由发挥完成度很高。这个案例也说明了一个判断标准你需要判断你的需求是否足够标准。如果传感器数据采集定时刷新异常显示这三个词描述完十个工程师心里能浮现出差不多的代码结构那就是标准的放心交给AI。3.2 让AI处理交叉编译和系统集成脚本嵌入式开发里最花时间的不一定是写功能代码有时候是配置交叉编译环境、写systemd服务脚本、调整Buildroot的defconfig这些琐碎工作。这些活本身逻辑重、报错信息长、处处有平台差异特别适合Vibe Coding。我举个例子在某款ARM开发板上我们想让应用开机自启需要写一个systemd service文件还要保证应用在Modbus总线未就绪时等待重试。这个任务我直接描述给AI写一个systemd service服务名为modbus-gateway需要在网络和串口设备/dev/ttymxc0存在后才启动失败后每5秒重启一次最多重启6次。AI给了我一个久经沙场的老手才会写的方案用RequiresMountsFor/dev和udev的SYSTEMD_READY属性在[Unit]里用ConditionPathExists判断设备节点在[Service]里配置Restartalways和RestartSec5加上WatchdogSec看门狗。这比我手写一版考虑得还周全。交叉编译环境这种配置Vibe Coding同样能发挥价值。有一次同事在Ubuntu上构建一个老的Qt项目遇到无法找到libqt5serialport5-dev的交叉编译版本这种平台问题报错信息贴进对话里AI给出的方案是检查CONFIG serialport有没有被条件编译宏挡住同时确认交叉编译工具链搜索路径里有没有把sysroot的/usr/lib/arm-linux-gnueabihf加进去。这种知识极其零散搜索起来费时但模型的记忆中存了大量论坛帖子里的碎片它能快速拼出一个正确的排查方向。我在这个过程中明确感受到Vibe Coding在开发效率上的提升其实存在着一个悖论它让你在代码生成速度上收益巨大但让你的系统理解能力提升曲线变陡了。你不会亲手敲那些初级代码了但也不能要求自己不读懂就上板子调试否则会踩进坑里出不来。想用好它基本功反而更硬了。3.3 Buildroot场景一次让AI处理包配置的真实案例团队里做Linux系统集成的人应该都有体会Buildroot的配置文件——defconfig和Config.in——是典型看着简单改起来救命的东西。你要的包在menuconfig里翻半天找不到Dependency关系一锅粥编译报错信息经常是未找到头文件你根本不知道是哪个包缺了依赖。我试过一次让AI帮我梳理Buildroot的包关系需求是给rootfs里加一个Python3和一个pyserial库同时保证不会因为Python导致编译时间爆炸。AI给出的回答是推荐用BR2_PACKAGE_PYTHON3y打开Python解释器然后用BR2_PACKAGE_PYTHON_PYSERIALy选入pyserial同时提醒我Python的locale支持会拉进一堆ICU依赖建议用BR2_PACKAGE_PYTHON3_STANDARD_LIBRARYn裁剪标准库来减小体积。这个建议并不仅仅是从配置语法上给的它体现出对所依赖包的版本和编译链的理解。我验证了一遍完全正确这省去了我翻menuconfig和交叉编译错误日志的一个多小时。不过我也有翻车的时候。同样在Buildroot场景让AI调整内核配置去支持某个USB转串口芯片时它给我推荐了CONFIG_USB_SERIAL_CH341y但我实际芯片是CP2102正确的配置是CONFIG_USB_SERIAL_CP210Xy。这个错误原因很简单训练样本中CH341出现频率远高于CP2102模型按先验概率猜了一个最可能的答案。解决方式也不复杂在prompt里明确写出芯片型号和dmesg日志里的usb 1-1: cp210x converter now attached这类信息模型就能纠正。这提醒我关键性的硬件识别信息必须由你自己提供不能期待AI从需求里猜出来。4. 嵌入式Vibe Coding的翻车现场与排查思路4.1 编译过了真机一跑就崩这是我认为最危险的Vibe Coding翻车模式——因为AI生成的代码能一次通过编译太容易给开发者造成已经可以上板的错觉。整个过程是我按照需求描述让AI写了一个设备树解析模块功能大致是把/proc/device-tree下的一堆二进制属性解析成结构体。AI用的是我上面批评过的memcpy直接映射方式还加了个#pragma pack(push, 1)。在x86主机上用交叉编译测试一切都对扔到板子上运行结构体里的字符串字段偶尔会出现乱码。排查思路我记一下第一步看dmesg和串口日志锁定崩溃发生在解析特定节点时第二步用devmem2读取对应寄存器的原始值对比结构体里读出的值确认不是硬件问题第三步发现是结构体内存对齐问题——ARM默认对齐访问策略跟x86不一样用pack(1)解决了一类对齐问题却引入了非对齐访问的性能开销在某些配置下会导致总线错误。最终手工修正为逐字段拷贝加显式偏移量计算测试稳定了。从这件事里我给自己立了一条规矩凡是AI输出涉及通过结构体强转解析协议数据的代码一律重写。原因很简单C语言的结构体布局受编译器、对齐、目标平台字节序等多重影响在裸机/Linux用户空间/内核空间之间传递数据时结构体强转是无数不稳定bug的温床。协议解析只要遇到字节流老老实实用字节数组位移掩码或者用专门的序列化库别贪图代码短。4.2 时序和实时性AI理解不了的看不见的约束有一次做电机控制的项目让AI写一个Cortex-M4上的PWM占空比更新函数。AI给了我一个看起来无可挑剔的代码读影子寄存器、更新CCR值、触发重载。但测试时电机相电流有明显抖动排查了半天才发现AI把两个寄存器的更新顺序搞反了导致其中一个PWM通道比另一个晚一个周期更新。这种时序问题在逻辑上完全正确因为每个寄存器本身的值都对只是更新的先后顺序在硬件上引入了偏差。嵌入式里到处都是这种代码看起来静悄悄硬件行为很诚实的约束。AI无法从源代码里推断出外设寄存器X的操作必须发生在外设寄存器Y的操作之前且中间的延迟要小于200ns因为它从来不参与硬件行为验证它的世界里只有文本和逻辑。这类问题一旦发生你的调试手段会自动退化到示波器反复上电试验效率极低。我的处理原则变得很明确硬实时任务、中断相关的控制逻辑、外设初始化序列这三个类型的代码我从头到尾自己写AI只允许做代码审查。代码审查反而是AI有用的地方——你把自己的代码发给它让它从MISRA C规范角度挑毛病它能找出几个你漏掉的隐患比如未使用的变量、不合理的类型转换。这个模式比让它写驱动代码靠谱得多。4.3 数据完整性bug字节序、对齐与隐式假设我这里专门列一个字节序的例子。嵌入式系统里大小端问题几乎不可避免MCU可能是小端Cortex-M全系列默认小端传感器是通信协议定义的大小端外部设备可能是大端。AI生成代码时默认按主机字节序来写在交叉编译时x86主机的行为掩盖了目标平台的差异。我踩过的具体场景是一个AI生成的函数用于拼接两个16位寄存器值组成32位float——涉及的平台是小端的寄存器值本身也是小端存储AI的代码逻辑天衣无缝。但我另一个同事的平台是大端的POWERPC同样需求AI生成的代码直接拼出一个大小端完全颠倒的值仪表的数值变成了天文数字。这倒不全是AI的错——prompt里没有说明平台字节序AI用了默认的小端世界假设。所以规范化的prompt里一定要包含目标平台的字节序、编译器版本、C标准。我甚至会在需求包的最开头写一行所有代码必须符合目标平台字节序禁止使用无符号整型之间的强制转换来构造浮点数。4.4 汽车电子场景MISRA和AUTOSAR下的严格禁区做汽车电子嵌入式开发的朋友可能会更谨慎。在汽车领域代码要过MISRA C规范检查要满足AUTOSAR的分层架构功能安全上还要过ISO 26262的认证。Vibe Coding在汽车电子里基本是禁区原因不是AI模型能力不够而是合规验证的价值链被打断了。你的代码最终要能追溯每一个需求的来源要能向审核方证明每一行代码都经过了特定方法论的验证。AI生成代码天然缺少这种可追溯性除非你把AI生成的代码Andrius经过与人工编写代码相同的验证流程写进你们的流程文档里——但那样的话效率优势就大打折扣了。我自己帮朋友看过一些打着汽车电子旗号的AI生成项目很多所谓AUTOSAR代码生成工具生成的代码质量堪忧要么不符合RTE映射关系要么在复杂驱动里瞎用全局变量。这类代码拿到台架上一跑十个里有八个出问题。所以我的建议简单粗暴如果你在安全关键场景汽车、医疗、工业安全且代码需要过认证Vibe Coding现阶段只能用来做辅助分析工具——分析和阅读现有代码、生成测试数据、检查代码风格——不能直接生成交付代码。这个边界我建议团队在引入工具时就用规章制度明确下来别靠个人自觉。4.5 常见问题排查速查表最后给一张速查表方便出问题时快速对照。这些坑都是我实际踩过或帮人排查过的内容偏实操。现象可能原因排查顺序编译通过上板即崩溃结构体对齐/字节序/AI默认x86语义1. 抓串口日志 2. 检查协议解析是否用了memcpy强转 3. 对比寄存器原始值系统运行一段时间后偶发死机内存越界或资源泄漏1. 开启AddressSanitizer/Valgrind主机测试 2. 看板子上free内存曲线 3. 检查堆栈大小电机/PWM控制逻辑抖动外设寄存器更新顺序错1. 示波器看波形周期 2. 对比数据手册时序要求 3. 手工重写控制逻辑CAN报文解析数据错乱字节序/位域布局不匹配1. 查协议定义 2. 打印原始字节对比解析值 3. 禁止位域结构体转换Buildroot包依赖编译失败包依赖关系缺项或版本冲突1. 查看具体报错位置 2. 用make XXX-源查看依赖 3. 贴报错让AI提供排查方向AI生成代码违反MISRA规则训练样本未覆盖严格规范1. 接入静态分析工具如PC-lint 2. 修复全部告警级输出 3. 高风险场景禁用AI生成这张表做成团队内部wiki之后我让组里新人遇到问题时先查一遍很多低级坑都不用来来回回折腾了。5. 我对Vibe Coding 嵌入式开发的阶段总结5.1 三个阶段能力评估工具、流程与人先说工具本身。Vibe Coding如今的能力跟两年前的AI编程辅助相比已经完全是两个物种。不是它多聪明而是它整合了序列理解和上下文管理能力可以在一个很长的对话里持续理解你的工程约束。它的体验有点像你身边坐了一个行动力强但判断力平庸的实习生你说得越细它干得越靠谱你说你自己看着办它真敢在关键位置上给你来一段错得离谱的东西。流程层面我认为Vibe Coding在嵌入式团队里能不能落地取决于你能否把AI生成-人工审查-硬件验证这个闭环固化下来。闭环运转得好它能让你把省下来的精力花在真正需要人的地方——架构设计、疑难bug定位、产品级可靠性测试。闭环运转得不好它最终会变成一堆漂亮但危险的代码堆在仓库里等着某天爆发。5.2 我现在实际怎么用Vibe Coding收个尾说说这套玩法用下来我的最终改变。以前一个Qt界面功能模块从设计到编码大概要两小时现在是我搭好框架、写清楚接口注释、让AI生成具体实现我review后连编译带跑测试大概半小时。Modbus协议层和CAN解析器这类规范明确、无歧义、有大量参考实现的代码我的产出效率提升非常明显。我再也不用逐行敲样板代码也不需要在官网文档和论坛帖子之间来回翻找细节。但反过来那些直接影响安全、时序、硬件行为的核心逻辑我一个字也不让AI碰。比如设备树中断绑定、DMA描述符的分配与释放顺序、硬实时任务的优先级配置。这些代码我现在仍然是在编辑器里跪着手写写完之后逐行看汇编确认编译器没给我埋坑。这个习惯保持了十年在Vibe Coding时代依然有效而且我觉得更必要了——你没看懂的东西越堆越多到后面就成了定时炸弹。最后再分享一个我调整过很久的工作习惯AI生成的每一个文件我都会在文件头上加注释写明由AI在x年x月x日生成用途xxx人工审查人xxx测试结果xxx。这个习惯在出问题时能救命——因为当功能出bug时排查速度取决于你能多快判断这个文件是哪一版逻辑、谁改过、怎么测的。有追溯才有安全感。对整个行业来说Vibe Coding会不会彻底改变嵌入式开发的方式我觉得会但它的影响是渐进的它会先吞掉应用层开发、协议栈开发和系统集成的低价值重复劳动然后无限逼近但无法完全吞掉驱动层和硬实时层。直到有一天硬件调试手段本身被AI化——总线分析仪能自动出结论、示波器能自己解释波形——嵌入式开发的边界才会真正松动。在那之前我们这代人还得保持一项传统手艺看懂代码、看懂硬件、看懂它们之间的江湖。
Vibe Coding嵌入式实战：四层开发中的边界与避坑指南
这几年“Vibe Coding”这个词在开发者圈子里火得很快从Web前端到后端开发都有不少人在用。但在我们嵌入式开发这个行当里情况要复杂得多——有人觉得AI写代码解放了生产力也有人觉得这玩意儿在嵌入式领域就是个定时炸弹。我自己是一名做了十多年嵌入式开发的工程师从8051玩到Cortex-M从裸机开发到LinuxQt5的应用层都搭过这段时间把Vibe Coding的工作方式引入到嵌入式项目里试了一遍有不少心得体会。这篇文章不聊空话就讲清楚Vibe Coding在嵌入式开发里到底能干什么、不能干什么以及我踩过的坑和总结出来的可落地方案。先说清楚Vibe Coding本身是个什么概念它是由前Tesla AI总监、OpenAI创始成员Andrej Karpathy在2025年初提出的一个说法描述的是你用一种比较随意的自然语言表达想要的代码让AI模型生成一整个模块或者文件然后你在测试和运行的过程中通过反馈不断调整直到功能看起来符合预期这种开发方式。它和传统的AI辅助编程不一样——早几年的Copilot是自动补全帮你接下一行而Vibe Coding是人跟AI在一个对话窗口里反复沟通AI给你整块整块的代码你负责感觉这个对吗的判断然后把跑不通的地方再丢回去让它改。本质上你变成一个评审者和调试者写代码的体力活让模型干。在嵌入式圈子里大家对Vibe Coding的态度非常分裂。有人说我让AI写了一百多行的寄存器初始化一次就对了比我手敲快多了。也有人直接怼回去它写过一个能过编译却在真机上把电机干烧的PWM驱动。这两种声音其实都是对的。嵌入式开发的特殊性决定了Vibe Coding不能直接用互联网圈那套能跑就行的逻辑但也没必要因噎废食。这篇文章就是想把能用和不能用的边界划出来再给出我实测过的一套工作流让想在嵌入式项目里用Vibe Coding的人少走弯路。1. Vibe Coding到底适合嵌入式开发的哪一层1.1 嵌入式开发的四层结构要讨论Vibe Coding能不能用先把嵌入式开发的工作内容拆开看。我习惯把嵌入式工程分成四个层级每一层的代码特征、失败代价和测试难度差别巨大最底下是硬件层原理图、PCB Layout、芯片选型这一层跟软件代码没关系但决定了上层代码怎么写。什么引脚复用什么外设中断优先级怎么分配这些在画板子的时候就定死了。往上是驱动层寄存器操作、中断服务程序、DMA描述符管理、时钟树配置、Cache一致性处理。这一层的代码离硬件最近编译器行为、芯片勘误表、信号完整性问题都会在这里炸雷。代码量通常不大但每行都是用命写出来的。再往上是中间层实时操作系统RTOS的移植和配置、通信协议栈TCP/IP、CAN、Modbus、EtherCAT、文件系统、日志框架、电源管理策略。这一层对时序敏感任务优先级和资源竞争是主要矛盾。最上面是应用层业务逻辑、人机交互界面比如Qt、LVGL、数据采集与处理、状态机、参数管理。这一层跑在操作系统之上资源相对宽裕crash了也能重启测试手段也丰富。为什么要分这么细因为Vibe Coding在这四层里的可用程度是断崖式下降的应用层最好用驱动层基本不能用中间层要挑场景用。很多人问应用层开发是不是嵌入式我从工程组织的角度看应用层开发当然属于嵌入式开发流程的一部分但它更接近运行在嵌入式系统上的应用软件开发。如果你干的活主要是Qt界面、业务状态机、通信服务器对寄存器、时序、内存布局完全不敏感那你的开发体验跟做桌面应用非常接近Vibe Coding的适用性自然就高。这不丢人每个团队都需要人把上层逻辑理清楚。反过来如果干的是驱动层和硬实时中间层那Vibe Coding得小心再小心。原因不是AI写不出代码——它能写出看起来完全正确的驱动代码而是它写出来的代码无法通过它自己的逻辑推演来验证。Web端的代码错了页面报错信息怼在你脸上嵌入式驱动错了可能是上电三秒后系统跑飞也可能是在零下二十度、跑了两千小时才偶发一次故障。这种反馈延迟和故障隐蔽性让Vibe Coding最核心的边聊边调、跑一下看看循环完全失效。1.2 为什么Vibe Coding在嵌入式领域会过拟合到错的答案上我们得明白大模型写代码的本质它是在海量代码样本上学习到的条件概率分布预测给定这个需求描述和上文接下来最可能出现的token序列。问题在于嵌入式的训练样本占整个程序员社区产出的代码总量比例非常低。GitHub上公开的代码绝大多数是Web后端、数据处理、DevOps脚本和算法题解。真正躺在NXP官方SDK、ST的HAL库里、汽车电子BSP里的嵌入式代码大部分是私有仓库或者半公开状态。所以模型在生成嵌入式代码时它其实是在用Web开发的那种代码感来猜嵌入式怎么写。最典型的现象就是它默认你会用malloc随意分配内存、默认你有无限长的栈、默认你的中断服务函数可以调用任何库函数、默认整型是32位且小端——这些在x86 Linux上成立的假设在嵌入式环境里可能全错。我让AI写过一个STM32的ADC采样任务它给我生成了一段非常漂亮的DMA双缓冲代码逻辑完整注释齐全但我一眼就看到它没有处理DMA传输完成中断里的半传输标志位这是ST官方的经典坑——如果你不在半传输中断里切换buffer数据会在覆盖写的时候被CPU读到乱七八糟的值。模型不知道这个坑因为它的样本里关于这一点的高质量解释太少了。另外嵌入式项目还有一个隐藏约束芯片勘误表。很多芯片在特定条件下有官方承认的硬件bug需要软件规避。比如某款MCU的I2C外设在某些时钟配置下会产生假START信号官方勘误表里明确要求软件增加一个高电平脉宽检测。这种知识存在PDF里、存在老工程师的脑子里根本不在模型的训练语料里。Vibe Coding再厉害它也没法写出它没见过的东西。但反过来数据层和应用层的代码就不一样了。这类代码的规则高度公开、语义高度标准化Modbus协议帧格式是公开的Qt的信号槽机制是公开的JSON解析、SQLite操作、Modbus CRC校验算法、命令行参数解析……这些是海量训练样本模型见过无数遍写出来的质量甚至比平均水平的人类工程师还稳。Vibe Coding在嵌入式里的正确姿势不是让它写全部代码而是把工程里属于确定逻辑的那一大块外包给它剩下的硬骨头自己啃。2. 实操前先搞明白环境、工具链和开发平台的选择2.1 嵌入式Linux开发必须在Ubuntu下做吗很多刚入门的朋友都在问嵌入式Linux开发需要在Ubuntu下开发吗尤其是Windows用户看到热词里还有windows18-hd19嵌入式开发这种课程名更困惑了。直接说结论不一定必须用Ubuntu但Ubuntu或Debian系是最省心的选择没有之一。为什么这么绝对不是Linux系统高深而是嵌入式工具链的历史包袱决定的。交叉编译工具链比如arm-linux-gnueabihf-gcc、aarch64-linux-gnu-gcc在Windows下能用但你要处理各种路径分隔符、环境变量、DLL依赖Buildroot和Yocto这两个最主流的上层构建系统官方文档里的步骤全是基于Linux脚本写的虽然Yocto在Windows下能跑在WSL里但WSL环境有一堆坑:文件系统IO慢、串口和USB转接设备映射麻烦、Qt交叉编译时的图形依赖经常出奇怪问题。我自己试过在WSL 2里编译Yocto一个小时的构建任务比原生Ubuntu慢了接近一倍后来果断在双硬盘上装了双系统。要区分两个需求如果你的工作是纯应用层的写代码、调Qt界面、交叉编译一个可执行文件放到板子上跑Windows VS Code远程连到Ubuntu服务器或者开个WSL都能应付。但如果要碰内核模块、设备树、根文件系统裁剪直接上原生的Ubuntu环境实测下来最稳。Ubuntu LTS版本用22.04或者24.04都行注意老一点的工具链在24.04上有时有libc兼容问题不够省心就换22.04老牌稳定。工具方面我把常用的列个表方便新手直接照抄工具用途我的建议VSCode Remote SSH日常代码编辑、远程到Ubuntu编译服务器最主流插件Marketplace里搜remote-ssh即可QEMU用户态模拟x86主机上直接跑ARM可执行文件做冒烟测试装qemu-user-static验证基础逻辑够用交叉编译工具链编译目标平台二进制apt install gcc-arm-linux-gnueabihf即可Buildroot生成定制根文件系统、交叉工具链、bootloader、内核建议用国内镜像或本地缓存因为网络下载量大Device Tree Compiler编译设备树blobapt install device-tree-compiler关于Vibe Coding工具的安装和下载问题也顺带说一句现在主流的Vibe Coding工具不是一个单独的绿色软件大多是IDE插件加上云端模型服务的组合。VSCode上装好对应插件配置好模型API让它能读取你的工程文件这就完成了基础环境搭建。这里有一个嵌入式的独家建议不要只把代码文件喂给模型要把你的编译出错信息、串口日志、芯片数据手册的PDF片段一起丢进去。大模型对上下文非常敏感你给的约束越多它生成的东西越靠谱。而且现在的模型普遍支持markdown和代码块你把Buildroot的defconfig贴在对话里把报错贴在后面让它给出修复建议这个循环比我手动查文档快太多了。2.2 一个可复用的Vibe Coding 嵌入式工作基线我用了大概三个月的时间在真实开发流程里反复调整最终固定下来一套基线工作流分享给各位参考。这套流程的前提是你已经有一个跑通的编译环境和能启动的基础板级工程不是从零开始点灯。第一步把大工程拆成模块把模块的文件范围喂给AI。不要让AI看整个项目的全部代码它上下文窗口有限喂太多它抓不住重点。我一般会提供一个project_tree.txt用tree命令生成的目录结构然后在对话里指明本次只修改src/protocol/can_parser.c这一个文件其他文件不要动。第二步用文档化的方式描述需求。Vibe Coding的Vibe不代表你可以只说给我写个串口解析你要把完整约束写清楚。我习惯给AI一个模板输入是什么、输出是什么、依赖哪些头文件、目标平台的字节序和编译选项、错误怎么处理。例如我让AI写一个CAN报文解析器时给出的描述是STM32F407平台小端字段定义见文件can_proto.h解析结果存入结构体CanFrame返回值表示校验状态不允许使用memcpy直接转换结构体。这个描述包含了平台、字节序、接口、安全约束四类信息AI生成的代码就很少跑偏。第三步强制让它产出单元测试。这是很多嵌入式开发者用Vibe Coding容易忽略的一点。不要让它给你一个函数就完事让它同时写一个能在PC上跑的测试桩——输入一组十六进制字节验证解析字段是否正确。因为嵌入式代码最终要交叉编译上板子但逻辑测试可以在主机上先跑。这一步能把很多愚蠢的错误挡在编译之前。第四步代码审查不留死角。我不管AI生成的代码看起来多漂亮最终merge前必须逐行review。审查的重点是内存分配是否有界、循环是否有退出条件、中断上下文里有没有调用阻塞函数、有没有隐式的字节序假设。这个过程不可替代。这套基线流程跑下来我体感开发效率提升最大的是三件事Modbus和CAN协议解析、Qt界面状态机搭建、以及Buildroot的包配置调整。这三类工作的共同特点就是逻辑繁琐但有明确规范、重复性高、又有大量可参考样本。太适合Vibe Coding了。3. 具体实操让AI写LinuxQt5应用层的一个完整范例3.1 从需求到成品传感器数据采集界面我们团队的一个项目是在NXP i.MX6ULL板子上开发一个温湿度监控系统Qt5做界面数据来自一个Modbus传感器。换成Vibe Coding工作流以前我的做法是自己拉一个QMainWindow加两个QLabel再写一个QModbusClient的子类代码量不算大但琐碎信号槽连接、定时器刷新、异常分支处理写多了也烦。这次我故意让AI全程主导看看效果。我先准备了一个需求包里面包含三样东西项目目录树、Modbus传感器寄存器地址表、设计要求每500ms刷新一次数据异常显示红色日志写入本地文件。然后我把这几项内容作为prompt发给AI要求在本项目架构下新增数据采集与显示功能不改变原有工程结构。AI在几分钟内给出了一个可以编译的框架代码一个SensorWidget类负责界面显示一个ModbusWorker类用QModbusDataUnit读保持寄存器通过Qt信号把数据传回主线程更新界面日志用QFile追加写。整体结构干净线程边界清晰还自动处理了Modbus设备断线重连用了一个简单的重试计数器。这个输出质量比我预期的要好核心原因是传感器值读取和界面刷新是标准场景模型在训练时见过大量同类模式它甚至能正确选择Cadence和ReconnectDelay这类常见参数。我做了两处调整把重试计数器的上限从默认的15次改为可配置值把日志文件路径改为从配置文件读取——这是项目特有的需求它不可能知道。你看这就是我在前文说的让AI写模块不写架构。整体架构是我定义的模块边界是我划的AI在边界内自由发挥完成度很高。这个案例也说明了一个判断标准你需要判断你的需求是否足够标准。如果传感器数据采集定时刷新异常显示这三个词描述完十个工程师心里能浮现出差不多的代码结构那就是标准的放心交给AI。3.2 让AI处理交叉编译和系统集成脚本嵌入式开发里最花时间的不一定是写功能代码有时候是配置交叉编译环境、写systemd服务脚本、调整Buildroot的defconfig这些琐碎工作。这些活本身逻辑重、报错信息长、处处有平台差异特别适合Vibe Coding。我举个例子在某款ARM开发板上我们想让应用开机自启需要写一个systemd service文件还要保证应用在Modbus总线未就绪时等待重试。这个任务我直接描述给AI写一个systemd service服务名为modbus-gateway需要在网络和串口设备/dev/ttymxc0存在后才启动失败后每5秒重启一次最多重启6次。AI给了我一个久经沙场的老手才会写的方案用RequiresMountsFor/dev和udev的SYSTEMD_READY属性在[Unit]里用ConditionPathExists判断设备节点在[Service]里配置Restartalways和RestartSec5加上WatchdogSec看门狗。这比我手写一版考虑得还周全。交叉编译环境这种配置Vibe Coding同样能发挥价值。有一次同事在Ubuntu上构建一个老的Qt项目遇到无法找到libqt5serialport5-dev的交叉编译版本这种平台问题报错信息贴进对话里AI给出的方案是检查CONFIG serialport有没有被条件编译宏挡住同时确认交叉编译工具链搜索路径里有没有把sysroot的/usr/lib/arm-linux-gnueabihf加进去。这种知识极其零散搜索起来费时但模型的记忆中存了大量论坛帖子里的碎片它能快速拼出一个正确的排查方向。我在这个过程中明确感受到Vibe Coding在开发效率上的提升其实存在着一个悖论它让你在代码生成速度上收益巨大但让你的系统理解能力提升曲线变陡了。你不会亲手敲那些初级代码了但也不能要求自己不读懂就上板子调试否则会踩进坑里出不来。想用好它基本功反而更硬了。3.3 Buildroot场景一次让AI处理包配置的真实案例团队里做Linux系统集成的人应该都有体会Buildroot的配置文件——defconfig和Config.in——是典型看着简单改起来救命的东西。你要的包在menuconfig里翻半天找不到Dependency关系一锅粥编译报错信息经常是未找到头文件你根本不知道是哪个包缺了依赖。我试过一次让AI帮我梳理Buildroot的包关系需求是给rootfs里加一个Python3和一个pyserial库同时保证不会因为Python导致编译时间爆炸。AI给出的回答是推荐用BR2_PACKAGE_PYTHON3y打开Python解释器然后用BR2_PACKAGE_PYTHON_PYSERIALy选入pyserial同时提醒我Python的locale支持会拉进一堆ICU依赖建议用BR2_PACKAGE_PYTHON3_STANDARD_LIBRARYn裁剪标准库来减小体积。这个建议并不仅仅是从配置语法上给的它体现出对所依赖包的版本和编译链的理解。我验证了一遍完全正确这省去了我翻menuconfig和交叉编译错误日志的一个多小时。不过我也有翻车的时候。同样在Buildroot场景让AI调整内核配置去支持某个USB转串口芯片时它给我推荐了CONFIG_USB_SERIAL_CH341y但我实际芯片是CP2102正确的配置是CONFIG_USB_SERIAL_CP210Xy。这个错误原因很简单训练样本中CH341出现频率远高于CP2102模型按先验概率猜了一个最可能的答案。解决方式也不复杂在prompt里明确写出芯片型号和dmesg日志里的usb 1-1: cp210x converter now attached这类信息模型就能纠正。这提醒我关键性的硬件识别信息必须由你自己提供不能期待AI从需求里猜出来。4. 嵌入式Vibe Coding的翻车现场与排查思路4.1 编译过了真机一跑就崩这是我认为最危险的Vibe Coding翻车模式——因为AI生成的代码能一次通过编译太容易给开发者造成已经可以上板的错觉。整个过程是我按照需求描述让AI写了一个设备树解析模块功能大致是把/proc/device-tree下的一堆二进制属性解析成结构体。AI用的是我上面批评过的memcpy直接映射方式还加了个#pragma pack(push, 1)。在x86主机上用交叉编译测试一切都对扔到板子上运行结构体里的字符串字段偶尔会出现乱码。排查思路我记一下第一步看dmesg和串口日志锁定崩溃发生在解析特定节点时第二步用devmem2读取对应寄存器的原始值对比结构体里读出的值确认不是硬件问题第三步发现是结构体内存对齐问题——ARM默认对齐访问策略跟x86不一样用pack(1)解决了一类对齐问题却引入了非对齐访问的性能开销在某些配置下会导致总线错误。最终手工修正为逐字段拷贝加显式偏移量计算测试稳定了。从这件事里我给自己立了一条规矩凡是AI输出涉及通过结构体强转解析协议数据的代码一律重写。原因很简单C语言的结构体布局受编译器、对齐、目标平台字节序等多重影响在裸机/Linux用户空间/内核空间之间传递数据时结构体强转是无数不稳定bug的温床。协议解析只要遇到字节流老老实实用字节数组位移掩码或者用专门的序列化库别贪图代码短。4.2 时序和实时性AI理解不了的看不见的约束有一次做电机控制的项目让AI写一个Cortex-M4上的PWM占空比更新函数。AI给了我一个看起来无可挑剔的代码读影子寄存器、更新CCR值、触发重载。但测试时电机相电流有明显抖动排查了半天才发现AI把两个寄存器的更新顺序搞反了导致其中一个PWM通道比另一个晚一个周期更新。这种时序问题在逻辑上完全正确因为每个寄存器本身的值都对只是更新的先后顺序在硬件上引入了偏差。嵌入式里到处都是这种代码看起来静悄悄硬件行为很诚实的约束。AI无法从源代码里推断出外设寄存器X的操作必须发生在外设寄存器Y的操作之前且中间的延迟要小于200ns因为它从来不参与硬件行为验证它的世界里只有文本和逻辑。这类问题一旦发生你的调试手段会自动退化到示波器反复上电试验效率极低。我的处理原则变得很明确硬实时任务、中断相关的控制逻辑、外设初始化序列这三个类型的代码我从头到尾自己写AI只允许做代码审查。代码审查反而是AI有用的地方——你把自己的代码发给它让它从MISRA C规范角度挑毛病它能找出几个你漏掉的隐患比如未使用的变量、不合理的类型转换。这个模式比让它写驱动代码靠谱得多。4.3 数据完整性bug字节序、对齐与隐式假设我这里专门列一个字节序的例子。嵌入式系统里大小端问题几乎不可避免MCU可能是小端Cortex-M全系列默认小端传感器是通信协议定义的大小端外部设备可能是大端。AI生成代码时默认按主机字节序来写在交叉编译时x86主机的行为掩盖了目标平台的差异。我踩过的具体场景是一个AI生成的函数用于拼接两个16位寄存器值组成32位float——涉及的平台是小端的寄存器值本身也是小端存储AI的代码逻辑天衣无缝。但我另一个同事的平台是大端的POWERPC同样需求AI生成的代码直接拼出一个大小端完全颠倒的值仪表的数值变成了天文数字。这倒不全是AI的错——prompt里没有说明平台字节序AI用了默认的小端世界假设。所以规范化的prompt里一定要包含目标平台的字节序、编译器版本、C标准。我甚至会在需求包的最开头写一行所有代码必须符合目标平台字节序禁止使用无符号整型之间的强制转换来构造浮点数。4.4 汽车电子场景MISRA和AUTOSAR下的严格禁区做汽车电子嵌入式开发的朋友可能会更谨慎。在汽车领域代码要过MISRA C规范检查要满足AUTOSAR的分层架构功能安全上还要过ISO 26262的认证。Vibe Coding在汽车电子里基本是禁区原因不是AI模型能力不够而是合规验证的价值链被打断了。你的代码最终要能追溯每一个需求的来源要能向审核方证明每一行代码都经过了特定方法论的验证。AI生成代码天然缺少这种可追溯性除非你把AI生成的代码Andrius经过与人工编写代码相同的验证流程写进你们的流程文档里——但那样的话效率优势就大打折扣了。我自己帮朋友看过一些打着汽车电子旗号的AI生成项目很多所谓AUTOSAR代码生成工具生成的代码质量堪忧要么不符合RTE映射关系要么在复杂驱动里瞎用全局变量。这类代码拿到台架上一跑十个里有八个出问题。所以我的建议简单粗暴如果你在安全关键场景汽车、医疗、工业安全且代码需要过认证Vibe Coding现阶段只能用来做辅助分析工具——分析和阅读现有代码、生成测试数据、检查代码风格——不能直接生成交付代码。这个边界我建议团队在引入工具时就用规章制度明确下来别靠个人自觉。4.5 常见问题排查速查表最后给一张速查表方便出问题时快速对照。这些坑都是我实际踩过或帮人排查过的内容偏实操。现象可能原因排查顺序编译通过上板即崩溃结构体对齐/字节序/AI默认x86语义1. 抓串口日志 2. 检查协议解析是否用了memcpy强转 3. 对比寄存器原始值系统运行一段时间后偶发死机内存越界或资源泄漏1. 开启AddressSanitizer/Valgrind主机测试 2. 看板子上free内存曲线 3. 检查堆栈大小电机/PWM控制逻辑抖动外设寄存器更新顺序错1. 示波器看波形周期 2. 对比数据手册时序要求 3. 手工重写控制逻辑CAN报文解析数据错乱字节序/位域布局不匹配1. 查协议定义 2. 打印原始字节对比解析值 3. 禁止位域结构体转换Buildroot包依赖编译失败包依赖关系缺项或版本冲突1. 查看具体报错位置 2. 用make XXX-源查看依赖 3. 贴报错让AI提供排查方向AI生成代码违反MISRA规则训练样本未覆盖严格规范1. 接入静态分析工具如PC-lint 2. 修复全部告警级输出 3. 高风险场景禁用AI生成这张表做成团队内部wiki之后我让组里新人遇到问题时先查一遍很多低级坑都不用来来回回折腾了。5. 我对Vibe Coding 嵌入式开发的阶段总结5.1 三个阶段能力评估工具、流程与人先说工具本身。Vibe Coding如今的能力跟两年前的AI编程辅助相比已经完全是两个物种。不是它多聪明而是它整合了序列理解和上下文管理能力可以在一个很长的对话里持续理解你的工程约束。它的体验有点像你身边坐了一个行动力强但判断力平庸的实习生你说得越细它干得越靠谱你说你自己看着办它真敢在关键位置上给你来一段错得离谱的东西。流程层面我认为Vibe Coding在嵌入式团队里能不能落地取决于你能否把AI生成-人工审查-硬件验证这个闭环固化下来。闭环运转得好它能让你把省下来的精力花在真正需要人的地方——架构设计、疑难bug定位、产品级可靠性测试。闭环运转得不好它最终会变成一堆漂亮但危险的代码堆在仓库里等着某天爆发。5.2 我现在实际怎么用Vibe Coding收个尾说说这套玩法用下来我的最终改变。以前一个Qt界面功能模块从设计到编码大概要两小时现在是我搭好框架、写清楚接口注释、让AI生成具体实现我review后连编译带跑测试大概半小时。Modbus协议层和CAN解析器这类规范明确、无歧义、有大量参考实现的代码我的产出效率提升非常明显。我再也不用逐行敲样板代码也不需要在官网文档和论坛帖子之间来回翻找细节。但反过来那些直接影响安全、时序、硬件行为的核心逻辑我一个字也不让AI碰。比如设备树中断绑定、DMA描述符的分配与释放顺序、硬实时任务的优先级配置。这些代码我现在仍然是在编辑器里跪着手写写完之后逐行看汇编确认编译器没给我埋坑。这个习惯保持了十年在Vibe Coding时代依然有效而且我觉得更必要了——你没看懂的东西越堆越多到后面就成了定时炸弹。最后再分享一个我调整过很久的工作习惯AI生成的每一个文件我都会在文件头上加注释写明由AI在x年x月x日生成用途xxx人工审查人xxx测试结果xxx。这个习惯在出问题时能救命——因为当功能出bug时排查速度取决于你能多快判断这个文件是哪一版逻辑、谁改过、怎么测的。有追溯才有安全感。对整个行业来说Vibe Coding会不会彻底改变嵌入式开发的方式我觉得会但它的影响是渐进的它会先吞掉应用层开发、协议栈开发和系统集成的低价值重复劳动然后无限逼近但无法完全吞掉驱动层和硬实时层。直到有一天硬件调试手段本身被AI化——总线分析仪能自动出结论、示波器能自己解释波形——嵌入式开发的边界才会真正松动。在那之前我们这代人还得保持一项传统手艺看懂代码、看懂硬件、看懂它们之间的江湖。
