真实浏览器采样与 API 调用有什么不同？GEO 监测为何要保留现场证据
同样向一个 AI 提问，通过 API 得到的答案和用户在网页端看到的答案可能不同。对于模型评测，这种差异可以被当作实验条件；对于 GEO 监测，它决定了报告能否代表真实客户体验。
从第一性原理看，GEO 要测的不是“模型理论上会怎么答”，而是某个真实入口在特定时间和状态下，向用户展示了什么。只记录文本结果，会丢失影响判断的大量上下文。
API 与真实浏览器分别适合解决什么问题
| 维度 | API 调用 | 真实浏览器采样 |
|---|---|---|
| 主要目的 | 模型能力、提示词和批量实验 | 用户终端体验与现场取证 |
| 上下文 | 由调用方显式配置 | 受页面、账号、地域、联网和产品策略影响 |
| 输出 | 结构化文本或流式响应 | 文本、引用、页面状态、截图和交互 |
| 异常 | 通常是状态码与错误体 | 登录墙、验证码、额度提示、加载失败、页面改版 |
| 可复现性 | 更容易控制参数 | 更接近真实，但需要记录环境与时间 |
为什么网页端可能给出不同答案
- 产品提示词不同：网页端可能加入搜索、引用、安全和产品风格指令。
- 联网策略不同：同一模型在 API 与产品端可能使用不同检索来源。
- 账号状态不同：会员等级、历史会话、地区、每日额度会影响功能。
- 页面交互不同：深度搜索、思考模式、自动模式或引用展开可能改变结果。
- 模型路由不同：产品端可能按负载和任务动态选择模型版本。
因此，“我们用某模型 API 测过了”不能直接证明真实用户会看到同样的品牌提及。
截图不是装饰，而是文本之外的证据
一条回答如果只保存正文，很难判断它来自正常对话、登录提示、限额错误还是页面残留。截图能证明问题、平台、回答、引用区和异常提示同时出现，也能在平台改版后保留当时现场。
但截图也不是唯一证据。它不便搜索和统计，长回答可能需要滚动。完整监测应同时保存结构化文本、关键原文、截图、采样时间、平台、节点、账号状态和原始记录。
异常为什么必须单独分类
假设用户问“某类服务商有哪些”，页面返回“今日使用次数已达上限”。如果系统只做关键词分析，会得到“未提及品牌、回答负面或内容为空”的错误结论。登录墙、验证码、连接失败、模型维护、无权限、超时都不属于品牌表现。
正确流程是：识别异常类型，停止情感和品牌评分，记录现场，尝试切换可用节点或等待人工验证，必要时进入补采队列。补采结果应与原异常关联，而不是静默覆盖。
真实采样也可能不真实，关键在执行纪律
打开浏览器并不自动等于真实。若节点长期离线、账号状态未知、页面未加载完成、脚本抓到旧内容，或者只保留成功样本，结果同样会失真。至少要有以下门槛：
- 节点心跳、版本与平台登录状态可见。
- 任务从分配、执行、限制、切换到完成有链路记录。
- 页面完成稳定加载后再提取，避免刷新循环和半屏答案。
- 失败和异常不计入品牌分数，但必须进入运维统计。
- 批量结果保留平台与节点分布，防止单一环境偏差。
铭文鼎成 GEO 的采样边界
平台把“真实浏览器采样”和“广度覆盖扫描”明确区分。前者由采样节点访问 AI 产品并保留回答、截图和现场证据；后者用于大量长尾目标的覆盖估算，不替代真实样本。报告中应显示数据来源，避免把估算值包装成用户亲眼可见的结果。
管理端的批次链路可以看到一批任务分配到哪些节点、具体平台由谁执行、是否触发限制、切换到哪个节点以及最终结果。异常补测只针对可补的采样错误，不重复消耗客户额度，也不篡改历史证据。
企业如何验收一次真实采样
- 随机打开记录，问题、平台、时间和完整回答是否一致。
- 点击截图能否看到与文本相同的页面现场。
- 引用链接是否来自当次回答，而不是后续推断。
- 登录墙和使用限制是否被标为异常，没有进入品牌评价。
- 同批次异常是否能看到补采或节点切换结果。
结论：API 回答模型问题，浏览器回答用户问题
API 具有稳定、便宜、易批量的价值，可以用于提示词和模型能力研究；真实浏览器更昂贵、更复杂，却能保留真实产品体验。两者不是谁替代谁，而是验收对象不同。
当 GEO 报告声称“用户在 AI 中看到什么”时，就必须用能证明用户现场的采样方式，并把所有异常、截图和原始回答一起留下。