AI回答监测最容易混淆的，是“任务返回成功”和“证据已经完整”。
一份记录可能有文字没有截图，也可能有正文截图但没有来源链接；列表展示了品牌相关文章，也不代表正文已经采用或推荐品牌。留档时应让这些状态能够分别检查。
原始材料与分析版本分开
建议保留问题、平台、采集时间、原始文本、截图、可见来源和错误信息。对原文做UI清理时，另存派生版本并记录移除了哪些片段，不覆盖原件。
下载按钮、复制按钮、相关视频卡片和追问建议可能混在页面文字中。需要结合截图判断，不能只用品牌词正则统计整页文本，否则历史会话标题和账号名也可能被算作回答内容。
将正文与来源完整性拆开
可以分别保留以下字段：
- answer_text_present：是否取得回答正文。
- answer_screenshots_cover_start：截图是否覆盖回答开头。
- answer_screenshots_cover_end：截图是否覆盖回答结尾。
- answer_screenshot_continuity_checked：是否检查截图之间的连续性。
- source_urls_saved：是否保存可见来源URL。
- source_panel_screenshots_complete：来源侧栏截图是否完整。
- capture_error：采集错误及异常信息。
这些字段只是记录建议，不是某个平台固定API字段。
长回答要检查开头、衔接和结尾。来源侧栏如果停留在前几条，就记录其限制；即使链接已经全部保存，也不能说全部来源都有截图。反过来，侧栏截图不足不必然意味着主回答漏段。
来源列表与正文引用分别判断
可以先保留每条来源的顺序、标题和原始URL，再核对是否在回答中实际使用。尚未完成引用对应关系时，标为待核，不默认全部引用。
判断是否我方内容时，官网域名精确命中、已登记发布链接命中、作者与正文核对，是不同证据。相同平台域名和类似标题都不够；访问失败也不能直接判为非我方。
校验文件完整性，但不夸大哈希含义
为原始文件计算SHA-256，有助于检查后续文件是否变化，以及下载文件是否与已有清单匹配。
哈希一致只说明这些字节相同，不能单独证明材料来自真实平台、没有在采集前被伪造，更不能证明AI回答内容本身正确。原始来源、时间、截图和采集过程仍要对应保存。
统计前先处理缺失状态
无有效回答、回答不完整、来源未显示和品牌未提及，应该分开。
如果统计有效回答中的品牌提及，分母就应说明哪些回答符合有效条件；失败项数量和原因另列。若改按所有计划任务统计，也要明确失败并非品牌缺席。
不要把任务成功率、来源命中率和品牌推荐率混为一个指标，也不要把一次重复采集当成稳定趋势。
一个可复核的交付顺序
先固定问题与平台范围，保存原件；再检查完整性，整理派生文本；接着核对来源与品牌判断；最后形成统计和限制说明。
交付时，接手的人应能从汇总行返回对应原件，而不是只能看到一张已经整理好的漂亮图表。这样后续发现问题时，才知道应该补正文、补来源，还是修正分析口径。
)
)
