企业官网建设流程全解析

Vibe Coding这个词，最近在嵌入式圈子里讨论度肉眼可见地高了起来。身边不少做Linux应用、跑Qt界面的同事都开始试水AI辅助开发，甚至直接丢给模型一个需求描述就把代码跑起来了。但做嵌入式底层、做板级驱动、做汽车电子的朋友，普遍反应比较保守：生成代码能不能过编译是一回事，上板能不能跑、跑起来稳不稳、中断能不能进、时序会不会崩，又是另一回事。

这种分野很有意思，也值得深入拆一拆。Vibe Coding强调随性、意图化、让模型去填大部分实现细节。嵌入式开发则一直强调确定性、边界、算力预算和硬件耦合。当这两种开发哲学撞在一起，既不是简单的“底层不适合用AI”，也不是“掌握新工具就躺赢”。真正值得聊的，是怎么给这个老行业引入一套适合它自身约束条件的AI协作范式。

1. 先搞清楚一件事：Vibe Coding到底在“低于哪一层”工作

“Vibe Coding”严格说不是一种编程语言，也不是什么IDE插件，它更接近一种人机协作的状态。Andrej Karpathy最早用这个词的时候，说的就是“我完全拥抱误差，我不逐行读代码，我描述意图，让模型写，然后我跑、我试、我反馈”。本质上是把编程从“按语法精确表达”变成了“用自然语言描述预期行为，再通过运行结果反向调节描述”。

这套工作流在应用层确实跑得通，原因很朴素：反馈回路极短。写个网页、写个Python脚本、写个业务接口，写完就能起服务，报错信息就在眼前，改一改重跑，几十秒一个循环。哪怕生成的东西第一次不能跑，第二次语法错，第三次逻辑错，第四次终于通了，整体成本依然低得可怕。模型不懂业务没关系，跑起来的行为就是最好的“老师”。

但嵌入式场景完全不是这个节奏。你写的不是一串跑在通用操作系统上的逻辑，而是跑在某个特定SoC或者MCU上的机器代码，旁边连着传感器、电机、屏幕、总线。程序的行为不是只由你的代码决定，还由电源时序、外设初始化顺序、时钟配置、中断优先级这些东西共同决定。更麻烦的是，一次迭代的反馈成本是按“编译→烧写→上电→观察→调试”来算的，遇到难缠的问题一次循环可能大半天。

所以很多嵌入式工程师一开始接触Vibe Coding时会有一种错位感：它看起来是为“无限低成本重试”设计的，而嵌入式最贵的东西恰恰就是重试。于是自然产生一个疑问：这工具到底能不能用在我的日常里？

我的标准答案是：能用，但用在哪里、用多深、怎么用，边界非常清楚。这背后是两条完全不同的工程逻辑。

2. 嵌入式开发的“确定性底色”，为什么Vibe Coding天生和它有点别扭

要理解什么场景能用，先得说清楚为什么很多场景用不了。这不是保守，而是嵌入式开发的物理底色决定的。

2.1 硬件不重试，生成代码没有“试错冗余”

应用层开发最大的恩赐是：错了重来成本低，甚至上线出bug也能靠快速迭代补救。但嵌入式代码一旦烧进去，面对的是实打实的外部世界。GPIO拉错了引脚可能烧掉驱动板，PWM占空比算错了可能让电机过流，Flash写时序不对可能把整个分区擦掉。硬件不给你“再来一次”的机会，这是和Web开发最本质的差异。

这带来的直接影响是：模型生成的代码“看起来合理”是不够的，必须“在特定硬件上、特定电参数下、特定时间要求内”都成立。而模型对硬件的理解是统计性的，它见过很多相似的寄存器配置和驱动写法，但没见过你的板子。你的电源纹波多大、晶振精度如何、外设有没有复用冲突，模型一概不知。让一个统计模型去猜硬件行为，然后把结果烧进Flash，这个决定本质上超出了AI能担保的范围。

2.2 资源预算不是风格偏好，是物理边界

做MCU开发的人都知道，RAM不是按G算的，是按KB算的。中断栈多个几百字节可能直接导致深嵌套时栈溢出。Flash空间不够，再漂亮的代码也进不了片内存储。AI生成代码最常见的毛病是什么？防御性代码泛滥。动不动就来两层if判断、各种结构体私有变量、冗余错误处理，这在PC上是优雅，在MCU上是慢性失血。

