今年社区里讨论 AI 和嵌入式的帖子特别多有人问嵌入式学习路线能不能绕开“八股”有人在 GitHub 上搜嵌入式架构设计时发现不少项目描述里多了“Claude Code 辅助开发”几个字还有人直接把嵌入式面试题丢给大模型让它帮忙出答案。“AI 会让嵌入式行业技术平权吗”这个问题几乎每次聊到都会有人争论。我做了十几年嵌入式开发从 8 位 MCU 一路做到嵌入式 Linux最近大半年高频使用 AI 编程工具说下我的真实感受。这篇文章不站在“AI 万能”或者“AI 无用”任何一边而是把嵌入式行业的技术门槛拆开看再给一些能落地的实操经验适合正在学嵌入式、准备转行嵌入式、以及已经在做嵌入式但对 AI 辅助开发持观望态度的工程师。1. 平权之前先看看嵌入式行业到底在难什么1.1 表面是“八股”背后是一棵系统化的知识树嵌入式面试题在很多外行人看来非常刻板网上甚至有个热词叫“嵌入式八股”。链表、二叉树、AVL 树、内存管理、中断嵌套、编译链接过程、C 语言面向对象设计看起来都是最基础的计算机知识但嵌入式行业为什么这么执着于考这些因为嵌入式开发的运行环境太接近硬件你写出来的每一行代码最终都要面对只有几百 KB 内存的芯片、不确定的时序、外部中断的抢占以及电源波动带来的诡异现象。这些基础知识不是用来背的而是用来构建“在受限环境下如何做出可靠系统”的判断力。AI 在这里确实实现了第一层平权以前想搞清楚 AVL 树在嵌入式场景里到底有什么用需要翻教材、翻开源项目、翻论坛帖子信息散落且过时现在直接问 AI它能给你解释清楚 AVL 树的旋转过程还能给你一段能在 MCU 上跑的最小 C 实现甚至能告诉你为什么在节点数量不大时顺序查找可能比 AVL 树更快。热词里的“嵌入式二叉树之 AVL 树”“嵌入式八股”“嵌入式面试题”本质上是同一类需求如何高效地补齐嵌入式工程师必备的知识底座。AI 在这件事上是一个非常好的“解释器”因为它能把几十页教材压缩成一段带着具体例子的对话。但也要清醒一点知识树可以被 AI 帮忙爬树上的果实得自己摘。AI 能告诉你中断服务函数里不能做耗时操作但它不会替你在示波器前蹲一下午去确认某条中断线是否真的产生了毛刺。知识获取的平权只是第一步后面的工程判断才是关键。1.2 难在“看不见摸不着”的硬件行为软件行业有个说法叫“本地跑不通提交 CI 跑”嵌入式行业没有这么幸福。代码能编译通过不代表板子能跑板子能跑不代表长时间运行不崩溃长时间运行没问题不代表换一批物料后依然稳定。这里面的差距核心来自硬件行为的不确定性包含电源纹波、信号完整性、时钟树配置错误、外设上电时序不满足、Flash 擦写寿命等等。以芯片原厂手册为例一颗稍微复杂点的 SoC参考手册动辄几千页。以前我们查一个定时器捕获模式的寄存器配置要在 PDF 里翻半天还要对照勘误表确认某个位在某个芯片版本上真的有效。现在 AI 可以快速帮你定位到相关的寄存器描述甚至生成一份初始化代码。但问题在于AI 没有“看过”你这块板子的原理图它不知道你的外部晶振是 25MHz 还是 24MHz不知道你的 GPIO 有没有被别的外设占用。这类“看不见摸不着”的硬件行为是 AI 目前很难平权的部分。我把嵌入式的门槛拆成两类一类是“知识门槛”比如某个外设怎么配置、某个协议怎么实现AI 可以显著降低另一类是“经验门槛”比如为什么板子在低温下偶发死机、为什么两块相同设计的板子表现不一样这类问题需要大量的现场调试、原理图阅读、信号测量积累AI 最多帮你缩小排查范围但没法替你拍板。1.3 工程经验的“暗知识”最难被替代嵌入式行业存在大量没有被写进文档的“暗知识”。举个例子某个 WiFi 模块在断线重连时如果直接调用厂商 SDK 的重连函数可能会导致系统主线程阻塞这时候需要在业务层做个看门狗来兜底再比如用 Linux 的 U 盘测速方法很多但真正量产时你还要考虑 U 盘文件系统格式、挂载点冲突、掉电损坏风险。这些东西有相当一部分是“老工程师在某个凌晨三点因为设备出了问题才总结出来的”不会出现在任何公开代码仓库里。热词里出现了“嵌入式 wifi 断线重连怎么弄”“嵌入式 linux u盘测速方案”这类问题是典型的“暗知识”型问题。你去问 AI它会给你一个表面上非常完整的方案但如果你照着做大概率会在量产现场踩坑。因为 AI 的答案来自公开资料和常见实践而嵌入式工程里的坑往往藏在特定硬件平台、特定内核版本、特定驱动版本里。这也是为什么我一直认为AI 让知识变得廉价但经验依然溢价。2. AI 在嵌入式开发里的真实作用域2.1 写代码从驱动到应用逻辑AI 能帮上一大截先说结论AI 写嵌入式代码的能力已经超过了很多人的预期但低于很多人的幻想。它能很好地完成三类事情一是芯片外设初始化比如 STM32 的定时器 PWM、UART DMA、I2C 读取传感器只要你在提示词里给清楚芯片型号和引脚它生成的代码八九不离十二是应用逻辑比如状态机、协议解析、环形缓冲区、日志模块三是 Linux 用户空间的工具脚本比如热词里那个“U 盘测速方案”AI 生成一个 shell 脚本或者 C 小程序毫无压力。我自己试过一个很典型的场景一块嵌入式 Linux 板卡要求开机后自动检测 USB 存储设备插入执行读写测速然后把结果通过日志上报。以前我写这套逻辑大概需要大半天包括查挂载规则、处理异常插拔、考虑多个分区的情况。这次我直接问 AI给它限定条件“嵌入式 Linux、busybox 环境、支持 vfat 和 ext4、不能引入额外依赖”它给了一个基于 udev 规则加 shell 脚本的方案核心逻辑能直接用。最让我意外的是它甚至考虑到了 U 盘拔掉后挂载点残留的清理问题这个细节很多初级工程师都容易忘。但我也踩了坑。AI 生成的代码里把/dev/sda1当成了唯一设备节点而实际板卡上还可能插入 USB 读卡器、4G 模块设备节点可能变成/dev/sdb1甚至/dev/mmcblk1p1。这种问题AI 在生成代码时是没法感知的因为它不了解你的具体硬件拓扑。所以我的经验是让 AI 写代码时一定要把你对硬件的那部分已知约束全部写进提示词里并且生成后逐行确认设备操作相关的逻辑。2.2 当“第二双手”补文档、做 Review、理命名嵌入式工程师普遍对写文档有抵触情绪但项目交付又躲不开。AI 在这里是个非常称职的“第二双手”。我最近做了一个小型的嵌入式 Linux 项目代码量不大但函数命名很随意变量全是一堆tmp、flag、ret。把代码丢给 AI让它按项目惯例重命名、补注释、生成 README十分钟就搞定了。如果用人工来干没有两个小时下不来。Code Review 也是 AI 的强项。我试过把一段刚写完的 GPIO 中断处理代码给 AI它提醒我“中断服务函数里调用了printf虽然能编译过但在某些平台会导致死锁或输出乱码”。这个提醒对于一个新手来说是有价值的因为很多教材只教你“中断里不要做耗时操作”但没说printf具体会带来什么后果。不过也要注意AI 的 Review 是基于静态分析和公开模式它发现不了某个寄存器在特定芯片版本上的别名问题这类问题只能靠芯片勘误表和人肉排查。热词里有一项很显眼“C 语言面向对象编程:嵌入式实战 pdf”。嵌入式 C 的面向对象本质上是用结构体封装属性、用函数指针实现多态这在驱动分层和协议栈设计里非常常见。AI 对这类风格的代码理解相当好因为它看过大量开源驱动源码。我曾经让 AI 把一个纯 C 的函数式驱动改造成支持多个设备实例的“类”风格驱动它改完之后代码结构比我自己手写还要规整。2.3 学习助手怎么用 AI 消化八股、面经和内核源码很多人把 AI 当成“背答案工具”拿它直接生成面试题的答案然后开背。我强烈不建议这么做。AI 给出的答案有时过于“正确”反而缺失了嵌入式领域那种“分情况讨论”的微妙感。比如“嵌入式面试题”里常问的一个问题中断和轮询怎么选AI 的标准答案是“中断适合低频事件、轮询适合高频事件”听起来没毛病但实际工程里你还要考虑中断的服务时间是否会导致其他任务饿死轮询会不会占用总线带宽。所以与其背答案不如让 AI 给你“换着场景出题”。用 AI 读嵌入式内核源码是另一种效率很高的方式。热词里的“嵌入式内核源码”很多初学者打开 Linux 内核的kernel目录就懵了几百万行代码根本不知道从哪里看。我一般让 AI 扮演“内核导览员”先让它用几句话解释某个子系统的整体框架比如“设备模型”“中断子系统”然后我再挑关键路径的代码问细节。这种方式能把阅读源码的坡度放缓让“从 0 到能改驱动”的过程缩短不少。还有一点AI 可以当嵌入式面试的模拟考官。你把“嵌入式软件工程师”岗位的 JD 发给它让它按岗位要求生成一套面试题然后进行追问。这个过程的意义不在于押题而在于通过反复追问把你知识体系里的漏洞暴露出来。这和背答案是完全不同的学习逻辑。2.4 Agent 开始接管的“体力活”最近 AI Agent 类工具的热度非常高热词里就有“AI Agent”“Spring AI”“vscode集成claude code 开发嵌入式mcu代码工程”。Agent 和普通聊天的最大区别是它能主动读文件、运行命令、修改代码甚至反复迭代。我在 VSCode 里集成 Claude Code 试了一段时间发现它在嵌入式开发里最实用的场景是“处理已知问题范围的重复修改”。举个例子一个 MCU 工程里有一颗传感器的寄存器地址全错了一共 40 多处Agent 可以读 datasheet 里我标注好的地址段然后自动批量替换并在替换后执行编译检查。这种活以前要写脚本或者手动改现在只需要用自然语言描述清楚规则Agent 就能完成。另一个让我印象深刻的场景是编译报错的修复嵌入式工程常因为头文件路径、宏定义、链接脚本配置导致编译失败Agent 会读编译器输出自己翻 Makefile 和 CMakeLists然后提出修改方案我可以决定接受或者拒绝。但 Agent 的边界也很清晰它无法感知硬件层面的问题。比如某个引脚和按键冲突Agent 即使翻了原理图 PDF如果它能读的话也很难理解机械结构上的限制。它更适合做“软件工程内部的体力活”而不是“软硬件交界的决策活”。3. 一次完整实操回顾让 AI 帮我重构一个嵌入式 Linux 小工程3.1 项目场景与工具选型前几天我刚好做一个嵌入式 Linux 外设管理的小工具需求包括三块WiFi 断线自动重连、U 盘插入测速并记录结果、状态信息上报到远端日志。目标平台是 ARM Cortex-A7 双核内核版本 5.10根文件系统基于 busybox交叉编译工具链是厂商提供的。工具选型上我用的是 VSCode 加 Claude Code 的集成环境同时在服务器上保留了厂商的交叉编译工具链和板子的串口调试终端。为什么这么选因为这类嵌入式工程对格式化和静态分析工具要求不高但对“能直接操作文件、执行编译、看报错”的能力要求很高。普通聊天窗口只能给代码我还得自己复制粘贴Agent 直接把文件改了我只需要巡检 diff效率高得多。工具链部分没有引入任何云端编译服务因为涉及公司内部代码和硬件相关信息。整个工程建在本地AI 只作为“代码生成与重构助手”所有最终编译和板端验证都在本地完成。这是嵌入式使用 AI 的一个基本原则AI 可以生成、可以建议但最终必须由你控制完整的构建链路。3.2 从需求到 AI 对话怎么提需求才能得到好代码这次实操给我最大的感触是给 AI 的需求描述越具体产出的代码越能直接落地。我这次用了三段式提示词模板效果不错第一段交代平台和约束目标平台是 ARM Cortex-A7、Linux 5.10、busybox 环境、只有一个网卡、需要兼容常见的 WiFi 模块。第二段说明功能需求检测到 WiFi 断线后自动尝试重连重连次数有限制不能阻塞主流程需要输出日志。第三段补充边界情况要考虑/tmp目录空间有限日志轮转U 盘挂载点冲突处理。AI 给的第一版 WiFi 断线重连方案是一个基于 shell 脚本的循环检测加wpa_supplicant重新关联的流程核心逻辑是这样的#!/bin/sh # wifi_guard.sh - 简单可靠的 WiFi 断线重连脚本(嵌入式 Linux/busybox) # 用法: wifi_guard.sh # 注意: 依赖 /bin/ping、/sbin/wpa_cli、/sbin/ifconfig GW_IP192.168.1.1 IFACEwlan0 RETRY_MAX5 RETRY_COUNT0 while true; do if ! ping -c 1 -W 2 $GW_IP /dev/null 21; then RETRY_COUNT$((RETRY_COUNT 1)) if [ $RETRY_COUNT -ge $RETRY_MAX ]; then # 超过重试次数后强制重新关联 wpa_cli -i $IFACE disconnect sleep 1 wpa_cli -i $IFACE reconnect RETRY_COUNT0 fi logger -t wifi_guard WiFi down, retry $RETRY_COUNT else RETRY_COUNT0 fi sleep 15 done脚本的思路没问题它用 ping 网关来检测网络连通性断线后先调wpa_cli disconnect/reconnect而不是直接 ifdown/ifup因为后者会触发完整的 DHCP 流程耗时更长。但 AI 第一版里有个隐患wpa_cli命令在不同 WiFi 模块的路径可能不同有些模块厂商会改写成自定义工具所以我把可执行路径抽成了变量便于适配。这段脚本我测试下来基本可用但它只覆盖了“已经连接过 WiFi后来掉线”的场景。如果是设备开机后第一次连不上 WiFi或者 AP 换了密码这种脚本就无能为力了。你需要补充对应的连接配置逻辑而不是指望它解决所有问题。3.3 调试踩坑记录AI 和真机之间的差距第一版脚本上线后板卡出现了一个典型的嵌入式问题脚本运行一段时间后消失了。排查发现板子上跑了一个自定义 init 进程会周期性清理异常退出的后台进程而我的脚本因为长时间运行被误判为“僵尸任务”。解决方式是把脚本改成开机自启且加入系统init.d管理而不是直接在 shell 里后台运行。第二个坑出现在 U 盘测速部分。AI 给出的方案是检测/dev/sd[a-z]1设备节点然后直接挂载到/mnt/usb。我按这个方案配置后发现插入两张 U 盘时第二张会挂载失败因为挂载点被占用。更隐蔽的问题是如果 U 盘是 NTFS 格式而内核没开启相关驱动AI 生成的mount -t ntfs-3g会直接报错。这类问题属于典型的“环境感知缺失”AI 无法知道你当前的 kernel 打开了哪些文件系统选项。第三个坑是 WiFi 重连脚本里的日志空间问题。我起初没有限制日志输出结果/var/log/messages被刷爆导致根文件系统只读。AI 生成的代码里虽然有logger调用但没有做日志轮转。这一点显然不符合量产要求。综合这次实操我用一张表格整理一下 AI 辅助开发和传统开发的差异对比项传统开发方式AI 辅助开发方式原型代码产出速度慢需要查阅大量手册快一次对话能拿到完整框架硬件相关约束识别靠工程师经验主动规避需要工程师在提示词中明确约束编译错误修复手动逐条排查Agent 能快速定位大部分语法和链接问题板卡适配和量产问题依赖长期积累的现场经验AI 无法感知必须人工验证代码规范和文档靠自觉容易拖延AI 能强制补齐降低交付阻力3.4 效率对比我实际省了多少时间这个项目如果用传统方式我预估需要 4 到 6 小时其中三分之一的时间在查手册和写初始代码三分之一在调编译和连接剩下的时间在板卡上处理各种“莫名其妙”的问题。这次用 AI 辅助原型代码只花了 40 分钟左右编译和板端调试花了大概 1 小时中间还包含我手动核对wpa_cli路径和 U 盘挂载规则的时间。整体从动手到能在板卡上稳定跑通大概 1.5 小时。这里面有一个很关键的前提不是我直接拿到 AI 代码就用而是我明确知道“哪些地方需要自己确认”。如果你是一个完全没有嵌入式开发经验的人拿着 AI 生成的代码往板子上跑大概率会卡在环境搭建、交叉编译工具链配置、设备树编译这些“AI 帮不上忙”的环节。所以我觉得AI 给嵌入式工程师带来的真实效率提升不是“取代你去写代码”而是“替你省掉大部分机械性工作让你更集中精力去判断真机行为”。4. 平权的真相门槛降低但新落差出现了4.1 入门门槛确实被拉低了如果把“技术平权”定义为“让更多人能够上手嵌入式开发”那 AI 确实做到了很大一部分。最直接的变化就是学习路径变得更加清晰。以前一个转行者问“嵌入式学习路线”得到的答案往往是一长串书单和视频列表信息过载且互相矛盾。现在让 AI 根据你的基础和时间生成一份学习计划把“嵌入式 Linux 项目”“嵌入式架构设计 项目 github”这类资源按优先级排好效率高很多。代码生成也极大地降低了“从 0 到 1”的阻力。写过 MCU 驱动的人都知道第一次对着空工程初始化时钟和 GPIO是一件非常劝退的事情。AI 可以帮你生成完整的初始化框架甚至附带注释说明每个寄存器的作用。你不需要一开始就理解所有细节可以先让代码跑起来再慢慢深挖。这种“先能跑再搞懂”的模式对新手非常友好也弥补了缺少老工程师带教的问题。工具链的集成也在加速这个过程。热词里“vscode集成claude code 开发嵌入式mcu代码工程”说明很多人已经开始在实际的 MCU 开发环境里使用 AI Agent。只要搭好编译调试环境AI 就能在你写代码、发现错误、修复错误之间形成闭环。这个闭环对于新人建立信心非常重要。4.2 新门槛出现提问、判断、验证但平权的另一面是原有门槛消失后新的门槛会浮现上来。第一道新门槛是提问能力。AI 再强也需要你告诉它芯片型号、引脚编号、内核版本、外设连接方式。一个只会说“帮我写个点灯程序”的新手拿到的代码大概率在他的板子上跑不起来。而一个能准确描述“STM32F407VET6、PC13 引脚接了一个低电平有效的 LED、内部高速时钟、使用 HAL 库”的开发者AI 给出的代码几乎可以一次通过。第二道新门槛是判断能力。AI 生成的代码看起来越像那么回事越考验你识别它“哪里有问题”。前文里那个 WiFi 重连脚本如果本身不具备基本的 shell 功底你可能根本看不出它忽略了 DHCP 租约的影响也意识不到wpa_cli disconnect在某些驱动上会触发模块固件异常。经验在这里不是可有可无而是决定“AI 方案能不能落地”的关键。第三道新门槛是验证能力。嵌入式代码不像 Web 前端改完刷新页面就能看到效果。你要验证一段代码必须有对应的硬件环境、编译工具链、烧录调试流程。AI 能帮你生成测试用例但没法替你做硬件在环测试。没有硬件验证能力的“嵌入式开发者”只能停留在“代码看起来没问题”的阶段这是非常危险的错觉。用一张表格来对比能力维度有经验工程师 AI无经验新手 AI需求拆解能准确描述硬件约束和边界情况描述不完整经常遗漏关键参数代码生成质量生成后能主动修正倾向于直接使用很少质疑编译错误处理能分析根因并修复容易被 AI 的“表面修复”带偏板卡联调知道从电源、时钟、复位逐步排查容易陷入“反复编译烧录”的循环最终交付能保证可靠性、安全性和可维护性能跑通 demo但距离产品化差距很大4.3 行业影响不是“替代”而是“分工重构”很多人担心 AI 会让嵌入式软件工程师失业我觉得这个担忧是多余的但“部分岗位的工作内容会发生变化”是确定的。以前一个团队需要一个专门写底层驱动的工程师、一个专门写应用层逻辑的工程师、一个专门做测试验证的工程师现在写驱动的工程师可以借助 AI 更快地覆盖应用层逻辑写应用的工程师也可以借助 AI 理解底层驱动的关键路径。岗位之间的壁垒会被打破通用型嵌入式工程师的价值会上升。但另一类岗位反而更难被替代嵌入式架构师、硬件工程师、系统可靠性工程师。AI 可以帮你生成一个 WiFi 重连脚本但它没法帮你决定“系统是使用 Linux 还是 RTOS”也没法帮你权衡“用硬件看门狗还是软件看门狗”。这些决策建立在长期工程实践的安全意识和成本考量之上涉及的是产品生命周期的整体利益。热词里的“2026 年全球嵌入式设备安全报告”其实也在提醒一件事AI 生成的代码里可能存在大量安全漏洞而最终为安全负责的依然是人。还有一个变化是端侧 AI 的落地。热词里“宠物检测ai模型——嵌入式设备上的猫狗实时识别”这类项目会越来越多嵌入式工程师不仅要会写驱动还要了解模型量化、算子优化、内存布局。AI 在这里既是开发者又是开发对象用 AI 工具去开发嵌入式的 AI 应用会让这个领域的技术门槛比想象中更低但要走通从模型到板端推理的完整链路依然需要扎实的嵌入式底子。4.4 我的结论技术平权是“半平权”所以回到标题那个问题AI 会让嵌入式行业技术平权吗我的回答是知识会平权经验不会入门会平权精通不会工具会平权判断不会。AI 把大量显性知识压缩成了对话和代码片段让一个零基础的人能更快地写出“看起来能跑”的程序但嵌入式行业的壁垒从来就不只是“写代码”而是理解物理世界的不确定性。以前你花三个月才能摸清一个芯片的外设特性和坑点现在 AI 帮你总结好了一份速查表但真正到量产阶段你依然要面对芯片勘误表里标注的“在某种条件下状态寄存器可能返回错误值”这种细节。AI 能帮你节省的是时间不能帮你替代的是经验和责任。所以我更愿意把这种变化称为“半平权”它让新人和老手之间的起点差距缩小了但在终点处经验的价值反而会被放大。5. 给同行的一点避坑心得5.1 用 AI 但不盲信 AI三个前置检查经过这段时间的高频使用我总结了一套自己的使用规矩每条 AI 生成的硬件操作类代码落地前必须完成三个前置检查。一是引脚复用表确认检查 AI 配置的 GPIO 是否和板子上其他外设冲突二是外设时钟树确认确认它生成代码里使能的时钟源和分频系数是否匹配你的晶振频率三是边界条件确认比如缓冲区长度、超时设置、错误处理分支是否覆盖了真实使用场景。这三个检查有些可以借助 AI 自己完成比如让它去读芯片手册但大部分情况下还是依赖工程师对硬件的理解。因为 AI 对“你的板子”没有认知你问它“这个引脚能复用成 PWM 吗”它只能根据芯片型号给出理论上的答案而实际板卡上该引脚可能已经连了按键或者 LED。5.2 提问方式决定了 AI 的下限和上限AI 生成代码的质量和你提问的质量高度相关。如果泛泛地问“嵌入式怎么实现 WiFi 断线重连”它给你的答案是普适性的往往不能直接用如果你按“平台 硬件约束 功能诉求 边界条件”的结构描述问题拿到的代码基本就是定制化的。我个人的习惯是在提问前先花 30 秒整理一个“工程上下文清单”包含芯片/平台型号、编译工具链、外设关键引脚、运行环境限制、已知不能用 X 方法等信息。把这些丢给 AI它给出的代码能直接落地的概率会大幅提升。如果 AI 给的方案不是你想要的或者报错信息不够记得把完整的编译日志、设备树文件、甚至芯片手册的相关章节一起喂给它。这比单纯说“还是不行”有效得多。有时候 AI 给我方案的思路和我的习惯不一样我不会直接否定而是先问一句“这样做的风险是什么”它会给出一个更立体的分析。5.3 下一步的趋势AI 帮你生成测试用例但可靠性还得自己扛我发现 AI 在嵌入式领域一个非常有潜力的用途是“生成测试用例和自动化回归”。比如你写了一个环形缓冲区可以让 AI 生成大量随机读写、断言的测试代码然后在开发板上跑起来。这种“AI 生成测试人来做判决”的模式会在很大程度上提升嵌入式软件的可靠性。但最终的可靠性认证比如安全认证、一致性测试AI 是替代不了的这部分需要人来负责。热词里“嵌入式架构设计 项目 github”说明越来越多的人在公开社区分享 AI 辅助嵌入式项目的完整流程这对整个行业来说是好事。我建议同行们可以多关注端侧 AI 和嵌入式结合的方向因为 AI 既是工具也是产品功能。一个嵌入式工程师如果能把基础硬件能力、AI 工具使用能力和端侧模型部署经验结合起来在未来几年的竞争力会非常强。最后说一点个人体会AI 对我来说更像一个“读过万卷书但没上过战场”的同事能给你提供大量参考资料和代码草稿但真到板子跑不通的时候你还是得自己拿着示波器去测引脚。不要迷信 AI也不要无视 AI把它当成一个随叫随到的助手嵌入式行业依然是那个需要耐心、细心和责任心的行业。
