纯应用层开发里，很多问题会以比较清楚的方式出现：接口报错、日志堆栈、异常码、请求超时、数据库连接失败。虽然也复杂，但至少系统愿意给你一些文字证据。
嵌入式软件不一样。
它经常只给你一个现象。
- UART 偶发丢一帧。
- I2C 总线偶尔挂死。
- ADC 数据在某个工况下突然抖动。
- 电机运行一段时间后任务卡住。
- 低温正常，高温复现。
- 实验室正常，客户现场复现。
- 换一块板子正常，换回来又坏。
- 加一行日志后问题消失。
这些问题很少有一条干净的调用栈。它们更像现场事故，需要把电气、时序、任务调度、协议、硬件差异和历史版本放在一起看。
这就是嵌入式问题的常态。代码只是其中一部分，而且不一定是最先出问题的那部分。
如果只把源码丢给 AI，它会默认从代码文本里找答案。它可能会找到一些真实风险，也可能会把一个硬件时序问题分析成软件逻辑问题。
这就是“没有现场感”的代价。
所以，现场感到底包括什么？
我现在会把“现场感”拆成六类资料。不是每次都要全部准备，但遇到复杂问题时，缺哪一类，AI 就容易往哪一类误判。
| 现场资料 | 应该怎么描述 | 不描述的后果 |
|---|---|---|
| 现象 | 什么时候发生、频率多少、表现是什么 | AI 会把偶发问题当成稳定 bug |
| 硬件 | 板卡版本、电源、传感器、飞线、外设连接 | AI 会忽略硬件差异和电气边界 |
| 时序 | 中断频率、DMA 行为、采样点、通信周期 | AI 会只看函数调用，不看时间关系 |
| 软件状态 | RTOS 任务、队列、栈、堆、版本、配置宏 | AI 会漏掉任务调度和编译差异 |
| 历史约束 | 哪些代码不能动，为什么不能动 | AI 会给出无法落地的重构建议 |
| 验证方法 | 怎么复现，怎么确认修好了 | AI 会停在“看起来合理”的补丁上 |
很多时候，真正关键的不是多贴代码，而是把这些信息说清楚。
嵌入式问题经常藏在边界条件里：
- 中断和任务同时访问同一个标志位。
- DMA 写指针更新和缓存拷贝顺序刚好反过来。
- 看门狗喂狗任务低优先级，被一个长时间临界区饿住。
- I2C 错误恢复时没有释放总线。
- ADC 采样和 PWM 噪声在某个占空比下重合。
- 旧协议兼容分支只在某个客户固件版本触发。
这些都不是单看一两个函数就能稳稳判断的。
那怎么办？
可以先让 AI 画链路，再让它动代码。
我现在不会一上来就让 AI 改。
复杂问题里，我会先让它输出故障链路图。
图画不清，代码大概率也改不准。
例如看门狗复位，先让它梳理：
这张图不是为了好看，而是为了逼它把时间关系讲出来。
嵌入式问题里，时间关系经常比调用关系更重要。
函数调用图只能告诉你谁调用了谁，不能告诉你谁抢占了谁、谁等了谁、谁在中断里做了不该做的事。
让 AI 先画链路，可以提前暴露很多问题：
- 它有没有分清中断上下文和任务上下文。
- 它有没有注意到队列满、信号量等待、临界区长度。
- 它有没有把 DMA 回调和协议解析混在一起。
- 它有没有考虑看门狗任务可能被饿住。
- 它有没有把硬件条件纳入判断。
如果这些没讲清楚，就不要急着让它写补丁。
AI不能凭空拥有现场感。
没有现场感时，它只能从代码文本里猜。猜对了很惊艳，猜错了也很自信。
有现场感时，它才会开始像一个真正加入项目组的新同事：知道这块板子有历史版本，知道中断里不能乱打日志，知道某个 GPIO 不能碰，知道客户现场那个旧固件还在跑，知道修完以后必须上板、回放、升温、跑长时间。
所以，给得越像真实工程现场，它越像工程师。