我试过让模型生成一个I2C从机的状态机，逻辑很清晰，注释也漂亮，但编译出来Flash增加了将近4K，RAM堆了2K多的全局状态。就为一个从机收发逻辑，这个代价在新唐和STM32的小容量型号上根本忍不了。Vibe Coding的“高冗余倾向”和嵌入式“以字节为单位的资源预算”天然冲突。

2.3 实时性要求：跑通不等于满足时序

嵌入式系统里大量逻辑是受时间约束的。CAN报文错过了时间槽就丢帧，控制环晚了几毫秒执行稳定性就崩了，中断服务程序里多塞一个函数调用就可能破坏硬实时保障。AI生成代码擅长的是“状态转换正确”，但不擅长“这个状态转换要在多少微秒内完成”。

举个实际例子，我之前让模型写一个电机编码器的正交解码读出逻辑。模型给了一个很好的状态机框架，用查表法判断方向，逻辑没毛病。但放上示波器一看，花了将近30个周期才完成一次完整判断，对于高频电机来说这个开销直接导致转速估算滞后。你让模型“优化”它可能给你换一个更聪明的查表算法，但它意识不到瓶颈出在中断入口处的寄存器保护。

换句话说，Vibe Coding能帮你实现“什么”，但很难帮你回答“多快”“多准”“多省”。后者恰恰是嵌入式系统量产之后真正要命的问题。

2.4 调试链路太长，单次反馈成本昂贵

Web开发里一个bug从出现到定位，往往就在IDE和浏览器之间。嵌入式调试呢？交叉编译后烧录，串口输出日志，逻辑分析仪挂总线，示波器量波形，有时候还要JTAG单步。就算一切顺利，一次完整的“代码改动→验证行为”周期也要以分钟甚至小时计。

Vibe Coding的调参式迭代，依赖的是高频反馈。反馈成本一旦上来，自然语言对话的效率会断崖式下降。你在一个循环里让模型改了三次，每次都要重新烧录验证，时间消耗就非常可观了。这不是工具不好用，是反馈链路本身的物理限制。

所以结论很清楚：越是靠近硬件的层，纯“Vibe”的空间越小；越是对确定性有严格要求的场景，越需要人去给模型“画边界”。但这不等于嵌入式就不能玩Vibe Coding，它只是要求我们把“Vibe”的颗粒度控制在一个合理的层。

3. 哪些嵌入式场景，实测真的适合引入Vibe Coding

在说“不适合”的时候容易陷入另一个极端，好像嵌入式就永远和AI辅助开发绝缘。我这一年半高频使用下来，反而觉得有几个场景的收益非常显著。关键是它们都具备同一类特征：反馈周期短、需求边界清晰、硬件交互弱。

3.1 Linux用户态应用：天然优质的Vibe区域

嵌入式Linux里的用户态程序，包括业务逻辑、协议解析、配置管理、日志处理、状态机调度，这些东西跑在操作系统之上，有完整的错误处理和调试手段。你对着一块开发板写一个MQTT上报逻辑，和对着一个普通服务器写一个网络服务，本质上没有太大区别。

这一类开发我是重度使用Vibe Coding的。比如写一个串口协议解析模块，我会直接把协议帧格式丢给模型，告诉它按状态机实现，要求正确处理帧头校验和超时。模型生成的帧解析逻辑在边界情况上往往比你手写骨架子时要细，尤其是超时处理、半包处理这种细节，它见过的模式比你多。

更关键的还有UI层。现在嵌入式产品大量用Qt做界面，用LVGL做屏显。这类工作的核心是把数据映射成呈现，再处理用户交互。上一轮我在做一个车载仪表盘项目时，整个显示逻辑框架就是靠对话搭出来的，从控件布局到信号槽连接再到刷新策略，AI全包了。我只需要把样式表、刷新率要求和状态转换约束讲清楚。

• 串口、网口、CAN等通信协议的数据解析、分包、会话管理
• 日志系统、状态上报、服务间通信的业务逻辑
• Qt / LVGL 界面布局、数据绑定、菜单状态机
• 嵌入式Linux下的配置解析（JSON / INI / YAML）
• 各种守护进程、超时重试、心跳机制

这些场景共同的特点是：问题边界清晰，输入输出可观测，出错了有运维手段兜底。和写一个普通后端服务没有本质差别，全力Vibe没问题。

3.2 测试桩与模拟器：AI生成增量最大的区域

