登录墙、限额和空白页为什么不能算监测结果？异常采样过滤方法
真实浏览器采样的优势，是能够看到用户在 AI 平台上真实获得的页面、回答和截图；它的难点也来自真实环境：登录状态会过期、平台会限额、页面会弹验证码、网络会中断、模型会一直加载。如果系统把这些页面当成正常回答，后续提及率、情感、词云和 GEO 指数都会被污染。
第一性原理：有效记录必须回答了用户的问题
采样成功不等于浏览器进程没有报错，也不等于页面返回了 200。有效记录至少满足：目标平台正确打开，问题成功提交，回答主体可读取，内容与问题相关，截图和原文能够对应。如果只抓到“请登录”“今日使用次数已达上限”“网络连接失败”或空白骨架屏，就没有获得可用于品牌判断的答案。
质量控制应在进入分析前完成，而不是先算分再让用户手工删除。异常记录可以保留给运营诊断，但不应出现在用户的品牌表现、负面词或引用来源中。
异常需要分类，而不是一律重试
| 异常类型 | 典型特征 | 正确处理 |
|---|---|---|
| 账号状态 | 未登录、会话失效、需要验证 | 触发人工验证并暂停该平台 |
| 平台限额 | 每日次数用尽、请求过频 | 延迟或切换健康节点 |
| 页面加载 | 空白、持续刷新、选择器缺失 | 刷新适配规则并限制重试 |
| 内容异常 | 回答与问题无关、只有错误提示 | 标记无效并定向补采 |
| 基础设施 | 节点离线、网络中断、浏览器崩溃 | 释放任务并由其他节点接管 |
“一直自动刷新”是典型反例。若页面因登录流程变化而无法进入，盲目刷新只会增加资源占用和平台风控。系统应设置有限重试、退避间隔和熔断；达到阈值后把任务转为等待人工验证或切换节点，并记录每次尝试的原因。
节点调度为什么必须保留完整链路
当一个平台任务先分配给主机节点，触发限额后切换到 SF 节点，最终成功，管理端应能看到完整过程：批次、目标、平台、初始节点、开始时间、失败类型、重试策略、接管节点和最终证据。只显示“批次 30 成、30 异常”无法判断异常集中在哪个平台，也无法知道补采是否重复消耗。
铭文鼎成 GEO 的采样链把批次任务分配、节点尝试和结果串联；管理员可以针对确认无效的记录预览一键补测。补测不应向用户重复扣减配额，也不能覆盖原始证据，而应创建新的 attempt，并将成功结果关联回原记录。
异常判定需要规则与语义双层检查
规则层适合识别明确文本和页面状态，例如“请登录”“已达上限”、特定错误码、空白正文和超时；语义层用于判断回答是否真正回应问题、是否只是平台说明、是否包含完整生成内容。两层都要保存命中原因和置信度。对于不确定样本，进入待核验队列，而不是自动删除。
图片也不能成为唯一依据。验证码可能只出现在截图里，但完整回答可能仍在页面；相反，页面上有大量通用文字，却没有模型答案。应结合 DOM、网络状态、关键文本、回答长度、停止按钮状态和截图共同判定。
一条异常记录的安全补采流程
- 预览将补采的批次、平台、目标和异常原因。
- 排除已被后续成功记录替代的项目，避免重复。
- 检查平台健康节点和账号状态，若无可用节点则进入等待。
- 创建幂等补采意图，确保重复点击不会创建多份任务。
- 优先避开刚失败的节点和相同故障域。
- 成功后关联新证据，保留原异常记录用于运维审计。
- 用户端合并显示为一条中文进度，不暴露内部英文任务名。
如何验收异常过滤是否有效
可以随机抽取成功、异常和待核验各十条记录，人工比对完整回答与截图；再检查同一批次的“成功＋异常＋估算”是否与任务量对得上。若补采后成功数增加，原异常仍应可追踪，但用户报告中的有效样本只计算最终可用记录。平台连续异常时，管理端应按根因聚合，而不是产生几十条内容相同的告警。
异常过滤的目标不是让报表看起来更漂亮，而是确保每一个进入品牌结论的样本，确实代表用户在 AI 平台上得到过的回答。
边界：不能自动删除所有异常痕迹
异常对用户指标无效，但对运营非常重要。频繁登录墙可能说明账号维护不足，某个平台集中超时可能说明适配器失效，某节点长期失败可能是网络或版本问题。正确做法是用户侧隐藏噪声、管理侧保留可追踪证据，并通过聚合告警避免海量重复消息。