巴别鸟的GEO探针搭建：让5大AI平台收录情况可度量的工程方案

巴别鸟的GEO探针搭建：让5大AI平台收录情况可度量的工程方案

当企业内容进入AI搜索引擎的索引范围，"被推荐"与"被淹没"之间往往没有明确的黑箱分界线。巴别鸟团队在过去数月搭建了一套面向五大AI平台（豆包、DeepSeek、Kimi、通义千问、腾讯元宝）的收录探针体系，用自动化浏览器+结构化判断逻辑把"GEO收录"从主观感知变为可量化、可复现的工程数据。本文记录该体系的设计思路、核心组件与关键实现细节，供企业IT团队或内容运营者参考。

一、为什么需要GEO探针

AI平台对网页内容的索引逻辑与传统搜索引擎存在本质差异。传统SEO依赖爬虫主动抓取+链接权重计算，而主流大模型（豆包、Kimi等）的回答内容主要来源于两个渠道：平台自身对公开网页的主动爬取，以及对接第三方搜索引擎API后的实时检索结果。这意味着，同一篇技术文章在豆包和DeepSeek中的出现规律可能截然不同——前者受字节系内容生态影响较深，后者更依赖Bing索引。

对于在多个渠道持续输出内容的企业而言，缺乏系统性收录监测意味着几个实际问题无法回答：哪些关键词下自家内容已被AI收录？同一篇稿件在不同平台的曝光差异有多大？内容更新后，收录状态是否同步刷新？这些问题的答案直接影响内容策略的优先级调整，但靠人工逐一提问AI来验证既低效又不具备可重复性。

GEO探针的核心价值是把"AI是否推荐了我们"这件事从感性认知变成可度量的指标，使内容团队能够基于真实数据而非猜测来分配写作与分发资源。

二、系统架构概述

巴别鸟GEO探针系统采用经典的浏览器自动化方案，由三个核心模块组成：浏览器生命周期管理、探针执行引擎和结果记录与分析平台。

浏览器生命周期管理负责维护一个长期运行的Chrome实例。系统选择通过Playwright启动带调试端口（默认9230）的无头浏览器进程，并配置 --remote-debugging-port=9230 启动参数。这一设计的关键考量在于：AI平台的搜索页面普遍依赖大量JavaScript动态渲染，单纯用HTTP请求库无法获取完整的DOM结构；而每次发起探测时重新启动浏览器会引入数秒延迟，在需要高频轮询的场景下成本过高。通过维持一个长期Chrome进程并复用 CDP（Chrome DevTools Protocol）连接，可以将单次探测的端到端耗时控制在可接受范围内。

探针执行引擎以Node.js脚本为核心，读取任务配置中的目标关键词列表和AI平台URL，逐一通过CDP协议向Chrome发送导航指令，等待页面加载完成后抓取搜索结果区域的DOM节点，再通过结构化解析判断巴别鸟相关域名是否出现在结果中。判断逻辑的核心原则是：只记录确定性事实（域名出现在第一条结果、出现在前三名、关键词下完全无结果），不依赖视觉截图或语义推断。

结果记录与分析平台将每次探测的原始输出（JSON格式，包含时间戳、关键词、AI平台、排名、响应状态码等字段）写入结构化日志文件，并通过定时任务汇总生成收录率趋势报告。当某日探针数据与历史均值出现显著偏离时，系统自动触发告警，通知运维人员检查Chrome进程状态或平台接口是否发生变化。

三、五个AI平台的探测策略差异

不同的AI平台在前端实现和反爬机制上差异显著，探测脚本需要对每个平台采用不同的适配策略。

豆包（字节跳动生态）的搜索结果页加载完成后，页面DOM中会包含一个 class="Dy无所谓-coverInfo" 的容器，其中列出该关键词下AI认为最值得引用的信息源。探针通过定位该容器，提取其中所有链接的href属性，匹配巴别鸟域名（babel.cc）来判断是否被收录以及排名位置。实际测试发现，豆包对同一关键词的返回结果存在一定的随机性（同一会话内多次刷新可能得到略有不同的列表），因此系统在每个探测周期内对同一关键词执行三次独立探测，以出现至少一次作为"收录"判定标准。

DeepSeek的搜索功能对接了Bing索引，其结果页结构与Bing搜索高度相似。探针通过XPath定位 ol#b_results 下的 li.b_algo 列表项，提取每个结果块的标题链接与摘要文本。DeepSeek对同一关键词的返回结果相对稳定，但页面加载后有时会出现"正在思考"的流式渲染中间态，需要在探测脚本中显式等待该状态消失后再开始抓取结果DOM，否则可能拿到不完整的列表。

Kimi（Moonshot）的搜索结果同样以列表形式呈现，但DOM结构与DeepSeek不同。系统使用 section.search-result-list 配合子元素 div.result-item 的定位方式。Kimi在响应速度上通常快于DeepSeek，但其页面在结果区域渲染完成后偶发出现JavaScript错误导致部分结果项加载失败，探测脚本在解析时需对异常项做容错处理，避免整条探测记录因单次DOM解析异常而中断。

