1. 当“感觉流”编程撞上寄存器：一场关于效率与掌控的拉锯战
“Vibe Coding”这个词最近在圈子里出现的频率越来越高，大概意思就是借助强大的AI编程助手，你只需要描述意图、把握方向、感受代码的“氛围”，具体的语法、API调用甚至模块实现都交给AI去补全。这种模式在Web开发、脚本编写、应用层业务逻辑实现上确实爽快，敲几句注释就能生成一大段能跑的代码，效率提升肉眼可见。但我干了十多年嵌入式，从8位机裸跑到Cortex-A系列跑Linux，第一反应就是：这套玩法放到嵌入式里，怕是要出大问题。
嵌入式开发和纯软件应用开发有一个根本性的差异——你写的每一行代码最终都要落到具体的硅片上，和物理世界打交道。寄存器配置错一位，外设就罢工；时序差几个时钟周期，通信就丢包；内存越界一点点，系统就HardFault。AI生成的代码在语法层面往往没问题，编译也能过，但它对硬件细节的理解是缺失的，或者说它给出的“合理推测”在特定芯片、特定板子上可能就是行不通。这不是AI不行，而是嵌入式本身的碎片化程度太高，AI的训练数据里很难覆盖到你手上那块具体型号的MCU或SoC的所有勘误表和隐藏约束。
所以这篇内容我想聊的不是“Vibe Coding好不好”，而是在嵌入式开发这个对确定性要求极高的领域里，怎么把Vibe Coding的效率和传统嵌入式开发的严谨性结合起来。我会从实际项目出发，拆解哪些环节适合让AI冲在前面，哪些环节必须自己死死盯住，以及怎么建立一套“AI生成+人工验证”的工作流。不管你是刚入行的嵌入式新人，还是做了几年Linux应用开发想往底层走的老手，这些经验应该都能帮你少走点弯路。
2. 嵌入式开发的“不可Vibe”地带：为什么AI在这里容易翻车
2.1 硬件抽象层的碎片化现实
先说说为什么嵌入式开发不能像写React组件那样放心交给AI。你让AI生成一个STM32的GPIO初始化代码，它大概率会给你一个标准库或HAL库的版本，看起来没问题。但实际项目里，你可能用的是某款国产替代芯片，寄存器地址偏移和STM32有细微差别；或者你的板子上这个引脚接了外部上拉，初始化时不能开内部上拉；又或者这个引脚在低功耗模式下有特殊唤醒功能，配置顺序有严格要求。这些信息AI不知道，你不在提示词里说清楚，它就只能按“最常见情况”来生成。
我遇到过最典型的一次：用AI辅助生成一段I2C读写EEPROM的代码，逻辑看起来完全正确，起始条件、设备地址、寄存器地址、数据、停止条件，一气呵成。烧进去一跑，读出来的数据全是0xFF。查了半天发现，这颗EEPROM的页写周期是5ms，而AI生成的代码在连续写操作之间没有加足够的延时，导致前一次写还没完成，后一次写就被忽略了。AI知道I2C协议，但它不知道具体这颗料的时间特性。这种“知识盲区”在嵌入式里遍地都是。
注意：AI对硬件时序、电气特性、芯片勘误的认知几乎为零。凡是涉及“等待时间”“上电顺序”“时钟配置”的代码，必须对照数据手册逐行核对。
2.2 资源约束下的“隐形天花板”
嵌入式系统另一个特点是资源极其有限。RAM可能只有几十KB，Flash可能只有几百KB，主频可能只有几十MHz。AI在生成代码时，默认环境是“资源充足”的，它不会主动考虑内存碎片、栈溢出、代码体积这些问题。比如你让它写一个字符串处理函数，它可能直接给你一个用了动态内存分配的版本，在PC上跑没问题，在单片机上跑几次就堆碎片了。
我一般会这样处理：让AI生成逻辑框架，但明确告诉它“禁止使用malloc/free”“所有缓冲区必须静态分配”“函数调用深度不超过3层”。这些约束写进提示词里，AI的输出质量会好很多。但即便如此，生成之后还是要自己过一遍，看看有没有隐式的递归调用、有没有大数组放在栈上、有没有浮点运算在无FPU的芯片上跑。这些细节AI不会主动帮你规避，它只负责“功能正确”，不负责“资源友好”。
2.3 中断上下文与并发陷阱
嵌入式中断服务程序（ISR）的编写有严格的约束：不能阻塞、不能调用非可重入函数、执行时间要尽可能短。AI生成的代码如果放在ISR里，经常会犯一些低级错误，比如在ISR里调用printf、在ISR里做浮点运算、在ISR里操作动态内存。这些操作在应用层开发里稀松平常，在ISR里就是灾难。
更隐蔽的是并发问题。AI生成的代码往往假设自己是独占CPU的，不会考虑中断随时可能打断当前执行流。比如一个全局变量的读-改-写操作，在AI看来就是三行普通代码，但在中断环境下，如果中断里也修改了这个变量，就需要关中断或使用原子操作。AI不会主动帮你加这些保护，除非你在提示词里明确要求“这段代码可能在中断和主循环中同时访问，请给出线程安全的实现”。
3. 把AI用在对的地方：嵌入式开发中Vibe Coding的合理打开方式
3.1 协议栈实现与数据解析：AI的舒适区
说了这么多AI的局限，那嵌入式开发里有没有适合Vibe Coding的地方？有，而且不少。协议解析、数据格式转换、状态机框架、算法原型验证这些偏逻辑、偏数学、和硬件耦合度低的环节，AI的表现相当不错。
举个例子，我之前做一个自定义串口协议的项目，帧格式是“帧头+长度+命令字+数据+校验+帧尾”，校验用的是CRC16。这种代码手写起来很繁琐，但逻辑清晰。我直接把协议文档贴给AI，让它生成解析函数和打包函数，再让它写一个单元测试。生成出来的代码基本可用，我只需要调整一下字节序和CRC初始值就能跑通。整个过程比我手写快了至少三倍。
再比如一些滤波算法、PID控制、简单的状态机，AI也能给出不错的实现。这些代码的正确性可以通过数学推导和仿真验证，不依赖具体硬件，所以AI的“通用知识”在这里是有效的。
3.2 代码重构与注释补全：提升可维护性
嵌入式项目里经常有一些“祖传代码”，变量命名是a、b、c，函数没有注释，逻辑绕来绕去。这种代码维护起来极其痛苦。我现在的做法是：把这类函数丢给AI，让它“在不改变功能的前提下重构，补充注释，提取魔法数字为宏定义”。AI在这方面做得很好，它能快速理解代码意图，给出可读性更高的版本。
但这里有个前提：你必须能验证重构后的代码和原代码功能完全一致。我的做法是，重构前先写一组测试用例（哪怕只是在PC上模拟运行），记录输入输出；重构后再跑一遍，对比结果。嵌入式里没有现成的单元测试框架，但你可以用条件编译把硬件相关部分mock掉，在PC上验证逻辑。这个投入是值得的，尤其是当你要维护一个生命周期很长的项目时。
3.3 文档生成与寄存器配置辅助
写文档是大多数嵌入式工程师讨厌但又不得不做的事。AI可以帮你根据代码生成API文档、根据寄存器操作序列生成配置说明、根据状态机代码生成状态转移图。虽然不能全自动，但能省掉大量机械劳动。
寄存器配置这块，AI也能帮上忙，但用法要讲究。我一般不会让AI直接生成寄存器配置代码，而是让它“解释这个寄存器的每一位是什么意思”“根据这个配置值反推各个位的设置”。这样我可以快速核对数据手册，确认配置是否正确。AI在这里扮演的是“翻译官”角色，把二进制和手册文字对应起来，而不是“决策者”。
4. 建立“AI生成+人工验证”的嵌入式工作流
4.1 提示词工程：把硬件约束写进对话
要让AI在嵌入式场景下输出可用代码，提示词的质量至关重要。我总结了一个模板，基本上包含这几个要素：
- 目标平台：具体到芯片型号、内核架构、主频、RAM/Flash大小
- 编译环境：用的什么工具链、什么库（HAL/LL/标准库/裸机）
- 约束条件：禁止动态内存、禁止浮点、中断上下文限制、栈深度限制
- 功能描述：输入输出、边界条件、异常处理要求
- 参考代码：如果有类似功能的现有代码，贴给AI参考风格
比如我要生成一个SPI Flash的读写函数，提示词会这样写：“目标平台是STM32F103C8T6，使用标准外设库，SPI1，主模式，时钟分频到18MHz。禁止使用malloc，所有缓冲区由调用者传入。读写函数需要在主循环中调用，不涉及中断。请生成页写、扇区擦除、页读三个函数，包含超时等待和状态检查。”
这样AI生成的代码，基本框架和约束都是对的，我只需要检查时序和具体命令字是否正确。
4.2 分层验证：从PC仿真到硬件在环
AI生成的代码不能直接烧进板子就跑，必须经过分层验证。我的流程是这样的：
- PC端逻辑验证：把硬件相关部分用宏或函数指针隔离，在PC上编译运行，用测试用例验证逻辑正确性。
- 硬件抽象层检查：对照数据手册，逐行检查寄存器操作、时序延时、引脚配置。
- 示波器/逻辑分析仪验证：对于通信接口，用仪器抓波形，确认时序符合协议要求。
- 边界条件测试：故意制造异常情况（断电、拔线、发送错误数据），看代码是否健壮。
这套流程走下来，AI生成的代码基本就能达到可交付质量。虽然比“直接烧录”麻烦，但比“从零手写”还是快很多，而且质量更有保障。
4.3 版本控制与回滚策略
用AI辅助开发，代码变更频率会变高，版本控制就格外重要。我的习惯是：每次AI生成或修改代码后，先提交一个临时commit，验证通过后再合并到主分支。这样如果发现AI改坏了东西，可以快速回滚。
另外，我建议在项目里维护一个“AI生成代码清单”，记录哪些文件、哪些函数是AI参与生成的，用了什么提示词，验证情况如何。这不是为了追责，而是为了后续维护时心里有数——AI生成的代码往往有特定的风格和潜在问题模式，知道来源有助于快速定位问题。
5. 嵌入式Linux与Qt开发中的Vibe Coding实践
5.1 应用层开发：AI的主战场
如果你做的是嵌入式Linux应用开发，那Vibe Coding的适用性就高多了。Linux应用层有完善的系统调用、丰富的库、标准化的构建工具，AI对这些内容的掌握程度远高于裸机寄存器。文件操作、网络通信、多线程、进程间通信、数据库操作，这些代码AI生成的质量相当高。
我最近用AI辅助写了一个基于Qt5的数据采集上位机，跑在嵌入式Linux上。UI布局、信号槽连接、串口读写、数据存储，大部分代码都是AI生成的。我只需要告诉它“用QSerialPort读串口，数据按行分割，解析后显示在QTableWidget里，同时写入SQLite”。生成的代码基本能跑，我改了几个地方：串口超时时间、表格刷新频率、数据库事务提交策略。整体效率比手写高太多了。
5.2 交叉编译与部署：AI容易忽略的环节
但嵌入式Linux开发和PC Linux开发有个关键区别：交叉编译。AI生成的代码在PC上编译通过，不代表在目标板上能跑。架构差异、库版本差异、文件系统差异，都可能导致运行时错误。
我踩过的一个坑：AI生成了一段使用std::filesystem的C++代码，在PC上编译运行没问题。但交叉编译到ARM板子上，发现工具链的libstdc++版本太老，不支持std::filesystem。最后只能改用POSIX的dirent.h和stat函数重写。这个教训告诉我，让AI生成代码时，必须明确告诉它目标平台的工具链版本和可用库版本。
5.3 Qt特定场景：UI与业务逻辑的分离
Qt开发中，AI对UI部分的生成能力很强，但对业务逻辑和硬件交互部分就需要更多人工干预。我的做法是：让AI生成UI框架和信号槽连接，业务逻辑自己写或让AI生成后严格审查。这样既能享受AI的UI生成效率，又能保证核心逻辑的可靠性。
另外，Qt的元对象系统（MOC）和信号槽机制有一些隐式规则，AI有时候会生成看起来正确但实际无法编译的代码，比如在非QObject派生类里使用信号槽、忘记加Q_OBJECT宏、跨线程连接类型不对。这些问题编译时才能发现，所以生成后要尽快编译验证，不要攒一堆代码再一起编。
6. 汽车电子与安全关键领域的特殊考量
6.1 功能安全标准下的AI使用边界
如果你做的是汽车电子、医疗设备这类安全关键领域，Vibe Coding的使用就要格外谨慎。这些领域通常有功能安全标准（如ISO 26262）的约束，对代码的可追溯性、确定性、失效模式都有严格要求。AI生成的代码很难满足这些要求，因为AI的决策过程是不透明的，无法提供完整的追溯链。
我的建议是：在安全关键模块，AI只能用于辅助生成测试代码、文档、非安全相关的工具链脚本。核心功能代码必须由人工编写，并且经过严格的评审和测试。这不是对AI的不信任，而是对安全标准的尊重。
6.2 汽车电子中的通信协议栈
汽车电子里常用的CAN、LIN、FlexRay等通信协议，AI对协议本身的理解是够的，但对具体控制器（如英飞凌、NXP的CAN控制器）的寄存器操作和硬件行为理解有限。我一般让AI生成协议层的数据结构和状态机，底层驱动自己写。这样分工比较合理，AI负责它擅长的逻辑部分，我负责硬件相关的部分。
另外，汽车电子对实时性要求很高，AI生成的代码往往没有考虑最坏执行时间（WCET）。在安全关键场景下，你需要自己分析每个函数的执行路径，确保在最坏情况下也能满足时限要求。这个工作AI帮不上忙，必须人工完成。
7. 我踩过的那些坑：Vibe Coding嵌入式翻车实录
7.1 一次由AI生成的“看似正确”的时钟配置
有一次我用AI生成了一段STM32的时钟树配置代码，目标是跑到72MHz。AI生成的代码看起来完全正确：使能HSE、配置PLL倍频、切换系统时钟源。编译下载，程序跑不起来。用调试器一看，卡在while (RCC_GetFlagStatus(RCC_FLAG_HSERDY) == RESET)死循环里。查了半天发现，板子上的晶振是8MHz，但AI生成的代码里PLL倍频参数是按12MHz晶振算的，导致PLL配置错误，HSE起振失败。AI不知道我的板子上焊的是多少MHz的晶振，它只是按“常见情况”给了个参数。这个教训让我明白：凡是和硬件参数相关的配置，必须自己根据原理图和BOM核对。
7.2 中断优先级配置的隐蔽错误
还有一次，AI生成了一段FreeRTOS的任务创建代码和中断配置代码。任务跑起来后，偶尔出现数据丢失。查了很久发现，AI配置的中断优先级和FreeRTOS的configMAX_SYSCALL_INTERRUPT_PRIORITY冲突了。在Cortex-M上，如果中断优先级高于这个阈值，就不能在中断里调用FreeRTOS的API。AI生成的代码在中断里调用了xQueueSendFromISR，但中断优先级设得太高，导致偶尔触发断言或数据丢失。这个问题很隐蔽，因为不是每次都复现。最后是翻FreeRTOS的移植文档才找到原因。
7.3 内存对齐与DMA传输的坑
用AI生成DMA传输代码时，它一般不会考虑内存对齐问题。比如你让AI生成一段从ADC到内存的DMA传输代码，它可能把目标缓冲区定义成一个普通的uint8_t数组。但如果DMA要求半字或字对齐，这个缓冲区地址可能不满足要求，导致传输错误或硬件异常。我现在的习惯是：所有DMA缓冲区都加上__attribute__((aligned(4)))或使用ALIGN_32BYTES宏，不管AI有没有提醒。
8. 给不同阶段嵌入式工程师的Vibe Coding建议
8.1 新手：先建立硬件直觉，再谈效率
如果你刚入行，我的建议是：不要过早依赖AI生成代码。嵌入式的核心能力是对硬件的理解和调试能力，这个能力只能通过亲手写代码、亲手调板子来积累。你可以用AI解释概念、生成参考代码，但一定要自己逐行理解、自己动手改、自己用仪器验证。否则你会陷入“代码能跑但不知道为什么能跑”的状态，一旦出问题就束手无策。
我见过一些新人，用AI生成代码很快，但遇到HardFault就懵了，不会看寄存器、不会查栈回溯、不会用调试器。这些基本功必须自己练，AI替代不了。
8.2 有经验者：把AI当作“高级代码补全”
如果你已经有几年嵌入式经验，对硬件和调试都比较熟悉，那AI可以成为你的效率倍增器。你可以让AI处理那些繁琐但逻辑清晰的代码，自己专注于架构设计、硬件交互、性能优化、问题排查这些高价值环节。但记住：AI生成的每一行代码，你都要有能力判断对错。如果你看不懂AI生成的代码，那就不要用。
8.3 团队协作：建立AI代码审查规范
如果你在团队里推广AI辅助开发，建议建立一套审查规范。比如：AI生成的代码必须经过至少一人review；涉及硬件操作的代码必须对照数据手册检查；AI生成的代码要在commit message里标注来源和提示词。这些规范看起来麻烦，但能避免很多低级错误，也能让团队成员互相学习AI的使用技巧。
9. 工具链与模型选择：我实际用下来的一些体会
9.1 通用大模型 vs 代码专用模型
我试过不少AI编程助手，有通用大模型，也有专门针对代码优化的模型。实际用下来，代码专用模型在语法正确性和API准确性上确实更好，但在理解硬件约束和项目上下文方面，通用大模型有时候反而更灵活。我的做法是：日常代码生成用代码专用模型，遇到需要解释数据手册、分析硬件行为、设计架构时，用通用大模型。
另外，模型的上下文窗口大小很关键。嵌入式项目往往需要参考多个文件（头文件、驱动文件、配置文件），如果模型上下文太小，它就只能看到当前文件，生成的代码可能和项目其他部分不兼容。所以我现在尽量选上下文窗口大的模型，把相关文件都贴进去。
9.2 本地部署 vs 云端服务
如果你做的是商业项目，代码保密是必须考虑的。云端AI服务虽然方便，但代码上传到第三方服务器总有泄密风险。我现在的做法是：非核心代码用云端服务，核心算法和硬件相关代码用本地部署的模型。本地部署的模型能力虽然弱一些，但至少代码不出内网。另外，本地模型可以针对自己的代码库做微调，生成风格更一致的代码。
9.3 与现有IDE和调试工具的集成
AI编程助手最好能集成到现有IDE里，这样不用来回切换窗口。我现在用的是VS Code + AI插件 + Cortex-Debug的组合，写代码、生成代码、编译、调试都在一个界面里完成。效率提升很明显。如果你用IAR或Keil，也有对应的AI插件，但生态不如VS Code丰富。我的建议是：如果项目允许，尽量往VS Code生态靠，工具链更现代，AI支持也更好。
10. 嵌入式开发的未来：AI会取代工程师吗
这个问题我被问过很多次。我的看法是：AI会取代一部分嵌入式开发工作，但不会取代嵌入式工程师。具体来说，那些重复性的、模式化的、和硬件耦合度低的代码编写工作，AI确实能做得又快又好。但嵌入式开发的核心价值从来不只是“写代码”，而是理解系统、理解硬件、理解约束、做出权衡。这些能力需要经验积累和工程判断，AI目前还不具备。
举个例子，一个嵌入式系统出现偶发性死机，AI能帮你分析可能的原因，但最终定位问题还是要靠你去看波形、查寄存器、分析栈回溯、做压力测试。AI可以给你提供排查思路，但执行和判断还是靠人。再比如，选择一个MCU、设计一个电源方案、规划一个通信协议，这些决策涉及成本、供货、开发周期、团队能力等多方面因素，AI给不出最优解。
所以我的态度是：拥抱AI，但不要依赖AI。把AI当作一个知识渊博但缺乏实战经验的助手，它帮你查资料、写模板、做重复劳动，你负责做决策、做验证、做那些需要真正工程判断的事情。这样配合下来，效率和质量都能兼顾。
11. 一个具体的Vibe Coding嵌入式实战案例
11.1 需求描述与提示词设计
前段时间我需要在一个STM32F4的板子上实现一个Modbus RTU从站，通过RS485和上位机通信。功能要求：支持03/06/16功能码，支持最多16个保持寄存器，波特率9600，8位数据位，无校验，1位停止位。硬件上用的是USART2 + 一个GPIO控制RS485收发切换。
我把这些信息整理成提示词：“目标平台STM32F407，使用HAL库，USART2，波特率9600，8N1。RS485方向控制引脚是PD5，高电平发送，低电平接收。需要实现Modbus RTU从站，支持功能码03（读保持寄存器）、06（写单个寄存器）、16（写多个寄存器）。保持寄存器数量16个，地址从0x0000到0x000F。请生成完整的代码，包括初始化、中断接收、帧解析、CRC校验、响应发送。禁止使用动态内存，所有缓冲区静态分配。”
11.2 AI生成代码的审查与修改
AI生成的代码结构很清晰：一个modbus.h定义寄存器和函数声明，一个modbus.c实现协议逻辑，一个main.c做初始化和主循环。我拿到代码后做了这几件事：
- 检查USART配置：确认波特率、数据位、停止位、校验位和需求一致。AI生成的配置是对的。
- 检查RS485方向控制：AI在发送前拉高PD5，发送完成后拉低。但HAL库的
HAL_UART_Transmit是阻塞式的，发送完成标志需要确认。我改成了用HAL_UART_Transmit_DMA，在DMA发送完成中断里拉低PD5，避免阻塞主循环。 - 检查CRC实现：AI生成的CRC16计算函数是标准的Modbus CRC，我用手算验证了几个测试向量，确认正确。
- 检查帧解析：AI用了一个状态机来解析帧，逻辑基本正确。但我发现它没有处理帧间隔超时（Modbus RTU要求帧间至少3.5个字符时间），我补上了定时器超时判断。
- 检查中断优先级：确认USART中断优先级和系统其他中断不冲突。
11.3 实测结果与性能数据
修改后的代码烧进板子，用Modbus调试助手测试。03功能码读取16个寄存器，响应时间约2ms；06功能码写单个寄存器，响应时间约1.5ms；16功能码写多个寄存器，响应时间约3ms。连续测试1小时，没有丢帧或错误响应。用逻辑分析仪抓RS485波形，时序符合Modbus RTU规范。
整个项目从开始到跑通，大概用了半天时间。如果完全手写，估计要两天。AI帮我省掉了协议解析、CRC计算、状态机框架这些繁琐但逻辑清晰的部分，我只需要专注于硬件配置和时序调整。这个案例让我对Vibe Coding在嵌入式中的应用更有信心了，但也更清楚它的边界在哪里。
12. 一些零散但重要的经验碎片
12.1 关于AI生成的延时函数
AI生成的延时函数经常用空循环实现，比如for(i=0;i<1000;i++);。这种延时在编译优化开启后可能被优化掉，而且延时时间不精确。我现在的做法是：所有延时都用硬件定时器实现，或者至少用__NOP()配合循环计数，并且用示波器实测校准。AI生成的延时函数只能作为参考，不能直接用于时序敏感的场合。
12.2 关于AI生成的位操作
AI对位操作的理解有时候会出问题。比如它可能生成reg |= (1 << 3);来置位，但如果你要置位的寄存器是只读的或者有写保护，这个操作就无效。更隐蔽的是，有些寄存器要求“写1清零”或“读-修改-写”序列，AI不知道这些特殊规则。所以涉及寄存器操作时，我一般让AI生成注释和框架，具体的位操作自己对照手册写。
12.3 关于AI生成的错误处理
AI生成的代码往往缺乏完善的错误处理。比如它可能不检查函数返回值、不处理超时、不处理异常状态。在嵌入式里，错误处理至关重要，因为硬件随时可能出问题。我现在的习惯是：让AI生成正常流程代码，然后自己补充错误处理分支。或者直接在提示词里要求“每个可能失败的操作都要有错误处理和超时机制”。
12.4 关于AI生成的代码风格
AI生成的代码风格往往比较统一，但可能和项目现有风格不一致。比如项目用uint8_t，AI用unsigned char；项目用static修饰内部函数，AI不写。这些风格差异虽然不影响功能，但会影响代码可读性和维护性。我的做法是：在提示词里贴一段现有代码作为风格参考，让AI模仿。或者在生成后用代码格式化工具统一风格。
13. 最后聊几句掏心窝的话
写了这么多，其实核心观点就一个：Vibe Coding在嵌入式领域不是不能用，而是要会用。你得清楚AI擅长什么、不擅长什么，然后在合适的环节用它，在不合适的环节自己上。这就像你带一个聪明但没经验的实习生，你得给他明确的指令、检查他的输出、在关键决策上把关。
我见过两种极端：一种是完全排斥AI，觉得AI生成的代码不可靠，坚持全部手写；另一种是过度依赖AI，代码能跑就行，不深究原理。这两种我都觉得不可取。前者效率太低，后者风险太大。比较好的状态是：用AI处理繁琐的、模式化的、逻辑清晰的部分，自己专注于硬件交互、架构设计、问题排查、性能优化这些真正体现嵌入式工程师价值的地方。
嵌入式开发的门槛从来不只是“写代码”，而是对系统的整体理解和掌控。AI可以帮你写代码，但帮不了你理解系统。所以不管AI怎么发展，底层能力还是得自己练。工具在变，但硬功夫不会过时。