嵌入式测试往往是整个行业最缺人的地方。板子还没回来要提前调上位机，硬件不稳定要模拟外设行为，自动化测试需要自动生成大量输入数据。这些事以前靠手写，耗时巨大。现在模型天生适合干这个。

我之前做传感器项目，需要一个模拟三轴加速度计数据的PC程序，用来提前验证算法模块。这个程序要求模拟不同运动模式下传感器输出波形，带噪声，偶尔产生丢帧异常。传统做法是手写一个带状态切换的数据生成器，工程量两三天。这次我直接把需求描述给模型，包括初始静止、直线加速、转弯离心、颠簸路况几种模式，让它生成带噪声的数据流。一次对话搞定，最后在PC上直接跑通了算法验证。

测试桩代码的本质是什么？是“看起来像硬件但不需要是真硬件”的替身。它的正确性检验标准是后面接的算法模块能否正确处理，而不是它自身要满足任何物理约束。这个特点让AI生成的代码完全够用，因为就算有微小逻辑瑕疵，跑起来后马上能通过算法的输出反馈发现。

更进一步，QEMU这类仿真器环境也是极大受益者。你在x86侧模拟一个Cortex-M核，板上外设全部抽象成模拟设备，AI生成的代码在这里先跑通逻辑，再移植到真板。逻辑性错误在仿真阶段就暴露了，硬件相关的错误留给测试阶段验证，能减少非常多的硬件返回迭代。

3.3 驱动模板与初始化代码：半Vibe半手写的最佳案例

直接让AI写底层寄存器驱动，我在很长一段时间里是拒绝的。后来发现问题的关键不是“让不让他们写”，而是“让他们写到什么粒度”。

现在很多SoC的寄存器映射、头文件定义、时钟树配置都是板上钉钉的，网上资料也极其充分。模型读过的数据手册和驱动源码比任何一个工程师都多。你让它生成一个“基于STM32F407通过SPI读取外部Flash ID的驱动”，它给出的骨架八九不离十，芯片头文件定义、SPI初始化序列、Flash命令字这些都是标准答案，模型完全有能力填对。

但你要让它直接把这个驱动跑通在你自己画的板子上，它做不到。因为板级排布、页大小、扇区划分、电源引脚的GPIO复位状态这些是项目私有的。所以我的用法是：

• 让模型生成驱动的初始版本，包括寄存器配置、外设初始化函数、基本读写流程
• 人负责修改引脚映射、中断配置、等待超时等硬件相关部分
• 生成代码里涉及DMA和中断协作的部分，从第一版就明确要求模型只在函数骨架层提供，具体实现人自己填
• 对生成的代码做资源审计，确认RAM、Flash占用符合目标MCU空间

这样做的实质是：把“硬件事实”留给人来判断，把“通用模式”交给模型滑铲。模型见过的外设驱动框架比人多，它能从一个标准序列开始，但最终细化到你的板子上，人的判断不可替换。

3.4 设备树与中间配置梳理：一个被低估的高频收益区

嵌入式Linux开发里最烦的事情之一，是梳理设备树。一堆节点、属性、中断映射、时钟引用、GPIO复用关系，信息极其琐碎，而且经常散落在好几份文档里。AI在这里的收益特别高，因为它是一个模式匹配问题。

我有一次要适配一个新的Sensor模块到既有平台，原来的设备树里完全没有对应节点。手写也可以，但要翻半天参考文档确认中断号和时钟绑定的写法。直接把SoC参考手册的片段和类似模块的设备树块丢给模型，让它按新模块的参数生成一份改动版，五分钟就拿到了一版可编译的设备树，补上GPIO和中断映射后直接使用。

类似地还有外设配置的中间代码，比如CMSIS配置、DMA描述符初始化、FATFS挂载参数、LWIP网络接口配置等。这些代码的共性是什么？它们高度模板化，但模板的具体参数跟芯片和板子绑定。模型不知道你的板子细节，所以参数由人确认，模板骨架交给模型生成。这也解释了为什么“应用层开发是不是嵌入式”这个热搜词会火——现在两边的工作方式越拉越近，嵌入式工程师越来越像写复杂业务逻辑的应用开发者，只是额外承担了硬件理解的责任。

4. 我现在的嵌入式AI协作工作流：强制约束+短反馈循环

聊应用场景，得往落地走。这套工作流我从一开始的“什么都让AI写”调了好几个月，现在逐渐固定下来，直接分享当前版本。