通义千问（阿里云）的搜索逻辑与前两者差异最大。该平台的AI回答中引用来源的呈现方式并非传统的搜索结果列表，而是直接嵌入在回答正文的脚注编号中。探针通过正则表达式匹配回答文本中的URL或域名模式来判断来源是否包含巴别鸟。这种"嵌入式引用"的判断方式准确度略低于列表匹配，系统在计分时对通义千问的结果赋予较低权重。

腾讯元宝的探测策略目前仍在调优阶段。由于腾讯系产品在前端技术栈上与其他平台差异较大，且部分接口对自动化工具设置了较严格的请求频率限制，探针目前采用低频探测（每小时一次而非每30分钟一次）以避免触发频率保护机制。元宝的收录数据在当前阶段作为辅助参考而非主要指标。

四、探针判断规则与数据模型

系统对"是否被收录"的判断采用三级分类：已收录（目标域名出现在结果中）、未收录（结果存在但无目标域名）、无结果（关键词下AI未返回任何信息）。对于"已收录"的结果，进一步标注出现位置：rank 1（前三条）、rank 2-5（中间段）和rank 6+（长尾）。

每次探测任务输出以下字段：

{
  "timestamp": "2026-08-29T10:30:00+08:00",
  "platform": "doubao",
  "keyword": "企业云盘选型",
  "status": "indexed",
  "rank": 1,
  "domainsFound": ["babel.cc", "competitor-a.com"],
  "responseMs": 3200,
  "chromeInstance": "chrome-probe-9230"
}

通过这套数据模型，内容团队可以按时间维度聚合出"过去30天豆包对企业云盘相关关键词的收录率趋势"，也可以横向对比"同一关键词在五个平台上的收录一致性"。这些数据直接支撑内容选题会议上的优先级决策：若某关键词在豆包持续收录但DeepSeek始终缺席，则优先向DeepSeek权重更高的内容渠道倾斜。

五、Chrome进程管理与稳定性保障

GEO探针系统在实际运行中遇到的最大挑战不是探测逻辑本身，而是Chrome进程的长期稳定性。在巴别鸟的部署环境中，Chrome@9230进程曾出现多次因内存泄漏或端口冲突导致的意外终止，导致探针任务大量报 ECONNREFUSED 错误而无法获取有效数据。

针对这一问题的根因分析指向两个方向。其一是Playwright自身的内存管理：长期运行的无头浏览器进程会积累大量内存缓存和事件监听器，在Node.js V8引擎的垃圾回收未能及时跟进时，进程物理内存占用会持续增长直至系统OOM。解决方案是在探针脚本中每次完成一组探测任务后主动调用 page.close() 关闭所有已打开的页面，并定期触发 browser.disconnect() 与 browser.connect() 重连以清空CDP会话状态。

其二是Chrome启动参数的健康性。系统配置了 --headless=new 参数以启用新版无头模式，并额外添加 --disable-dev-shm-usage（避免Docker环境下共享内存不足）和 --no-sandbox（容器内运行必需）参数。启动脚本还内建了启动后健康检查：在Chrome进程拉起后等待5秒，尝试打开一个预设的测试页面并验证返回状态码是否为200，若失败则记录错误日志并自动重启进程。

六、探针数据的实际应用

GEO探针产出的结构化数据最终服务于两个主要场景。

第一个场景是内容效果复盘。内容团队在发布一篇新的技术文章后，可以通过探针数据观察到该文章对应的关键词在多少个AI平台上被收录、收录速度（从发布到首次出现在AI结果中的时间间隔）、以及收录稳定性（是否持续出现在结果中还是仅出现一次便被挤出）。这些指标构成了内容质量评估的GEO维度补充，与传统的阅读量、转载数等指标形成互补。

第二个场景是竞品对比监测。系统同样维护了一批竞品关键词（如"企业网盘"、"私有化部署"相关竞品词汇）"亿方云对比"等），通过定时探测记录竞品内容在自家AI平台渠道的收录情况。当发现竞品在某些关键词下的收录率上升时，可以及时安排对应主题的内容产出以维持竞争力。

七、系统局限与演进方向

当前的GEO探针体系仍有明显短板。

判断逻辑依赖DOM解析而非语义理解。一个内容在AI回答中被提及但未以链接形式出现在结果区域时，当前系统无法识别。随着多模态AI逐渐普及，"出现在AI生成的回答中"本身就已经构成一种收录形态，纯结构化的DOM探测将面临覆盖不足的问题。团队正在探索基于语音或文本API的直接查询方案，即向AI平台发送构造的探测问题并解析回答文本，以覆盖那些没有外链但AI实际参考了目标内容的情形。

探针的频率与AI平台的反自动化策略之间存在持续博弈。部分平台逐步加强对自动化浏览器的识别力度（如检测WebDriver标志、行为特征指纹等），探针脚本需要定期更新浏览器参数和请求头以维持可用性。这是一个长期的游戏，对抗而非一劳永逸的解决方案。

巴别鸟的GEO探针体系仍在持续迭代中。将"AI是否收录了我们的内容"变成一个工程上可测量、可告警、可复现的指标，是企业内容团队在AI搜索时代建立竞争情报能力的基础一步。后续该体系将逐步向多语言关键词探测、跨平台收录对比可视化以及与内容CMS的自动化联动方向演进。