“Vibe”这个词第一次出现在嵌入式工程师的聊天群里时，我正对着一个串口解析器的崩溃现场挠头。AI 花十分钟生成了一大段漂亮的 UART 协议解析代码，单元测试也过了，可一上板子，系统就在中断里随机卡死。后来定位原因：AI 在中断处理函数里顺手插了一个调试打印，而这个打印函数是阻塞式的。Web 端这也许只是“日志乱了”，在嵌入式环境里却直接是“设备挂了”。
我最初的态度和很多人一样：Vibe Coding 是 Web 开发者的玩具，和寄存器、中断、时序打交道的嵌入式开发，注定是它碰不了的硬骨头。但一年多观察下来，我的看法变了很多。真实情况是：Vibe Coding 带来的不是“代码质量”的重排，而是“工程师成本结构”的重排。你不再需要为每一行手写代码付出键盘成本，但你必须为每一次判断付出更高溢价——而判断力，恰恰是嵌入式工程师最值钱的东西。
这篇文章不是来吹“AI 取代嵌入式工程师”的，也不打算贩卖焦虑。它是我把 C、驱动、RTOS、裸机工程这些老本行放进“Vibe Coding 流水线”之后，整理出来的一张实用地图：哪些环节可以让 AI 尽情发挥，哪些环节必须攥紧方向盘，具体工作流怎么搭，以及我踩过的几个刻骨铭心的坑。
1. “Vibe Coding”与嵌入式：从代码生成到硬件反馈
1.1 先拆解一下“Vibe Coding”到底爽在哪里
所谓 Vibe Coding，简单说就是你不必逐行敲代码，而是用自然语言描述目标、风格、约束，让 AI 助手（Copilot、Codex、Cursor、Claude Code 这类工具）直接生成成片代码，然后你运行、观察、再提要求，循环往复。整个过程中人类的姿态更像“监工”而不是“打字员”，你靠“感觉”和“大致方向”来引导迭代，而不是靠语法细节。
这套玩法在 Web 后端和前端开发里能跑得飞起，有三个很现实的原因：
- 反馈极快：改完代码，保存，热更新，浏览器里立刻看到效果。一次迭代可能只需要十几秒。
- 失败成本极低：代码崩了，最多是本地进程重启，大不了 CI 挂掉，没人因此受工伤。
- 上下文高度数字化：接口文档、UI 设计稿、DTO 定义，全都能贴给 AI 当上下文，它“理解”起来不太费劲。
在这三个条件都满足的场景里，AI 生成的代码即使有 bug，也会在极短的反馈循环里被揪出来。所谓“Vibe”，本质上是“快速试错”的底气。
1.2 嵌入式开发的“硬件现实”改写了什么
再看嵌入式开发，事情就没这么温柔了。
我调过 STM32，也写过不少 Linux 驱动和 RTOS 上的应用层。嵌入式代码的运行环境是一个资源受限、时序敏感、和外部物理世界直接交互的硬件。你写的每一行代码，最终都要面对这些约束：
- RAM 可能只有几十 KB，Flash 容量以 KB 计，你敢让 AI 随意引入动态内存分配和大型日志缓冲？
- 中断服务程序里不能调用阻塞函数，不能执行复杂浮点运算，不能在临界区里睡大觉，这些潜规则不会出现在任何提示词里。
- 交叉编译让“本地跑一下”变得麻烦，你往往需要开发板、调试器、示波器，甚至还要搭一套信号发生器来模拟外部传感器输入。
- 设备一旦发出去了，没有“热更新”兜底。哪怕是一个字段解析错误，也可能让整批产品现场卡死。
所以，Web 开发者的“Vibe”靠的是快速反馈的试错，嵌入式工程师的“谨慎”靠的是硬件失败的高昂代价。表面上看，这两者确实八字不合。
1.3 真正冲突的不是代码风格，是反馈回路的密度
但深入想一步会发现：Vibe Coding 并不是必须有浏览器才能成立，它需要的是“足够短的反馈回路”和“足够低的试错成本”。嵌入式开发之所以显得与 AI 格格不入，是因为我们把“上板调试”当成了唯一的反馈手段，而这是所有反馈回路里最慢、最贵、最痛苦的一种。
如果能把反馈回路往前移动，问题就完全变了。
举个例子：你让 AI 生成一个串口指令解析器。如果直接把生成结果烧到板子上试，大概率要反复编译、烧录、看串口日志，半小时起步。但如果你先在 PC 上搭一个模拟串口的测试环境，让 AI 生成的代码跑在 PC 上，用一段伪造的串口数据流做输入，断言它解析出正确的字段，那么一次迭代只需要十几秒——和 Web 开发的反馈速度几乎一样快。
这才是嵌入式拥抱 Vibe Coding 的正确姿势：不是让 AI 直接面对硬件，而是先把硬件的不确定性剥离掉，制造一个能快速验证的“软环境”。真正的核心矛盾，不是“AI 行不行”，而是“你有没有给它修一条足够短的反馈回路”。
2. 哪些嵌入式代码可以“放开手”，哪些必须攥紧缰绳
2.1 框架代码、BSP 和初始化序列：让 AI 大胆干
嵌入式项目不是一个铁板一块的整体。它像一个夹心蛋糕：最底层是芯片寄存器、外设驱动、BSP；中间是操作系统或 RTOS 的任务、通信协议、状态机；最上层才是业务逻辑和用户交互。不同层次的容错空间和对 AI 的容忍度，天差地别。
最先可以放心交给 AI 的，是模板化、机械化的那一批：
- 芯片初始化序列：打开时钟、配置 GPIO、设置串口波特率、初始化 SPI/I2C。
- BSP 板级支持包：把芯片外设封装成统一接口，比如
bsp_uart_init()、bsp_gpio_set()。 - 工程脚手架：Makefile、CMakeLists、链接脚本、IDE 工程文件。
- 工具脚本：固件打包脚本、烧录脚本、日志解析脚本。
这类代码的特点是“重复性高、逻辑简单、对错一眼就能看出来”。即使 AI 生成的初始化参数不对，编译大概率报错，或者硬件上电后用示波器量一量就能发现。失败成本低，反馈也直接，完全可以让 AI 当主力，你负责检查参数和手册就行。
2.2 状态机和协议解析：可以轻松，但必须有“护栏”
再往上走一层，状态机和通信协议解析器就属于“灰色地带”了。AI 在生成这类逻辑时往往表现不错，因为它本质是“有限状态转换 + 数据字段映射”，AI 擅长从大量训练数据里模仿此类模式。但这里有两个隐患：
- 协议解析经常会处理“半包”“粘包”“超时”等边界情况，AI 容易只写“理想路径”，漏掉异常分支。
- 解析器如果跑在中断或 RTOS 任务里，任何阻塞操作都会造成灾难，AI 不会主动意识到上下文环境。
我的做法是：让 AI 生成主状态机和解析逻辑，但强制要求它同时生成一套 PC 端单元测试，把所有边界情况列成测试用例。这等于给 AI 的“自由发挥”装上了围栏——它可以在里面随便跑，但撞到围栏立刻会报警。
2.3 中断、DMA、低层寄存器：请保持人类主导
真正不能撒手的，是中断服务程序、DMA 描述符链、临界区管理、低功耗状态切换这类“硬实时”代码。
原因很简单：这些代码的正确性往往不取决于“逻辑是否清晰”，而取决于“时序是否精确”。AI 无法感受到“这个 while 循环在临界区里多待了 200 个时钟周期意味着什么”，它也无法体会“此时关中断会导致无线协议栈 ACK 超时”。
我见过 AI 在 ISR 里生成一个for循环来等待外设标志位，结果把整个中断响应时间拉长了十几微秒，直接导致音频数据断流。这类问题在 PC 端的测试里完全无法暴露，只有用逻辑分析仪、示波器，甚至现场故障报告才能发现。
所以我的规矩是：中断处理函数里只做“置标志位 + 拷贝数据”，具体逻辑全部放到任务级代码里；DMA 配置和描述符链必须人工逐字段核对；寄存器位的含义必须对照数据手册复查。这些地方，AI 可以作为“注释生成器”和“代码风格统一器”，但不能作为“决策者”。
2.4 一张可以对照的“可 Vibe 等级表”
我把多年项目里常见的嵌入式开发任务整理成了一个表，方便大家直接对照：
| 代码区域 | AI 参与度 | 理由 | 实操建议 |
|---|---|---|---|
| 芯片初始化 / 时钟配置 | 很高 | 模板化，错误容易暴露 | 检查寄存器基地址和位定义 |
| BSP 驱动封装 | 高 | 接口清晰，重复性强 | 统一命名风格，让 AI 对齐 |
| Makefile / 链接脚本 | 高 | 语法机械，可读性好 | 注意交叉编译工具链差异 |
| 状态机 / 协议解析 | 中 | 逻辑可测试，边界要补 | 强制生成边界测试用例 |
| 应用层业务逻辑 | 中高 | 与硬件解耦，迭代快 | 优先做 PC 端模拟 |
| RTOS 任务实现 | 中低 | 依赖信号量/队列交互 | 让 AI 画时序图，代码人工审 |
| 中断服务程序 | 低 | 时序敏感，阻塞致命 | 人工编写，AI 仅辅助 |
| DMA / 低功耗管理 | 极低 | 时序和硬件耦合极深 | 逐句审，必须有手册对照 |
| 安全性关键逻辑 | 禁止 | 需认证、可追溯 | 传统开发流程，AI 不碰 |
这张表不是真理，但它给出的优先级帮我在项目里快速决策：把 90% 的精力放在表格下半部分的审核上，上半部分则可以大方地让 AI 跑起来。
3. 我在嵌入式项目里调 AI 的实战流程
3.1 核心心法：给 AI 一条可验证的“窄轨道”
很多嵌入式同行抱怨 AI 生成的代码不靠谱，我观察下来，大部分问题出在“提问方式”上。大家习惯直接丢一句“帮我写一个 UART 数据解析器”，然后期望 AI 像变魔术一样给出完美代码。结果拿到手一看，用了哪个库？跑在什么环境？输入数据什么格式？错误如何处理？全都没说，AI 只能靠猜，猜出来的代码自然没法直接用。
正确做法是：给 AI 修一条“窄轨道”——把任务拆小，把边界说死，把验证方式内置进去。我每次让 AI 干嵌入式活儿，提示词里一定会包含以下五要素：
- 运行环境：芯片型号、编译器版本、RTOS 还是裸机。
- 输入输出：数据结构、缓冲区大小、字节序。
- 硬性约束：不可用动态内存、不可阻塞、中断里禁止打印。
- 交付物清单：源码 + 测试用例 + 简要设计说明。
- 验证方法：在 PC 上如何编译运行，用什么 mock 替代硬件。
这里有一个非常典型的例子。我需要在 STM32F407 上实现一个 Modbus RTU 从站解析器。传统流程是：翻协议文档、写状态机、调试串口收发、反复烧板子。而我现在的做法是把它变成一个“PC 优先”的 AI 协作任务：
请生成一个 Modbus RTU 从站解析器模块，运行在 STM32F407 (ARM Cortex-M4) 上， 使用裸机 C 代码。 约束： - 输入来自 UART 中断接收的环形缓冲，解析函数在任务循环中调用； - 解析器内部禁止使用 malloc，全部使用静态缓冲； - 函数必须是可重入的，使用传入的 context 结构体保存状态； - 字节序为 little-endian，CRC16 使用 Modbus 标准多项式 0xA001； - 不要求直接访问硬件寄存器，串口收发通过外部提供的 uart_recv_byte() 回调，可写假函数。 交付： 1. modbus_rtu.h 和 modbus_rtu.c； 2. 一个可以在 PC 上直接编译运行的单元测试文件 test_modbus_rtu.c； 3. 用 Unity 测试框架，覆盖以下用例：完整单帧、拆包半帧、多帧粘包、CRC 错误、非法功能码。注意，我特意让它在“不访问硬件寄存器”的隔离层上工作，还要求写假函数。这等于把 PC 变成了一个模拟环境，AI 生成的代码不需要烧到板子上就能跑起来验证。
3.2 配套测试怎么写才真正有用
很多人在 PC 上跑所谓的“单元测试”，其实就是把代码塞进main()里打印两句。这样的测试对 AI 生成代码的验错能力几乎为零，因为它只验证了“正常路径没崩”，根本没测边界。
我习惯用 C 语言圈子里的老牌组合： Unity + CMock + Ceedling。Unity 负责断言和测试用例组织，CMock 负责自动生成 ICUART 等外设的 mock 函数。你只要定义好接口，测试框架就能自动生成替身，让 AI 生成的模块运行在“电脑假硬件”上。
拿上面的 Modbus 解析器举例，我会让 AI 把测试代码写成类似这样的形态：
void test_parse_half_frame_waits_for_remaining_bytes(void) { modbus_ctx_t ctx; modbus_init(&ctx); // 模拟收到半个帧：只发 3 个字节，期望返回 MODBUS_INCOMPLETE uart_receive_fake_data((uint8_t[]){0x01, 0x03, 0x00}, 3); TEST_ASSERT_EQUAL(MODBUS_INCOMPLETE, modbus_parse(&ctx)); }这个测试模型不起眼，但价值极大：它把“时序相关的 bug”从“看串口日志猜”变成了“函数返回值直接报错”。AI 生成的解析器一旦漏掉半包处理，测试立刻红。而整个测试运行只需要几毫秒，意味着 AI 可以快速迭代尝试不同的实现方案，直到测试全绿，再进入下一步。
3.3 硬件在环冒烟测试：永远不能跳过的那道铁门
PC 端测试全绿只是第一步，它只能保证算法逻辑正确，不能保证硬件链路正确。Modbus 解析器就算在 PC 上处理假数据完美，也还得回答这些现实问题：UART 中断优先级配置对了吗？环形缓冲区会不会溢出？CRC 计算的字节序在串口线上是不是最终的那一个？
所以我保留了“硬件冒烟测试”这道铁门。做法很简单：把 AI 生成的驱动封装成固件，烧到板子里，用真实的串口工具发几组构造好的数据帧，看返回结果。但这和以前不同——以前我是在板子上从头调一个陌生的模块，现在 PC 端已经把代码质量拉到了 90 分以上，上板只需要验证那最后 10% 的硬件交互问题。
这道铁门不能跳，但它的时间成本已经被压到了最低。由于有自动化测试的守护，AI 生成的代码不会出现“一团乱麻导致上板基本不可用”的尴尬，我们大多是一次烧录、少量修复、直接通过。
4. 踩坑与排查：AI 在我板子上留下的几道疤
4.1 疤一：中断里调用 printf，正常通讯却随机死机
这是我最刻骨铭心的一次。项目是给客户做一个小型温度采集设备，RTOS 上一个任务负责接收无线模块数据，另一个任务负责把数据通过串口打印到调试端子。为了让日志更直观，我顺手拜托 AI 在无线接收中断里加了一行调试打印。
PC 上跑 Logic 测试时一切正常，因为我把串口打印当作一个虚函数，并没有真的让它等待硬件。可一到板子上，随机复现死机——每隔几分钟就会卡死一次，看门狗复位也不稳定。
排查了半天才发现，那个调试打印调用的 UART 发送函数是阻塞式轮询加忙等待。在中断上下文里执行这个函数，一旦优先级比它低的任务正占用 UART 外设，中断就直接卡在那个 while 循环里出不来。经典的临界区死锁还被 AI 包装得挺含蓄。
从那以后我给自己立了一条规则：AI 生成的任何代码必须通过人工“上下文审查”。这个函数将被谁调用？它所在的执行环境允许阻塞吗？允许调用不可重入函数吗？AI 不会主动理解这些，必须由人来兜底。
4.2 疤二：AI 幻觉出了一个不存在的外设寄存器
那次是在 SPI 驱动上。我让 AI 参考某国产芯片厂商的 SDK 生成一个读传感器 ID 的驱动，它一本正经地生成了类似REG_CHIP_ID = 0x04的定义。结果上板后，传感器返回的数据永远不对，怎么调都不对。
后来我翻遍数据手册，发现这个芯片的 ID 寄存器其实在0x0E，而寄存器0x04是控制寄存器，写入特定值会让芯片进入一种奇怪的睡眠模式。也就是说，AI 不仅读错了寄存器，还差点把传感器配置成睡死状态。
教训很直接：像寄存器地址、掩码位、字节序这类“必须精确到一位都不能错”的硬信息，绝不能靠 AI 的记忆或推测。我会明确要求 AI 在生成硬件相关代码时，必须在注释里标注寄存器读写的依据来源，宁可让它“我不知道，请给我数据手册”，也不能让它“自信地瞎编”。
4.3 疤三：结构体直接映射 DMA 缓冲区，字节序和填充全乱
另一个经典的噩梦是字节序。AI 特别喜欢生成“把接收缓冲区直接强转成结构体指针”的代码，这在 PC 上往往没问题，因为 x86 和网络字节序通常是反的，包一解析就乱了。
项目里通信协议要求按大端序传输多个 int16 数据。AI 生成的结构体里没有考虑__attribute__((packed))和位对齐，我用小端设备接收后直接强转，数据量一多字节顺序就彻底乱了。最坑的是，这种错误在 PC 模拟测试中很难发现，因为 PC 也是小端，模拟出的“接口数据”和内存布局天然配套，只有实际抓包对比时才会炸。
现在我的要求是：凡是涉及外设 DMA 和多字节数字转换的代码，强制用显式字节操作（读低字节、高字节再拼接），禁止直接把内存块强转成结构体指针。如果 AI 生成的代码里出现了*(struct foo *)buf，我会直接打回重写。
4.4 从这些疤里总结出的铁律
AI 在嵌入式领域犯的错误，和它在 Web 领域犯的错误有本质差异。Web 里 AI 的错误大多是“业务逻辑理解偏差”，属于可调试的范畴；而嵌入式里 AI 的错误往往是“对硬件的物理行为无知”，一不留神就是把硬件推向错误状态的定时炸弹。
我的应对方法是三句话：
- 所有涉及硬件寄存器、地址、时序的代码，必须有人工手册核对环节；
- 所有被中断调用的代码，默认不得是阻塞的、不可重入的，除非人工明确确认安全；
- 所有字节序、数据宽度、内存对齐的问题，必须用显式代码，不能依赖平台的对齐行为。
这三条铁律现在都写进了团队的 Code Review Checklist。AI 生成的代码不是不能用，而是必须在这些“敏感触点”上接受比人类代码更严格的检查。
5. 当嵌入式开发真正迎来“Vibe 时代”：几个会爆发的方向
5.1 数字孪生与硬件在环：AI 的“舒适区”将被大幅扩展
前面已经论证过：Vibe Coding 想要在嵌入式领域扎根，最关键的是把“硬件反馈”变成“数据反馈”。做到这一点的技术方向早就不是科幻了，叫数字孪生，在嵌入式领域更接地气的说法是“硬件在环(HIL) 仿真”。
对 AI 来说这是重大利好。如果在电脑里有一个足够精确的板级虚拟环境——比如用 Renode 或 QEMU 模拟一个 Cortex-M 内核，挂载虚拟串口、虚拟 GPIO、虚拟传感器——AI 生成的驱动代码就可以在完全模拟的硬件上迭代。中断的时序被模拟了，硬件寄存器的访问被模拟了，连传感器返回的数据流都能模拟出来。这时 AI 的反馈速度和 Web 开发一样快，而且错误成本约等于零。
我身边的人已经这么干了。有人用 Renode 跑 Thread 协议栈的回归测试，让 AI 自动补协议状态机的用例；也有人用 QEMU 模拟 ESP32，让 AI 反复修改 Wi-Fi 驱动里的某个时序 bug。虽然模拟环境和真实硬件仍有差异，但作为第一道筛子，它足以让 AI 成为嵌入式开发的可靠“初级工程师”。
5.2 从“自动写驱动”到“自动把设备观测化”
另一个我认为会先爆发、而且目前已经被验证实用化的方向，不是“让 AI 写驱动”，而是“让 AI 制造观测手段”。
嵌入式开发里最贵的永远不是写代码，而是“看”。看变量、看时序、看中断、看内存、看波形。一个经验丰富的工程师手里那套串口日志、逻辑分析仪、JTAG 断点、RTOS trace 工具，才是他年复一年积累的核心资产。
AI 在这块的表现反而特别稳定。我经常让它干这些事：
- 根据固件源码生成系统行为分析脚本，比如把二进制日志解析成人能看懂的协议流程；
- 根据 I/O 时序图，自动生成一段测试用波形数据喂给被测设备；
- 根据 RTOS 的 trace 文件，标注出任务切换的异常点；
- 为现有代码自动补上数据观测 hook，比如周期性地把关键变量打包发到调试串口。
这些任务本质上是“元技能”：不直接产出业务固件，但把固件变得可观察、可理解、可调试。AI 把观测工具的门槛直接打了下来，这就是嵌入式开发往“Vibe 时代”过渡的真正引擎——不是自动把代码写好，而是自动把设备变透明。
5.3 嵌入式专项 AI 工作流：现在就能动手的三个基建项
如果你也想在团队里铺一条通往嵌入式 Vibe Coding 的路，我建议从下面三个基础设施开始：
第一，把“PC 可运行”作为新模块的第一道验收标准。任何新写的协议、状态机、业务逻辑，先在 PC 上编译运行；用 mock 屏蔽所有硬件依赖；让 AI 能快速在本地验证。这比任何代码规范都有用。
第二，建一个团队的“知识库切片”。把常用的芯片数据手册、SDK 文档、公司编码规范、经典驱动模板整理成 AI 可检索的目录，而不是让 AI 每次去“猜”。我在实践中发现，给 AI 喂一张寄存器描述表，比让它背一万个 GitHub 仓库里相似的代码有效得多。
第三，把硬件在环测试纳入 CI。哪怕是一个再简陋的、用树莓派接串口模拟目标板行为的夹具，只要能每天自动跑一轮真实设备上的冒烟测试，AI 的每一次改动都会被硬件亲手打一次分。反馈回路一闭合，Vibe 才真正发生。
6. 给还在用手搓寄存器的同行的几句真心话
6.1 Vibe Coding 不会让嵌入式消失，只会让“不学架构”的写法消失
很多同行怕 AI 把自己的手艺冲掉，尤其是一些写了十几年底层驱动的老工程师。但我的判断恰恰相反：AI 最先替代的，是那些“重复性最高、对硬件理解要求最低”的模板代码；而它最难替代的，恰恰是“在约束条件和物理现实之间做取舍”的工程设计思维。
举个例子，同样的“点亮一颗 LED”，AI 可以生成 GPIO 初始化和HAL_GPIO_WritePin调用。但设备手册上写着这颗 LED 由某个电源管理芯片的 GPIO 扩展器控制，上电时序要求 LED 必须在某个电压域稳定后才能点亮，而且这个 GPIO 扩展器本身挂在 I2C 上，I2C 总线又和另一颗温度传感器共用——这种跨层级、跨芯片、跨电气特性的综合判断，AI 帮不了你。
所以，Vibe Coding 真正淘汰的不是嵌入式工程师，而是那些只会“照着数据手册敲代码”、不会思考为什么这么敲的人。只要你能解释清楚“这个延时为什么不能短”“这里为什么必须加电平转换”“这个中断为什么不能嵌套”，你不但不会被淘汰，还会因为能更快速地产出和验证想法而变得更加值钱。
6.2 如果你决定拥抱 Vibe Coding，请带上这三样东西
第一样：一个能快速拿到结果的测试环境。 无论是 Unity/Ceedling、Renode，还是你自己写的一堆 fake 函数，先让你的代码能在没有硬件的情况下跑起来。这一步做到了，AI 才能有效工作。
第二样：一份永远在线的“不信任清单”。 清单上写清楚哪些模块必须人工审查：中断、DMA、低功耗、寄存器配置、字节序。AI 生成的代码进入这些区域前必须先过人工。不要讲原因，这是用真金白银的板子换来的教训。
第三样：把“指示词当代码评审”的自觉。 给 AI 的每一条指示，都要像你给实习生派活一样说得清清楚楚：运行环境是什么、约束是什么、验证手段是什么、交付物是什么。好的 AI 协作不是“让它自由发挥纳”，而是“把自由放在有限边界内”。
6.3 我的立场
我依旧会用 AI 帮我生成 UART 驱动框架、让 AI 补全状态机测试用例、请 AI 分析 RTOS 的 trace 日志。但我也依旧会花一整夜对着示波器看一根引脚的时序，只为确认某个中断延迟是否符合要求。
Vibe Coding 从来不是降低标准，而是把精力从“打字”转投向“判断”。在嵌入式开发里尤其如此——因为一轮硬件的返工成本，可能是整个项目组一个通宵的代价，是服务器日志多几行错误远远不能比的。当 AI 真正把“硬件不可观测”变成“硬件可快速虚拟化、可自动验证”，嵌入式开发也会进入它自己的 Vibe 时代。但在那之前，请一定握好你手里那只属于工程师的、谨慎的扳机。
