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

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

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

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

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

现场资料应该怎么描述不描述的后果现象什么时候发生、频率多少、表现是什么AI 会把偶发问题当成稳定 bug硬件板卡版本、电源、传感器、飞线、外设连接AI 会忽略硬件差异和电气边界时序中断频率、DMA 行为、采样点、通信周期AI 会只看函数调用，不看时间关系软件状态RTOS 任务、队列、栈、堆、版本、配置宏AI 会漏掉任务调度和编译差异历史约束哪些代码不能动，为什么不能动AI 会给出无法落地的重构建议验证方法怎么复现，怎么确认修好了AI 会停在“看起来合理”的补丁上

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

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

• 中断和任务同时访问同一个标志位。

• DMA 写指针更新和缓存拷贝顺序刚好反过来。

• 看门狗喂狗任务低优先级，被一个长时间临界区饿住。

• I2C 错误恢复时没有释放总线。

• ADC 采样和 PWM 噪声在某个占空比下重合。

• 旧协议兼容分支只在某个客户固件版本触发。

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

那怎么办？

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

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

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

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

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

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

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

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

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

• 它有没有分清中断上下文和任务上下文。

• 它有没有注意到队列满、信号量等待、临界区长度。

• 它有没有把 DMA 回调和协议解析混在一起。

• 它有没有考虑看门狗任务可能被饿住。

• 它有没有把硬件条件纳入判断。

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

AI不能凭空拥有现场感。

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

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

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