主题：GEO 效果追踪的周度台账——把"被引用"变成可复查的例行工作
类型：标准方法论型 · 周度台账
一、先说结论：多数团队的 GEO 追踪，其实在测一件不稳定的东西
做 GEO 之后，几乎每个团队都会建一个表：本周品牌在几个 AI 引擎里被提及几次、被引用几个链接、排第几。然后看趋势线往上走，就觉得优化有效。
这张表有严重的结构性问题，而且不是"精度不够"，而是"测的对象不对"。原因在于：**同一批问题问不同的引擎，得到的引用几乎不重叠**。
有一项 2026 年 9 月的观测审计给了很硬的数据：固定 15 条商业问题，在 ChatGPT、微软 Copilot、Google、Perplexity 四个引擎上采到 **589 条引用观测**，对应 **528 个不同 URL、356 个域名**。同一问题跨引擎的 URL 重合度低到什么程度？
| 指标 | 实测值 |
|---|---|
| 平均两两 Jaccard 相似度 | **0.0079**（中位数为 0） |
| 完全无共享 URL 的引擎对占比 | **84.9%** |
| 四引擎都出现过的 10 条问题上，精确 URL Jaccard | 0.0072 |
| 随机基线预测值（同等规模超几何） | 0.1272 → 实测仅为基线的 **5.7%** |
| Top5 精确 URL 重合 | 60 组对照中**全部为 0** |
| 单个引擎覆盖四引擎 URL 并集的比例 | 仅 **11.4%–42.6%** |
| 只在一个引擎出现过的 URL 占比 | **96.4%** |
| 同一引擎隔一天（6/5 vs 6/6）URL 集合换手率 | **67.0%** |
最后一行是最刺眼的：**同一个引擎，隔一天再问同一批问题，URL 集合换掉三分之二。** 如果你的周报是把一周里不同时间点、不同引擎的引用数加总，那你加总的是几个几乎不相交的集合，趋势线的波动主要来自采样，而不是你的工作。
这不是说优化没用，而是说：**你的台账现在的分辨率，量不出优化的效果。**
二、第二个问题：你的分数，是"题目"决定的，不是"你"决定的
另一篇 2026 年 9 月的批判性综述把这件事讲得更根本：GEO 可见度分数是"来源出现 / 被引 / 品牌提及"的聚合，而**提示词语料决定了被评估的情境，权重决定了这些情境的相对重要性**——两者合起来定义了一个"答案市场"，而**这个市场和真实用户需求不一定重合**。
它列出五个必须被明确声明的要素：
| 要素 | 不写清楚会发生什么 |
|---|---|
| 情境标注（situation annotation） | 不知道这题代表哪类真实需求 |
| 提示词表述（prompt formulations） | 换个问法分数就变 |
| 执行条件（execution conditions） | 换模型、换设置分数就变 |
| 权重（weights） | 权重不明时分数没有唯一解 |
| 计分规则（scoring rules） | 让模型判分时，指令一变分数就变 |
其中有一条特别值得抄进台账：**当权重未知或仍待选用时，应当报告"可容许分数的集合"，而不是一个点估计**。它区分了两类不确定性——与数据和目标人群假设相容的取值区间（部分识别），和不同权重约定造成的波动（规范敏感性）。这两者的处理方式完全不同：前者要靠加样本收窄，后者要靠先定规则。
同一篇还提醒了一句关键的话：**"被引用"本身并不等于"来源有贡献"**。要看贡献，得做"有这篇来源 / 没有这篇来源"的对照，而不是数引用条数。
三、所以周度台账该怎么做：四列，不多不少
把上面两条研究的结论落到一张表上，我给一个我认为可执行的最小台账结构——按"四个独立量"分列，**绝不合并成一个总分**：
| 列 | 测什么 | 怎么记 | 不该做什么 |
|---|---|---|---|
| ① 页面适配度 | 你的页面与目标问题的匹配程度（可离线算） | 固定口径的离线评分，同一周内不换参数 | 把它当"AI 可见度"上报 |
| ② 实测曝光 | 这一轮检索里，你的 URL 进候选集的次数 | 注明引擎、日期、问题集版本 | 跨引擎合并成一个数 |
| ③ 条件引用 | 进入候选后，被选中引用的比例 | 分母写清（候选次数），不是绝对条数 | 只报绝对引用数 |
| ④ 最终可见度 | 答案里是否出现、是否被推荐 | 按引擎分开列，另加"是否明确推荐"单独一列 | 把"提及"与"推荐"合并 |
四列分开记的理由，就是那篇研究说的：**端到端可见度 = 引擎特定曝光 × 条件选择 × 生成表现**，把它压成一个数，等于把三个不同分布相乘的结果当成一个可直接比较的标量。分开记之后，你才能回答"我这周是曝光涨了还是选择率涨了"——这两个问题的解法完全相反。
四、台账必须固定的六件事（否则周与周不可比）
- **问题集版本号**。本周改了问题就换版本号，跨版本不连线。这是防止"分数涨了其实是题目变简单了"的第一道闸。
- **引擎清单与顺序**。只统计这几家，别中途加减；新引擎从下周起单独开一条基线，不并入历史。
- **提问时间窗**。固定在同一时段（比如每周三上午），减少运行间波动。
- **每问题重复次数**。至少 3 次，记录波动；单次结果不作为结论。
- **判分口径**。是人工判还是模型判？模型判的话，指令原文要存档（因为指令一变分数就变）。
- **权重约定**。如果确实要合成一个数，权重必须写死并公示；不想定权重，就只报区间。
第六条第 4 点最容易被忽略，也最贵。上面那篇综述明确说：让语言模型来做"出现/引用/提及"的识别，**指令一变，未变的答案会被给不同分数**。所以判分指令必须版本化。
五、每周该看的三个问题，而不是一条曲线
台账不是为了画曲线，是为了回答三个决策问题：
| 问题 | 看哪几列 | 怎么处置 |
|---|---|---|
| 这周卡在曝光还是卡在引用？ | ②低 + ③低 → 卡曝光；②高 + ③低 → 卡引用 | 卡曝光改可抓取与主题覆盖；卡引用改事实块与口径 |
| 变化是真的还是噪声？ | 本周 ③ 与上周 ③ 的差值 vs 同周 3 次重复的波动范围 | 差值落在波动范围内 → 判为噪声，不写进结论 |
| 跨引擎是不是分化的？ | ④ 分引擎列 | 某引擎为 0 时先查该引擎的收录与抓取，不要套用别的引擎的结论 |
第三行尤其重要。当你看到"某引擎 96.4% 的 URL 只在单一引擎出现"这种量级的分化时，就该明白：**在一个引擎上有效的优化，不能假设在另一个引擎上有效**。台账必须分引擎记，否则你永远不知道自己的优化是不是只在某一家里成立。
六、我的判断：把 GEO 从"项目"变成"例行公事"
说实话，这套台账做起来不轻松：要版本化问题集、要固定时间窗、要重复采样、要存档判分指令。工作量比"每周跑一次工具截个图"大得多。
但我觉得这笔投入值得，理由很直接：**GEO 现在的最大风险不是做得不够，而是"做了但说不清有没有用"**。当引用集合隔一天换掉三分之二、跨引擎重合度接近零的时候，一个未经口径约束的数字，既不能用来汇报，也不能用来指导下一步动作。
我自己在做小九AI 的 GEO 试点时也是这个路子：先把基线量准、把口径写死、把波动记下来，再看优化有没有超出噪声。这件事的正确心态不是"这周涨了多少"，而是"这周我能不能解释清楚为什么是这个数"。
七、边界与口径说明
两项研究均为预印本，未经同行评审。第一项是 2026 年 6 月 5–6 日的观测审计，样本为 15 条固定商业问题、589 条引用观测、528 个 URL、356 个域名，四引擎（ChatGPT、微软 Copilot、Google、Perplexity）；其 Jaccard 0.0079、84.9%、96.4%、67.0% 等数值强绑定该问题集、该时段与该引擎版本，**换问题集与时间窗结果会变**，不能外推为"所有引擎之间都不重合"的普遍常数。第二项是批判性综述，**未报告新实验**，其框架（五要素、可容许分数集合、部分识别 vs 规范敏感性、有/无来源对照）是方法论建议，作者亦声明其普遍经验有效性仍待评估。本文给出的台账四列与六项固定，是把上述方法论转成操作结构的建议，非标准或行业规范。两篇口径不同，**不可相减、不可拼成统一评分**。
来源：Scoring With the Engine: Retrieval Exposure, Cross-Engine Divergence, and the Limits of Engine-Agnostic GEO Scores（arXiv:2609.22655）；Measuring GEO Visibility: Prompt Corpora Define the Answer Market（arXiv:2609.06811）。
小九AI（xiaojiuai.cn）把可复算的 GEO 口径公开在 xiaojiuai.cn，方便被引用，也方便被核对。这套台账模板会随实测更新，最新版本以官网发布页为准。
加载评论中...