Vibe Coding遇上嵌入式：AI辅助开发的适用边界与工程实践

说实话第一次看到“Vibe Coding”这个词的时候我正蹲在实验室里跟一块死活不启动的板子较劲。社交平台上铺天盖地都在晒“我用几句话生成了一整个项目”评论区一片狂欢。我扫了几眼又看了看手头的逻辑分析仪——脑子里蹦出来的念头是如果 AI 写完后只需要“感受一下氛围”就能上线那它遇到的第一个对手大概就是我们这种连串口日志都要掰开揉碎看半天的嵌入式开发场景。这个矛盾感一直让我惦记着。AI 确实改变了很多东西我以前遇到不懂的驱动习惯翻手册、搜例程、问群友现在第一反应是打开对话窗口把问题描述一遍它能在几秒内给我一份“看起来高度合理”的参考代码。但越来越多人开始把 Vibe Coding 当成一种工作方式的时候我却发现它背后藏着一个不那么舒服的前提这种编码模式默认了“代码写错了可以回滚”默认了“环境会宽容你的试错”默认了“反馈是即时的”。而嵌入式开发的物理世界恰恰把这几个默认全部推翻了。所以这篇文章不打算带着“AI 会替代谁”的焦虑来写也不是来吹“AI 一键生成嵌入式工程”的。我想做的是把这个时代里嵌入式工程师真正要面对的东西拆开看看哪些环节 AI 确实能帮你省时间哪些环节它看起来在帮忙实则是一个巨大的坑以及 Vibe Coding 这套方法论在我们这个领域到底死在了哪里、又活在了哪里。1. Vibe Coding 的土壤和嵌入式的地貌天生不对付先把概念对齐一下。Vibe Coding 这个词强调的是“氛围感编程”——你用自然语言把需求描述给大模型它生成代码你简单验证后就说“这感觉对了”然后不断迭代。它之所以能在应用开发、Web 开发、脚本工具这些领域迅速流行绝不仅仅是因为 AI 模型强而是因为它被放在了一个非常宽容的土壤里。1.1 它流行的前提是“环境宽容”Web 开发里你让 AI 生成一段调用支付接口的代码就算逻辑有问题部署上去顶多是接口返回个错误回滚一下就好用户最多刷新两次页面。脚本工具更不用说跑挂了重新跑一遍连擦屁股的成本都几乎为零。在这种环境里“描述需求→让 AI 生成→快速验证→感觉不对再改”这个循环可以转得飞快试错成本低到几乎可以忽略。这种工作方式的核心假设有三条反馈要够快、错误要可逆、抽象层要够厚。Web 世界里这三条全都能满足——反馈是秒钟级的错误是可回滚的且框架、运行时、类型系统帮你兜住了一大批底层细节。1.2 嵌入式世界里那四面硬墙嵌入式开发呢这三个前提一个都不满足。反馈闭环极慢。你改了一行寄存器配置从编译、烧录、复位、观测波形最短也是分钟级。如果是排查一个偶发的时序问题可能半天都复现不了一次。Vibe Coding 最引以为傲的“快速试错、凭感觉迭代”在嵌入式这里根本转不起来——你连“感觉”都还没来得及形成半天已经过去了。硬件行为不可完全推导。AI 学习的是海量代码的统计规律但芯片行为取决于数据手册、勘误表、PCB 走线寄生参数甚至同一型号不同批次的实际表现。很多嵌入式 bug 是“道理上讲不通但现象就是那样”这时候 AI 如果给了你一个“看起来合理”的答案反而会把你带进更深的坑。出错代价极其昂贵。Web 项目错了回滚就好嵌入式错了轻则功能异常重则板子烧了、产线停了、设备要召回。在医疗、汽车、工控这些安全敏感场景代码错误带来的后果是不可逆的。这种场景要求的是“确定性优先于速度”而 Vibe Coding 的本质是“速度优先于确定性”。抽象层保护极少。Web 开发有浏览器、虚拟机和一大堆框架帮你隔离开底层嵌入式开发却大量工作在寄存器级、指针级、中断时序级。你用自然语言说“配置一下 UART”AI 确实能给你配置代码但这段代码有没有为你的芯片版本、你的外部晶振频率、你的引脚复用方式做正确调整没有任何框架能帮你兜底少了任何一个 bit它就是一个完全不能用的东西。我把这两类开发的差异整理成了一张表方便直接对照维度应用/Web 开发嵌入式开发试错成本极低回滚即可高重则物理损坏反馈速度秒级到分钟级分钟级到数天抽象层保护框架/运行时/类型系统大量兜底寄存器级/中断级手动管理硬件角色的确定性环境基本稳定同一型号芯片也可能有差异AI 生成代码的可用率较高错误不难发现需要人工逐行对活着业务实现排障依赖日志/堆栈/调试器示波器/逻辑分析仪/物理直觉所以这里的结论很清晰Vibe Coding 在嵌入式领域“水土不服”不是因为它本身有问题而是因为它背后的那套方法论假设在真实的物理世界里根本没有成立的空间。但这不代表我们该关掉 AI 对话框——问题从来不是“AI 能不能用”而是“它在哪个环节能帮上忙”。2. 别急着关掉AI对话框这几个环节它能省你一半时间说实话我自己也经历过从“AI 生成代码直接烧录”到“怀疑 AI 然后把它放回工具箱”的转变。现在我的态度很明确AI 不能是一个自动写代码的同事但它可以是一个非常高效的助手。关键是选对让它帮忙的位置。2.1 协议解析与数据加工AI 最舒服的领地如果让我给 AI 在嵌入式开发里的舒适度排个序排在第一位的一定是协议解析和数据加工类的模块比如 Modbus RTU、CAN 报文解析、MQTT 数据流处理、自定义帧格式的分包与校验。这些模块有一个共同特征输入输出边界清晰逻辑性强不依赖具体硬件时序。你给它一个明确的接口定义再给几个真实的示例帧它生成的代码在绝大多数情况下可以直接进单元测试。我常用的做法是// 定义解析函数接口输入原始字节流输出解析后的结构体 int modbus_rtu_parse(const uint8_t *buf, uint16_t len, modbus_frame_t *frame);我会在 prompt 里给 AI 描述清楚帧格式、CRC 校验方式、地址域和功能码的含义以及一个或两个完整的字节序列示例。AI 生成的解析函数我基本只需要做 code review很少需要改逻辑。这种工作属于“翻译类任务”——把规定好的格式翻译成 C 代码AI 做得比绝大多数初级工程师快得多。但这里有一个坑我踩过一次。让 AI 生成带状态机的分包逻辑时它很容易把边界条件写得过于复杂或者在处理残余帧时漏掉状态重置。所以协议解析类的代码虽然可以交给 AI 写但一定要配套单元测试桩跑一遍尤其是边界条件异常帧、半截帧、多帧粘连这种情况必须自己补测试用例。2.2 寄存器手册提取和初始化草稿让 AI 当“查手册加速器”嵌入式开发最耗时间的环节大概就是翻参考手册。1000 多页的 PDF找一个外设的寄存器说明要翻半天找到之后还要核对位域名称、复位值、与时钟树的关系。这块我非常建议让 AI 来当“查手册加速器”。具体做法是把参考手册里对应外设章节的关键页复制进对话窗口不要直接扔整个 PDF 给它因为大模型处理超长文档容易产生幻觉。然后让它提取该外设的全部寄存器地址和位域说明以表格形式输出标出与复位默认值不一致的关键位根据我提供的时钟主频和引脚复用需求生成一个初始化代码草稿。我实测下来这个流程至少能省一半的查手册时间。AI 提取信息的能力确实强比如 STM32 的 USART 配置它会很快算好波特率分频值给出一个方向完全正确的初始化函数。但注意草稿只是草稿你必须在烧录前把每个寄存器位对照手册逐条核对尤其是时钟树那一层很多人第一次用 AI 生成的初始化代码烧录后外设不工作八成是漏掉了 GPIO 复用时钟和外设时钟的使能顺序。AI 生成的“USART_Init”类的函数往往只关注了 USART 自身的寄存器而没有考虑 RCC 和 GPIO 的协作这一步人工核对是绝对不能省的。2.3 调试日志与串口数据分析AI 是最好的“翻译官”嵌入式调试里最烦人的一件事就是对着串口助手里的十六进制输出猜它在表达什么。我的经验是把原始数据扔给 AI 让它翻译这个环节 AI 表现得极好。比如逻辑分析仪导出了一段 I2C 总线数据地址是 0x50ACK 正常但第 5 个字节开始响应异常。把这段时序摘录和你的代码片段一起贴给 AI它能很快告诉你问题要么出在地址对不上要么是读写控制位弄反了。这种“翻译类”工作它做起来又快又准确。但有一个原则我强调了很多次AI 做翻译很好用做判断就危险。它说“看起来是地址冲突”那它就真的只是“看起来是”最终的判断必须由你来下因为它永远看不到你的上拉电阻焊在哪、走线有多长、板子上有没有别的干扰源。它的作用是帮你缩小范围而不是直接给出结论。2.4 单元测试桩和 Mock 模块把 Host 端测试变成日常嵌入式工程在开发机上跑单元测试最痛苦的就是硬件依赖。一个函数里面调用了某个外设的寄存器读写在 PC 上根本无从运行。而这一点 AI 帮了大忙——我经常让它根据我们的硬件抽象层接口定义生成 mock 实现和测试桩。比如我的驱动层定义了一个i2c_transfer()接口我会让 AI 生成这个接口的 mock 版本再根据配置生成一组测试用例把所有外部依赖全部 mock 掉。这套流程跑通之后我们的 CI/CD 里终于能跑单元测试了不用再等到烧录到板子上才能验证逻辑。这算是 AI 在嵌入式工程化方面比较实打实的贡献。3. 当“板子不动”时AI 的盲区恰好是嵌入式的主战场前面讲的是 AI 能帮上忙的环节但真正决定一个嵌入式工程师价值的地方恰恰是那些 AI 帮不上忙的环节——带硬件特征的排障场景里AI 的盲区和嵌入式的主战场完全重叠。3.1 一场典型的排查I2C 那根“偶尔不听话”的传感器我手头有一个实际项目板子上挂了三个 I2C 传感器现场反馈其中一个芯片偶尔无响应另外两个一直稳定。你们猜排查过程是怎样的我先接上示波器观察 SCL 和 SDA 两路波形。现象是SCL 波形正常但 SDA 线上有毛刺下降沿时间比预期慢了不少。我怀疑是上拉电阻阻值选大了但翻设计文档发现三个芯片用的都是同一个阻值为什么偏偏这个芯片出问题接着检查走线长度发现这个芯片离主控最远中间还过了一个连接器总线电容明显偏大。然后我再单独挂这个芯片测试确认不是地址冲突也不是芯片批次问题。最终确认是走线寄生电容导致的上升沿抖动在上拉电阻不变的情况下总线上多出的那截走线电容让 SCL 高电平时的 SDA 稳定时间超过规格书阈值极偶尔地造成误判。这个过程里每一步都用到了物理世界的反馈波形长什么样、温度湿度变化对上升沿的影响、连接器氧化带来的接触电阻……这些东西没有任何一环节在代码里AI 根本无从学习也无法从你的代码片段里推理出“走线电容偏大”这个结论。3.2 AI 为什么给不了“板子不动”的答案核心原因在于AI 没有现场感知通道。它只能基于你喂给它的信息做静态推理而这些关键信息往往不在代码里——是示波器上的那根毛刺是复位脚的 60mV 跌落是特定温度下才能复现的诡异现象。Vibe Coding 的“vibe”来自数据空间的统计规律而嵌入式问题的“vibe”来自物理世界的因果链条。这两者的距离比 AI 从“一段代码”到“另一段代码”的距离要远得多。换句话说AI 擅长的是“给定 A 求出 B”而嵌入式排障恰恰是“连 A 是什么都不知道得先找出 A”。3.3 AI 参与排查的正确姿势发散与收敛的分工那 AI 在排查里就真的啥也不能干吗也不是。我现在的做法是把它当成一个“第二头脑”负责发散我负责收敛。具体做法把现象描述波形时序、出错频率、温度湿度条件、相关代码片段、我已经试过排除的方案全部翻译成文字喂给 AI然后明确告诉它“不要给我解决方案先列出 3 到 5 个最可能的排查方向并为每个方向设计一个能够证伪它的实验方案。”这一步的产出质量相当高。AI 会基于它见过的海量案例给出“上拉电阻不足、总线长度超限、设备地址冲突、时钟延展式通信失败、焊接虚焊”这类可能性清单效率比自己拍脑袋想快得多。但接下来的辩伪实验比如换一颗传感器测试、量走线电容、用逻辑分析仪重新抓波形这些动作的设计和结果判断必须完全由自己来。这个分工一旦形成习惯你会发现 AI 不再是“替代你的判断”而是“帮你的判断提速”。4. “AI 不会取代嵌入式工程师”这句话只说对了一半我跟很多同行聊这个话题听到最多的安慰是“嵌入式工程师不会被 AI 取代因为我们有门槛”。这个说法太粗糙了门槛也分高矮。其实真正会被取代的不是“嵌入式工程师”这个身份而是那些“没有嵌入式的嵌入式工程师”。4.1 真正容易被取代的是“没有嵌入式的嵌入式工程师”最近热词里有个“应用层开发是不是嵌入式”问的人大概是想确认自己学的东西属不属于正统嵌入式。我的观点是应用层逻辑本身当然算嵌入式的一部分但如果你的全部工作就是在一个成熟的 RTOS 上写业务逻辑不碰寄存器、不看时序、不摸示波器那么这份工作在 Vibe Coding 时代确实危险。因为应用层逻辑的抽象层级足够高AI 完全能够处理。你把需求和接口描述清楚它生成的代码基本能跑。这和 Web 开发里的情况没有本质区别。容易受影响的是那些只掌握“调库写逻辑”这一种能力的工程师——在 AI 面前这门手艺的稀缺性正在迅速贬值。这其实和“会开车的人”与“真正理解汽车机械原理的人”的区别很像。AI 时代越来越多的人拥有“驾照”甚至 AI 自己就能“开得很溜”但修车、判断异响来源、在极端天气下做驾驶决策的能力依然极其稀缺。4.2 同一个“测方波频率”两种工程师的差距举一个具体例子让 AI 写一个“用定时器输入捕获测量方波频率”的功能。第一类工程师只会描述需求对定时器时钟树、捕获模式、滤波配置没有概念。AI 生成了一份“看起来完美”的代码8 位预分频、上升沿捕获、周期换算频率。但一旦数据不对——比如低频时跳动剧烈、高频时频繁重载溢出——他完全没有头绪。他去看代码每一行看起来都合理就是不知道问题出在哪。最后只能把整个 AI 生成的代码删掉上网搜“STM32 输入捕获不工作的原因”一条一条猜。这类工程师其实是在用 AI 把一个“不懂底层也能开发”的幻觉照进现实。第二类工程师拿到 AI 的代码后先不急着烧录。他先验算了一遍时钟树系统主频 72MHz预分频 72 得到 1MHz 计数时钟16 位定时的最大计数周期只有 65.535ms测低频方波时必然溢出。于是他重新配置了预分频把计数时钟降低到 100kHz最大计满时间提升到 655.35ms再配合溢出中断扩展计数范围。同时他检查了捕获引脚是否配置内部上拉、是否做了滤波、DMA 是否对齐。这些判断AI 不会凭空生成因为不是通过语言就能描述的“需求”而是需要理解“MCU 内部资源怎么为测量目标服务”的权衡能力。这里最核心的差距是第一类工程师把 AI 当成了“老师”或者“最终答案”第二类工程师把 AI 当成了“输入法”。输入法可以提高打字速度但决定文章质量的永远是写作者的思想。4.3 嵌入式工程师的新能力模型既然时代在变能力模型也得跟着调。我复盘了自己这几年的工作觉得真正拉开差距的是四件事问题定义能力。你连需求都说不清楚AI 只会给你一个看起来合理的错误。能把“让通信稳定一点”翻译成“降低总线上拉电阻的同时验证上升沿不超规格书阈值”这种能力在 AI 时代更值钱。硬件直觉。功耗、时序裕量、信号完整性、热插拔浪涌这些不是代码能呈现的直觉判断靠的是现场经验的积累。AI 没有这种直觉但它可以帮你把直觉转化成文字描述方便你复盘和分享。验证思维。嵌入式开发最大的风险不是代码错而是“不知道错在哪”。设计一个最小可验证实验来证伪某个假设这是 AI 最不擅长但却是工程师最核心的技能。知识表达能力。把经验翻译成 AI 能理解的上下文让 AI 的生成结果贴合你的场景这本身就是一门新手艺。我见过太多人抱怨 AI 生成垃圾代码深入一问他们输入的信息量只有一句话“写一个 I2C 驱动”。你只给一句话AI 也只能给你一个“一个 I2C 驱动”。5. 我现在怎么把 AI 嵌进嵌入式流程三分法、协作流和踩坑实录前面说了那么多理论层面的思考最后落到实操。我现在的确把 AI 用进了日常嵌入式开发流程但也不是无脑用我把它分成了“当用、谨慎用、绝不用”三类然后配一套固定协作流程。5.1 先分清什么能交出去、什么必须自己兜底我列了一张清单每次拿到一个需求先对照这张表决定分配方式类别任务特征实际示例使用策略当用逻辑明确、无硬件时序耦合、输入输出边界清晰协议解析、数据校验、日志插桩、单元测试桩、文档整理直接让 AI 生成人工 code review谨慎用涉及寄存器、中断、时序、外设资源分配外设初始化草稿、中断处理逻辑、驱动移植让 AI 生成骨架或“要点清单”人工逐行审查并核对参考手册绝不用安全关键路径、公开流程、人类生命财产相关bootloader 关键路径、看门狗/电源管理、任何我不理解的底层机制代码全程人工编写和 reviewAI 只做信息检索和方案脑暴这张表每次都能帮我避掉一堆坑。凡是类别是“绝不用”的代码哪怕 AI 生成的逻辑再合理我也会坚持自己从头到尾亲手写因为我知道在安全关键路径上我不能为一段“看起来合理”的代码负责。5.2 一套我验证过的协作步骤如果你已经在衡量要不要把 AI 引入嵌入式开发流程我可以分享我现在用的这套步骤。一开始就花时间把流程固定住后面会顺畅很多第一步给足上下文。你以为“写一个 I2C 驱动”就够了但 AI 最需要的其实是 MCU 型号、外设编号、时钟主频、IDE/编译器版本、引脚复用关系、已知约束比如不能使用 DMA 的区块。上下文越全AI 的产出越少跑偏、越少幻觉。第二步禁止 AI 直接给代码。我通常会先让它输出一个“实现要点清单”列清楚需要做哪几步、每一个步骤涉及哪些资源和风险点。这一步算是给我的 code review 打草稿让我在动手之前先有一个完整逻辑链可以审。第三步让 AI 生成草稿然后逐行走查。注意是逐行不是大概看一眼。我会对照参考手册的寄存器默认值、对照时钟树的分频关系一项一项核对。这一遍下来通常能发现至少 2-3 个需要修正的地方问题都不大但如果不核对就会变成烧录后纠结半天。第四步最小实验验证。把 AI 生成的代码嵌入一个最小的测试工程验证一个最基础的功能等到功能正确之后再往完整的业务工程里合入。这一步能把 AI 生成代码的风险隔离在一个可控范围内。第五步沉淀。把这次验证过后能用的代码片段、有效的 Prompt 结构、复查时发现的规律性问题整理成团队的知识库。这一步价值巨大因为同一类外设、同一类问题团队里的其他同事以后也可以直接复用不用再让 AI 从头生成一遍、再从头踩一遍坑。5.3 翻车实录DMA 搬运和“8字节对齐”的那次半夜这个流程也不是一开始就有的我先后过了不少跟头挑一个印象最深的讲讲。有次我让 AI 写一段 DMA 在内存和 UART 外设之间搬运数据的代码。逻辑上一点问题没有DMA 配置正确、源地址和目的地址正确、传输长度也正确。单独写在裸机工程里测试收发数据完全正常。我当时还挺得意觉得“这不就很稳定嘛”就直接把它合进了嵌入式 RTOS 的项目里。结果噩梦来了在某个高优先级任务频繁被触发的情况下偶发地出现数据错位大概每 20 次传输会有 1 次。我把现象和代码喂给 AI它给出了几个建议降低那个任务的优先级、增加 DMA 中断标志判断、增加互斥锁。方向看起来都合理我甚至一度试了增加互斥锁但问题依旧。最后熬到半夜盯着 DMA 的配置代码看了一个小时突然反应过来一个细节那段传输 buffer 是在一块带 cache 的内存区域分配的而我没有做内存对齐buffer 的开头不是 8 字节对齐的。外设 DMA 在突发模式下从不对齐地址读取一次搬运多取了一部分数据最终导致偶发错位。这个根因代码里没有任何线索除非你把这块 MCU 的存储体系、cache 一致性、DMA 突发模式的约束全部喂给 AI否则它永远不可能给你“检查内存对齐”这个答案。它给的“降低优先级”等建议在它的世界里当然是合理的因为问题是偶发性的看起来就是调度期的问题。但在物理世界里真相是硬生生的一个地址问题。这次之后我彻底明白了一件事AI 给的“看起来合理”恰恰是嵌入式里最危险的东西。因为 AI 永远只是从你给出的“抽象信息”里做知识匹配而不是从真实的“物理信号”里做因果推断。你能拿到“物理信号”的通道才是你值钱的地方。5.4 几个值得直接复用的 Prompt 模板最后分享几个我实际在用、效果不错的 Prompt 模板。这些模板不是让你无脑粘贴而是给你一个“正确提问”的参考框架。寄存器信息提取模板请从下面这段参考手册文本中提取该外设全部寄存器地址、位域名称、位域偏移、复位值并以 Markdown 表格形式列出。同时标记出复位后默认值为非零的位。若手册文本中未明确的地方请用“未明确标注”注明不要自行推断。 [手册片段粘贴]要点清单模式根据以下接口定义和约束条件先不要写具体代码请先列出一个实现要点清单。清单需包括数据结构设计、资源分配、边界条件、潜在风险点和建议的处理顺序。等这个清单被我确认后你再生成代码草稿。 [接口定义和约束条件]排障脑暴模板以下是一个嵌入式现场的故障描述和已排除方案。请你不要直接给解决方案先列出最可能的 5 个排查方向并按可能性排序。对于每个方向请设计一个具体的、可执行的证伪实验以及该实验在哪种结果下会推翻此假设。请基于我的现场现象和数据推理不要泛泛而谈。 [现象、代码片段、已排除的方案]测试桩生成模板根据下面的硬件抽象层接口定义生成一个可编译的 mock 实现并编写一组覆盖正常路径和异常路径的单元测试用例。外部依赖如寄存器读写、中断使能等请全部通过 mock 封装。生成的代码风格请对齐现有工程的配置文件。 [接口定义和现有文件工程结构]这些模板的核心价值是逼着 AI 进入到“先帮我思考、再帮我生成”的模式而不是一上来就给你一大堆代码。前者让你保持判断力后者让你逐渐失去判断力。一路写下来我的核心体会其实就一句话Vibe Coding 时代嵌入式开发里能被 AI 替代的从来不是“工程师”而是工程师身上那些和“物理世界对话”的属性如果被我们忽略的话。代码可以被生成但“为什么这行代码是对的”背后的整个上下文不能。芯片勘误表上新加的那行说明、示波器上那根毛刺、DMA buffer 里的对齐、连接器带来的寄生电容……这些东西才是我们在 AI 时代真正要守住并持续深耕的护城河。你越往“物理世界的确定性”里走AI 离你就越远你越停留在“抽象世界的概然性”里不离开AI 离你就越近。这个方向值得每个做嵌入式的同行想清楚。