一、背景：AI 引用分析缺的不是观点，是可复现的测量口径
生成式引擎优化（GEO）在过去一年被讨论得很多，但绝大多数内容停留在"应该做什么"。真正缺的是可复现的测量口径：当一条问句被 AI 回答时，它到底读了哪些来源、最终引用了哪些来源、两者差在哪里？
这三个问题不回答清楚，任何优化动作都是盲调。
我用 74 条中文商业问句，对两个中文大模型应用做了一轮独立会话采集（不登录、不带历史上下文、不提示任何品牌名），把完整响应落盘存档，再做结构化统计。原始数据规模：6183 条信源记录（含检索池候选与最终引用两部分）。
二、核心设计：必须把 RETRIEVED 和 SELECTED 分开
这是整套测量里最关键的一个设计。
集合 |
对应字段 |
含义 |
RETRIEVED |
|
平台检索到的候选池，未经过筛选 |
SELECTED |
|
最终写进回答、带引用编号的来源 |
为什么必须分开：一个来源进入检索池、却没被引用，和压根没进入检索池，是两种完全不同的失败原因。
- 进了池但没被选中 → 内容说服力 / 相关性 / 时效性问题，属于内容层
- 压根没进池 → 索引、收录、可抓取性问题，属于基础设施层
把这两件事混为一谈，就会去优化一个根本不存在的瓶颈。
三、工程实现要点
3.1 落盘粒度
每条 Prompt 存一份原始 JSON，保留以下字段，不要只存最终回答：
两个容易踩的坑：
search_result有时是 JSON 字符串而非数组。必须先判断类型再解析，直接当列表遍历会拿到一串字符。- 不同平台的引用卡片结构不一致。一个把真实 URL 嵌在
text_card子对象里，另一个是平铺字段。归一化层必须写两套分支，否则其中一个平台的引用统计会全为 0。
3.2 归一化参考实现
3.3 统计口径写死在代码里
聚合时最容易出错的一步是"域名归一化"。同一个站点会出现 www、裸域、带参数、跳转链等多种写法，必须统一到主域再计数：
3.4 测量纪律
这几条决定了数据能不能用：
- 全新会话，不携带任何历史上下文
- 不上传知识库、不在 Prompt 里提示目标品牌
- 不使用系统提示引导提及
- 测的是自然召回，不是"被引导后的表现"
- 未知值一律记
UNKNOWN，不做推测填充
四、结果：几个结构性发现
4.1 不同平台的信源结构差异极大
渠道类型 |
平台 A 引用占比 |
平台 B 引用占比 |
开发者社区 |
20.6% |
6.3% |
百科 / 词条 |
13.1% |
0.6% |
门户 / 财经媒体 |
11.5% |
10.5% |
短视频生态自有内容 |
0% |
15.9% |
结论：不存在"一套内容通吃所有 AI 平台"的策略。 同一个问句在平台 A 上靠开发者社区和百科类内容支撑，在平台 B 上则高度依赖其自有内容生态。渠道选择必须按平台分治。
4.2 长尾极长，但头部集中度并不低
平台 A 的 567 条最终引用分布在 204 个域名上，第一名只占 13.6%；检索池更分散，4804 条候选落在 1256 个域名。平台 B 的 812 条引用分布在 429 个域名。
这意味着两件事：
- 单点押注无效。不存在"发一篇到某个站就能被引用"的捷径。
- 但头部仍值得优先投入。前 5 个域名吃掉了两平台约 30% 的引用，性价比明显高于长尾。
4.3 技术社区类内容在引用中的权重最高
按渠道类型聚合后，与本次测量最相关的一个结果是：开发者 / 技术社区类内容占平台 A 全部引用的 20.6%，是所有渠道类型里最高的；进一步看单一域名，占比最高的正是阿里云开发者社区。
这个结果对做技术内容的人是一个正向信号：技术社区里的工程实践类文章，在中文 AI 回答的引用结构中权重相当高，而且这类内容天然具备"可被引用"的结构特征——有明确的问题、具体的实现、可核对的字段与口径。
反过来说，只写观点、不写实现的文章很难进入引用池：它们缺少可以被单独摘出的、可验证的技术断言。
4.4 自建域名应当被单独作为对照组测量
这是本文在方法上最重要的一个建议。
在采样中我额外设了一个对照组：把一个品牌自建站点单独标记，观察它三个指标——提及率 / 被引用率 / 被检索率。结果是三项全部为 0，也就是说它从未进入过检索池。
这个观测的价值不在于某个具体站点，而在于它揭示了一类容易被误判的情形：
如果只看"有没有被引用"，你会得出"内容写得不好"的结论，然后去改内容。 但真正的原因在上一层：这个域名根本没有进入候选集。
要区分这两种情况，唯一的办法就是单独测量自有域名的检索命中率——这也是上文强调必须分开 RETRIEVED 与 SELECTED 的现实理由。
常见的索引层成因有两类：域名尚未被主流中文索引收录（例如站点可抓取性、索引准入条件未满足），以及可抓取入口不足（缺少面向 AI 的说明文件、结构化数据不完整、站点地图未划分内容子集）。
说明：以上均为采集当日（2026-09-23）的观测状态。写"采集当日"是必要的——索引层状态会随时间变化，如果表述成现在时，读者按图索骥去核查就会发现与事实不符。 这也是本文方法的一部分：观测必须带时间戳，否则结论无法复现。
在索引层问题解决之前，优化内容对 AI 可见度的边际收益接近 0。 这是本轮实测最直接的一个教训。
五、局限
我愿意明确写出这套方法的边界，因为不写就没有参考价值：
- 样本为 74 条中文商业问句，不代表所有行业，结论不能外推到全部领域
- 单轮采集，未做时间序列，无法判断信源分布是否稳定
- 各平台响应结构会随版本变化，归一化层需要持续维护
- 部分平台不返回检索池，跨平台 RETRIEVED 对比不完整
- 采集经由第三方接口转发，不排除中间层对结果有影响
六、可复用清单
如果你要自己跑一轮，最少需要这些东西：
项 |
要求 |
Prompt 集 |
≥ 50 条，覆盖"认知 / 问题 / 方案 / 选型 / 效果测量"多类意图，避免同质 |
采样纪律 |
全新会话、无历史、无品牌提示 |
落盘 |
每条一份原始 JSON，保留检索池与引用集原始字段，不要只存清洗后结果 |
判定口径 |
提及 / 引用 / 检索命中三者分开统计，口径写死在代码里而非人工判读 |
对照组 |
至少记录"自有域名被检索率"，这是区分内容层与索引层问题的唯一指标 |
七、结语
AI 引用分析目前最大的问题不是缺工具，而是缺口径。把 RETRIEVED 与 SELECTED 分开、把域名归一化写进代码、把自有域名单独设为对照组——这三件事做完，一轮 74 条问句的采集就能产出可复现、可对照、可迭代的结论。
原始响应数据涉及第三方平台返回内容，此处不公开；文中的字段结构、归一化实现与统计口径均已完整给出，可按上述步骤自行复现。
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。文中数据来自 2026-09-23 的一轮独立会话采集，采集方法与局限已在第四、五节说明。