4.1 上下文工程是嵌入式Vibe的前提

嵌入式项目跟Web项目最大的区别在于：自然语言描述远远不够，模型必须拿到足够多的“项目事实”才能生成可用代码。这里的“项目事实”不是泛泛的“这是一个F407项目”，而是：

• 完整头文件路径和函数原型
• 寄存器映射的关键字段定义
• 外设配置的实际参数（时钟频率、数据位宽、校验位）
• 网络抓包或数据手册里的协议帧格式
• 编译环境的目标架构、优化等级、链接脚本概要

我通常的做法是，把项目关键的头文件、配置宏、协议文档直接粘贴进对话，然后再描述需求。比如要写CAN报文接收解析，我会先贴can.h里消息帧结构体的原型，再把总线波特率、验收滤波器的配置宏发过去，然后再说“基于这些，实现一个解析器”。这个上下文给足了，模型生成的代码贴合度完全不一样。它不再给你可移植的通用写法，而是直接能用你的变量名、你的结构体的项目内代码。

4.2 把编译反馈喂回模型，做成半自动循环

纯手动对话调参还是太慢。我现在的习惯是在命令行里把“make输出→错误定位→修正代码”做成一个小脚本，编译报错直接喂给模型，让它分析并给出修正。这样一次编译循环压缩到分钟级，已经接近应用层Vibe的迭代体验。

注意这里不是让模型帮你debug，而是让模型做“编译器错误翻译器”。嵌入式编译错误极其晦涩，经常是因为某个宏没定义导致了一连串连锁报错。模型对这种“错误语义还原”很擅长。它会告诉你这个宏在哪个头文件里定义、这个失配字段和结构体定义之间的关系，省去大量人工溯源。

4.3 强制使用的三个“信任边界”

用AI写代码，最重要不是让它“多干活”，而是让它“在划定的圈子里干活”。我现在给自己定了三个强制边界，任何生成代码跨过就要回退：

第一，生成代码不允许直接操作物理硬件抽象之外的内容。也就是说，模型可以生成通过HAL或驱动API访问外设的代码，但直接寄存器操作的代码必须人审，重点核对位域定义和时序约束。

第二，任何涉及中断上下文、关键区保护、并发资源竞争的代码，模型只能生成第一版候选，人必须重审并自行确定锁策略。AI生成代码对临界区的粒度理解经常不合理，如果它自动加了关中断但没考虑上下文切换损失，在硬实时系统里会出大问题。

第三，生成代码必须做资源审计。我会给模型设定明确的Flash和RAM预算，它生成完第一版本，我会用编译器的map文件确认占用情况。超标的直接要求重构，而不是接受冗余实现。

这三个边界不是不信任AI，而是承认“AI生成质量平均不错，但嵌入式要求的是极端情况正确”。极端情况恰恰是模型最容易翻车的区域。

4.4 基于PC原型的前置验证

嵌入式最大的痛是反馈慢，所以一切能在PC上先验证的东西都不应该上板调。我现在养成的习惯是：所有纯逻辑、无硬时钟依赖的模块，先在PC的模拟环境里Vibe出来。状态机、协议栈、算法滤波、通信数据解析、帧格式转换，通通先让AI生成，在PC上编译、单测、调参。只有和真实硬件交互的那层，再移植到目标板。

我之前做过一个BMS项目的数据帧解析和告警判断逻辑，整个模块是纯PC开发完的。AI生成逻辑框架，我补充了阈值参数和告警响应策略，PC上跑了几百轮测试。等板子回来，这个模块一把烧录通过，后面调的都是硬件层的事，逻辑部分零返工。

这也印证了“应用层开发是不是嵌入式”的火爆讨论。当一个嵌入式项目的核心壁垒越来越偏向“逻辑算法和系统架构”，而物理硬件交互被标准化驱动和中间层屏蔽得越来越多时，它能Vibe的部分就会越来越大。这趋势挡不住，我能做的就是让这个占比可控地变大。

4.5 代码审查的新方法：不逐行看，但要盯风险模式

不逐行读代码，不代表不审查。我现在的代码审查方式变了：不再从第一个字符盯到最后一个，而是带着风险清单去扫。这个清单是我半年用了不同模型写嵌入式代码后总结出来的：

