最近公司内部有个特别有意思的割裂画面应用层的同事开周会时来一句“今天下午 vibe coding 了一把接口直接调通了”语气轻松得像点了杯奶茶而我们嵌入式小组的几个人面面相觑脑子里全是寄存器地址、时序约束和“这玩意儿要是跑飞了板子会不会冒烟”。这个场景让我意识到Vibe Coding 这股风已经刮到嵌入式开发的门口了但大多数人——包括很多做嵌入式的老手——对它到底是什么、能干什么、会在哪里碰得头破血流其实并没有一个清晰的判断。所以这篇不是教程也不是带货文更不是“AI 要取代程序员”的焦虑复读。我想以一个在嵌入式领域摸爬滚打十来年的工程师视角聊聊 Vibe Coding 与嵌入式开发相遇时的真实面目哪些环节它确实能帮你省下半天时间哪些环节它看起来像模像样但实际是一颗定时炸弹以及在这个浪潮里嵌入式开发者的核心价值到底该怎么重新定位。1. Vibe Coding 的本质不是“让 AI 写代码”而是“意图到代码”的反馈周期缩短1.1 这个词到底在说什么“Vibe Coding”这个说法是 Andrej Karpathy 在 2025 年初提出来的原话大意是“你不再是一个专注的代码编写者而是一个跟随氛围、描述意图、偶尔审查的人”。换句话说以前的编程是“动手写每一行”现在的 vibe coding 是“用自然语言描述我要什么AI 生成代码我看一眼没问题就跑”。这里的“vibe”指的是那种跟着感觉走、不完全较真每行细节的状态。放到应用层开发里非常好理解对一个 Python 后端开发者来说需求通常是清晰的——接一个支付回调、写一个数据清洗函数、做一个 CRUD 接口。环境可复现依赖能装测试能跑出了问题看日志就能定位。AI 生成一段代码出错了无非是接口返回 500重新生成一次就行。反馈循环极短试错成本接近于零所以“vibe”得起来。1.2 它真正改变的不是“写代码”而是“反复试错”的廉价化很多人讨论 Vibe Coding 时都聚焦在“AI 能不能写代码”我觉得这个讨论方向从一开始就偏了。Vibe Coding 真正的变化是把“从意图到可运行代码”的迭代成本压到了一个前所未有的低成本区间。过去你写一个排序算法要自己调边界条件现在你只需要说“给我一个稳定的归并排序不要用递归注意省内存”。AI 给的代码可能不是最优但大概率能跑然后你再基于结果提要求“改成原地排序”一次循环就完成了。这个变化对应用层是革命性的因为应用层开发的大部分工作本来就发生在“意图到代码”这一段。需求到了手里剩下的就是搬运逻辑、调整格式、修补边界条件。这一段恰好是 AI 最擅长的事情。但对嵌入式开发来说事情没有这么简单因为嵌入式开发的完整链路是“物理世界的约束 - 硬件规格 - 驱动 - 系统软件 - 应用逻辑”代码只是位于最末端的薄薄一层。Vibe Coding 改变的只是最末段而前面一大段硬约束它连看都看不到。1.3 为什么嵌入式开发者本能地反感这个词我们团队第一次讨论 vibe coding 时一位做了七八年汽车电子的同事说了句很扎心的话“AI 知道我这颗芯片的勘误手册第 42 页写了什么吗”这句话基本戳中了嵌入式开发的命门。嵌入式开发的信息源极其特殊芯片参考手册上千页寄存器定义、时序图、勘误表分布在不同的 PDF 里很多细节还在不断更新同一系列芯片的不同型号外设映射都可能不同再加上交叉编译环境、RTOS 的调度策略、中断优先级、电源域管理这些上下文全部注入到一段代码里时问题空间远比“写一个 CRUD 接口”大得多。AI 模型的训练数据里通用软件代码占比极高而某个冷门 MCU 的 BSP 代码可能只有几千条有效样本。这不是“AI 不够聪明”的问题而是嵌入式开发的知识密度太高、物理耦合太强“意图到代码”这一段本身就不是主要矛盾。所以先别急着站队说“vibe coding 就是邪道”或者“以后没人写代码了”。在我看来正确的态度是先把嵌入式开发的特殊性摆清楚再讨论哪些环节可以引入 vibe 工作流哪些环节必须保持人肉把关。2. 嵌入式开发的特殊性为什么“让 AI 写代码”在这里容易失灵2.1 嵌入式开发的完整链条代码是最末端的一环很多非嵌入式背景的人以为“嵌入式开发就是写 C 语言跟写应用差不多无非是要注意内存”。这种误解非常普遍但实际情况差得远。一次典型的嵌入式项目从上游到下游大致是这样的需求定义物理环境、功耗、实时性指标- 芯片选型 - 原理图设计 - 芯片寄存器手册阅读 - BSP 和驱动编写 - RTOS 移植或裸机调度 - 中间件与协议栈 - 应用逻辑 - 测试与认证。在这条链路上真正属于“写代码”的部分可能只占了 30% 的工作量其余时间花在读手册、调硬件、做验证、排查总线冲突、压功耗、过认证这些事上。Vibe Coding 即便是再厉害它也只能作用于“写代码”这一截前面那些步骤它帮不上忙。举一个很具体的例子你要初始化一颗新的 I2C 外设AI 可以给你生成一个看起来很标准的i2c_init()函数填好寄存器地址和时钟分频系数。但 AI 不知道你的硬件设计里 SCL/SDA 上拉了多大的电阻不知道从设备是否支持 400kHz 快速模式不知道你的中断优先级会不会跟定时器冲突。这些信息只存在于原理图和芯片数据手册里而这两样东西AI 的上下文窗口里通常没有。2.2 成本模型完全不同应用层错了重启嵌入式错了烧板子应用层开发的试错成本可以用一句话概括便宜到可以忽略。代码出 bug报错日志打出来改一下重新部署顶多两三分钟的事。Vibe Coding 能流行很大程度上是因为这种低试错成本撑得起“让 AI 去试错、我只看结果”的工作模式。嵌入式开发完全相反。一个典型的错误案例某工程师让 AI 生成了一段 GPIO 初始化代码上下文里没写清楚是推挽输出还是开漏输出AI 默认选了推挽结果接在 I2C 总线上把应答信号直接拉死板子表现为“所有传感器偶尔读不到数据”光排查这个偶发问题就花了两天时间。如果这段代码是用在电机驱动上配置错误可能直接导致过流烧管。应用层代码跑飞了最差是用户体验变差嵌入式代码跑飞了的代价是硬件损伤、现场事故甚至安全认证推倒重来。所以我一直跟团队里的人说在嵌入式场景里AI 生成的代码不能“看着能跑就行”而是要“推演过每一条危险路径之后才能烧录”。这个推演过程恰恰是 AI 目前最难替代的部分因为它需要系统工程思维和物理直觉。2.3 训练数据与硬件上下文模型的盲区比你想象的更大很多做应用层的朋友不理解为什么 AI 写 Python 那么溜写 C 就显得平庸一个很重要的原因是训练数据的分布。互联网上的 Python 代码、JS 代码、Java 代码到处都是GitHub 上千万量级的仓库在反复训练这些模式。但嵌入式代码——尤其是带具体芯片型号的寄存器操作代码——通常不会公开或者只散落在芯片厂商的 SDK 里、论坛的回答里数量和质量都不在一个量级。更要命的是硬件上下文是“局部知识”。假设你用的是某国产车规级 MCU网上能找到的开源代码本来就不多芯片手册还是厂商自己写的AI 很可能从未见过这个型号。你让 AI 帮忙写启动文件、写链接脚本、配置时钟树它只能基于泛化的 STM32 经验去猜而不同厂商的寄存器布局、启动流程差别很大猜出来的东西往往“看起来很对”一编译全是错。这也是我在实际使用中最大的感受Vibe Coding 在处理“通用问题”时表现惊艳在处理“具体硬件对象”时经常胡说八道。你需要把手册中关键寄存器定义贴给它才能把它的“幻觉”拉回现实。3. 我的真实实践哪些环节省了大劲哪些环节翻了大车3.1 省力场景一驱动框架的脚手架代码先说说真正让我觉得“真香”的地方。有一次我需要给一颗传感器写 I2C 驱动传感器寄存器表有几十个读写时序比较简单。我没有从零敲而是把传感器手册里寄存器表的部分贴给 AI让它生成一份驱动骨架包含设备结构体定义、读寄存器函数、写寄存器函数、基本的初始化流程。AI 给出的结果确实省了不少事i2c_read_reg、i2c_write_reg这类函数写得规规矩矩错误处理、超时判断也都带上了我只需要把平台相关的底层 I2C 收发函数填充进去。这个环节就属于典型的“通用模式”识别读寄存器、写寄存器在成千上万个驱动里都是类似结构AI 学得很好。而且这类代码即使出错也容易通过肉眼审查和单元测试兜底。我的体会是凡是“模板化、模式化、逻辑重复”的代码都可以放心交给 Vibe Coding比如外设驱动的框架、协议解析的骨架、日志模块、环形缓冲区、状态机框架。这些项目差异不大AI 见得多生成的代码质量相当稳定。3.2 省力场景二测试桩和调试脚本嵌入式开发里有一类工作非常痛苦但又不值钱写测试桩stub、写 mock、写 Python 脚本解析二进制日志、写一个小工具把寄存器 dump 转成可读的 CSV。这类工作技术含量不高但非常耗时间而且跟硬件本身没有直接关系纯粹是开发效率工具。这个领域我觉得 Vibe Coding 目前表现得近乎完美。我给 AI 描述“我有一个二进制 log 文件每条记录包含时间戳、事件 ID、两个 uint16 参数帮我写个 Python 脚本解析成 CSV顺便统计每个事件 ID 出现的次数”它很快就能给我一个可以运行的脚本。这种任务需求清晰、环境简单、反馈快出了问题日志一看就懂完全不涉及物理世界的风险。我目前的工作流里凡是跟“测试、构建、日志分析”相关的脚本已经习惯性地先让 AI 出一版我再改改边界条件。这部分省下来的时间保守估计每周有三四个小时。3.3 翻车现场一时钟树的“一本正经胡说八道”前面说的都是好消息接下来聊聊差点把项目带沟里的案例。某次需要为一块新板子配置系统时钟我把主频目标、外部晶振频率、锁相环配置需求告诉了 AIAI 很自信地生成了一段初始化代码。我拿过来审了一遍表面上寄存器地址都对逻辑也没毛病。但等我对着芯片手册逐条核对分频系数的时候发现它把 PLL 的倍频值设定得非常激进等效系统主频直接超了芯片规格上限 20%。如果这段代码烧进去轻则系统不稳定重则芯片直接锁死。后来我复盘了一下AI 为什么会在这种地方出错一是它没有当前芯片的完整手册只是凭训练数据里的相似型号做外推二是我给出的自然语言需求里没有包含“该型号 PLL 倍频范围是 8 到 32”这样的硬件约束。它并不是故意犯错而是在信息不完整的情况下选择了统计上最“常见”的做法而“常见”不等于“正确”。这个案例给我的教训非常深刻Vibe Coding 在嵌入式里最大的风险不是代码写得烂而是它因为信息缺失而产生“自信的幻觉”这种幻觉对人的欺骗性比明显的错误大得多。3.4 翻车现场二把“应用层思维”带进了中断上下文还有一个更隐蔽的翻车案例。当时我需要写一个在中断服务函数里执行的 FIFO 入队逻辑要求不能阻塞、不能调用任何不可重入的函数。我把需求描述给 AI结果生成了一段在雨点大的中断里打印日志的代码还用了printf。如果在 PC 上用问题不大内部缓冲慢一点而已但在嵌入式的中断上下文里调用一个阻塞型日志函数可能直接造成实时性灾难甚至导致系统崩溃。这个案例让我意识到AI 默认的“正确代码”是从通用软件语境里学来的它不会主动考虑中断延迟、临界区保护、可重入性这些嵌入式特有的约束。除非你把约束条件非常显式地写进 prompt否则它就会按照应用层开发的默认值来生成代码。3.5 一张表总结能省力和要避开的场景适合交给 Vibe Coding 的环节必须保持人工把控的环节驱动框架、寄存器读写模板时钟树与电源管理配置协议解析、状态机骨架中断上下文与临界区逻辑单元测试、mock 与测试桩低功耗模式切换与唤醒日志分析、构建脚本、小工具安全关键功能如刹车、气囊数据手册章节的有效信息抽取硬件时序的最终验证与确认这张表是我个人实践的总结只代表我所在领域的经验不同行业比如消费电子和车规级的要求差异很大但核心原则是一致的越靠近硬件物理约束、越靠近不可逆风险的地方越需要人来兜底。4. 嵌入式工程师的“Vibe Coding 正确姿势”把模糊需求变成可验证的约束4.1 核心心法先写硬件约束规格再让 AI 干活经过前面这些成功和翻车我总结出了一套目前用下来最稳的工作流核心只有一句话不要让 AI 替你做硬件决策只让 AI 帮你做代码实现。具体操作是在跟 AI 对话之前我先把下面这些信息整理成一个结构化约束清单芯片具体型号、编译工具链版本、目标架构关键寄存器地址与位域定义直接从手册复制时钟频率、外设总线分配、中断优先级规划代码执行的上下文普通线程、中断、低功耗哪些函数不允许被调用阻塞、不可重入、动态内存分配启动文件或链接脚本是否需要保持现有结构不动这个清单看起来繁琐但它是把“vibe 的模糊意图”翻译成“AI 可理解的精确规格”的关键步骤。一开始你会觉得多花了几分钟但换来的是 AI 生成代码的准确率大幅提升后续审查时间反而缩短很多。举一个实际例子同样是要求 AI 生成一个 SPI 初始化函数以前的 prompt 可能是“帮我写个 SPI 初始化时钟 8MHz”结果它给你生成一个标准库版本在你的寄存器级裸机项目里根本不能编译现在的 prompt 是“在 STM32F103 上使用寄存器操作APB2 时钟为 72MHz配置 SPI1 为主模式、时钟极性低、相位第一边沿、8 位数据、最高速率不超过 8MHz分频因子设为 8”这样 AI 生成的代码基本能直接用。4.2 用“约束注入”训练自己的 AI 工作流我还养成了一个习惯每做一个新项目先把该芯片的参考手册关键章节时钟树、GPIO 复用表、外设寄存器映射复制成文本文件作为“项目知识库”。跟 AI 对话时把相关片段粘贴进上下文。很多模型的上文窗口已经能容纳几万字足够放下一颗 MCU 最核心的配置信息。但这里要注意一个细节AI 并不会自动“读”你给的手册片段它只是把这些文本当作上下文来生成代码。所以你需要明确告诉它“使用我提供的寄存器定义不要使用你印象中的标准库定义”并且让它针对不确定项提问。这种显式的指令比泛泛地说“帮我写一个驱动”有效得多。我建议每个嵌入式团队建立一套 prompt 模板包含上述约束清单的固定格式。新人上手时只要照着模板填参数AI 生成代码的质量就能稳定。这本质上是把 Vibe Coding 从“靠运气”变成“靠流程”。4.3 验证环节静态分析 代码审查 硬件在环AI 生成的代码在嵌入式场景里必须过三道关缺一不可。第一道关是静态检查。用编译器的-Wall -Werror、cppcheck或clang-tidy扫一遍能挡掉大量未初始化变量、类型不匹配、隐式转换等问题。这道关最便宜效果也最直接。第二道关是人工代码审查。我一般重点审查的是中断保护是否覆盖临界区、寄存器配置是否与目标芯片完全匹配、是否有不符合项目规范的接口调用比如在中断里用了printf、在低功耗路径里用了阻塞延时。AI 生成的代码往往逻辑通顺但规范层面的坑很多需要人来纠正。第三道关是硬件在环验证。这一步没有任何替代方案。你可以用单元测试覆盖纯逻辑部分但只有把代码跑在真实硬件上通过逻辑分析仪、示波器确认信号时序满足规格才算是真正验证过了。AI 写不出“时序匹配”它写出来的代码只是一个静态文本而硬件验证是物理世界的最终裁决。4.4 工具选型的实操体会到目前这个阶段我试过的工具包括 GitHub Copilot、ChatGPT、Claude 和 Codex 的编程模式各有各的用法GitHub Copilot 适合在编辑器里写代码时做局部补全但它对项目整体结构理解有限容易“小修小补”不太适合让它独立完成一个大模块。ChatGPT 或 Claude 这类会话式工具适合把一个完整需求描述给它让它在一次回复里输出完整模块。它的优点是上下文管理方便缺点是你需要格外注意它是否“记住”了你提供的硬件约束。Codex 这类偏智能体agent的工具适合自动执行多步骤任务比如“读完这个目录下的头文件然后给每个外设生成驱动初始化代码”。但它跑链路越长风险越高我会非常谨慎地使用每一步都会人工检查。我不太建议嵌入式新手一上来就用 vibe 工作流填满整个项目。更好的方式是先从脚本和测试桩这种低风险任务开始逐步建立对“AI 输出质量”的判断力再慢慢扩大使用范围。5. 更深一层的思考Vibe Coding 会冲击嵌入式岗位的价值吗5.1 我的判断短期不会但能力模型一定会变嵌入式社区里最近有一种焦虑AI 连代码都能写了我们这些“写代码的人”是不是要失业我的看法是短期来看嵌入式岗位不仅不会贬值反而会因为“能落地的物理系统”越来越稀缺而更有价值但长期来看嵌入式开发者的核心能力模型一定会发生明显迁移。为什么短期不会因为嵌入式开发的价值从来不在代码本身而在于对物理世界约束的理解和折中。AI 可以替你写出一个 PID 控制算法的实现但它不知道你的电机最大允许电流是多少不知道你的控制周期是 1kHz 还是 100Hz不知道你的机构是皮带传动还是齿轮传动更不知道机械谐振频率落在哪里。这些知识只有长期在项目里的人才能积累AI 无法从互联网的训练数据里学到你所在团队特定产品独有的物理特性。而长期看Vibe Coding 会把“编码”这个环节的稀缺性进一步压低。一个嵌入式新人刚入行时干的活——照着芯片手册写寄存器初始化、写外设驱动、写协议解析——会越来越多地被 AI 接管。这一层本来也是可替代性最高的部分。新人如果只停留在“我能调通 I2C 时序”这个水平确实会感受到压力。但如果他能往上走一层理解“为什么这条 I2C 总线要这样配置、为什么传输速率限制在这个值、这个传感器在整个系统里扮演什么角色”那他就依然具备 AI 无法替代的系统级判断力。5.2 嵌入式工程师的新壁垒定义问题、拆解约束、验收结果Vibe Coding 时代最能拉开差距的能力不再是敲码速度而是下面三种一是定义问题的能力。场景描述越模糊AI 生成的代码越危险场景描述越精确AI 生成的代码越可用。能够把客户一句“设备偶尔重启”翻译成“需要在低功耗模式下检查看门狗喂狗时序、确认中断唤醒后各外设时钟是否稳定”的人才是真正在推动项目前进的人。二是拆解约束的能力。一块板子上同时跑着电机控制、无线通信、用户交互时序上互相牵扯。你能不能判断哪些任务必须用中断、哪些必须放到线程里、哪些可以在低优先级下轮询这种约束拆解AI 给不了你标准答案因为正确答案和你的硬件方案强相关。三是验证结果的能力。AI 生成的代码几乎不可能一次就满足嵌入式项目的可靠性要求你需要设计测试用例、构造异常情况、做故障注入去检验它在极端条件下是否还能保持稳定。在嵌入式领域“能跑”和“可靠”之间隔着十个量级这个鸿沟需要人来填。5.3 给新入行者的建议先学“不带 vibe 的功底”再享受 vibe 的便利我一直很反对那种“反正以后 AI 写代码我不用学了直接让它写就行”的想法在嵌入式领域尤其危险。原因很简单你连“正确代码长什么样”都不知道你怎么判断 AI 给你的是不是幻觉你连“这条时序为什么要求 setup 时间 100ns”都不理解你怎么知道 AI 生成的延时是不是恰好覆盖了规格所以我的建议是新手阶段一定要亲手从头到尾写过一个完整的驱动、调过一块裸板、踩过几个系统跑飞的坑之后再开始用 Vibe Coding。这就像学车老司机可以用辅助驾驶但新手如果一上来就依赖辅助驾驶一旦系统误判连基本的方向盘控制感都没有。等你有了一定的判断力再让 AI 帮你提效它就会变成你手里的一把好工具。反过来如果跳过了基础训练Vibe Coding 对你来说就不是效率工具而是一台盲盒生成机。6. 关于“Vibe Coding 时代的嵌入式”最后几句大实话说实话我自己对 Vibe Coding 的心态经历了三个阶段一开始觉得是噱头后来在某些场景被它惊艳到再后来被它的幻觉坑过一次才慢慢找到跟它和平共处的方式。现在我的项目里已经常态化了 AI 辅助但我不会把“vibe coding”当成一种放松警惕的理由。在嵌入式这里正确的说法应该是“vibe then verify”——跟着感觉生成然后极其严格地验证。最后分享一个我自己的小习惯每让 AI 生成一段嵌入式代码我都会顺手写几条“它可能错在哪里”的检查清单存到项目的 doc 目录里。比如AI 是否可能误用了更高主频的配置是否可能在中断里调了不可重入函数是否可能在临界区里加了阻塞延时这个习惯后来成了团队新人的 review 模板比单纯让 AI 写代码有价值得多。AI 不会让嵌入式开发消亡物理世界永远需要有人去理解、去配置、去兜底。但 AI 一定会淘汰那些只会“照着手册敲寄存器”的人然后把省下来的时间留给善于定义问题、拆解约束和验证结果的人。趁着还在这个行业里我们确实应该认真想想自己的下一个不可替代点到底在哪一层。