AI写代码时代，嵌入式工程师到底会不会被淘汰？我的答案是：不会，但你会被会用AI的同事淘汰

一句话观点：AI写业务代码已经能打80分了，但嵌入式开发剩下的20分——硬件时序、中断延迟、功耗约束、信号完整性——恰好是AI的盲区，也是你值钱的地方。

先看两条今天的新闻。

第一条：Bun（一个JavaScript运行时）宣布把核心代码从Zig重写为Rust，用AI在11天内完成了"机械移植"。代码能编译、测试能过、性能还提升了。

第二条：Grok Build CLI被曝静默上传完整代码仓库到xAI服务器。安全研究员抓包发现，你满心信任地让它帮你写代码，它在背后把你的整个项目连根打包上传了。

这两个事放在一起看，很有意思。

一边是AI写代码的效率已经离谱到可以11天完成一门语言的跨语言重写，另一边是AI工具连基本的代码安全边界都守不住——你都不敢把公司核心代码喂给它。

作为一个在嵌入式行业摸爬滚打18年的人，我的判断是：AI对嵌入式行业的影响，不是"替代"而是"洗牌"。

洗掉的是那些只会"调API-调库-调参数"的嵌入式工程师，留下的是真正懂"硬件怎么工作、时序怎么收敛、系统怎么稳定"的人。

---

AI现在能做什么？说实话，不少

先说句公道话。如果你还觉得AI写代码是"玩具"，那是你没好好用。

我拿我自己最近的两个例子来说：

案例1：写一个Linux SPI设备驱动

以前：翻芯片手册→看内核同名驱动→对着寄存器抄→编译→挂掉→printk调三天。

现在：把芯片手册PDF扔给Claude Code或GitHub Copilot，描述需求。它5分钟给你一个能编译通过的驱动框架。然后你只需要验证时序对不对、寄存器偏移对不对。

案例2：写一个Yocto/Buildroot的recipe/package配置

以前：翻Yocto手册找变量名，写错了BB_NUMBER_THREADS拼成BB_NUMBER_THREAD，编译到一半才报错。

现在：AI直接生成recipe，甚至能把依赖关系帮你理清楚，make menuconfig都不用开。

说句实话，AI把嵌入式开发里最"脏"的那部分活——配环境、写模板、改配置、生成模板代码——处理得比大多数初级工程师都好。

---

但AI在嵌入式领域的三个死穴

吹完AI，说点实话。我在实际项目里踩过的坑告诉我，AI在以下三个场景里跟废物一样。

死穴1：AI不理解"物理世界"

纯软件的世界里，输入输出是确定的。你给一个JSON，它返回另一个JSON。出错了有stack trace。

嵌入式不一样。你的代码最终要控制一个物理设备。 电机转没转、LED亮不亮、UART有没有毛刺——这些不是AI能"推理"出来的。

我见过一个团队用AI写了一个PWM驱动。代码逻辑完全正确，寄存器配置也对着芯片手册来。但烧进去之后电机不转。为什么？因为AI不知道这个芯片的PWM输出引脚默认是GPIO功能，需要在pinmux寄存器里先切到PWM模式——这个信息不在主手册里，在芯片的"勘误表"里，在论坛的某个深水帖里。

AI不知道这种"隐含知识"。你也不知道，但你有示波器，你能点波形，你能推理出问题在哪。这就是你的价值。

死穴2：AI不懂"成本"

写嵌入式软件的终极约束不是"能不能实现"，而是"多少钱能实现"。

• 这颗MCU涨价了，换个便宜方案，代码得重写——AI不知道BOM预算。
• 这个功能的实现需要增加一片额外的Flash芯片——AI不知道硬件团队能不能挤出PCB空间。
• 这个算法精度高5%，但RAM多占20KB——AI不知道这20KB可能会让系统OOM。

我做过的项目里，至少有一半的"技术决策"本质上是"成本决策"。AI可以帮你写代码，但AI不会帮你算账。

死穴3：AI会给看起来对但实际错的代码

这是最危险的。

前几天我测试一个AI生成的网络协议栈代码。看起来完美：注释清晰、结构合理、API设计优雅。然后我用strace跟踪了一下——它在每次recv()之前都调了一次sleep(1)。

AI的"理由"是：防止CPU忙等。

问题是这是嵌入式系统，100ms的延时意味着这个设备在工业总线上会超时，整个产线都得停。

AI生成的代码往往"看起来对"但"用起来错"。 它不会在代码里写注释说"这里的超时值是我瞎猜的，您根据实际硬件调一下"——它就给你个100ms，看起来像专业建议。

---

"洗牌"会发生什么？

我不是在唱衰AI。我的判断是：

未来3-5年，嵌入式行业会分成三层：

层级	能力	会被AI替代吗？
第一层：调API写业务逻辑	用现成SDK做应用开发	高度可能
第二层：驱动+系统移植	写驱动、移植内核、调BSP	部分替代（效率提升）
第三层：芯片级+系统架构	芯片验证、时序收敛、功耗架构	几乎不可能

第一层的人，老实说已经能感受到压力了。AI能写STM32的HAL库调用、能生成ESP32的网络应用代码、能把Arduino示例改一改就拿出来干活。

第二层的人，AI是你的"超级实习生"——能帮你干80%的重复工作，但最后的20%需要你来收尾。用AI的人效率是没用的人的两倍，这不是AI替代你，是用AI的人替代不用AI的人。

第三层的人，暂时安全。因为你解决的问题没有标准答案，没有现成代码，甚至芯片手册都还在NDA阶段。AI连数据都拿不到，怎么帮你写？

---

我给嵌入式工程师的建议

1. 别对抗AI，学会用它

这是我见过最傻的事。有人说"我坚持手写，这样才能保持对代码的理解"——你写100行Makefile模板的时间，AI已经帮你生成好了，你把精力省下来去调那个死活不对的I2C时序不好吗？

我现在的开发工作流：

• AI写框架我写逻辑
• AI生成第一版我来改到能用
• AI写测试用例我来写边界条件

2. 死磕硬件基础知识

越底层的知识越值钱。中断延迟、Cache一致性、DMA传输时序、信号完整性——这些是AI的盲区。你学得越深，AI越替代不了你。

3. 理解业务，不仅仅是代码

为什么这个功能值500万？为什么这个bug会导致客户损失？为什么这个方案比那个方案好不是因为技术而是因为供应链？这些问题AI回答不了，但你能。

---

最后说一句

Bun用AI在11天完成Zig到Rust的移植，听起来很吓人。

但你注意一下新闻的细节：它叫"机械移植"——就是把同样逻辑用不同语言翻译一遍。真正的难点从来不是"翻译代码"，而是"设计系统"、“权衡约束”、“解决问题”。

嵌入式工程师的护城河从来不是你会写C还是Rust，是你懂硬件、懂系统、懂物理世界。

AI不是来抢你饭碗的，是来帮你把时间从"写模板代码"里解放出来，去做真正需要你做的事。

只要你愿意学、愿意往上走，你的饭碗比那些"写业务API"的纯软件工程师稳得多。

但如果你只会调HAL库、只会复制粘贴SDK示例、只会做"第一层"的事——那AI替代的名单上，你的名字确实在最前面。