1. 我是谁，以及我遇到了什么问题
我是物联网方向的嵌入式开发，日常主力是 ESP32 + ESP-IDF，最近在做一块采集板的固件，板子上有 CAN 总线、I2C 传感器和一个通过 UART 挂载的 4G 模组。
遇到的具体问题：设备在实验室跑得好好的，一到现场就出现随机复位——有时候跑 2 小时没事，有时候 20 分钟就重启一次。串口日志抓到了复位前的输出，只有一行 core dump 的寄存器信息和 backtrace 地址，没有任何业务层报错。这种「现场才能复现、日志看不出因果」的问题，是嵌入式开发里最磨人的类型。
2. 我是怎么用 TraeCode 解决这件事的
使用模式：IDE 模式（Chat），全程没让 AI 盲改代码，只让它做「日志侦探」
第一步：把原始日志直接丢进去，不加工
以前我的习惯是自己先从日志里摘「可疑片段」再去搜，这次反过来，我把完整的复位前日志 + backtrace 原文整个贴给 TraeCode，附一句：
「设备随机复位，这是复位前的完整串口日志和 backtrace，帮我分析复位原因和可能的代码位置。」
它先从 backtrace 地址解析出了调用链：复位发生在 esp_task_wdt_isr —— 任务看门狗超时，被卡住的线程是一个自己写的 CAN 接收任务。这是第一个关键转折：不是硬件问题、不是电源问题，是任务死循环。
第二步：让它结合代码定位根因
我让它打开 CAN 接收任务的源文件（@can_task.c），它读完代码后指出了嫌疑点：我在 while 循环里用了 xQueueReceive(queue, &frame, portMAX_DELAY) 阻塞等待，但循环里还有一段手动关中断做总线错误恢复的逻辑，在特定 CAN 错误风暴场景下会自旋等待总线恢复标志，而这个标志在中断被关掉期间永远不会被置位——经典的自锁死。
更关键的是它解释了「为什么现场才复现」：现场的 CAN 总线质量差，错误风暴触发概率高；实验室总线干净，永远走不到那个分支。
第三步：让它给修复方案并加防御
确认根因后我让它给出修复：
-
自旋等待改成带超时的
vTaskDelay轮询 -
给看门狗喂狗点从「循环外」挪到「循环内」
-
顺手在错误恢复路径加了错误计数日志，下次再出问题现场日志能直接说话
改完编译烧录，挂机 48 小时零复位，结案。
3. 成果展示
-
定位并修复了一个「实验室不复现、现场随机触发」的看门狗复位问题，修复后设备在客户现场连续运行一周无复位
-
沉淀了一个可复用的调试模式：原始日志不加工直接丢给 AI → backtrace 反解调用链 → 结合源码找根因，后来排查 4G 模组偶发无响应时又用了一次，10 分钟锁定是 AT 命令超时设置过短
-
错误恢复路径上新增的计数日志，已经帮现场售后远程判断过两次故障
4. 效率对比
-
以前怎么做：拿着 backtrace 地址手动对照
.map文件查符号（或者靠 addr2line 一条条转），猜根因、加打印、重新烧录挂机等复现——这个问题我第一天就是这么干的，一天下来只在「排除电源问题」上有进展 -
现在怎么做：日志丢给 TraeCode，第一轮对话就锁定了看门狗方向，第三轮对话拿到修复方案，实际投入不到 1 小时，剩下的时间是挂机验证
5. 经验和技巧总结
-
原始日志不要人工预处理：我以前总想「帮 AI 摘重点」，后来发现恰恰是那些我以为没用的垃圾行（任务切换记录、错误计数）里藏着因果链。完整贴，让 AI 自己过滤
-
先让它定位，别让它改代码：调试类任务的第一目标是搞清「为什么」，不是「改哪里」。我会明确说「先分析原因，不要改代码」，等根因确认再放开手脚
-
嵌入式场景记得喂上下文：
@引用对应的任务源文件和 sdkconfig 相关片段，AI 才能判断是不是 FreeRTOS 的调度问题——只贴日志不给代码，它只能猜
[TraeCode的100种用法]