我以前看 AI 线索，最先看的是图片、类别和置信度。后来做无人机项目，才慢慢把注意力挪到另一组字段上。
识别那一刻，飞机在哪里，高度是多少，云台往哪看，用的是哪一路载荷，消息晚了多久。
这些字段平时不起眼。出问题时，它们就是能不能把事情讲清楚的证据。
一条线索不能只剩一张图
AI 识别服务生成线索时，常见字段是图片、目标类别、检测框、置信度和识别时间。这个结构能让页面展示结果，也能让人判断模型有没有认出来。
但它解释不了目标位置从哪里来。
无人机在飞。镜头在动。云台角、航向角、飞行高度、变倍值都可能变化。同一个画面框，放在不同姿态下，对应的地面位置会完全不同。
所以线索里要保存识别时刻的实时快照。至少要能回到当时的无人机位置、飞行姿态、云台姿态、载荷编号和消息时间。
原始快照和结构化字段都要留
项目文档里有一个设计我觉得很实用。实时信息要保存两份。
| 数据 | 用处 |
|---|---|
| 原始 MQTT 快照 | 后续复算和排查字段变化 |
| 结构化字段 | 页面展示、筛选、地图定位和统计 |
只保存结构化字段，后面字段解析错了很难回头。只保存原始 JSON，页面和查询又会很难做。
两份都留，系统看起来多存了一点东西，后面少很多解释成本。
时间差要显式记录
MQTT 属性消息不一定和 AI 识别完全同一毫秒发生。更现实的做法，是按设备和识别时间去找附近的快照，再把时间差记下来。
这里最要紧的是把匹配过程记清楚，让结果知道自己是怎么来的。
如果匹配到了，就记录匹配状态和延迟。
如果超时了，线索仍然可以入库，但要标记实时信息缺失或超时。
如果载荷没对上，就不要把另一只镜头的云台角拿过来用。
我现在会要求的几个状态
| 状态 | 我希望系统怎么处理 |
|---|---|
| matched | 可以展示实时信息，并参与后续定位判断 |
| timeout | 保留识别结果，提醒实时信息超过有效窗口 |
| missing | 保留图片和类别，不生成可信目标坐标 |
| parse_failed | 保存原始快照，结构化字段留待排查 |
这几个状态比一个空值有用得多。空值只告诉你没有结果，状态能告诉你为什么没有结果。
留给下次
MQTT 接入不要只验收“能收到消息”。要验收它能不能和 AI 识别结果绑在一起，能不能解释一条线索从图片到坐标的过程。
线索能追溯，项目后面才有复盘的余地。