最近这半年，身边做 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 应用开发”和“Linux+Qt5 嵌入式开发课程”里教的东西，大多数落在第四层，做的就是窗口、信号槽、业务模型、进程通信这一套。说实话，这一层和桌面开发、后端开发在代码风格上差异不算大，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 先写，再调试硬件相关部分 |
| 内存优化 | 低 | 需要 profiling，AI 没有运行反馈，容易给出误导性建议 |
| 中断/实时任务 | 低 | 时序约束和优先级关系，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 写得好不好”。
这个判断力来自几个方面：对硬件行为的理解，对数据手册的阅读能力，对系统级约束（电源、时序、内存、功耗）的整体感知，以及完善的测试意识。大学课程里 Linux+Qt5 之类的内容可以帮你快速进入应用层，但真正让你区别于“只会让 AI 生成业务代码”的开发者，是你对底层机制的把控。
我现在带项目，会刻意让新人先手写一个 GPIO 驱动，再进到协议栈，最后才允许他们用 AI。目的不是考验，而是让他们建立“硬件手感”。AI 可以帮助一个已经有手感的人如虎添翼，却很难替一个完全没有手感的人兜底。
我自己现在的日常已经离不开 AI 辅助了：一个驱动模块，先让 AI 搭骨架，我再花时间在数据手册上补细节；一个应用功能，先让 AI 写初版，我再集中精力处理内存和安全边界。代码生成的时间被大幅压缩，省下来的时间，我几乎全部用在测试和评审上。
说白了，Vibe Coding 把“写代码”这件事变便宜了，但“做嵌入式开发”从来不只是写代码。它是对物理世界的把握，是对系统运行的负责任。这句话听起来有点大，落到日常就是：AI 可以帮你写很多行代码，但它不会替你的板子跑高温测试，不会替你看波形，更不会替你在客户现场排查那个偶发的死机问题。
所以我的体会是：不必焦虑 AI 会不会让嵌入式岗消失，但要警惕自己在“只享受生成快感”的过程中丢掉了判断力。保持对硬件的好奇，保持对数据手册的死磕，把 AI 当成一个特别勤快、但偶尔说胡话的实习生来带。如果你能带好这个实习生，你会发现自己的工作重心正在从“敲代码”转向“做决策”，这其实是一件值得期待的事。
