在纯应用层开发领域，大多数问题都表现得相当"友好"。接口出错会返回清晰的状态码，日志崩溃能提供完整的堆栈信息，数据库连接失败则会抛出明确的异常编号。虽然排查过程同样需要投入精力，但至少系统会给出具体的文字线索，让你能够沿着明确的方向追查问题根源。

然而在嵌入式软件开发中，情况则截然不同——它往往只呈现一个现象，没有任何文字说明或错误提示。

比如：

• UART 通信偶尔丢失一帧数据，无明显规律。
• I2C 总线在运行过程中突然挂死，无法自动恢复。
• ADC 采集的数据在特定工况下出现异常抖动。
• 电机持续运转一段时间后，整个任务莫名卡死。
• 低温环境下一切正常，温度升高后问题立即复现。
• 实验室测试完全正常，部署到客户现场便出现故障。
• 更换一块板子就恢复正常，换回原板又复现问题。
• 更令人头疼的是，多添加一行日志代码，问题就神奇消失。

这类问题几乎不可能提供一条完整的调用栈。它们更像是一起"现场事故"，需要你将电气特性、时序逻辑、任务调度、协议交互、硬件差异，甚至历史版本变更记录全部摊开，进行综合分析。

这就是嵌入式问题排查的常态——代码只是拼图中的一块，而且往往不是最先出现问题的环节。

如果仅仅把源码交给AI分析，它会本能地从文本中寻找答案。这种方式有时确实能发现一些真实风险，但也极有可能将一个硬件时序问题，硬生生地分析成软件逻辑错误——这就是缺乏"现场感"所付出的代价。

那么，嵌入式调试中的"现场感"究竟包含哪些要素？

接下来，我们将"现场感"拆解为六类关键资料。并非每次排查都需要全部备齐，但在处理复杂问题时，缺少任何一类，AI都容易朝缺失的方向产生误判。

很多时候，真正关键的因素并非贴出更多代码，而是将这些上下文信息清晰准确地描述出来。嵌入式问题往往隐藏在各类边界条件之中：

• 中断服务函数与任务同时访问同一个标志位，未进行互斥保护。
• DMA 写指针的更新顺序与缓存拷贝的执行顺序恰好相反。
• 看门狗喂狗任务的优先级设置过低，被长时间运行的临界区阻塞导致饿死。
• I2C 错误恢复流程中遗漏了总线释放操作。
• ADC 的采样时刻与 PWM 产生的噪声在特定占空比下恰好重合。
• 某个旧协议的兼容分支，仅在特定客户的固件版本中才会被触发。

上述问题，都不是仅凭查看一两个函数就能准确定位的。

如何应对？先绘制故障链路图，再着手修改代码。

正确的做法是，不要一开始就让AI直接修改代码。面对复杂问题时，应首先让其输出一张完整的故障链路图。如果链路图绘制不清晰，代码修改大概率也无法准确。

举个例子，在排查"看门狗复位"问题时，可以先让它梳理出一条完整的事件链：

【图片：看门狗复位故障链路图】

绘制这张图并非为了美观，而是迫使AI将时间关系梳理清楚。在嵌入式系统中，时间关系的重要性往往超越函数调用关系。函数调用图只能显示谁调用了谁，却无法揭示谁抢占了谁、谁在等待谁、以及哪个中断服务函数执行了不应有的长耗时操作。

让AI先绘制链路图，可以提前暴露许多潜在问题：

• 它是否清晰区分了中断上下文与任务上下文？
• 它是否关注到队列已满、信号量超时等待、临界区过长等状态？
• 它是否将DMA回调与协议解析逻辑混为一谈？
• 它是否考虑到看门狗喂狗任务本身也存在被饿死的风险？
• 它是否将硬件条件（如电源波动、温度变化）纳入了判断逻辑？

如果这些问题都没有梳理清楚，就不要急于让AI编写补丁。

归根结底，AI无法凭空获得现场感。缺乏现场感时，它只能从代码文本中"猜测"。猜对了固然惊艳，猜错了却异常自信。而拥有了现场感之后，它就会像一位真正加入项目组的新同事：了解这块板子有哪些历史版本遗留的陷阱，知道中断中不能随意打印日志，清楚某个GPIO引脚绝对不能改动，明白客户现场还有旧固件在运行，懂得修复之后必须上板测试、回放数据、升温老化、长时间拷机验证。

因此，提供的信息越贴近真实的工程现场，AI的分析结果才会越准确可靠。