嵌入式开发这个圈子过去十几年一直有个不成文的规矩你得先把数据手册翻烂把寄存器位定义背熟把时序图刻在脑子里然后才有资格说“我会做嵌入式”。但最近一两年尤其是大模型编程能力突飞猛进之后一种叫 Vibe Coding 的工作方式开始在开发者社区里蔓延开来。我第一次听到这个词的时候直觉是排斥的——嵌入式开发讲究的是确定性时钟周期、中断延迟、内存对齐哪一样容得下“凭感觉”但后来我实际试了几次用自然语言描述需求让模型生成底层驱动框架、配置寄存器、甚至写状态机我发现事情没那么简单。Vibe Coding 不是让你放弃底层理解而是把“查手册、抄例程、调参数”这些重复劳动交给模型你自己专注于系统架构和关键决策。这篇文章我想把这段时间的实践和思考完整地聊一聊包括它到底适合嵌入式的哪些环节、哪些环节绝对不能碰、以及我踩过的那些坑。如果你是在做嵌入式 Linux 驱动、裸机开发、或者 Qt 应用层开发这篇文章应该能给你一些直接能用的参考。1. 先搞清楚 Vibe Coding 在嵌入式语境下到底指什么1.1 不是“让 AI 帮你写代码”这么简单很多人把 Vibe Coding 理解成“用自然语言让 AI 生成代码”这个理解太浅了。如果只是这样那它跟几年前就有的代码补全工具没什么本质区别。Vibe Coding 的核心变化在于工作重心的转移你不再逐行敲代码而是用描述性的语言表达你的意图模型生成初版实现你负责审查、调试、修正方向。整个过程更像是在“引导”而不是“编写”。放到嵌入式开发里这个转变尤其微妙。因为嵌入式代码有一个特点它的正确性不只取决于逻辑还取决于硬件行为。你写一个 GPIO 翻转的代码逻辑上就是置位和清零但实际能不能跑取决于时钟有没有使能、引脚有没有复用成 GPIO 模式、输出速度配置是否匹配你的信号频率。模型生成的代码可能在逻辑上完全正确但硬件配置层面缺了关键几行你烧进去就是没反应。所以嵌入式场景下的 Vibe Coding我的定义是用自然语言驱动模型生成硬件抽象层和应用逻辑的初版代码开发者负责硬件相关的关键配置审查和系统级调试。模型帮你跳过的是“从零开始写”的阶段而不是“理解硬件”的阶段。1.2 为什么嵌入式社区对这件事反应这么分裂我观察到一个很有意思的现象做应用层开发的人对 Vibe Coding 接受度很高做底层驱动的人普遍持怀疑态度。这个分裂不是没有道理的。应用层开发比如用 Qt 做界面、用 Python 做数据处理这些工作的核心复杂度在业务逻辑和交互设计上硬件差异被操作系统和框架屏蔽得差不多了。模型见过大量的类似代码生成质量很高你改改就能用。但底层驱动开发不一样。每一颗芯片的寄存器定义都不同同一个外设在不同厂商的芯片上行为可能有细微差异中断控制器的配置方式更是千差万别。模型训练数据里虽然包含了不少驱动代码但覆盖度和准确性远不如应用层代码。更关键的是驱动代码出错往往不会给你一个漂亮的报错信息而是直接死机、跑飞、或者出现偶发性异常调试成本极高。我的判断是Vibe Coding 在嵌入式领域不是“能不能用”的问题而是“用在哪个层次”的问题。用对了地方效率提升非常明显用错了地方你花在调试上的时间可能比手写还多。1.3 一个真实的对比手写 vs Vibe Coding 的耗时差异我拿一个实际项目做过对比。需求是在 STM32 上实现一个 Modbus RTU 从机通过 UART 接收命令控制几路继电器输出同时支持参数掉电保存。手写的话我的流程大概是查 UART 配置寄存器、配波特率和中断、实现 Modbus 帧解析状态机、处理 CRC 校验、写 Flash 读写函数、处理超时和错误恢复。整个流程我大概需要一天半到两天其中大部分时间花在调试 UART 中断接收的边界情况和 Flash 写入的时序问题上。用 Vibe Coding 的方式我先用自然语言把需求拆成几个模块描述给模型UART 初始化配置、Modbus 帧解析、CRC16 计算、Flash 参数存储。模型在几分钟内生成了四个模块的初版代码。我花了一个小时审查代码发现 UART 初始化里漏了中断优先级配置Modbus 状态机对异常帧的处理不够健壮Flash 写入没有考虑页对齐。修正这些问题花了大概半天。最终整体耗时压缩到一天以内而且代码结构比我手写的更清晰。但这个对比有个前提我对 STM32 的 UART 和 Flash 操作非常熟悉所以能快速定位模型生成代码中的问题。如果是一个刚入门的开发者可能连模型哪里写错了都看不出来那 Vibe Coding 反而会带来更大的风险。2. 嵌入式 Linux 驱动开发中 Vibe Coding 的实际边界2.1 字符设备驱动模型能帮你省掉大量模板代码嵌入式 Linux 驱动开发里字符设备驱动是最常见的一类。传统的写法你需要实现 file_operations 结构体、注册设备号、实现 open/read/write/ioctl、处理并发和同步。这些代码有很强的模板性模型生成的质量相当不错。我试过让模型生成一个基于 miscdevice 的字符设备驱动框架描述是“一个提供寄存器读写接口的字符设备支持 ioctl 命令读写 32 位寄存器需要处理并发访问”。模型生成的代码包含了 misc_register、file_operations 实现、mutex 保护、copy_to_user/copy_from_user 的正确使用。我检查了一遍除了 ioctl 命令号的 _IOR/_IOW 方向定义需要根据实际情况调整之外其他部分基本可以直接用。这里的关键在于字符设备驱动的框架是高度标准化的模型在训练数据里见过大量类似的代码所以生成质量有保障。你省掉的是查内核 API、回忆结构体成员、处理错误码这些琐碎工作。2.2 设备树配置模型容易忽略硬件实际约束设备树是嵌入式 Linux 开发中模型表现比较差的一个环节。原因很简单设备树的正确性依赖于具体的硬件连接而模型不知道你的板子上 I2C 设备挂在哪个控制器下、中断引脚接的是哪个 GPIO、时钟源是什么。我让模型生成过一个 I2C 温度传感器的设备树节点描述是“I2C1 上挂了一个地址为 0x48 的温度传感器中断引脚接到 GPIO1_IO12”。模型生成的节点结构是对的compatible 字符串、reg 属性、interrupt-parent 和 interrupts 都写出来了。但问题是interrupts 属性的值需要根据具体的中断控制器映射来计算模型给的是一个通用值实际用的时候中断根本触发不了。设备树这块我的经验是让模型生成结构和属性名的框架但所有跟硬件相关的数值——寄存器地址、中断号、时钟频率、GPIO 编号——必须自己查手册确认。模型可以帮你记住“要写哪些属性”但不能帮你确定“属性值是多少”。2.3 内核模块的并发与同步模型给的方案需要仔细审查并发处理是驱动开发中最容易出问题的部分。自旋锁、互斥锁、原子操作、RCU、完成量选哪种机制取决于具体的上下文和性能要求。模型在这方面给出的建议往往偏保守倾向于用 mutex 解决所有问题。但在中断上下文里mutex 是不能用的因为中断处理程序不能睡眠。我遇到过模型在一个中断处理函数里生成了 mutex_lock 的调用这在编译时不会报错但运行时如果中断触发时锁已经被持有系统直接死锁。这类问题需要你对内核的并发机制有清晰的理解才能发现。我的做法是让模型生成代码后专门检查所有涉及共享资源访问的地方确认锁的类型和上下文匹配。中断上下文用自旋锁或原子操作进程上下文可以用 mutex读多写少的场景考虑 RCU。这个检查过程不能省。2.4 实际案例用 Vibe Coding 加速一个 SPI 屏幕驱动我最近用 Vibe Coding 的方式给一块 SPI 接口的 TFT 屏幕写驱动整个过程大概花了三个小时其中模型生成代码只用了十几分钟剩下的时间都在调试硬件时序。我的操作流程是这样的先给模型描述屏幕的控制器型号、分辨率、SPI 模式、初始化序列的大致流程让它生成一个 fbtft 框架下的驱动初版。模型生成的代码包含了 probe 函数、SPI 传输封装、初始化命令序列的发送逻辑。然后我根据屏幕手册调整了初始化序列中的参数修正了 SPI 模式配置模型默认给了 Mode 0实际屏幕需要 Mode 3调整了复位时序的延时。最终驱动跑起来的时候屏幕正常点亮framebuffer 读写也正常。如果完全手写我估计需要一整天因为初始化序列那几十条命令的格式虽然手册里有但逐条敲进去很费时间模型帮我省掉了这部分机械劳动。3. 裸机开发场景Vibe Coding 能做什么、不能做什么3.1 外设初始化代码模型是高效的“寄存器配置助手”裸机开发最繁琐的部分就是外设初始化。以 STM32 的定时器为例你需要配置预分频器、自动重装载值、计数模式、输出比较通道、PWM 模式、死区时间、刹车功能等等。这些配置项在参考手册里分散在好几个章节每次写都要翻半天。用 Vibe Coding 的方式你可以直接描述“TIM1 通道 1 输出 PWM频率 20kHz占空比 50%系统时钟 72MHz死区时间 500ns”模型会帮你算出预分频器和重装载值生成完整的初始化代码。我验证过几次计算逻辑基本正确生成的代码结构也很清晰。但这里有个前提你得告诉模型系统时钟频率。如果你没说模型会默认一个值算出来的频率就不对。另外死区时间的计算涉及到具体的时钟分频配置模型有时候会算错需要你自己复核。3.2 中断服务程序模型生成的框架需要你补充关键逻辑中断服务程序的框架是标准化的保存上下文、清除中断标志、处理业务逻辑、恢复上下文。模型生成这部分代码没有问题。但关键的业务逻辑比如“收到特定数据后触发什么动作”“异常情况下如何恢复”这些需要你根据具体需求来补充。我让模型生成过一个 UART 接收中断的处理程序描述是“接收不定长数据超时后触发帧解析”。模型生成了中断服务函数、环形缓冲区管理、超时定时器回调。但环形缓冲区的读写指针在中断和主循环之间共享模型没有加任何保护。在单核 MCU 上如果主循环读缓冲区的时候被中断打断而中断又写了缓冲区就可能出现数据不一致。这个问题需要你自己识别并加上临界区保护。3.3 状态机实现Vibe Coding 表现最好的场景之一状态机是嵌入式开发中非常常见的模式也是我认为 Vibe Coding 表现最好的场景。因为状态机的逻辑可以用自然语言清晰地描述模型生成的状态机代码结构好、可读性高、容易修改。我做过一个项目需要实现一个简单的协议解析状态机处理帧头、长度、命令字、数据、校验和。我用自然语言把状态转移图描述给模型模型生成了一个基于 switch-case 的状态机实现每个状态的处理逻辑清晰边界条件也考虑到了。我只需要调整几个状态转移的条件就能直接集成到项目里。这个场景之所以效果好是因为状态机的逻辑是纯软件层面的不涉及硬件细节模型的训练数据里有大量类似实现生成质量自然高。3.4 时序敏感的代码不要让模型碰有些代码对时序要求极高比如软件模拟的 SPI、I2C 时序或者精确的延时循环。这类代码的正确性依赖于具体的 CPU 频率、编译器优化等级、甚至指令流水线行为。模型生成的代码在逻辑上可能没问题但实际跑起来时序完全不对。我试过让模型生成一个软件 I2C 的起始条件时序模型给的代码是标准的“拉低 SDA、拉低 SCL、拉高 SCL、拉高 SDA”流程但没有任何延时。在实际硬件上这个时序太快了从机根本来不及响应。你需要根据从机的时间要求插入合适的延时而延时的具体值需要你自己测量和调整。我的原则是涉及时序精确控制的代码模型可以生成框架但所有延时参数、时钟配置、信号采样点必须自己根据手册和实测来确定。这部分没有捷径。4. 应用层开发是不是嵌入式Vibe Coding 在 Qt 和上层逻辑中的表现4.1 Qt 应用开发模型生成质量超出预期很多人讨论“应用层开发是不是嵌入式”的时候其实是在纠结技能树的问题。但从 Vibe Coding 的实践角度来看Qt 应用开发恰恰是嵌入式项目中模型表现最好的部分。我让模型生成过一个基于 Qt5 的串口调试助手界面描述是“左侧串口配置面板右侧数据收发区支持 HEX 和 ASCII 显示切换定时发送功能”。模型生成的代码包含了 UI 布局、信号槽连接、串口读写、数据格式转换。我编译运行后界面布局基本符合预期功能也都能用只需要调整一些样式细节。这个场景下模型表现好的原因很直接Qt 的 API 稳定、文档完善、社区代码量大模型在训练数据里见过大量 Qt 项目代码。而且 Qt 应用开发不涉及硬件寄存器操作纯软件逻辑的复杂度模型完全能驾驭。4.2 数据处理与协议解析模型是高效的“算法实现者”嵌入式项目里经常需要处理传感器数据、解析通信协议、做滤波和校准。这些工作的核心是算法逻辑模型在这方面表现相当不错。我让模型实现过一个滑动窗口滤波加卡尔曼滤波的组合用于处理 IMU 数据。模型生成的代码包含了滤波器的初始化、更新步骤、参数配置接口。我只需要根据实际传感器的噪声特性调整过程噪声和测量噪声参数就能直接使用。如果手写的话卡尔曼滤波的矩阵运算和更新公式很容易写错模型帮我省掉了推导和调试的时间。4.3 跨平台构建与部署模型能帮你写 CMake 和脚本嵌入式 Qt 项目的构建系统配置往往很繁琐交叉编译工具链、sysroot 路径、依赖库查找每一项都可能出问题。模型在生成 CMakeLists.txt 和构建脚本方面表现不错能帮你快速搭起框架。我让模型生成过一个针对 ARM 平台的 Qt5 交叉编译 CMake 配置描述是“使用 arm-linux-gnueabihf 工具链Qt5 安装在 sysroot 中需要链接 serialport 和 widgets 模块”。模型生成的 CMakeLists.txt 结构清晰工具链文件也基本正确。我只需要根据实际的工具链路径调整几个变量就能正常构建。4.4 应用层与驱动层的边界Vibe Coding 让边界更清晰有意思的是Vibe Coding 的实践反而让我更清楚地看到了应用层和驱动层的边界。模型在应用层代码上表现好在驱动层代码上需要大量人工审查这个差异本身就说明了两个层次的本质不同。应用层的复杂度在业务逻辑和交互设计这些可以用自然语言清晰描述模型也能生成高质量代码。驱动层的复杂度在硬件行为和时序约束这些很难用自然语言完整表达模型也缺乏足够的硬件上下文来保证正确性。所以“应用层开发是不是嵌入式”这个问题我的回答是它是嵌入式系统的一部分但它的开发方式和纯应用软件开发更接近Vibe Coding 在这里的适用性也更高。如果你在做嵌入式 Qt 开发完全可以放心地把大部分界面和业务逻辑交给模型生成自己专注于系统集成和性能优化。5. 我踩过的坑和总结出的实操原则5.1 模型生成的寄存器配置代码不能直接烧录这是我踩过的第一个坑也是最危险的一个。模型生成的寄存器配置代码在语法上完全正确编译也能通过但实际烧录后外设就是不工作。原因往往是某个关键的控制位没有置位或者时钟使能顺序不对。我的做法是模型生成的每一行寄存器操作代码都要对照参考手册确认。特别是时钟使能、引脚复用、外设使能这三个步骤的顺序不同芯片要求不同模型经常搞混。这个审查过程很枯燥但省不掉。5.2 中断优先级和嵌套配置容易被忽略模型生成中断相关代码时往往只关注中断服务函数的逻辑忽略了中断优先级配置和嵌套控制。在多中断系统中优先级配置错误会导致中断响应顺序不符合预期甚至出现中断丢失。我现在会让模型生成代码后专门检查 NVIC 配置部分确认优先级分组、抢占优先级和子优先级的设置是否符合系统需求。这个检查项我已经加入了固定的审查清单。5.3 内存对齐和字节序问题在通信协议中频繁出现嵌入式通信协议里结构体直接映射到字节流是很常见的做法但这里有两个坑内存对齐和字节序。模型生成的代码往往假设结构体是紧凑排列的但实际上编译器会插入填充字节。另外网络字节序和主机字节序的转换也容易被遗漏。我的处理方式是所有涉及通信的结构体都显式使用attribute((packed)) 或者手动序列化不依赖编译器的默认对齐。字节序转换用标准宏 htons/ntohs 处理不自己写转换逻辑。5.4 模型对芯片特有功能的支持有限不同厂商的芯片有很多特有的功能比如 STM32 的硬件 CRC、DMA 双缓冲、定时器的编码器模式等。模型对这些特有功能的支持程度参差不齐有些能正确生成有些会给出错误的配置。我的经验是对于芯片特有的功能先让模型生成一个初版然后对照官方例程和参考手册逐项核对。如果模型生成的代码和官方例程差异较大以官方例程为准。不要盲目相信模型对特定芯片外设的理解。5.5 版本兼容性是隐藏的雷区嵌入式开发中芯片型号的版本、库的版本、编译器的版本都会影响代码的正确性。模型训练数据里的代码可能来自不同版本生成的代码可能混用了不同版本的 API。我遇到过模型生成的 HAL 库代码混用了不同版本的函数签名编译时报了一堆错误。后来我养成了一个习惯在描述需求时明确指定芯片型号、库版本、编译器版本让模型在限定的范围内生成代码。这样虽然不能完全避免版本问题但能减少很多。6. 嵌入式开发者该怎么定位 Vibe Coding 这件事6.1 它改变的是工作流不是知识门槛我反复强调一个观点Vibe Coding 降低的是编码的体力成本不是嵌入式的知识门槛。你仍然需要理解时钟树、中断机制、内存映射、通信协议只是这些知识不再需要通过逐行敲代码来体现而是体现在你审查模型代码、定位问题、做架构决策的能力上。对于刚入门的开发者我的建议是不要一上来就用 Vibe Coding。先用传统方式完整地做过几个项目把底层的东西摸清楚然后再引入模型来加速。否则你连模型哪里写错了都看不出来调试成本会高到让你怀疑人生。6.2 最合理的分工模型做初版人做审查和集成经过这段时间的实践我形成了一套比较稳定的工作流先用自然语言把需求拆解成模块让模型生成每个模块的初版代码然后逐模块审查重点检查硬件配置、并发处理、边界条件接着在开发板上实际测试根据测试结果修正最后做系统集成和性能优化。这个流程里模型承担了大概百分之六十到七十的编码工作量我承担了全部的设计决策、代码审查、调试和集成工作。整体效率比纯手写提升了大概百分之三十到四十而且代码质量没有下降。6.3 哪些能力在 Vibe Coding 时代反而更重要了模型能生成代码之后有几项能力反而变得更关键了。第一是代码审查能力你得能快速看出模型生成的代码哪里有问题。第二是调试能力模型生成的代码出问题时你需要有系统的排查思路。第三是架构设计能力模型可以写模块但模块怎么划分、接口怎么定义、系统怎么集成这些需要你来决策。还有一项容易被忽略的能力是“精确描述需求”。你用自然语言描述得越精确模型生成的代码质量越高。这其实是一种新的编程能力把硬件需求翻译成清晰的文字描述让模型能准确理解。6.4 对嵌入式教育和学习路径的影响我观察到的一个趋势是嵌入式学习的路径正在发生变化。过去的学习路径是“先学寄存器操作再学库函数最后学框架”现在可能变成“先理解系统架构和外设原理然后用模型生成底层代码自己专注于调试和优化”。这个变化对初学者来说既是机会也是挑战。机会在于入门门槛降低了你可以更快地做出能跑的东西。挑战在于如果你跳过了底层理解的阶段后面遇到复杂问题时就会缺乏排查能力。我的建议是用模型加速项目开发但底层知识的学习不能跳过该看的参考手册还是要看该做的实验还是要做。7. 一个完整的实操示例用 Vibe Coding 加速 STM32 项目开发7.1 项目需求拆解与模块划分我拿一个实际做过的项目来完整演示一遍。需求是在 STM32F103 上实现一个环境监测节点采集温湿度传感器数据通过 UART 上报支持命令配置采集间隔参数掉电保存。我把这个需求拆成五个模块传感器驱动、UART 通信、命令解析、参数存储、主循环调度。每个模块我用一段自然语言描述给模型让它生成初版代码。传感器驱动模块的描述是“DHT11 温湿度传感器单总线协议GPIO 推挽输出需要微秒级延时读取 40 位数据包含湿度整数、湿度小数、温度整数、温度小数、校验和”。模型生成的代码包含了 GPIO 方向切换、微秒延时、位读取、校验和验证。我检查后发现延时函数需要根据实际系统时钟调整其他部分基本可用。7.2 关键模块的代码审查要点UART 通信模块模型生成了基于中断的收发代码。我重点检查了三点中断优先级配置是否正确、环形缓冲区的读写指针是否有并发保护、错误处理是否完整。发现环形缓冲区的写指针在中断中更新读指针在主循环中更新模型没有加内存屏障在 Cortex-M3 上虽然因为强内存模型不太会出问题但加上 volatile 和临界区保护更稳妥。命令解析模块模型生成了基于状态机的解析器。我检查了状态转移的完整性特别是异常帧的处理。模型对帧长度超限的情况没有处理我补充了长度校验和缓冲区溢出保护。参数存储模块模型生成了基于 Flash 的读写代码。我检查了页对齐、写入前的擦除、写入后的校验。模型生成的代码在写入前没有擦除页直接写会失败这个必须修正。7.3 集成测试中暴露的问题和修复过程五个模块单独测试都通过后集成到一起跑出现了两个问题。第一个是 UART 接收偶尔丢数据排查后发现是命令解析模块的处理时间过长导致 UART 中断被延迟响应。我把命令解析移到主循环中处理中断只负责收数据问题解决。第二个问题是 Flash 写入时系统会卡顿因为 Flash 擦写期间 CPU 取指会暂停。我把参数保存操作放到系统空闲时执行并且写入前先关闭全局中断写入后恢复减少了卡顿的影响。这两个问题都不是模型生成的代码本身的错误而是模块集成后出现的系统级问题。这恰好说明了 Vibe Coding 的边界模型可以帮你写模块但系统集成和优化需要你自己来做。7.4 最终代码结构与效率对比最终项目的代码结构是main.c 负责初始化和主循环调度dht11.c/h 负责传感器驱动uart.c/h 负责通信cmd_parser.c/h 负责命令解析param.c/h 负责参数存储。每个模块的接口清晰耦合度低。整个项目从开始到完成我花了大概两天时间。如果完全手写我估计需要三到四天。效率提升主要来自模型生成的模板代码和标准逻辑我节省了查 API、写框架、处理边界条件的时间。但调试和集成的时间并没有减少太多因为这部分工作依赖的是对系统的理解和排查经验模型帮不上忙。8. 关于 Vibe Coding 和嵌入式开发的一些个人判断8.1 短期内它不会取代嵌入式工程师我听到过一些声音说 Vibe Coding 会让嵌入式工程师失业我的判断是短期内不会。原因很简单嵌入式开发的复杂度不只在于写代码更在于理解硬件、调试系统、做工程决策。模型可以生成代码但它不理解你的板子上实际发生了什么不知道信号完整性有没有问题不知道电源纹波会不会导致复位。而且嵌入式项目的调试往往需要示波器、逻辑分析仪、调试器这些工具需要你在物理世界里排查问题。这些工作模型目前完全做不了。所以嵌入式工程师的价值不会因为 Vibe Coding 而降低反而会因为模型接管了编码工作让你有更多时间做更有价值的事情。8.2 它正在改变嵌入式项目的开发节奏虽然不会取代工程师但 Vibe Coding 确实在改变开发节奏。过去一个嵌入式项目的前期大量时间花在搭框架、写驱动、调通外设上。现在这部分时间被压缩了你可以更快地进入系统集成和优化阶段。这个变化带来的影响是项目前期的迭代速度变快了你可以更快地验证想法、调整方案。但同时也意味着如果你在前期没有做好架构设计后期集成时的问题会暴露得更早、更集中。所以架构设计的重要性反而提升了。8.3 对工具链和开发环境的影响Vibe Coding 的普及也在影响嵌入式的工具链。现在越来越多的 IDE 和编辑器开始集成模型能力你可以在写代码的时候直接让模型生成片段、解释代码、查找问题。交叉编译、烧录、调试这些环节也在逐步和模型工具打通。我目前的使用方式是在 VS Code 里集成模型插件写代码时随时调用。对于嵌入式开发来说模型工具和调试器的结合还不够紧密比如模型还不能直接读取调试器的变量值来辅助排查问题。但我预计这个方向会快速发展。8.4 给不同阶段嵌入式开发者的建议如果你刚入行我的建议是先把基础打牢寄存器操作、中断处理、通信协议这些核心知识必须扎实。然后用 Vibe Coding 来加速你的练习项目但每生成一段代码都要自己审查和理解不要直接复制粘贴。如果你有几年经验可以开始把重复性高的编码工作交给模型自己专注于架构设计和系统调试。同时要注意保持对底层细节的敏感度不要因为长期不手写代码而生疏了。如果你在做团队管理可以考虑在团队内建立 Vibe Coding 的使用规范明确哪些环节可以用模型生成、哪些必须人工审查、代码审查的检查清单是什么。这样既能提升效率又能控制风险。8.5 我目前的工作流和工具选择最后分享一下我目前的工作流。我用的编辑器是 VS Code集成了模型插件用于代码生成和解释。对于嵌入式项目我通常先用模型生成模块框架然后在本地用交叉编译工具链构建烧录到开发板上测试。调试用 J-Link 配合 Ozone逻辑分析仪用 Saleae。模型生成代码时我会在描述里明确芯片型号、库版本、编译器版本并且要求模型给出关键配置的计算过程。生成后我会逐行审查硬件相关部分然后在开发板上做单元测试。这个流程目前运行得比较顺畅效率提升明显代码质量也稳定。如果你也在尝试 Vibe Coding 做嵌入式开发我的核心建议是把模型当成一个知识面很广但缺乏硬件上下文的助手。它能帮你快速写出结构良好的代码但硬件相关的每一个决策你都要自己把关。这个边界守住了Vibe Coding 就是提效利器守不住它就是埋雷工具。