当嵌入式工程师 染上了“AI 病“~
正文
大家好，我是bug菌~
最近跟几个朋友唠嗑，经常聊到AI给我们嵌入式软硬件行业带来的冲击，当然还有一些关于AI的有趣见闻，我发现现在开始有些工程师慢慢的染上了“AI病”，你们看看是不是有这些症状:
1
代码不会写了
以前嵌入式软件工程师们，要写出一个完整、健壮高效的的MCU串口中断服务函数，他得清楚知道NVIC的优先级分组、DMA的双缓冲模式、环形缓冲区的指针该在什么时候回绕等等一系列技术问题，还得联调测试。
而现在很多工程师：打开AI对话框 → 输入“用HAL库写一个USART3的DMA收发，波特率115200，8N1，开启空闲中断” → 复制粘贴 → 改几个宏定义 → 编译。
上周review一位新同事的代码，他在某个驱动程序里面增加了个HAL_Delay(10)
我当时就问他这里为什么是10ms。他愣了一下，说：“当时调试的时候不记得了，好像只有加了这行延时代码才好使，而且我也用AI确认过没问题”。
那一刻我后背发凉，那部分驱动代码AI味挺浓的，连自己都没理解的AI代码，你还真敢上~
2
调试能力退化
其实嵌入式开发最残酷的现实是：硬件不会说谎，很多bug其实是来源于物理根源。
以前遇到问题，大部分务实的工程师会把持着这些工具链：示波器探头 → 逻辑分析仪 → 万用表 → JTAG单步 → 看汇编。每一个环节都需要动手、动脑、动经验。
现在AI时代，很多时候大家都是：把错误日志丢给AI → 等它给建议 → 按建议改代码 → 烧录测试 → 不行就再问一次。如果三次还不奏效，我就开始“玄学调试”：换一根USB线、重启电脑、甚至对着开发板念咒语。
上周有个同事调试一个USB枚举失败的问题，他首先就是问AI，AI回复了一堆原因，他逐一尝试了各种办法，问题依旧。折腾了几个小时后，终于架起了示波器，发现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