Vibe Coding遇到嵌入式开发：真实场景、翻车风险与工程师新定位

最近公司内部有个特别有意思的割裂画面：应用层的同事开周会时来一句“今天下午 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 翻车现场一：时钟树的“一本正经胡说八道”

前面说的都是好消息，接下来聊聊差点把项目带沟里的案例。某次需要为一块新板子配置系统时钟，我把主频目标、外部晶振频率、锁相环配置需求告诉了 AI，AI 很自信地生成了一段初始化代码。我拿过来审了一遍，表面上寄存器地址都对，逻辑也没毛病。但等我对着芯片手册逐条核对分频系数的时候，发现它把 PLL 的倍频值设定得非常激进，等效系统主频直接超了芯片规格上限 20%。如果这段代码烧进去，轻则系统不稳定，重则芯片直接锁死。

后来我复盘了一下，AI 为什么会在这种地方出错：一是它没有当前芯片的完整手册，只是凭训练数据里的相似型号做外推；二是我给出的自然语言需求里，没有包含“该型号 PLL 倍频范围是 8 到 32”这样的硬件约束。它并不是故意犯错，而是在信息不完整的情况下，选择了统计上最“常见”的做法，而“常见”不等于“正确”。

这个案例给我的教训非常深刻：Vibe Coding 在嵌入式里最大的风险不是代码写得烂，而是它因为信息缺失而产生“自信的幻觉”，这种幻觉对人的欺骗性比明显的错误大得多。

3.4 翻车现场二：把“应用层思维”带进了中断上下文

还有一个更隐蔽的翻车案例。当时我需要写一个在中断服务函数里执行的 FIFO 入队逻辑，要求不能阻塞、不能调用任何不可重入的函数。我把需求描述给 AI，结果生成了一段在雨点大的中断里打印日志的代码，还用了printf。如果在 PC 上用，问题不大，内部缓冲慢一点而已，但在嵌入式的中断上下文里，调用一个阻塞型日志函数可能直接造成实时性灾难，甚至导致系统崩溃。

这个案例让我意识到：AI 默认的“正确代码”是从通用软件语境里学来的，它不会主动考虑中断延迟、临界区保护、可重入性这些嵌入式特有的约束。除非你把约束条件非常显式地写进 prompt，否则它就会按照应用层开发的默认值来生成代码。

3.5 一张表总结：能省力和要避开的场景

这张表是我个人实践的总结，只代表我所在领域的经验，不同行业（比如消费电子和车规级）的要求差异很大，但核心原则是一致的：越靠近硬件物理约束、越靠近不可逆风险的地方，越需要人来兜底。

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 一定会淘汰那些只会“照着手册敲寄存器”的人，然后把省下来的时间留给善于定义问题、拆解约束和验证结果的人。趁着还在这个行业里，我们确实应该认真想想：自己的下一个不可替代点，到底在哪一层。