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

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