正文大家好我是bug菌~最近跟几个朋友唠嗑经常聊到AI给我们嵌入式软硬件行业带来的冲击当然还有一些关于AI的有趣见闻我发现现在开始有些工程师慢慢的染上了“AI病”你们看看是不是有这些症状:1代码不会写了以前嵌入式软件工程师们要写出一个完整、健壮高效的的MCU串口中断服务函数他得清楚知道NVIC的优先级分组、DMA的双缓冲模式、环形缓冲区的指针该在什么时候回绕等等一系列技术问题还得联调测试。而现在很多工程师打开AI对话框 → 输入“用HAL库写一个USART3的DMA收发波特率1152008N1开启空闲中断” → 复制粘贴 → 改几个宏定义 → 编译。上周review一位新同事的代码他在某个驱动程序里面增加了个HAL_Delay(10)我当时就问他这里为什么是10ms。他愣了一下说“当时调试的时候不记得了好像只有加了这行延时代码才好使而且我也用AI确认过没问题”。那一刻我后背发凉那部分驱动代码AI味挺浓的连自己都没理解的AI代码你还真敢上~2调试能力退化其实嵌入式开发最残酷的现实是硬件不会说谎很多bug其实是来源于物理根源。以前遇到问题大部分务实的工程师会把持着这些工具链示波器探头 → 逻辑分析仪 → 万用表 → JTAG单步 → 看汇编。每一个环节都需要动手、动脑、动经验。现在AI时代很多时候大家都是把错误日志丢给AI → 等它给建议 → 按建议改代码 → 烧录测试 → 不行就再问一次。如果三次还不奏效我就开始“玄学调试”换一根USB线、重启电脑、甚至对着开发板念咒语。上周有个同事调试一个USB枚举失败的问题他首先就是问AIAI回复了一堆原因他逐一尝试了各种办法问题依旧。折腾了几个小时后终于架起了示波器发现D线上的上拉电阻焊接虚焊1.5kΩ变成了开路AI在你们眼里就这么权威吗连自己这么多年工作经验就不相信了花了这么多时间向AI讨教不如几分钟实实在在的回归问题的本质。这不就是把本该属于工程师的“直觉”和“系统思维”外包给了一个语言模型至少短期内语言模型不可能替你去看波形、测信号、闻有没有焦糊味。3架构哪里萎缩AI目前能够做的无非就是开放信息的整合它并不了解你实际的需求甚至你问同一个问题它都无法给出相同的答案。在当前的语境下没法跟你考虑到如此优雅的递归函数会把仅有8KB的栈空间撑爆更不会考虑你的产品要在-40℃到85℃的环境下稳定运行。习惯了AI的“喂食”之后很多人开始丧失从整体上审视系统的能力。工程代码变成了各种AI生成片段的缝合怪。更可怕的是你会发现自己开始“以AI的方式思考问题”——追求单点解决忽略全局约束追求代码简洁忽略硬件特性追求快速实现忽略长期维护。一个嵌入式系统的寿命是五到十年后续到底是AI来维护还是你来维护4对硬件的理解嵌入式工程师和纯软件工程师最大的区别是我们对硬件的理解。我们知道每一个比特最终都会变成电信号在铜皮上以接近光速传播受到EMI干扰、电源纹波、温度漂移、晶振误差的影响。我们知道写Flash有寿命限制知道看门狗不是用来处理业务逻辑的知道中断服务函数里不该做的事比该做的事多得多。这些东西你不跟AI说清楚它不知道AI不了解你的情况然而有些东西又岂是几句话就能说清楚的呢5小结一下AI病不是简单的“用AI写代码”。工具从来无罪有罪的是使用工具的方式。AI病的本质是用快捷方式代替了理解用效率掩盖了无知。我们误以为既然AI能写出可运行的代码那我们就不需要理解那些代码背后的原理。我们误以为既然AI能快速定位问题那我们就不需要建立系统的调试方法论。我们误以为既然AI可以帮我们完成80%的工作那我们剩下的20%就只是修修补补。但嵌入式工程不是这样的。嵌入式工程是关于“确定性”的工程。一个嵌入式系统是否可靠取决于工程师对每一个比、微秒、毫瓦的掌控程度。你可以让AI帮你写代码但你无法让AI替你承担对系统的责任。当产品在用户现场死机、在极端环境下重启、在关键时刻丢失数据的时候客户不会听你解释“这是AI生成的代码”。客户只会说你们工程师连这点事都搞不定最后好了今天就跟大家分享这么多了如果你觉得有所收获一定记得点个赞~唯一、永久、免费分享嵌入式技术知识平台~推荐专辑 点击蓝色字体即可跳转☞MCU进阶专辑☞嵌入式C语言进阶专辑☞“bug说”专辑☞专辑|Linux应用程序编程大全☞专辑|学点网络知识☞专辑|手撕C语言☞专辑|手撕C语言☞专辑|经验分享☞专辑|电能控制技术☞专辑 | 从单片机到Linux