AI再聪明，也看不见你板子上的那根飞线

纯应用层开发里，很多问题会以比较清楚的方式出现：接口报错、日志堆栈、异常码、请求超时、数据库连接失败。虽然也复杂，但至少系统愿意给你一些文字证据。

嵌入式软件不一样。

它经常只给你一个现象。

• UART 偶发丢一帧。
• I2C 总线偶尔挂死。
• ADC 数据在某个工况下突然抖动。
• 电机运行一段时间后任务卡住。
• 低温正常，高温复现。
• 实验室正常，客户现场复现。
• 换一块板子正常，换回来又坏。
• 加一行日志后问题消失。

这些问题很少有一条干净的调用栈。它们更像现场事故，需要把电气、时序、任务调度、协议、硬件差异和历史版本放在一起看。

这就是嵌入式问题的常态。代码只是其中一部分，而且不一定是最先出问题的那部分。

如果只把源码丢给 AI，它会默认从代码文本里找答案。它可能会找到一些真实风险，也可能会把一个硬件时序问题分析成软件逻辑问题。

这就是“没有现场感”的代价。

所以，现场感到底包括什么？

我现在会把“现场感”拆成六类资料。不是每次都要全部准备，但遇到复杂问题时，缺哪一类，AI 就容易往哪一类误判。

很多时候，真正关键的不是多贴代码，而是把这些信息说清楚。

嵌入式问题经常藏在边界条件里：

• 中断和任务同时访问同一个标志位。
• DMA 写指针更新和缓存拷贝顺序刚好反过来。
• 看门狗喂狗任务低优先级，被一个长时间临界区饿住。
• I2C 错误恢复时没有释放总线。
• ADC 采样和 PWM 噪声在某个占空比下重合。
• 旧协议兼容分支只在某个客户固件版本触发。

这些都不是单看一两个函数就能稳稳判断的。

那怎么办？

可以先让 AI 画链路，再让它动代码。

我现在不会一上来就让 AI 改。

复杂问题里，我会先让它输出故障链路图。

图画不清，代码大概率也改不准。

例如看门狗复位，先让它梳理：

这张图不是为了好看，而是为了逼它把时间关系讲出来。

嵌入式问题里，时间关系经常比调用关系更重要。

函数调用图只能告诉你谁调用了谁，不能告诉你谁抢占了谁、谁等了谁、谁在中断里做了不该做的事。

让 AI 先画链路，可以提前暴露很多问题：

• 它有没有分清中断上下文和任务上下文。
• 它有没有注意到队列满、信号量等待、临界区长度。
• 它有没有把 DMA 回调和协议解析混在一起。
• 它有没有考虑看门狗任务可能被饿住。
• 它有没有把硬件条件纳入判断。

如果这些没讲清楚，就不要急着让它写补丁。

AI不能凭空拥有现场感。

没有现场感时，它只能从代码文本里猜。猜对了很惊艳，猜错了也很自信。

有现场感时，它才会开始像一个真正加入项目组的新同事：知道这块板子有历史版本，知道中断里不能乱打日志，知道某个 GPIO 不能碰，知道客户现场那个旧固件还在跑，知道修完以后必须上板、回放、升温、跑长时间。

所以，给得越像真实工程现场，它越像工程师。