摘要
我在飞书上用Hermes Agent，但它有时候会"胡说八道"——问美食推荐天气，问天气推荐景点。问题是：你根本不知道它中间经历了什么，是搜索失败了？还是理解错了？无从判断。于是我花了半天时间，用 TRAE SOLO 给它装了个"行车记录仪"——飞书侧边栏，右键消息就能看到 AI 完整的思考过程、工具调用和中间结果。
话说 Hermes 对应 “骑马记录仪"更合适，那open claw就是"遛虾记录仪”
结果上线第一天，就发现了一个大坑……
01 | 行车记录仪的价值：上线第一天就抓了个大 bug
先说说最精彩的部分。
侧边栏刚上线，我兴奋地打开看效果。AI 回复里有个 Markdown 表格，侧边栏里渲染得漂漂亮亮的，数据对齐、表头清晰，完美。
然后我切回飞书聊天窗口一看——
表格内容直接消失了。 整个表格被飞书过滤掉了，只留下表格前后的文字，中间的数据全丢了。
飞书不支持 Markdown 表格，遇到表格语法会直接把内容过滤掉。
这个 bug 不是侧边栏的，是 AI 输出的问题。但如果没有侧边栏，我可能永远发现不了——因为 AI 觉得自己输出得挺好的，我也不会特意去对比两个窗口。
这就是"行车记录仪"的价值：不是为了抓 AI 的错，而是让你看到它到底在干什么。
就像行车记录仪不是为了证明司机违规，而是让所有人都安心。
02 | 成果展示
打开方式：一起进入AI的内心世界
思考过程：AI 在想什么？
点开蓝色节点，可以看到 AI 的内心独白——它是怎么理解你的问题的，打算怎么解决：
工具调用：AI 在干什么？
点开橙色节点，可以看到 AI 调用了什么工具、传了什么参数、返回了什么结果。比如这里可以看到它用工具查询经纬度：
子代理：AI 派了帮手
紫色节点是子代理——AI 觉得自己搞不定，就派了一个"分身"去专门做某件事。比如这里派了个子代理去搜索美食：
03 | SOLO实现步骤
第一步：可行性报告
第二步：直接执行
第三、四、五、六、七、八、九步：改、改、改、改、改、改
中间改到MTC调试
03 | 踩坑实录
坑 1：AI 回答"串台"
有时候 AI 会把不同问题的答案搞混——问美食推荐天气，问天气推荐景点。原因是消息匹配逻辑有 bug，用时间窗口匹配时把两条不同的消息搞混了。改成内容匹配后，再也没串过台。
坑 2：时间线上的时间全是假的
侧边栏上线后，我发现一个诡异的现象：AI 执行了 20 步（包括多次网络搜索和子代理调用），但时间线上显示总耗时只有 0.38 秒。
0.38 秒？你让 AI 搜一次百度试试？
后来发现，AI 框架用的是"批量写入"——所有消息都在对话结束后才一起存进数据库，所以每条消息的时间戳几乎一样。SOLO 帮我改了 AI 框架的源码，让每条消息在创建时就记录真实时间，问题解决。
代码开源
完整代码已开源，附带详细的适配文档，其他 AI 助手也能装这个"行车记录仪"：
https://github.com/nujgnoix/feishu-sidebar
05 | 一些感想
关于 AI 透明度
现在大家都在说"AI 要可解释"、“AI 要透明”，但大多数产品只给你看最终结果。我觉得真正的透明不是给你一个"解释为什么"的按钮，而是让你亲眼看到它做了什么。
关于 SOLO
说实话，我之前没怎么用过 AI 写代码。这次整个项目——飞书签名认证、数据库查询、React 前端、甚至改 AI 框架源码——全都是 SOLO 帮我写的。我负责的部分主要是：
- 告诉它我想要什么
- 发现 bug 后，把调试面板里的原始数据直接复制给它，让它自己分析
- 说"不对，再改改"
这里有个很重要的经验：报 bug 不要截图，直接复制数据。 侧边栏自带调试面板，能看到 API 返回的原始 JSON、飞书 SDK 的认证日志、数据库查询结果。发现 bug 时，我直接把这些原始数据复制粘贴给 SOLO，它自己就能分析出问题在哪。比截图高效太多了——截图里 SOLO 看不到实际的数值和错误信息，但原始数据它能直接理解。
整个过程就像和一个很靠谱的朋友结对编程——它负责敲代码，我负责拍砖。
关于"上线即翻车"
上线第一天就发现飞书不支持表格，听起来像是翻车，但我反而觉得这是最有价值的事。一个调试工具最大的价值，不是帮你找到已知的 bug，而是让你发现未知的 bug。
如果你也在用 AI 助手干活，建议你也给它装个"行车记录仪"。你会发现，它比你想象的更努力，也比你想象的更容易翻车 