最近这半年身边做 Web 的朋友经常在群里晒 AI 编程的战绩丢一句需求描述过去代码自动生成编译、测试、重构都在一个会话里完成。那是他们的 Vibe Coding 时代。回到嵌入式这边气氛完全不一样——底层要跟寄存器、中断、时序打交道上层要跟交叉编译链、Bootloader、开发板纠缠。很多同行在问同一个问题AI 写代码这事到底跟嵌入式有没有关系我的结论是有关系而且关系比大家想象中复杂。我花了大半年时间在裸机、RTOS、嵌入式 Linux 应用层都试了一遍 AI 辅助开发踩了不少坑也沉淀出一些能真正落地的方法。这篇文章想把 Vibe Coding 在嵌入式领域的真实面貌拆开讲讲哪些地方能直接受益哪些地方千万别让 AI 碰以及在这个环境下嵌入式工程师原有的“手艺”里什么东西反而变得更值钱了。1. Vibe Coding 的本质以及它为什么在嵌入式面前会有“水土不服”1.1 Vibe Coding 不等于“让 AI 把整个项目写了”先把概念对齐。Vibe Coding 不是一个严谨的学术名词它更接近一种开发状态开发者用自然语言描述意图 AI 补全代码然后开发者review、提出修改、继续生成。整个过程里人负责“拿捏方向”机器负责“敲键盘”。Karpathy 在推广这个词的时候特别强调了一个体验开发者对代码本身保持一定的“模糊感”不追求每一行都看懂重点是快速把想法变成一个能跑起来的东西。这在 Web、脚本、数据分析这些场景里确实有效因为反馈链路短代码错了马上就能看到效果。但嵌入式开发不是这样。你写的代码不是跑在你的电脑上而是跑在一块目标板上它要看的是具体硬件的行为。AI 生成的驱动看起来逻辑通顺不代表目标板上的传感器就真的能出数据AI 帮你写的线程调度不一定能满足你这个电机控制任务的硬实时要求。所以嵌入式里谈 Vibe Coding必须先丢掉“让 AI 全权代工”的幻想。1.2 反馈速度决定一切为什么 Web 能 Vibe嵌入式不能完全 Vibe我观察下来Vibe Coding 好不好用核心取决于“从改代码到看到结果”的速度。在 Web 开发里这个链路是保存代码 → 热更新 → 浏览器刷新 → 看到页面变化几秒钟就能完成一轮“生成-验证”。即便 AI 写错了你也能快速定位问题再丢一句修改提示给它。这种高频反馈让 AI 非常容易自我修正。在嵌入式里常见链路是写好代码 → 交叉编译 → 烧录/下载 → 复位运行 → 打开串口看日志 → 回来改代码一个循环动辄几分钟如果涉及到硬件调试器还要插线、抓波形、看寄存器。更关键的是很多嵌入式问题不只在软件层面暴露它还和硬件行为耦合在一起——同样一段 I2C 驱动代码你换一个上拉电阻配置表现可能就差很大。AI 不知道你的电阻值不知道你的晶振精度不知道你的中断优先级分配它只能按“通常经验”来写。这就是嵌入式对 Vibe Coding 的“第一道过滤网”上下文信息严重缺失。AI 在 Web 场景可以通过读整个项目代码来理解上下文但嵌入式场景里除了代码之外还有芯片手册、原理图、外设时序、勘误表这些“非代码上下文”模型接触不到。所以我一直建议团队里的新人可以用 AI 帮忙但心里要清楚你才是那个替 AI 补全硬件上下文的人。2. 嵌入式开发的分层决定了 Vibe Coding 的吸收程度2.1 应用层开发是不是嵌入式先把软件栈说清楚讨论兴趣圈里经常有人问“应用层开发是不是嵌入式”。这其实是个很实在的问题因为它直接影响了你用 AI 的方式。我习惯把嵌入式软件按贴近硬件的程度分成四层层级典型任务和硬件耦合程度Vibe Coding 适用度Boootloader/启动代码链接脚本、启动汇编、时钟初始化极高寄存器手册决定一切低BSP/驱动层UART/I2C/SPI/GPIO 驱动、中断处理高涉及时序、电气特性低到中中间件/协议栈Modbus、MQTT、文件系统、状态机中逻辑为主但要注意资源限制中到高应用层Qt 界面、业务逻辑、网络通信、系统集成低接近通用软件开发高“嵌入式 Linux 应用开发”和“LinuxQt5 嵌入式开发课程”里教的东西大多数落在第四层做的就是窗口、信号槽、业务模型、进程通信这一套。说实话这一层和桌面开发、后端开发在代码风格上差异不算大AI 在这里的表现相当不错。我之前带过一个项目用 Qt5 在 ARM 板上做工业 HMI。界面逻辑、配置读写模块、串口数据展示这种代码我直接把需求丢给 AI 生成再人工 review 哪块内存分配不适合嵌入式小内存环境整体效率非常可观。2.2 越靠近硬件Vibe Coding 越需要“人肉护栏”刚才那层表格里低层的 Vibe Coding 适用度低。不是 AI 能力不行而是纠错成本太高。举个例子AI 生成的时钟初始化代码会根据芯片手册算出分频系数听着很靠谱。但实际芯片往往有硅前勘误某些分频组合在特定电压下会不稳定这些信息藏在几十页的勘误表里AI 不可能知道。同样链接脚本里 Flash 的地址范围写错一位编译可能照样通过运行起来却会花式死机这种问题靠 Vibe 是 Vibe 不出来的。所以我的习惯是底层代码当作“初稿生成器”来用让它给一个结构完整的骨架但每一个寄存器值、每一段时序等待都要回到数据手册里对照一遍。这听起来累但比从头写要快很多因为框架和注释价值是实打实的。2.3 汽车电子嵌入式开发严格程度又高一档如果做的是汽车电子嵌入式开发这个分层还要再加一道约束。车规项目里软件要过功能安全标准代码要可追溯、可验证。你用 AI 生成一个模块逻辑上没问题但你怎么证明这个生成过程是可控的怎么证明代码里没有隐藏的高危逻辑路径如果出了问题责任归属怎么界定这些不是技术问题是工程治理问题。目前行业里的普遍做法是AI 生成的代码必须经过和普通代码完全相同的评审、静态分析、单元测试、集成测试流程甚至要求更严格因为 AI 的“隐藏先验”可能引入团队成员都不熟悉的行为。我在和做 BMS、域控制器的朋友交流时大家态度一致AI 可以帮忙做测试脚本、做文档、做注释但核心控制算法该手写还是手写至少现在是这个局面。3. 哪些嵌入式任务适合让 AI 来“铺路”3.1 我不建议在中断和实时路径里用 AI但其他环节可以放心铺路在一次内部分享里我列过一张“嵌入式 AI 辅助任务适合度”的表基本成了团队里的实用工具任务类型适合度说明通信协议解析串口帧、Modbus、CAN 报文解析高输入输出边界清晰适合 AI 生成初稿状态机代码骨架高状态迁移逻辑容易描述AI 生成后人工补事件处理驱动模板生成中AI 给出结构和基本读写函数寄存器配置还是得自己查手册单元测试/模拟器高输入输出明确很适合让 AI 先写再调试硬件相关部分内存优化低需要 profilingAI 没有运行反馈容易给出误导性建议中断/实时任务低时序约束和优先级关系AI 很难在对话里搞清楚代码注释/文档高AI 写注释和文档很稳定但注意不要让它编造行为这套总结来自我自己的试错。刚开始我也试着让 AI 帮我优化一个中断处理函数结果它反复建议我把重活全部挪到中断里“提高响应”这在裸机场景下简直是灾难。后来学乖了凡是中断上下文里的代码全部自己写写完让 AI 做一次代码审查找找疏漏但绝不采纳它的“优化方案”上脑式改动。3.2 协议解析AI 的好球区要说 AI 在嵌入式里最擅长的我个人投票给协议解析。这类任务输入输出边界清楚逻辑固定错误模式也容易预料非常配合语言模型的文本归纳能力。比如我做过一个 GPS 模块接入项目需要解析 NMEA 0183 协议的 GPRMC 帧提取经纬度、速度、UTC 时间并且做校验和验证。我把需求丢给 AI它很快生成了一版基础代码uint8_t nmea_checksum(const char *frame) { uint8_t sum 0; if (*frame ! $) return 0; for (const char *p frame 1; *p ! \0 *p ! *; p) { sum ^ (uint8_t)*p; } return sum; }这段代码本身没问题。但注意它带了一个隐性假设帧已经完整存放在一个以 \0 结尾的缓冲区里。在 PC 上这是常识在嵌入式里串口是一字节一字节中断进来的缓冲区管理才是大头。AI 的初稿只处理了“解析”这半边另外半边“数据如何安全地到达解析器”还是得我自己来设计。所以我的用法是让 AI 把解析函数写好我自己用环形缓冲区接收串口数据再把整帧交给解析函数。这个分工效率和正确率都高。3.3 嵌入式 Linux 应用层AI 带来的效率提升更明显应用层的情况就乐观多了。我在做一个嵌入式 Linux 网关项目时需要写不少 JSON 配置管理、MQTT 上报线程、Modbus 转 MQTT 的映射逻辑。这些代码几乎不碰寄存器也很少关心具体硬件AI 在理解需求之后给出的初稿经常可以直接编译运行。像 Qt5 界面开发AI 对信号槽机制、布局管理这类相对固定的模式非常熟。让 AI 生成一个带滚动日志区、状态栏、多页面切换的主窗口骨架它两三分钟就能给出一个结构完整的版本比手写快得多。但即便在这一层嵌入式应用和纯 Web 应用还是有区别。我们的目标板内存小文件系统可能是只读的崩溃会产生严重后果。AI 不会自动考虑这些约束所以 review 的重点不在“逻辑对不对”而在“这个方案适不适合我的板子”。4. 实操记录从 GPS 帧解析到 EEPROM 驱动AI 帮我踩平了大半坑4.1 GPS 帧解析一轮生成两轮修正来一段真实的操作记录。我最初的提示词是这样的写一个 C 函数解析 NMEA GPRMC 语句提取时间、是否有效、纬度、南北、经度、东西、地面速度、日期。要求带校验和验证返回解析结果结构体。运行环境是 STM32 裸机注意不要用动态内存分配。AI 很快给了一版完整代码定义了GprmcFrame结构体、parse_gprmc()函数、校验和验证函数。第一版我就发现了两个问题一个是它用了strtok()这个函数会修改原字符串内部状态在多线程或中途打断的场景下不可靠另一个是它把整帧当作参数传入但我的系统里帧还没有被拼装完整。我做了两轮修正指令1. 不要用 strtok改用按逗号逐字段扫描的方式保持函数可重入。 2. 在函数内部只解析帧完整性由调用方保证。修完之后代码可读性和健壮性都好很多。中间我还让 AI 加了一个 UTC 时间转北京时间的小函数这种逻辑简单又容易出边界问题的地方AI 一次性写对我只需要补个测试用例验证跨天和闰年。这个流程走下来我的体感是一个原本要花 40 分钟的解析模块十分钟左右能搞到可以集成测试的状态。但前提是我清楚知道自己在干什么哪些坑不能踩哪些假设要打破。4.2 AT24C32 EEPROM 驱动 AI 给的是骨架手册才是裁判再举一个更“硬”的例子I2C 接口的 AT24C32 EEPROM 读写驱动。我的提示词想写一个 I2C EEPROM AT24C32 的驱动实现单字节读写、页写、多字节读。需要处理页边界问题读写在带超时阻塞的 I2C 总线上执行调用方传入 HAL 层函数指针。C 语言裸机。AI 生成的代码结构很完整函数封装、错误码定义、HAL 结构体设计都像模像样。如果只看逻辑可以直接编译。但做嵌入式的人都知道EEPROM 驱动真正的魔鬼在细节里。第一写周期。AT24C32 每次写入完成后芯片内部擦写需要最多 5 毫秒这段时间内芯片不响应任何指令。AI 的代码里用了一个HAL_Delay(5)来处理这在阻塞式驱动里勉强能跑但更好的做法是通过 ACK 轮询检测写完成不必死等固定的时间。我改成写完后连续尝试读取应答位直到芯片重新应答。第二页边界。AT24C32 的页写一次最多 32 字节如果跨页界限需要拆分写入。AI 生成的代码虽然提了“处理页边界”但实现里只判断了剩余空间没有处理地址回绕和首地址偏移。我手动补了一个地址对齐逻辑这属于数据手册里明说但 AI 容易忽略的地方。第三超时策略。I2C 总线卡死是很常见的硬件问题驱动必须有超时机制不能无限等下去。AI 的初稿直接调用了阻塞 API没有全局超时概念我用一个 tick 计数器包裹了整段访问逻辑超时后返回ERR_I2C_TIMEOUT。这个案例代表了我所说的“人肉护栏”AI 帮你把结构、命名、接口节奏这些“软件味”的部分做好硬件行为和数据手册相关的内容还是得靠人补。4.3 数据手册才是最终的“代码评审官”我发现一个特别有意思的现象AI 生成的代码从“语法正确”到“硬件正确”之间差着至少一次数据手册 review。比如你让 AI 生成某个定时器的 PWM 输出初始化代码它会给出常见的寄存器配置流程但具体到你的芯片型号是哪个定时器、哪条通道、复用引脚映射在哪个 AF 编号它只能靠猜。这类信息藏在 pins 表格和 alternate function mapping 里不是模型训练数据能稳定覆盖的部分。所以现在我的团队定了一个规矩AI 生成的任何驱动代码必须附带数据手册中对应的寄存器说明或引脚定义否则不进入代码评审流程。这既防了 AI 的幻觉也逼着开发者把硬件上下文搞清楚。5. Vibe Coding 进嵌入式的底线什么不能含糊5.1 中断和实时路径拒绝“生成即信任”嵌入式和 Web 最大的区别之一是我们被中断和实时约束包围。一个中断处理函数跑太久直接破坏系统的实时性一个共享资源没有加保护偶发死锁能让人排查三天。AI 在生成中断服务函数时很难意识到这些约束。它倾向于把逻辑写得很“自然”比如在 ISR 里调用阻塞函数、使用不可重入的库函数、在函数内修改全局状态而不加临界区保护。这些模式在普通代码里只是风格问题在中断里就是炸弹。我的原则是中断处理程序和硬实时逻辑必须由人来写AI 只能事后来做 review。即便是 review也只看一些静态层面的问题比如是否有未声明的外部变量访问、是否有明显的类型转换错误。至于时序行为必须靠硬件实测验证AI 帮不上忙。5.2 汽车电子等安全场景合规流程比代码生成更重要前面提到汽车电子嵌入式开发这个领域还有一个特殊问题流程合规。在带有功能安全要求的项目里代码只是交付物的一部分代码背后还要有需求追溯、设计文档、测试报告、变更记录。AI 生成的代码不管多完美前面没有需求编号后面没有测试签名在评审会上就是不合法。我见过一个域控制器项目团队尝试用 AI 生成诊断协议栈的协议解析部分整个逻辑很快代码质量也不错但一提到追溯性就卡住了。测试经理问这代码对应哪条需求怎么证明生成过程没有引入未评审的变体最后他们只留下了 AI 生成的测试向量产品代码还是走了传统流程。这里想表达的是Vibe Coding 在嵌入式不是技术能力问题而是工程治理问题。技术上说多数代码 AI 都能搭把手但治理上很多安全场景还没准备好接受“生成式”代码。5.3 给 AI 划一条“可控边界”而不是让它自由发挥到底怎么在嵌入式里合理地用 Vibe Coding我实践下来最有效的方法是给 AI 划一个极小的、边界清晰的任务让它在这个盒子里自由发挥。比如与其让 AI “写一个 BLE 驱动”不如说“写一个函数从 BLE 接收缓冲区里解析出温度值温度值是大端两个字节带符号返回浮点数。输入是指针和长度。”这样 AI 表现会非常好因为任务边界清晰、逻辑简单、几乎没有硬件依赖。反过来当你觉得任务描述很长、需要解释很多背景的时候说明这个任务超出了 AI 的“盒子”。这时候应该先自己拆任务拆到 AI 能安稳接住的粒度再逐块交给它。我把它叫作“碎粒化提示”大型任务先生成骨架小型任务再做填充。6. 给嵌入式工程师的落地建议从工具链到心态6.1 到底要不要在 Ubuntu 下做嵌入式 Linux 开发有一个搜索热词是“嵌入式 Linux 开发需要在 Ubuntu 下开发吗”。我直接给结论如果你打算认真做嵌入式 Linux 应用开发长期在 Ubuntu 下工作是省心的选择。原因有三个。第一工具链集成度高。交叉编译工具链、GCC 系工具、make/CMake、文件系统制作工具、设备树编译工具在 Ubuntu 下可以一条链子打通很多官方 SDK 默认支持的就是 Linux 环境。某芯片厂给的 BSP 压缩包解压之后你发现里面的构建脚本全是在 bash 下写的。第二文本和命令行操作方便。嵌入式开发里大量操作发生在终端串口连接minicom/picocom、网络传输tftp/scp、远程调试、日志分析在 Linux 下这些都是原生体验。Windows 下虽然也有替代但始终隔了一层。第三容器和虚拟化友好。你用 Windows 做宿主机可以开一个 WSL2 或者虚拟机跑 Ubuntu开发环境放在里面。如果你用 Ubuntu 当宿主机跑 Windows 虚拟机来做其他事情也一样顺手。我自己现在平时用的是 Ubuntu VS Code 串口调试偶尔用到 Windows 下的专用烧录工具就在虚拟机上开一下。刚开始会有点折腾渡过入门期之后效率比在两个系统之间来回切换要高很多。6.2 AI 编程工具的选择与安装思路现在嵌入式的 AI 辅助工具其实和 Web 侧用的底层模型差不多。常见的有 Claude Code、Codex、Cursor以及一些国内可访问的编程助手。它们都支持 C/C能处理你项目里的代码文件重要的是它们能和你本地工具链配合。安装的方式基本都是去工具官网下载对应版本或者安装 IDE 插件拿到 API 调用的授权之后在终端或 IDE 侧栏里直接对话。免费额度用完之后通常按量付费。我不建议盲目跟风最新工具而要先确认它能不能读取你板级 SDK 的包括路径、能不能调用你本地的编译器和调试器。我踩过的坑是在 Windows 上装某个 AI 插件它对文件路径和解析器兼容性不好整个项目索引乱七八糟AI 的代码补全质量直线下降。后来切到 Ubuntu 环境一切顺了。所以如果你在 Windows 上感觉 AI 工具有点“笨”先想想是不是环境兼容问题别急着换工具。6.3 重新审视自己的技能矩阵最后聊聊心态。Vibe Coding 时代嵌入式工程师最值钱的技能是什么我觉得不是“敢让 AI 放开写”而是“能判断 AI 写得好不好”。这个判断力来自几个方面对硬件行为的理解对数据手册的阅读能力对系统级约束电源、时序、内存、功耗的整体感知以及完善的测试意识。大学课程里 LinuxQt5 之类的内容可以帮你快速进入应用层但真正让你区别于“只会让 AI 生成业务代码”的开发者是你对底层机制的把控。我现在带项目会刻意让新人先手写一个 GPIO 驱动再进到协议栈最后才允许他们用 AI。目的不是考验而是让他们建立“硬件手感”。AI 可以帮助一个已经有手感的人如虎添翼却很难替一个完全没有手感的人兜底。我自己现在的日常已经离不开 AI 辅助了一个驱动模块先让 AI 搭骨架我再花时间在数据手册上补细节一个应用功能先让 AI 写初版我再集中精力处理内存和安全边界。代码生成的时间被大幅压缩省下来的时间我几乎全部用在测试和评审上。说白了Vibe Coding 把“写代码”这件事变便宜了但“做嵌入式开发”从来不只是写代码。它是对物理世界的把握是对系统运行的负责任。这句话听起来有点大落到日常就是AI 可以帮你写很多行代码但它不会替你的板子跑高温测试不会替你看波形更不会替你在客户现场排查那个偶发的死机问题。所以我的体会是不必焦虑 AI 会不会让嵌入式岗消失但要警惕自己在“只享受生成快感”的过程中丢掉了判断力。保持对硬件的好奇保持对数据手册的死磕把 AI 当成一个特别勤快、但偶尔说胡话的实习生来带。如果你能带好这个实习生你会发现自己的工作重心正在从“敲代码”转向“做决策”这其实是一件值得期待的事。