嵌入式工程师如何避免AI依赖症

1. 嵌入式工程师的"AI依赖症"现象剖析

最近半年，我在团队管理中发现一个令人担忧的趋势：越来越多的嵌入式工程师开始过度依赖AI工具解决问题。上周代码评审时，一位工作3年的工程师提交的串口驱动模块让我印象深刻——代码结构工整、注释规范，但当我询问某个延时参数的设计依据时，他却支支吾吾答不上来。后来他坦言，整个模块都是通过AI生成的，自己只是做了简单适配。

这种现象我称之为"AI依赖症"，主要表现在三个维度：

1.1 基础能力退化

传统嵌入式开发需要掌握的技能树正在被快速侵蚀。以USART通信为例，合格的工程师应该清楚：

• NVIC优先级分组对中断响应的影响（如Group4和Group0的区别）
• DMA双缓冲机制的内存对齐要求
• 空闲中断与接收完成中断的配合时序
  但现在，这些知识正在变成"可选项"。就像我团队那位同事说的："既然AI能直接给出可运行的代码，为什么还要记这些细节？"

1.2 调试方法论异化

上周处理的一个典型案例：某物联网终端设备频繁出现SPI通信失败。两位工程师的排查方式形成鲜明对比：

• 新人小王：将错误日志喂给AI，尝试了软件复位、降低时钟频率等建议方案
• 资深老张：用示波器捕获CS/CLK信号，发现PCB走线过长导致信号完整性下降

最终是老张通过缩短走线长度解决了问题。这个案例暴露出：过度依赖AI会导致工程师忽视最基础的硬件调试手段——示波器、逻辑分析仪、万用表这些工具正在被冷落。

1.3 系统思维缺失

最危险的趋势是全局视角的丧失。AI生成的代码往往是"片段式"的，缺乏：

• 资源约束考量（如Flash寿命、RAM占用）
• 环境适应性设计（如-40℃低温启动）
• 长期可维护性（如寄存器版本兼容）

我见过最极端的案例：某温控设备使用AI生成的PID算法，在实验室运行完美，但现场部署后频繁死机。后来发现是AI没有考虑STM32的FPU性能限制，在低温环境下出现计算溢出。

2. AI工具在嵌入式开发中的合理定位

2.1 当前AI的技术边界

必须清醒认识到，现有AI（如ChatGPT、Copilot）在嵌入式领域存在明显局限：

2.2 工具与责任的边界划分

我在团队内制定了AI使用红线：

1. 关键安全模块（如看门狗、电源管理）禁止直接使用AI代码
2. 所有AI生成的代码必须附加详细注释说明设计依据
3. 硬件相关操作（如寄存器配置）必须比对参考手册验证

一个典型案例：某电机驱动项目中使用AI生成的PWM配置代码，虽然功能正常，但未考虑死区时间设置。后来在我的坚持下，工程师重新查阅STM32参考手册（RM0390），补充了BDTR寄存器的配置，避免了潜在的桥臂直通风险。

3. 构建抗"AI病"的免疫力体系

3.1 基础能力强化训练

我们团队现在每周举行"回到基本功"研讨会，例如：

• 寄存器级编程实战：用标准外设库重写HAL库功能
• 示波器挑战赛：通过波形诊断SPI通信故障
• 内存分析演练：用map文件优化RAM使用

最近一次活动中，我们重现了经典问题：为什么在中断服务例程中调用printf会导致HardFault？通过反汇编分析，新人工程师真正理解了栈溢出机制，这比任何AI解释都更令人印象深刻。

3.2 系统思维培养方法

我总结了一套"5W1H"代码审查法：

• Why：这段代码解决什么问题？
• What：依赖哪些硬件资源？
• Where：运行在什么上下文（中断/主循环）？
• When：时序关键路径在哪里？
• Who：后续维护者如何理解设计意图？
• How：如何验证功能正确性？

应用这个框架后，团队提交的AI生成代码质量显著提升。例如某CAN总线驱动改造项目，工程师主动补充了：

• 总线负载率计算说明
• 错误帧统计实现
• 冷启动同步机制

3.3 建立AI使用规范

我们制定的《AI辅助开发指南》核心条款包括：

1. 禁止直接提交未经理解的AI代码
2. 硬件相关代码必须附带参考手册条目
3. 关键参数（如时序、门限）需提供计算过程
4. 异常处理流程必须人工设计
5. 资源使用情况（ROM/RAM/CPU）需明确标注

这份指南的实践效果很好。上个月的BLE Mesh项目中，虽然使用了AI生成的基础协议栈适配代码，但工程师严格遵循规范，补充了：

• RF功率调整策略
• 中继节点功耗预算
• 网络密钥更新机制

4. 典型案例深度解析

4.1 USB枚举失败事件复盘

回到文中提到的USB问题，完整的技术细节值得展开：

1. 问题现象：设备在Windows能识别，但Linux下枚举失败

2. AI建议路径：

   • 检查描述符配置（尝试无效）
   • 调整端点大小（无改善）
   • 更换USB库版本（问题依旧）

3. 硬件排查过程：

   • 示波器捕获D+线：发现1.65V电平异常（正常应为3.3V）
   • 万用表测量：1.5kΩ上拉电阻两端压降异常
   • 热成像检查：电阻焊点温度异常

4. 根本原因：0402封装电阻虚焊，导致上拉无效

这个案例完美展示了硬件问题的典型特征：

• 软件层面的修改无效
• 需要物理测量工具介入
• 最终解决方案是返修而非改代码

4.2 温度传感器误报分析

另一个典型案例：某工业设备在高温环境下频繁报告温度异常。AI给出的建议是：

• 校准ADC参考电压
• 增加软件滤波
• 检查传感器供电

实际排查发现：

1. 传感器I2C走线与电机PWM线平行
2. 高频干扰导致信号畸变
3. 解决方案：重新布线+增加磁珠滤波

这个教训告诉我们：AI很难理解PCB布局等物理设计约束。

5. 健康使用AI的实践建议

5.1 作为增强工具而非替代品

我推荐的分工模式：

• AI负责：模板代码生成、文档查询、语法检查
• 工程师负责：架构设计、硬件适配、异常处理

例如开发Modbus RTU从站：

1. 用AI生成协议解析框架
2. 人工添加：
   • RS485方向控制逻辑
   • 超时重传机制
   • 异常状态指示灯控制

5.2 建立验证闭环

每个AI生成的模块都需要：

1. 静态检查：代码审查+资源分析
2. 动态验证：单元测试+硬件测试
3. 环境测试：高低温循环、振动测试

我们某个车载项目中的实践：

• AI生成CAN通信代码
• 人工补充：
  • 总线off恢复策略
  • 错误帧统计
  • 负载率监控
• 测试环节：
  • 注入电磁干扰
  • 模拟电源波动
  • 极限温度测试

5.3 持续学习计划

为防止技术能力退化，我们团队：

1. 每月研究一个MCU外设的寄存器级实现
2. 每季度拆解一个经典开源项目（如FreeRTOS）
3. 每年完成一个全手工打造的练手项目（最近在做示波器）

这些实践带来的收获是AI无法替代的——就像我常对团队说的："你可以用AI写printf，但必须自己实现格式化输出；你可以用AI配置ADC，但必须清楚采样保持电路的原理。"