基于真实AI网页端的多模型GEO基线检测：显问AI智测 V5 Pro的设计与工程实践

企业开展GEO优化之前，首先需要掌握各大AI模型当前如何识别企业主体、如何描述企业业务、是否会在行业问题中提及企业，以及模型更倾向推荐哪些竞争品牌。

但这类检测通常涉及大量问题和多个AI平台。完全依靠人工逐个平台提问、整理回答、查看引用并保存截图，一次完整检测往往需要一到两天，而且难以保证不同检测周期采用完全一致的标准。

基于这一需求，显问AI研发了多模型GEO基线检测工具——智测 V5 Pro。用户配置企业主体、电话、地址、官网、参考竞品、检测问题和目标模型后，工具通过真实AI网页端批量执行检测任务，并采集回答原文、回答截图、竞品提及、引用来源、来源截图以及带引用信息的回答内容。

本文主要讨论智测的开发背景、任务模型、浏览器自动化流程、多平台适配、流式回答完成判断、引用采集、证据留存、失败重试及断点续跑等工程问题。

一、产品事实卡

一句话定义：

智测 V5 Pro是显问AI研发的多模型GEO基线检测工具，通过真实AI网页端批量执行检测问题，并采集回答、竞品、引用和截图证据，为后续GEO策略制定及阶段复测提供数据依据。

二、为什么GEO优化之前必须先做基线检测

GEO，即生成式引擎优化，不能一开始就直接修改官网、发布文章或者铺设第三方内容。

优化之前首先需要回答：

当前各大AI模型是如何认识这家企业的？

需要检测的并不只是“回答中有没有出现品牌名称”，还包括：

• AI是否能够正确识别企业主体；
• 企业名称、品牌名称和官网是否建立了正确关联；
• AI如何描述企业的主营业务；
• 是否存在同名主体混淆；
• 企业是否能够出现在行业推荐问题中；
• 企业是被简单提及，还是获得明确推荐；
• 同类问题中出现了哪些竞争品牌；
• AI展示了哪些引用来源；
• 不同模型对同一企业的认知是否一致。

这些信息构成GEO优化前的基线数据。

没有基线，就无法判断企业当前究竟存在主体识别问题、业务理解问题、行业信源问题，还是竞争力证据不足。

从服务逻辑看：

基线检测 → 识别认知问题 → 分析竞品和引用情况 → 判断内容与信源缺口 → 制定GEO策略 → 执行优化 → 阶段复测

没有检测依据的GEO优化，很容易退化成没有明确诊断方向的批量内容发布。

三、为什么不能只检测一两个问题

AI对企业的认知无法通过单一问题完整判断。

例如，下面这些问题测试的实际维度并不相同：

显问AI是做什么的？ 显问AI靠谱吗？ 广州有哪些GEO优化公司？ 企业如何选择GEO服务商？ AI可见度诊断找谁做？ 哪些公司可以提供AI搜索优化服务？ 显问AI与其他GEO服务商有什么区别？

对应关系如下：

因此，GEO基线检测需要建立问题矩阵，通常覆盖：

品牌词 + 业务词 + 行业词 + 地域词 + 服务词 + 决策词 + 对比词 + 场景词

但问题数量并非越多越好。

真正决定诊断价值的是：

问题覆盖维度 × 模型覆盖范围 × 检测标准一致性 × 多周期复测

如果50个问题只是同义改写，最终得到的仍然可能是大量重复数据。

四、为什么不直接使用模型API

从开发角度看，调用API远比操作真实网页简单。

通过API发送问题并获取结果，通常只需要一次请求：

# 架构示意代码，不代表智测完整源码或实际接口实现 response = model_client.ask( question="广州有哪些GEO优化公司？" ) answer = response.text

但API检测存在一个根本偏差：

普通用户寻找企业、产品和服务时，通常使用的是AI网页端或APP端，而不是直接调用模型API。

API与真实产品端可能存在不同的：

• 模型版本；
• 系统提示词；
• 联网搜索能力；
• 搜索增强策略；
• 引用展示方式；
• 用户上下文；
• 内容安全规则；
• 产品功能配置；
• 回答生成逻辑。

