純應用層開發里，很多問題會以比較清楚的方式出現：接口報錯、日志堆棧、異常碼、請求超時、數據庫連接失敗。雖然也復雜，但至少系統愿意給你一些文字證據。
嵌入式軟件不一樣。
它經常只給你一個現象。
這些問題很少有一條干凈的調用棧。它們更像現場事故，需要把電氣、時序、任務調度、協議、硬件差異和歷史版本放在一起看。
這就是嵌入式問題的常態。代碼只是其中一部分，而且不一定是最先出問題的那部分。
如果只把源碼丟給 AI，它會默認從代碼文本里找答案。它可能會找到一些真實風險，也可能會把一個硬件時序問題分析成軟件邏輯問題。
這就是“沒有現場感”的代價。
所以，現場感到底包括什么？
我現在會把“現場感”拆成六類資料。不是每次都要全部準備，但遇到復雜問題時，缺哪一類，AI 就容易往哪一類誤判。
很多時候，真正關鍵的不是多貼代碼，而是把這些信息說清楚。
嵌入式問題經常藏在邊界條件里：
這些都不是單看一兩個函數就能穩穩判斷的。
那怎么辦？
可以先讓 AI 畫鏈路，再讓它動代碼。
我現在不會一上來就讓 AI 改。
復雜問題里，我會先讓它輸出故障鏈路圖。
圖畫不清，代碼大概率也改不準。
例如看門狗復位，先讓它梳理：
這張圖不是為了好看，而是為了逼它把時間關系講出來。
嵌入式問題里，時間關系經常比調用關系更重要。
函數調用圖只能告訴你誰調用了誰，不能告訴你誰搶占了誰、誰等了誰、誰在中斷里做了不該做的事。
讓 AI 先畫鏈路，可以提前暴露很多問題：
如果這些沒講清楚，就不要急著讓它寫補丁。
AI不能憑空擁有現場感。
沒有現場感時，它只能從代碼文本里猜。猜對了很驚艷，猜錯了也很自信。
有現場感時，它才會開始像一個真正加入項目組的新同事：知道這塊板子有歷史版本，知道中斷里不能亂打日志，知道某個 GPIO 不能碰，知道客戶現場那個舊固件還在跑，知道修完以后必須上板、回放、升溫、跑長時間。
所以，給得越像真實工程現場，它越像工程師。
