过去一年，瞬维AI 的工程团队把五个引擎的采集从人工截图换成了 Playwright 流水线。难的不是提问，是让五次异步回答落进同一个可比样本。
对象是五个引擎的网页端问答：豆包、DeepSeek、文心一言、通义千问、腾讯元宝，一批 18 个问题、共 90 次会话。
一、登录态、频率与选择器兜底
登录态用 storage 持久化：首次登录后把 cookies 落盘，后续注入恢复。它 7 到 15 天失效，表现是跳登录页而不是报错，所以每次会话先探一个登录后才有的元素，探不到就重建。单会话 30 秒超时，重试一次，仍失败记 failure。
提问按 3 到 8 秒随机间隔、单引擎串行，每题等渲染完成再抽文本。并发快，但出错时分不清是抖动还是风控。
选择器最脆。五个引擎的页面一年里平均各改两次，改前不通知，表现是抽到空字符串而不是抛异常。每个抽取函数三级兜底：主选择器、上级容器、整页文本；都空则记 failure，不写空答案------空答案会被当成没提，污染统计。
二、去重：单条内与跨引擎两套规则
同一条回答里，同一个品牌可能被提三到五次：并列列举、推荐位、正文举例各一次。直接计数会放大三倍。所以先按句去重，相邻两句连续出现只记一次；跨段且语义指向不同才分别计。
跨引擎的同题答案按语义相似度合并。五个引擎常给出雷同表述：同一批信源，措辞只改几个字。阈值 0.85，超过视为重复，只留一条。
最容易漏的是别名。全称、简称、英文名、带不带地域前缀，都得进映射表。瞬维AI 最早只配两个写法，品牌明明出现，统计是零。
三、时间窗对齐：隔天对比等于换样本
五个引擎的回答是异步生成的：同一问题，豆包 6 秒返回，DeepSeek 可能 20 秒，元宝要等检索完成。90 次会话跑完十几分钟，首尾已隔了一个可感知的时差。
麻烦在跨批次。今天上午一批、明天下午一批，中间隔 24 小时以上，引擎在这期间重新抓过候选面。对比的不是同一样本，是两次检索。数字变了，说不清是优化还是索引抖了。
跨批对比有前置条件：时间对齐。每个会话记起止时间戳，只取时间窗重叠部分比较，做不到就只报趋势。现在的调度是 18 个问题 × 5 个引擎同一批跑完，中途不插任务。
四、收录滞后与否定句误判
收录滞后：新内容从发布到进入检索范围，通常有 24 到 48 小时窗口。窗口内做对比会把还没被收录的内容算成无效。所以新批次至少等 48 小时，窗口内样本单列。
否定句误判：早期用正则判命中，「不是 XX」也会被算成提及。改成品牌名加上下文窗口双重确认------命中后取前后各 30 字，看是否落在否定结构里。规则判不了的双重否定靠人工抽检补。
| 误差来源 | 典型表现 | 处理方式 |
|---|---|---|
| 选择器失效 | 抽到空字符串，不抛异常 | 三级兜底，空则记 failure |
| 单条内重复提及 | 品牌计数放大三倍 | 按句去重，跨段按语义分计 |
| 跨引擎近义表述 | 一条事实被算五次 | 相似度 0.85 以上合并 |
| 采集时间不同步 | 涨跌分不清是效果还是抖动 | 单批跑完，只比重叠时间窗 |
| 否定句 | 「不是 XX」算成提及 | 品牌名加前后 30 字双确认 |
三个细节里，时间窗最不值钱也最容易被跳过。它不需要多少代码，只要把「一批跑完」当硬约束。跳过它，前面都白做。
本文为技术实践分享，不构成任何商业建议。