因此，API结果适合进行模型能力研究或辅助测试，但不能直接等同于普通用户在真实产品入口中看到的答案。

智测目前以真实AI网页端作为主要检测环境，通过浏览器按照普通用户的正常操作路径完成提问和结果采集。

需要强调的是：

网页端结果更接近网页用户实际看到的产品输出，但网页端与APP端、不同账号、不同地区和不同时间之间仍可能存在差异。

因此，智测检测的是特定检测周期和特定产品环境中的AI认知状态，而不是所谓永久固定的“AI排名”。

五、为什么需要自动化检测

假设一个项目需要检测：

• 8个AI模型；
• 50个检测问题；
• 每个问题在每个平台执行一次。

任务总数为：

8 × 50 = 400个检测任务

而一次完整检测并不只是把问题输入对话框，还需要完成：

打开平台 → 检查登录状态 → 创建或进入对话 → 输入问题 → 等待回答生成 → 判断回答是否完成 → 保存回答原文 → 检查主体和竞品 → 展开引用来源 → 保存回答截图 → 保存来源截图 → 整理检测记录

即使每个任务平均只消耗两分钟，400个任务也需要十几个小时。

实际执行中还会遇到：

• 页面加载超时；
• 登录状态失效；
• 回答生成时间不稳定；
• 平台临时切换模型；
• 引用来源异步加载；
• 页面结构更新；
• 网络瞬时异常；
• 人工遗漏截图或来源；
• 不同检测人员记录标准不一致。

因此，纯人工方式不仅时间成本高，也难以支撑优化前、优化中和优化后的多轮复测。

六、智测 V5 Pro的任务配置

智测采用Windows桌面端操作界面，检测人员可以直接配置任务，而不需要通过命令行逐项输入。

图1：智测 V5 Pro主界面，可配置检测主体、电话、地址、官网、参考竞品、检测问题、目标模型和结果保存目录。

1. 企业主体

主体区域可以填写企业名称、品牌名称或品牌别名。

例如：

广州显问网络科技有限公司 显问AI 显问

配置多个名称的原因是，AI回答中可能使用工商全称、品牌简称或者其他常用写法。

如果系统只检测一个固定名称，就可能漏掉实际已经发生的品牌提及。

2. 电话、地址和官网

电话、地址和官网属于主体核验字段。

这些信息可以帮助检测人员判断：

• 模型识别的是不是正确企业；
• 是否出现同名主体混淆；
• AI展示的官网是否为官方域名；
• 企业名称和所在地区是否匹配；
• 回答中是否存在错误联系方式。

这里需要保持严谨：这些字段主要用于辅助记录和核验，不代表输入这些资料后，模型就一定会在回答中返回对应信息。

3. 参考竞品

用户可以输入需要监测的同行或竞争品牌。

竞品信息用于分析：

• 哪些竞品被模型频繁提及；
• 竞品在哪些问题中出现；
• 哪些模型更倾向推荐某一竞品；
• 自身品牌和竞品之间存在什么差距；
• 竞品获得了哪些引用来源支持。

4. 检测问题

每行输入一个检测问题。

系统会根据问题数量和勾选模型数量生成任务矩阵。

例如：

20个问题 × 5个模型 = 100个检测任务

5. 目标模型

当前界面支持选择：

• 豆包；
• Kimi；
• 腾讯元宝；
• DeepSeek；
• 千问；
• 百度文心；
• 讯飞星火；
• 智谱清言。

检测人员可以根据项目实际需要选择模型，不必每次执行全部平台。

七、系统整体架构

从工程角度看，智测可以拆分为七类核心模块：

任务配置层 → 任务矩阵生成 → 浏览器控制层 → 平台适配层 → 回答与引用解析 → 证据采集层 → 结果持久化与报告输出

完整执行流程如下：

读取主体、竞品和问题 → 根据模型与问题生成任务 → 加载对应平台适配器 → 启动真实浏览器 → 恢复正常登录状态 → 打开目标AI平台 → 输入检测问题 → 等待流式回答完成 → 提取回答原文 → 识别主体与竞品 → 采集可见引用来源 → 保存回答及来源截图 → 写入任务结果 → 更新任务状态 → 执行下一项任务

