一次提问拆成29次检索：AI搜索的fan-out机制

先给结论：在AI搜索里，用户的一次提问对应的不止一次检索。生产环境监测数据显示，平均每个源查询会被拆成28.83个不同的子查询——你优化的是"一个词"，AI 检索的是"二十几个问法"。这件事直接改写了内容布局的思路：只盯主词排名的做法，在AI引用场景里的投入产出正在被高估。

现象与数据：一次提问，二十九次检索

结论：Foglift Research 对 55,335 条 AI 回答的监测显示，平均每个源查询会拆成 28.83 个子查询，被引最多的域名也只占 2%。

这份证据来自 Foglift Research 发布的 GEO Statistics Report 2026，样本是五个引擎上 55,335 条成功AI回答，统计窗口为 2026 年 3 月 20 日至 10 月 2 日（UTC）。核心指标如下：

指标	数值	口径
成功AI回答样本	55,335 条（其中 ChatGPT 9,967 条）	五引擎，2026-03-20 至 10-02
带引用的回答占比	78.8%	同上
平均每条回答的引用数	6.22 条	同上
查询扇出（fan-out）乘数	28.83×	2,843 个源查询对应 81,974 个不同子查询，2026-04-27 至 10-02
被引最多域名占比	youtube.com，仅 2%	344,162 条引用去重后统计

三个数字放在一起看：78.8% 的回答带引用、平均每条回答 6.22 条引用、而被引最多的域名也只占 2%。这说明两件事——引用是AI回答的常态，但引用的分配高度分散，没有任何一个"万能信源"。

而扇出乘数 28.83× 揭示的是这些引用是怎么被找出来的：不是一次检索挑出六条链接，而是几十次子检索各自带回候选，再由模型汇总。

机制拆解：AI为什么要把一句话拆成几十次搜索

结论：AI 会把用户的一句意图拆成多个完整子问题，逐个检索、取证再汇总，这也是平均每条回答会挂 6.22 条引用的原因。

原因要从用户输入的形态说起。用户在对话框里写的是意图，不是查询词。"帮我挑一款适合小户型、有宠物也能用的扫地机器人"——这是一句话，但它同时包含预算判断、宠物毛发场景、噪音诉求、售后服务等多个信息面。

传统搜索引擎会把它切成几个关键词拼一次查询，AI 则倾向于把这句话拆成多个完整的子问题，逐个去检索、取证、再汇总成一段回答。这就是 fan-out，也就是查询扇出。

第二个原因是证据压力。此前已有研究测出，AI 摘要对问句式查询的触发概率远高于关键词式查询（可参考问句触发AI摘要的概率是关键词式的近7倍那篇的拆解）。问句意味着模型要"回答"而不是"罗列链接"，回答就需要论据。

一个意图拆出的每个子问题都要有自己的证据链，模型宁可多搜几次，也不会用一条页面的内容硬撑整段答案——这也是为什么平均每条回答会挂 6.22 条引用：引用数量本身就是扇出检索的结果。

还有一层容易被忽略：扇出不只发生在回答生成的起点。模型在组织答案的过程中，如果发现某个子问题的证据不足或相互冲突，会追加检索补证——检索、生成、再检索的循环意味着实际发生的子查询可能比初始拆解更多。

对内容方的含义是：你的页面不仅要能被"相关问题"召回，还要能扛住"追问式"检索的二次核对，写得含糊、经不起对照的段落会在这一轮被淘汰。

扇出如何改变"被命中"的定义

结论：在扇出结构里，一次提问会展开成几十次独立子检索，你的内容可能只在其中几次被召回，排名不再是全部。

在传统搜索里，"被命中"的定义很窄：某个关键词的某次搜索，你的页面排到了前列，用户看到了。一次提问对应一次检索，排名是全部。

而在扇出结构里，同一次提问会展开成几十次检索，你的内容可能在其中三次子检索里被召回、在另外二十几次里完全不出现。模型汇总时，这三次出现就是你的全部存在感。

这解释了引用分布为什么如此分散——youtube.com 这样的巨头也只占 2% 的引用份额，因为每个子问题各自偏好不同的信源，没有一个页面能同时是二十几个子问题的答案。

对做内容的人，这意味着竞争的单位变了：不再是"一个关键词下的一次排名之争"，而是"一次提问展开出的几十场小型召回，你能参加几场"。

第三方榜单类内容之所以频繁被AI引用，也与它们天然覆盖了大量并列子问题有关，此前AI引用为什么总落在第三方榜单上一篇分析过这个结构。

反直觉观点：宽度比单点深度更先起作用

结论：AI 引用场景下，围绕主词把单页打磨到极致的投入产出被高估，内容覆盖的宽度比单页深度更先决定引用概率。

主流说法是"把内容做深做透，一个页面打磨到位就能被引用"。

我们的判断更直接：在AI引用场景下，围绕主词把单页打磨到极致的投入产出被普遍高估了，内容覆盖的宽度——能不能接住扇出的那二十几个子问题——比单页深度更先决定你被引用的概率。

理由就是上面的机制：扇出后每场子检索是独立召回，一个再优秀的页面也只能赢下其中两三场，其余场次你没报名就等于弃权。