• 是否有不合理的动态内存使用（嵌入式开发严禁随意malloc）
• 是否有隐含的递归调用或过大栈变量
• 是否有对宽度的隐性假设（int到底按32位还是16位处理）
• 是否把同步逻辑放进了中断处理函数
• 是否存在忽略返回值却影响数据完整性的路径
• 是否有对时间开销的高估或低估（比如函数里藏了循环体）
• 是否可能让外设进入不确定状态（比如初始化失败后没恢复机制）

这个清单本质上是我从过往硬件产线事故里提炼的“高危模式”。AI生成代码的平均水平高，但风险模式会集中出现在这几处。用这种风险导向审查法，我能在一两百行代码里几分钟定位到需要修改的区域，其他部分直接信任行为测试。

5. 几个踩坑实例，帮你绕开我浪费过的两三个月

我不会说这些坑是AI独有的，但它们以高概率出现，边缘情况特别容易诱发。

5.1 模型把“轮询”和“中断”两种模式拼在一起

最典型的无意识错误。让模型写一个SPI从机接收逻辑，它给出的代码里，进去中断处理函数后又等了一个while循环轮询状态寄存器。这在低频测试下可能偶尔能跑通，但中断上下文里阻塞，直接导致CPU占用飙升，其他实时任务全受影响。模型“知道”两种访问外设的模式，却没有判断当前上下文的约束。这种错误在应用层几乎无感，在中断处理里就是事故。

5.2 生成代码里的时序假设不符合实际外设

有一次让AI生成Flash擦写操作时的等待超时逻辑。它写了一个固定的大循环，粗略算了算，延时大约是毫秒级。但实际Flash擦除的典型时间是几十毫秒，温度变化后会到百毫秒级。如果循环体太短，Flash查状态时还在忙，读取得到的结果是无效的。这种bug在正常室温测试下永远复现不了，但一到高低温测试就暴露。根源就是模型生成时凭借的是典型值，没有考虑环境边界。

5.3 位域打包方式在大小端环境下的错位

更冷门但致命。模型生成一个数据帧打包函数，直接按结构体位域来。在ARM默认小端下编译没问题，但如果你要跟一个x86上位机对数据，或者另一端是大端CPU，位域布局直接错位，整个帧解析全错。这类问题需要懂存储布局的人在审查时主动盯。它不存在语法错误，编译一定过，甚至单一环境下跑起来数据完全符合预期，直到跨平台联调才露馅。

5.4 “看起来链表，实际找半天找不到头”

模型喜欢用链表表达动态数据结构。嵌入式里我们尽量少用链表，更常见的是定长数组加标志位。有一次它生成一段内存池管理代码，里面既保留数组又套链表结构，逻辑倒了三层，结果数组索引超界完全靠运气。后来我明确在需求描述里写“禁止动态分配，使用预定义数组+索引映射”，生成的代码简洁不说，错误面一下窄了很多。

这些坑都不新鲜，关键是有没有形成审查清单和边界声明。

6. 工具链层面，我目前实际在用的组合

给想入坑的朋友一个当前可复用的环境参考。不是绝对最优，但我用了半年以上，稳定、顺滑。

6.1 代码生成侧

主力还是Claude和GPT系列，写嵌入式代码的偏好差异不大，关键是上下文工程。我会把Cortex-M的头文件、HAL库版本号、当前工程目录结构直接喂进去，代码生成之前先让它总结一遍目标平台的约束，相当于一个内部活化的外设知识库。这样生成的代码贴合度比直接描述要高一个量级。

6.2 仿真验证侧

QEMU能模拟一部分Cortex-M平台，虽然不能完全替代真板，但验证纯逻辑和中断处理流程的入口完全够用。很多“模型生成的代码是否真能挂在SysTick回调里跑完”这种问题，在仿真环境里跑一次就清楚了。配合ARM GCC工具链，把ELF直接丢进QEMU挂起调试，比每次烧Flash省很多时间。

6.3 编译驱动AI的循环脚本

这里给个简单思路：

while true do make 2>&1 | tee build.log if grep -q "Error" build.log then echo "喂给模型编译错误" # 将编译错误发送给模型，获取修正建议 # 应用修正后重新编译 else echo "编译通过" break fi done

这个脚本本身不复杂，但能帮你把“编译错误→向模型解释→应用修改→重新编译”循环自动化。嵌入式开发最耗时间的就是来回看编译日志，机器人干这事效率高得多。

配合一个文件监控，我甚至可以在编辑保存后自动触发构建，改完代码三秒内就能知道是否引入新问题。