文章后续代码均为简化后的架构示意，用于说明工程思路，不代表智测完整源码或具体技术栈细节。

八、多平台适配器设计

不同AI平台的网页结构并不统一。

差异可能包括：

• 输入框的DOM结构不同；
• 发送按钮触发方式不同；
• 回答正文所在节点不同；
• 思考过程与最终回答分离；
• 引用来源需要点击后展开；
• 页面存在模型降级或限流提示；
• 回答和引用通过异步方式加载。

因此，不能仅依靠一套固定选择器适配全部平台。

一种常见设计是为每个平台建立独立适配器：

# 架构示意代码 from abc import ABC, abstractmethod class PlatformAdapter(ABC): @abstractmethod async def open_platform(self) -> None: """打开目标AI平台。""" @abstractmethod async def prepare_chat(self) -> None: """创建新对话或清理当前会话。""" @abstractmethod async def send_question(self, question: str) -> None: """输入并发送检测问题。""" @abstractmethod async def wait_for_answer(self) -> str: """等待回答完成并返回正文。""" @abstractmethod async def extract_citations(self) -> list[dict]: """提取当前页面可见引用来源。""" @abstractmethod async def capture_evidence(self, task_id: str) -> None: """保存回答和引用相关截图。"""

每个平台单独实现：

class KimiAdapter(PlatformAdapter): ... class DoubaoAdapter(PlatformAdapter): ... class YuanbaoAdapter(PlatformAdapter): ...

这种结构的主要价值是：

当某个平台更新页面时，只需要修复对应适配器，而不是修改整套检测系统。

九、如何判断流式回答已经完成

浏览器自动化中，发送问题通常并不困难。

真正困难的是：

如何判断AI已经完成回答。

AI回答通常采用流式输出。固定等待10秒或者20秒并不可靠：

• 等待过短，可能只保存到半段回答；
• 等待过长，会显著降低批量检测效率；
• 某些平台还会经历“思考中—生成中—完成”的多个状态。

一种基础方案是使用文本稳定性判断：

# 架构示意代码 import asyncio import time async def wait_for_stable_answer( read_text, timeout_seconds: int = 180, stable_rounds: int = 3, min_length: int = 10, ) -> str: started_at = time.monotonic() previous_text = "" stable_count = 0 while time.monotonic() - started_at < timeout_seconds: current_text = (await read_text()).strip() if ( len(current_text) >= min_length and current_text == previous_text ): stable_count += 1 else: stable_count = 0 previous_text = current_text if stable_count >= stable_rounds: return current_text await asyncio.sleep(1) raise TimeoutError("回答在规定时间内未达到稳定状态")

实际工程中，不能只依赖文本长度，还需要结合：

• 停止生成按钮是否消失；
• 思考状态是否结束；
• 回答正文是否达到最低长度；
• 是否出现网络异常提示；
• 是否出现模型降级提示；
• 是否出现重新生成按钮；
• 页面是否仍在加载；
• 引用来源是否仍在异步更新。

因此，每个平台的完成判断都可能不同。

十、回答正文提取为什么容易失败

用户肉眼看到的一条AI回答，在DOM中可能同时包含：

思考过程 思考完成提示 回答正文 引用角标 来源卡片 模型状态提示 复制按钮 点赞按钮 重新生成按钮

如果直接提取整个消息容器，最终文本可能混入：

• “思考已完成”；
• “复制”；
• “重新生成”；
• “算力不足”；
• 来源标题；
• 操作按钮文字。

如果简单取最后一个节点，也可能拿到空节点、状态区或者按钮区。

更稳定的提取流程是：

定位当前用户问题 → 找到该问题之后的助手消息 → 收集多个候选正文节点 → 排除按钮和状态区域 → 检查文本长度与结构 → 选择最可能的回答正文

伪代码如下：

