在设计 AI 回答监测记录时如果只保留一个“是否命中”的布尔值就容易把几种不同情况混在一起回答出现目标名称但讲的是同名主体回答准确介绍目标却没有展示引用链接页面已有完整回答但采集程序没有成功保存。这三种情况需要不同的处理方式。本文给出一种记录设计思路不涉及特定平台的接口实现。一、名称匹配只负责找候选不负责确认主体假设需要监测一个名为“示例品牌”的软件产品。下面是两条模拟回答不是真实平台采集结果“示例品牌是一处露营基地。”“没有找到示例品牌的软件产品资料。”两条回答都包含目标名称但第一条介绍了错误主体第二条表达的是资料缺失。因此字符串匹配得到的结果只能说明“回答中出现了这个名字”不能直接推导出“目标产品被正确介绍”。记录设计可以把名称命中与主体判断拆开。主体判断至少保留以下状态状态含义correct根据回答上下文确认是目标主体wrong_entity可以确认是同名的其他主体not_established提到名称但没有建立目标主体的有效介绍unknown现有内容不足以判断等待复核业务类别、运营主体、官网信息等都可以作为复核线索但不必要求每条正确回答同时包含所有字段。重要的是上下文能否支持判断。二、正确介绍目标不代表有可见引用引用记录应与正文判断分开。回答可能准确描述目标却没有展示引用链接。此时可以记录主体识别正确但不能补造引用来源。还有一种情况正文写出了官网地址引用侧栏展示的却是另一篇介绍文章。应按实际展示的来源记录不能因为正文出现官网地址就把官网记成被引用页面。建议单独设计引用可见性字段displayed观察到了引用条目not_displayed当次回答没有展示可见引用unknown没有完成引用区域核查。“没有展示引用”与“没有查到引用”不是同一件事。前者是对页面的观察结果后者可能仍是采集缺口。搜索活动中的结果数量也不应该填入引用链接数量。空的引用列表只能说明当前记录没有可核验的引用链接不能证明回答完全没有参考网页。三、采集失败是记录问题不是内容结论页面已经生成回答但正文、来源或截图没有保存完整时不应把这条记录直接记成“未命中”。可以先分开保存三类信息采集过程是否执行、是否保存、发生了什么错误。内容判断回答是否正确识别目标是否有引用或推荐。证据状态正文、引用信息和截图分别保留到了什么程度。例如正文完整、截图保存失败可以保留已有正文同时注明截图缺失正文没有保存则无法仅靠任务失败状态判断回答内容。处理前先检查原对话。已有回答时优先补采现有内容如果重新提问产生了新回答则另建一条记录不覆盖原来的失败记录。四、一条示例记录下面的 JSON 只是用于说明字段分工的模拟数据不是任何平台的 API 返回值{ questionId: demo-question-01, platform: demo-platform, runId: demo-run-01, collectionStatus: saved, answerStatus: complete, nameMatched: true, entityMatch: correct, citationState: not_displayed, visibleSourceUrls: [], recommendation: false, reviewMethod: manual, reviewNote: 正确介绍目标主体未展示可见引用 }这条记录表达的是正文已经保存并完成复核名称与主体判断均有效但没有可见引用也没有推荐结论。它不是“所有指标都成功”也不是“引用采集失败”。实际使用时还应保留采集时间、时区、完整问题、回答原文、搜索模式和截图位置。尚未复核的推荐结果应保留 unknown 或 null不要默认填成 false。五、汇总前先确定哪些记录可比较建议按问题、平台、批次和采集条件组织记录避免把不同问题、不同时间的回答合并成一次测试。主体识别率如需统计应明确分母哪些回答已经完整保存并完成主体复核。待补采和待复核记录单独列出不作为识别失败混入。引用数据则应保留可见性差异。unknown 不能记成零次引用not_displayed 也不等于确认没有使用外部信息。同名误判、无可见引用和采集失败看起来都可能表现为一个“未成功”实际含义却不同。把状态拆开后续才知道应该核对主体、补查引用还是修复采集过程。