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

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

嵌入式软件不一样。它经常只给你一个现象：UART 偶发丢一帧、I2C 总线偶尔挂死、ADC 数据在某个工况下突然抖动、电机运行一段时间后任务卡住、低温正常高温复现、实验室正常客户现场复现、换一块板子正常换回来又坏、加一行日志后问题消失。

这些问题很少有一条干净的调用栈。它们更像现场事故，需要把电气、时序、任务调度、协议、硬件差异和历史版本放在一起看。这就是嵌入式问题的常态——代码只是其中一部分，而且不一定是最先出问题的那部分。

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

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

很多时候，真正关键的不是多贴代码，而是把这些信息说清楚。嵌入式问题经常藏在边界条件里：中断和任务同时访问同一个标志位、DMA 写指针更新和缓存拷贝顺序刚好反过来、看门狗喂狗任务低优先级被一个长时间临界区饿住、I2C 错误恢复时没有释放总线、ADC 采样和 PWM 噪声在某个占空比下重合、旧协议兼容分支只在某个客户固件版本触发。这些都不是单看一两个函数就能稳稳判断的。

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

我现在不会一上来就让 AI 改。复杂问题里，我会先让它输出故障链路图。图画不清，代码大概率也改不准。

比如看门狗复位，先让它梳理链路图：

这张图不是为了好看，而是为了逼它把时间关系讲出来。嵌入式问题里，时间关系经常比调用关系更重要。函数调用图只能告诉你谁调用了谁，不能告诉你谁抢占了谁、谁等了谁、谁在中断里做了不该做的事。

让 AI 先画链路，可以提前暴露很多问题：它有没有分清中断上下文和任务上下文、有没有注意到队列满/信号量等待/临界区长度、有没有把 DMA 回调和协议解析混在一起、有没有考虑看门狗任务可能被饿住、有没有把硬件条件纳入判断。如果这些没讲清楚，就不要急着让它写补丁。

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

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

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