6.4 硬件交互层的代码仓分层

最后给一个提醒：别让AI直接在你的pet项目分支上飞来飞去。我现在的仓库分了三层，核心驱动层几乎全部人工维护，业务逻辑层可以放宽让AI高频介入，中间配置层（设备树、链接脚本、启动文件）允许AI生成但必须二次人工确认。这个分层既控制了风险，也保住了人的核心能力。

7. 长远看，嵌入式工程师的能力模型正在悄悄变化

聊了太多操作细节，最后说点稍微远一点的思考。

7.1 判断力高于记忆力

以前嵌入式工程师的核心能力之一，是记住大量寄存器地址、外设时序和芯片特例。这部分现在确实没有优势了，模型记得比人全，查得比人快。但它没法判断“这个外设在这个项目里是否应该这么用”，也没法判断“时序异常时是先查电源还是先查配置”。这些判断力来自对硬件行为的深度理解，而不是记忆表格。

所以我越来越觉得，未来嵌入式工程师的核心竞争力不是“写得好不好”，而是“判断得准不准”。AI帮我们把代码生成的成本打到地板价，但谁来定义正确的行为、谁来划定边界、谁来对量产负责？这些事还是得人来，而且更加值钱。

7.2 硬知识反而更值钱了

一个反直觉的现象：Vibe Coding普及之后，真正懂硬件的人反而更稀缺了。因为AI生成的代码量大，但需要人判断哪些代码可以在硬件上跑、哪些不行。你越懂硬件，就越能高效利用AI这个生成器；你越不懂，生成的代码就越像一个黑盒。模型不懂硬件不确定性，真正掌握这种不确定性判断的人，就掌握了协作里的定义权。

7.3 嵌入式开发的“Vibe化”程度是由硬件抽象水平决定的

未来嵌入式领域Vibe Coding能不能更大范围铺开，不取决于模型本身的能力，而取决于平台的标准化程度。如果某个SoC提供了很好的HAL，把硬件差异和中断细节都抽象掉了，那它上面的业务代码就能越来越“Vibe”。反过来，裸寄存器开发的项目，AI参与度永远会受限。

这也解释了为什么Linux用户态嵌入式开发和中间件开发会成为Vibe友好的先锋——它们的硬件抽象程度已经足够高。FPGA和RTOS底层开发短期还是以人为主。

7.4 团队协作的方式需要跟着变

以前嵌入式团队里，负责写底层的人往往成为“瓶颈”，因为大家都依赖他来填中断、调时序。现在AI能生成初版底层代码，这个瓶颈松动了，但新的瓶颈是“谁来定义最后的架构边界”。我在团队里的做法是：让所有开发都能用AI生成前期版本，但核心的软硬件接口规范、资源预算、可靠性策略必须架构师给定。AI在前端发散，架构师做后端收敛，效率提升很快。

8. 写在最后：一些真实感受

做嵌入式开发这十几年，我经历过从汇编到C、从裸机到RTOS再到嵌入式Linux的转型。每次新工具出现，圈子里都会有一波“彻底改变”和“完全无用”的两极讨论。Vibe Coding在嵌入式领域的落地，大概率走的是中间路线：它不会让一个不懂硬件的人突然变成嵌入式高手，但可以让一个懂硬件的人用同样的工程时间完成以前两三倍的产出。

我现在的实际体感是：AI主要负责把那些“我已经知道怎么解决但懒得写”的部分快速消灭，我集中精力去盯那些“只有对硬件有直觉才能判断对错的”部分。这种分工让我在推进项目时明显更从容，不是因为它替代了我的思考，而是它让我把思考用在了更需要人的地方。

如果你做嵌入式开发，也打算试试Vibe Coding，我给的第一条建议是：从一个纯逻辑模块开始，最好是没有硬件依赖的状态机或协议解析。先把它在PC上跑通，找到那种“写完就能跑、跑不通就看反馈”的节奏感，再逐步扩展到设备树梳理、初始化代码和UI层。不要在第一天就试图让AI独立写一个驱动加中断管理模块，那只会让你对这个工具彻底失去信心。

工具在变，但有一个原则不会变：嵌入式系统的价值永远是建立在稳定可靠的基础上的。AI可以把代码生成得更好看、更快速，但可靠性判断永远是人类工程师的职责。谁能把这种判断力持续打磨，谁就能在任何工具时代都站稳位置。