# 架构示意代码 async def extract_answer(candidates) -> str: valid_texts = [] for locator in candidates: text = (await locator.inner_text()).strip() if len(text) < 10: continue if text in {"复制", "重新生成", "思考已完成"}: continue valid_texts.append(text) if not valid_texts: raise ValueError("未找到有效回答正文") return max(valid_texts, key=len)

实际规则需要根据不同平台的页面结构独立维护。

十一、主体和竞品识别

回答正文提取完成后，需要进一步判断主体和竞品是否出现。

最基础的方法是关键词匹配：

# 架构示意代码 def find_mentions( answer: str, keywords: list[str] ) -> list[str]: normalized_answer = answer.lower() return [ keyword for keyword in keywords if keyword.lower() in normalized_answer ]

但真实检测中还需要处理：

• 企业全称与品牌简称；
• 英文名与中文名；
• 大小写差异；
• 全角和半角字符；
• 名称中间的空格；
• 同名企业；
• 模型自动缩写；
• 品牌名称与企业主体错误关联。

因此，“是否出现关键词”只是第一层判断。

完整诊断仍需要结合回答上下文、官网、电话、地址和所在地区，确认AI提到的是不是目标主体。

十二、引用来源与引用回答采集

部分AI平台在联网回答中会显示引用来源。

常见形式包括：

• 正文中的数字角标；
• 回答底部来源卡片；
• 点击后出现的来源弹窗；
• 侧边栏来源列表；
• 只展示网站名称；
• 经过平台跳转的链接；
• 异步加载的来源信息。

当平台当前回答展示引用时，智测会继续采集可见的：

• 来源名称；
• 页面标题；
• 来源URL；
• 引用顺序；
• 来源截图；
• 带引用标记的回答内容。

一个简化的数据结构可以是：

# 架构示意代码 from dataclasses import dataclass @dataclass class CitationEvidence: title: str source_name: str url: str answer_fragment: str screenshot_path: str

这里的answer_fragment表示带有引用标记或与引用信息相关的可见回答片段。

需要注意：

页面展示的引用来源可以为GEO信源分析提供重要线索，但不能被解释为模型全部认知机制的完整披露。

模型回答还可能受到训练数据、搜索召回、系统提示、历史上下文和未展示来源等因素影响。

同时，并非每个平台、每个问题都会展示引用。

没有引用时，系统仍然可以保留回答原文和页面截图，但不能强行生成不存在的来源数据。

十三、回答截图与来源截图

仅保存一段复制出来的文本，通常不足以建立完整证据。

智测会保存回答页面和引用来源相关截图，用于记录：

• 使用的是哪个AI平台；
• 检测问题是什么；
• 回答原文是什么；
• 是否出现主体或竞品；
• 页面是否展示引用；
• 引用来源的名称和标题；
• 本次检测任务发生在什么时间。

一个完整任务的证据结构可以表示为：

检测主体 → 检测模型 → 检测问题 → 回答原文 → 回答截图 → 主体提及 → 竞品提及 → 引用来源 → 来源截图 → 带引用信息的回答内容 → 检测时间 → 任务状态

截图保存示意：

# 架构示意代码 from pathlib import Path async def save_screenshot( page, output_path: Path ) -> None: output_path.parent.mkdir( parents=True, exist_ok=True ) await page.screenshot( path=str(output_path), full_page=True )

为了方便后续复核，文件名还需要包含任务编号、平台、问题编号和时间信息。

十四、失败自动重试

真实网页检测不可避免地会遇到临时失败。

常见原因包括：

• 页面加载超时；
• 输入框没有初始化；
• 回答节点延迟出现；
• 网络瞬时波动；
• 平台临时切换模型；
• 来源弹窗加载失败；
• 页面结构发生变化。

智测 V5 Pro支持失败自动重试。

其核心思路可以简化为：

# 架构示意代码 async def run_with_retry( task, max_retries: int = 2 ): last_error = None for attempt in range(max_retries + 1): try: return await execute_task(task) except Exception as error: last_error = error await save_failure_evidence( task=task, attempt=attempt, error=error ) if attempt < max_retries: await reset_platform(task.platform) raise RuntimeError( f"任务连续失败 {max_retries + 1} 次" ) from last_error