这不是给注水内容开绿灯。宽度指的是用真实存在的子问题铺开结构：每个子问题有一段能独立成立的回答，而不是把同一件事换个说法重复二十遍——后者在模型汇总阶段会被去重甚至忽略。

我们在服务中看到，多数企业的内容清单是围绕几个核心词排出来的，客服记录、评论区、售后工单里用户真实的问法很少进编辑计划；结果页面在主词上做得很扎实，扇出的子检索里却大面积缺席。

把"用户会怎么问"而不是"我们想排什么词"作为内容清单的起点，是这一步真正的杠杆。

也要防另一个极端：宽度优先不等于放弃已覆盖子问题的质量。扇出之后的每个子检索都会做一轮筛选，能被摘录的段落必须自包含——不依赖上下文就能读懂、数字有出处、结论明确。

实践中比较稳的节奏是：先用子问题清单把覆盖面铺到位，再回头看每个被覆盖的子问题在AI里实际表现如何，把召回频繁但引用不下的段落逐个打磨。两步的顺序不能反——先打磨后铺面，会在没人看见的地方花掉大部分精力。

可执行做法：把扇出接进内容规划

1. 先列子问题清单：从一个主问题出发，列出 10-20 个用户真实的子问法，来源用客服记录、电商评论区、搜索下拉词，不用拍脑袋想。
2. 逐项检查可命中性：每个子问题对应的页面或段落，抽出来单独看——不看上下文能否自包含地回答它。h2 标题尽量写成子问句本身。
3. 补FAQ问答对：核心页面底部补一组常见问答，每问独立成立，覆盖那些不值得单开一页的碎问题。
4. 抽样观察真实扇出：用AI可见度监测工具抽样记录品牌相关 prompt，观察实际展开的子查询方向，对照自己的内容清单找缺口。
5. 按月复盘被引页面：统计被AI引用的页面各自覆盖了哪些子问题，把未被任何页面覆盖的高频子问题列入下月选题。

执行时有个取舍要说明：子问题清单里总会有一批低频尾部问法，单独成页的性价比不高。这类问题不必硬铺页面，放进核心页的FAQ段落即可——扇出检索对它们只要求"有答案可摘"，不要求"有专页可落"。

边界与不适用

结论：28.83× 来自 2,843 个源查询的匿名化监测样本而非全网普查，会随产品版本、语言市场和问题类型浮动。

这份报告是生产环境的匿名化监测样本（2,843 个工作区源查询），不是全网普查，28.83× 这个乘数会随产品版本、语言市场和问题类型浮动。

品牌词类查询的扇出通常明显低于探索型问题——"XX公司官网"拆不出二十几个子意图。对内容极少的小站点，先补齐基础事实字段比铺子问题矩阵更急。

另外，扇出乘数描述的是检索行为，不直接等于引用概率，两者之间还隔着内容质量与信源信任度的筛选。

信源：Foglift Research《GEO Statistics Report 2026》（n=55,335 条AI回答，窗口 2026-03-20 至 10-02 UTC；fan-out 口径 n=2,843 源查询/81,974 子查询，2026-04-27 至 10-02）。原始报告：foglift.io/research/generative-engine-optimization-statistics。相关背景另见AI Mode和AI Overviews的引用重合度分析。

常见问题（FAQ）

扇出乘数 28.83× 是所有AI平台都一样吗？

不是。这个数字来自 Foglift Research 生产环境的匿名化监测样本，会随产品版本、语言市场和问题类型浮动。品牌词类查询的扇出通常明显低于探索型问题，"某某公司官网"这类问法拆不出二十几个子意图。

内容宽度优先，是不是意味着可以少写深度内容？

不是。宽度指的是用真实存在的子问题铺开结构，每个子问题有一段能独立成立的回答。把同一件事换个说法重复二十遍属于注水，在模型汇总阶段会被去重甚至忽略。

小站点资源有限，应该先做宽度还是先打磨质量？

先铺覆盖面，再回头打磨。实践中比较稳的节奏是：先用子问题清单把覆盖铺到位，再看每个被覆盖的子问题在AI里实际表现如何，把召回频繁但引用不下的段落逐个打磨。两步顺序不能反。

怎么知道用户真实的子问法有哪些？

从三个地方取：客服记录、电商评论区、搜索下拉词。这些位置反映的是用户实际怎么问，比拍脑袋想的词更接近扇出检索的真实分布。

低频尾部问法需要单独成页吗？

不必。扇出检索对这类问题只要求"有答案可摘"，不要求"有专页可落"。放进核心页的 FAQ 段落即可，单独成页的性价比不高。

数据与来源

本文引用的核心数据出处：Foglift Research《GEO Statistics Report 2026》，样本为五个引擎上 55,335 条成功AI回答，统计窗口 2026-03-20 至 10-02（UTC）；其中查询扇出口径为 2,843 个源查询对应 81,974 个不同子查询，窗口 2026-04-27 至 10-02。原始报告：foglift.io/research/generative-engine-optimization-statistics。

想看这套方法在实际行业里的落地，可以看灵曦GEO的服务页。