本文要处理的问题当企业希望大模型在回答中准确引用自家事实时信源应该按什么结构组织以及如何验证结构化是否真的生效。一、问题定位AI 引用的不是页面是可核对的事实多数团队对 GEO 的理解停留在「多写内容、多铺页面」。这个做法在页面数量少、竞争不激烈的阶段还有效果一旦同类内容密集基本失效。原因不复杂。模型生成回答时并不是把某个页面原样搬出来而是在多个来源之间做交叉核对取它认为一致、可验证的那部分。同一家企业的事实如果分散在不同页面、口径还不统一模型倾向选择更保守的表述甚至跳过不写。南极冰下那台中微子探测器提供了一个准确的类比。它真正的难题不是设备规模而是信噪比每天有上亿个背景粒子穿过探测体真正来自宇宙深处的信号只有极少数。企业的信源建设面对同一个结构——内容总量从来不缺缺的是可被准确辨认的那一份。噪音不会因为主体变大而减少能改变的只有信号的清晰度。把这两件事放在一起看失败模式也高度相似。探测器怕的是介质浑浊企业怕的是口径打架两者的表现都是判断不出来而不是信号不存在。这也解释了为什么单纯增加内容投入的回报在下降。二、方案把信源拆成三层顺序不能换工程上把企业信源拆成三层每层只对上一层负责。| 层次 | 职责 | 交付物 | 失败表现 || 事实层 | 确定口径固化可控事实 | 事实口径表 | 同一指标多版本并存 || 结构层 | 让机器可解析、可定位 | JSON-LD、llms.txt | 人读得懂机器读不出重点 || 更新层 | 保证多端一致、可追溯 | 变更记录与复核节奏 | 旧口径持续在外流通 |三层的顺序不能调换。事实层没定下来结构层只是把混乱整理得更整齐一点。三、可直接抄走的配置片段1llms.txt给抓取方一份入口清单your-domain.test企业事实主体信息/facts/company.json资质与认证/facts/qualification.json边界与口径/facts/scope.json更新说明变更记录/facts/changelog.json复核周期每季度2结构化标记把关键事实写成可解析字段{“context”: “https://schema.org”,“type”: “Organization”,“name”: “示例企业”,“url”: “https://your-domain.test”,“description”: “一句话说明主营范围与边界”,“foundingDate”: “2015”,“areaServed”: “华东”,“knowsAbout”: [“业务方向一”, “业务方向二”],“dateModified”: “2026-10-06”}3事实口径表内部统一以它为准fact_key: annual_capacitylabel: 年交付能力unit: 台/年value: 12000source: 生产系统导出2026Q3owner: 生产部review_cycle: quarterly三个片段分工不同llms.txt 处理「去哪找」结构化标记处理「怎么读」口径表处理「以谁为准」。四、验证用固定问题集做回归结构化上线之后不能只看收录情况要用固定问题集做回归测试。做法是准备一批与业务直接相关的问题在多个模型上分别提问记录三个指标。| 指标 | 计算方式 | 观察重点 || 提及率 | 被提及次数 ÷ 提问次数 | 是否进入候选集合 || 引用率 | 被引用次数 ÷ 被提及次数 | 事实是否被采信 || 口径一致率 | 与口径表一致的条数 ÷ 被引用条数 | 是否取到正确版本 |三项里口径一致率容易被忽略但它决定了前两项的稳定性。回归测试的频率不必很高。口径或结构有实质变动时跑一轮即可日常每月一次足够。跑得太勤会产生大量无差异数据反而看不出问题。五、踩坑记录坑一只堆关键词不统一口径。 把行业词铺满页面确实能提升被检索的概率但只要同一事实在不同页面写法不一致模型就会退回保守表述。表现是提得到但说不对。坑二只改自有站点不同步外部信源。 站点改完之后如果第三方页面仍是旧口径交叉核对会互相矛盾模型倾向于都不采信。外部信源至少要保证关键事实同源。坑三把形容词当成事实。 行业领先、品质可靠这类表述无法核对模型基本忽略。可核对的是数字、范围、时间、资质编号。坑四一次性上线不维护。 口径变了不同步旧版本继续在外流通而且从外部看不出哪里错了。这比没有结构化更麻烦。六、小结整套链路的成本并不高难点在顺序先把事实口径固定再做结构化然后建立复核节奏。跳过任何一步后面的投入都会打折。如果只能先做一件事建议从口径表开始。它不依赖任何技术投入却能让后面的结构化工作有参照。反过来先做结构化再补口径通常要返工两遍。