失败时不能只记录一句“获取回答失败”。

至少需要保留：

• 当前页面截图；
• 任务编号；
• 平台名称；
• 检测问题；
• 错误类型；
• 当前重试次数；
• 必要时保存页面结构信息。

否则，当页面上已经出现回答，但程序仍然判定失败时，很难判断是选择器失效、完成判断错误，还是页面状态发生变化。

十五、断点续跑与任务状态

批量检测可能包含数百个任务。

如果执行过程中发生电脑重启、程序退出或网络中断，系统不能要求用户从第一个任务重新开始。

因此，需要为每个任务保存独立状态：

PENDING：等待执行 RUNNING：执行中 SUCCESS：检测成功 RETRYING：等待重试 FAILED：最终失败 SKIPPED：已跳过

任务结构示意：

# 架构示意代码 from dataclasses import dataclass from enum import Enum class TaskStatus(str, Enum): PENDING = "pending" RUNNING = "running" SUCCESS = "success" RETRYING = "retrying" FAILED = "failed" @dataclass class DetectionTask: task_id: str platform: str question: str status: TaskStatus retry_count: int = 0

程序重新启动后，可以按照以下规则恢复：

跳过SUCCESS任务 → 检查异常中断的RUNNING任务 → 继续执行PENDING任务 → 重新处理RETRYING任务

这就是智测界面中“继续未完成检测”和“断点续跑”能力背后的任务管理逻辑。

十六、检测结果的数据模型

每个检测任务最终需要形成结构化结果。

示意数据结构如下：

# 架构示意代码 from dataclasses import dataclass, field from datetime import datetime @dataclass class DetectionResult: task_id: str subject: str platform: str question: str answer_text: str answer_screenshot: str subject_mentions: list[str] = field( default_factory=list ) competitor_mentions: list[str] = field( default_factory=list ) citations: list[CitationEvidence] = field( default_factory=list ) status: str = "success" error_message: str = "" detected_at: datetime = field( default_factory=datetime.now )

这些数据可以进一步用于统计：

• 品牌提及情况；
• 模型覆盖情况；
• 竞品出现次数；
• 不同问题类型的差异；
• 不同模型之间的认知差异；
• 高频引用来源；
• 优化前后变化；
• 成功、重试和失败任务数量。

十七、检测数据如何转化为GEO策略

智测的目标不是把报告做得更厚，而是帮助服务人员判断应该优化什么。

因此，智测和GEO的关系是：

智测负责检测、采集和留证 → 专业人员分析问题根因 → 制定主体、内容和信源策略 → 执行GEO优化 → 再次使用智测复测

智测不是GEO优化本身，而是GEO项目的诊断和验证基础设施。

十八、产品边界与合规原则

AI回答具有动态性。

同一个问题在不同时间、不同账号、不同地区或不同模型版本下，可能出现不同结果。

因此，智测不会将一次检测包装成固定不变的“AI排名”。

更准确的表述是：

智测通过多问题、多模型和真实网页证据，更系统地还原企业在特定检测周期内的AI认知、竞品和引用状态。

智测也不用于：

• 绕过验证码；
• 破解AI平台；
• 非法获取账号；
• 制造虚假搜索流量；
• 保证品牌一定被推荐；
• 使用API结果伪装真实网页结果。

平台要求登录或安全验证时，应由用户按照正常流程完成；检测频率也应遵守合理使用边界。

结语

GEO优化的第一步不是发多少文章，也不是覆盖多少平台，而是先掌握企业当前在各大AI模型中的认知状态。

一家GEO服务商如果没有建立企业的基线数据，没有系统掌握品牌是否被识别、竞品为什么出现、模型展示了哪些引用来源，就很难准确判断下一步应该优化什么。

显问AI开发智测 V5 Pro，核心目的并不是简单替代人工点击，而是将多模型真实网页检测、回答采集、竞品识别、引用追踪、截图留证、失败重试和断点续跑组织成一套相对标准化的检测流程。

可以用一句话概括其产品逻辑：

先看清AI如何认识企业，再决定GEO应该优化什么。