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

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把嵌入式开发里最脏的那部分活——配环境、写模板、改配置、生成模板代码——处理得比大多数初级工程师都好。YesNo需求描述AI生成代码框架工程师Review验证时序/硬件约束满足?集成测试手动调整寄存器/时序但AI在嵌入式领域的三个死穴吹完AI说点实话。我在实际项目里踩过的坑告诉我AI在以下三个场景里跟废物一样。死穴1AI不理解物理世界纯软件的世界里输入输出是确定的。你给一个JSON它返回另一个JSON。出错了有stack trace。嵌入式不一样。你的代码最终要控制一个物理设备。电机转没转、LED亮不亮、UART有没有毛刺——这些不是AI能推理出来的。我见过一个团队用AI写了一个PWM驱动。代码逻辑完全正确寄存器配置也对着芯片手册来。但烧进去之后电机不转。为什么因为AI不知道这个芯片的PWM输出引脚默认是GPIO功能需要在pinmux寄存器里先切到PWM模式——这个信息不在主手册里在芯片的勘误表里在论坛的某个深水帖里。AI不知道这种隐含知识。你也不知道但你有示波器你能点波形你能推理出问题在哪。这就是你的价值。死穴2AI不懂成本写嵌入式软件的终极约束不是能不能实现而是多少钱能实现。这颗MCU涨价了换个便宜方案代码得重写——AI不知道BOM预算。这个功能的实现需要增加一片额外的Flash芯片——AI不知道硬件团队能不能挤出PCB空间。这个算法精度高5%但RAM多占20KB——AI不知道这20KB可能会让系统OOM。我做过的项目里至少有一半的技术决策本质上是成本决策。AI可以帮你写代码但AI不会帮你算账。死穴3AI会给看起来对但实际错的代码这是最危险的。前几天我测试一个AI生成的网络协议栈代码。看起来完美注释清晰、结构合理、API设计优雅。然后我用strace跟踪了一下——它在每次recv()之前都调了一次sleep(1)。AI的理由是防止CPU忙等。问题是这是嵌入式系统100ms的延时意味着这个设备在工业总线上会超时整个产线都得停。AI生成的代码往往看起来对但用起来错。它不会在代码里写注释说这里的超时值是我瞎猜的您根据实际硬件调一下——它就给你个100ms看起来像专业建议。有经验的工程师无经验的工程师AI生成代码Review发现隐含问题时序/功耗/安全直接烧录生产环境炸了修改后可用洗牌会发生什么我不是在唱衰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替代的名单上你的名字确实在最前面。