如何找到塑造行业 AI 回答的信息来源

读完之后你会得到什么

引用地图，是记录 AI 引擎在回答你的潜在客户提问时,实际引用了哪些页面的档案。它不是你的品牌有没有出现在回答里,而是这个回答是由哪些来源拼出来的。

我在足够多的品类上跑过这件事,所以知道第一次的结果通常不太好看。团队都以为自家网站撑起了那些回答。实际上往往不是。在某个 B2B 品类里,厂商自己的页面只占极小一部分,而一个没人去认领的评测网站承担了大部分工作。

这就是做这件事的意义。你不再靠猜,而是开始看真实的页面。

走完这套流程,你会拿到:

• 针对一个产品或服务品类的 10 到 20 个真实购买问题,用客户自己的说法写出来
• 每个问题都在买家真正使用的 AI 引擎里跑过,引用来源带日期记录下来
• 这些来源按类型整理好,你能看清自己品类的回答从哪里来
• 一份简短清单,列出竞品被引用而你没有被引用的页面,每条都配一个正当的下一步
• 负责人和复查日期,免得这份地图在共享盘里烂掉

适合谁: 企业内部的 SEO、GEO 或内容负责人,或者即便由别人落地、也能提出改进建议的代理商策略人员。不强制使用付费工具,但规模上来之后会有帮助。

前置条件: 一个浏览器、一份表格,以及你自己网站的查看权限。用 agent 版本的话,还需要装好你选的那个 agent,以及一个可以指向的文件夹。

耗时: 单个品类的第一轮大约两小时。其中约 45 分钟用于跑提示词和复制来源。这 45 分钟正是值得交给 agent 的部分,剩下的部分需要你的判断。

完成的定义: 你能说出自己品类里支撑回答的三到四类来源,能指出你缺席而竞品在场的具体页面,并且能把带 URL 的任务交给别人。如果你手上只有一串域名和"Reddit 好像挺重要"这种模糊感觉,那还没完成。

Auspia 的看法: 大多数团队会直奔"我们需要更多品牌提及",因为他们从没看过回答到底是由什么拼出来的。地图的作用,就是把这种模糊直觉变成一页可以行动的东西。

开始之前:决定一切的两个选择

后面的产出由这两个选择决定。两个都容易选错,而且事后都不好改。

只选一个品类,不要覆盖整个业务。 一家既卖软件又做服务业务的公司,有两套完全不同的来源生态。同时映射两者,只会得到一个谁都不像的平均值。选营收权重最大的那个品类,剩下的留到下个季度。

有意识地选择引擎。 Google AI Overview、ChatGPT、Perplexity、Gemini 并不是从同一个池子里取料。某个来源在一个引擎里失势了,在另一个引擎里可能依然有分量。至少跑两个。如果不知道选哪两个,问问销售团队客户会提到哪个界面,或者查一下来自 AI 域名的引荐流量。

现在划一条边界。这是观察工作,不是证明工作。你记录的是某个引擎在某一天返回了什么。回答每次运行都会变,所以单次观察是一个数据点,不是趋势。所有记录都要带日期,否则整份文件一个月后就没法用了。

第一步:搭建问题集

写下 10 到 20 个客户在做选择时会问的问题。不是关键词。是问题,用客户自己的话。

这一步很多人会赶着过,而它恰恰决定了后面值不值得做。用关键词导出做出来的问题集,产出的是"人们怎么搜索"的地图。用销售通话记录做出来的问题集,产出的是"人们怎么购买"的地图。这两份清单不是一回事。

可以拿来出题的素材:

• 销售团队最常被问到的购买前问题
• 购买后 30 天内的支持工单
• 主要商业查询的"大家还在问"板块
• 你自己的关键词研究,改写成问句
• 买家会做的竞品对比搜索

把问题类型混着来,因为不同形状会拉出不同的来源。

预期产出: 一份表格,每个问题一行,一列是问题形状,一列是你要跑它的引擎。

质量检查: 把清单读一遍,问自己真实买家会不会这样输入。如果一个问题只有已经懂你产品分类的人才看得懂,就重写。买家真会问的 10 个问题,胜过 50 个听起来像关键词导出的问题。

补救路径: 如果凑不到 10 个问题,那是调研问题,不是映射问题。先把最近 20 条销售通话记录或最近 50 张支持工单翻出来,从里面提取问题再继续。

问题形状是那个隐藏变量。同一个产品的直接对比问题和风险问题,返回的来源并不一样。

第二步:跑问题并记录来源

这里是机械性的核心,也是手工做会崩掉的地方。先手动做 5 个问题,搞清楚产出应该长什么样。剩下的再自动化。

对每个问题,在每个引擎里:

1. 开一个新会话。之前的上下文会改变引擎检索到什么。
2. 原样照抄地问。
3. 打开引用面板或来源列表。多数引擎里这是回答旁边的一个小图标,而不是一个可见列表。
4. 记录每一个被引用的 URL,同时记下域名和来源类型。
5. 记下日期、引擎,以及这次回答到底有没有引用。

按这个结构记录:

最后一行值得多想一会儿。品牌可能被回答点名,但自家页面一条都没被引用。反过来,品牌也可能被引用却没有被显著点名。这是两个不同的信号,如果你只追"有没有出现",两个都会看错。我见过团队为一个来自批评自家页面的提及而庆祝。

预期产出: 一张长表,每个问题、每个引擎、每条被引用的来源各一行。

质量检查: 至少挑三行点进去,确认被引用的页面确实支撑了它被引用的那个说法。引擎偶尔会引用一个只是提到话题、但并没有回答问题的页面。这类行是噪音,要标出来。

补救路径: 如果某个引擎对某个问题没有返回任何引用,那是一个发现,不是失败。记成零来源然后继续。那些不需要检索就能被回答的问题,是自家内容影响不到的问题。

这个闭环简单又枯燥。正是这种组合,让它成为适合交给 agent 的活儿。

第三步:按类型给来源归类

现在把长表压缩成你品类的全景图。把每个被引用的 URL 归到五个桶之一:

• 自有: 你自己的网站,或竞品的网站
• 零售与市场平台: 产品页、比价页、应用商店
• 社区与 UGC: Reddit、YouTube、Quora、论坛、被收录的 Discord 帖子
• 评测目录与 B2B 平台: G2、Capterra、Clutch、Trustpilot、行业垂直目录
• 独立编辑与参考资料: 行业媒体、新闻、Wikipedia、分析师解读、独立博客

按桶、按引擎数一遍,引用地图就出来了。

你要看的不是单一数字,而是形状。有些品类几乎全靠社区帖子和行业媒体撑着,品牌自家网站几乎没有存在感。另一些品类由产品页主导,因为答案本身就在产品页里。这个配比取决于买家问什么,而不是谁的网站做得多好。对已经在网站上砸了两年的人来说,这话不太好接受。

预期产出: 一张小表,每类来源一行,每个引擎一列,显示被引用来源的占比。

质量检查: 如果某个桶占了引用的 70% 以上,从里面抽 5 个 URL 确认它们真的属于这一类。一个高流量的聚合站可能伪装成编辑类来源,实际上是个目录。

补救路径: 如果数字看起来毫无规律,多半是你把不同形状的问题混在一起,把规律盖住了。按问题形状拆开表格再看一遍。价格问题和风险问题的来源构成经常完全不同。

第四步:找出竞品被引用而你缺席的缺口

把长表筛成"竞品出现、我们没出现"的行。筛出来的这份清单就是你的工作清单。它比"我们需要更多提及"这种笼统指令有用得多,因为每一行都已经挂着 URL 和客户问题。周一交给同事,他就能直接开工。

对每一行,打开被引用的页面,回答三个问题:

1. 我们的产品真的应该出现在这个页面上吗?
2. 如果应该,缺的是什么——一个我们从没认领的收录、一个我们缺席的对比、一个没人提到我们的帖子,还是一次我们没去要的评测?
3. 让我们出现在那里,最小的正当动作是什么?

第三个问题才是纪律所在。动作因桶而异。这里搞错,就是 SEO 跑去给记者群发关于 Reddit 帖子的冷邮件。

预期产出: 一份筛过并排好优先级的清单。按来源在你的问题集里出现的频次排序,而不是按域名听起来多权威。一个在 20 个问题里被引用 6 次的论坛帖,排在一次性的行业媒体前面,而且动手也容易得多。

质量检查: 对每条保留下来的行,确认你能说出它对应的客户问题。说不出来就删掉。为管道里没人问的问题而被引用的页面,只会分散注意力。

补救路径: 如果筛出来的清单还是巨大,说明筛得不够狠。第一轮最多留 10 条,按引用频次排序,做完再回头打开完整清单。

同样是缺口,修法不同。把每一次引用缺失都当成外联问题,团队最后就会去跟编辑推销 Reddit 帖子。

第五步:把机械的那一半交给 agent

第二步和第三步最耗时间、最不需要判断。这正是值得委派的工作的定义。问题集和优先级排序留在人手上,因为这两处一旦判断错,整套动作就白做了。

下面四个 agent 都能跑同一套方法。变的是方法存在哪里、产出怎么回到你手上。按这个选,而不是按这个月哪个模型在榜单上得分高。

Codex

适合你想让地图住在代码仓库里、每次运行都产出一份经过复核的成品。如果你的网站本来就在 git 里,这条路摩擦最小。

建一个项目文件夹,里面放 citation-map/ 目录、存问题集的 questions.csv,以及一个写明方法的 SKILL.md。SKILL.md 里写清楚:查哪些引擎、记哪些字段、怎么给来源分类、输出文件长什么样。每次运行存一个文件,用日期命名,这样是累积历史而不是覆盖。

让 Codex 跑这些问题,把行追加到当次运行文件里,并输出一张按引擎分列的来源占比汇总表。因为产出是仓库里的文件,你能拿到可复核的 diff,再决定什么算最终版。这个复核环节才是重点:你检查的是分类,不是重做采集。

有一条规则无论如何都要写进 SKILL.md:agent 只记录它观察到的内容,不得推断它没看到的引用。凭空造出来源是这套流程里破坏性最强的失败模式。一条明文规则加三行抽查就能挡住大部分,而且每次抽查的三行都要换。

Claude Code

适合你需要把方法对照一份明文政策来读,并且想用长上下文复核被引用的页面。

把方法写进 CLAUDE.md 或一个项目 skill,包含你的来源类型定义和精确的输出结构。把 Claude Code 指向运行文件夹,让它给每个被引用的 URL 分类,然后标记出那些页面内容其实并不支撑该引用的行。

第二件事才是值得付费的部分。读 200 个被引用的页面,判断每一个是否真的回答了问题,对人来说很痛苦,对有明文标准的 agent 来说是合理的活儿。让它给每一行输出一个置信度标记,你只复核低置信度的那些。

ChatGPT

适合你想把搭建成本压到最低,而且这件事是一次性做完而不是周期性运行。

把方法作为自定义指令或保存好的项目提示词粘进去,附上你的问题清单,按引擎分批处理。要求它输出一张列结构和第二步完全一致的表,这样可以直接粘进表格。

要注意的是,ChatGPT 本身也是你要测量的界面之一。如果你在映射 ChatGPT 自己的引用,请在一个没有加载你方法的干净会话里做,否则观察就被污染了。用一个会话采集,用另一个会话整理。

Hermes Agent

适合你想让方法作为 skill 持久化,不用每次重新解释就能跨运行改进。

把引用地图这套方法连同问题集和输出结构一起装成 Hermes skill,然后按周期运行,月度通常合适。因为 skill 和它的记忆是持久的,你第一个月做的修正会带到第二个月。如果 agent 把一个目录误判成编辑类来源,改一次规则就行。

代价是持久记忆需要定期复查。每隔几次运行,读一遍 skill 文件,确认累积下来的修正仍然描述的是你想要的方法,而不是一堆没人说得清的一次性例外。

四个 agent 跑的是同样的五个步骤。按方法该放在哪里来选,而不是按哪个模型在榜单上得分最高。

第六步:动手之前先验证地图

不要拿一份没验证过的地图去派活。先跑这套检查。这里的五分钟能省下一个季度的方向性浪费。

• 一周后重跑三个问题。 如果来源构成完全变了,要么你的问题集太不稳定,要么样本太小。记下这种波动,别把第一次当成标准答案。一定程度的波动是正常的,整体换血才是警告。
• 确认引擎,而不只是确认回答。 出现在 Perplexity 的来源,在同一个问题的 ChatGPT 里可能缺席。汇总时把引擎分列保留,合并后的总数恰好会盖住你需要的信号。
• 也检查你自己的引用。 如果品牌被引用了,打开那个页面。有时候引擎引用的是一个批评你的页面,或者一个你根本管不到的页面。那是有用的信息,不是胜利。
• 确认每一行都有日期。 没有日期的引用地图,之后跟什么都比不了。
• 核对来源数量。 如果一个问题返回了 40 个来源,其余都是 3 个,检查一下你是不是抓到了"相关"面板而不是真正的引用。

完成的定义: 你能把汇总表和一份筛好的工作清单交给同事,他们不用问任何一行的含义就能开工。

维护这份地图

每季度用同一套问题集跑一次全量,每月对商业价值最高的 5 个问题跑一次轻量版。旧记录留着。有意思的信号通常不是快照,而是漂移:某一类来源在悄悄增长,或者某个竞品开始出现在它以前不在的桶里。

问题集每半年重看一次。购买问题会随产品和市场变化,过期的问题集会产出一份你已经不在卖的品类的地图。

有一件事要克制:别把它做成仪表盘。产出是一份带负责人和 URL 的工作清单。如果最后没人手上有任务,这份地图就没起作用。

常见问题

做这件事需要付费的 AI 可见性工具吗?不需要。手工版对单个品类是可行的,半天就能做完。当你要跟踪多个品类或多个市场,或者想要历史趋势线又不想自己维护表格时,工具才值这个钱。

多少个问题才够?每个品类 10 到 20 个。少于 10 个,你分不清规律和巧合。第一轮超过 20 个,分析就做不完,而分析才是产出工作清单的部分。

要不要把我们已经出现的问题也算进去?要。知道哪些来源在支撑你,和知道哪些漏掉了你一样有用。它还能告诉你改内容的时候该守住什么。

如果每次问都得到不同的回答怎么办?这很正常,也值得记录。把同一个问题跑三次,记下波动。如果来源集合每次都完全不同,就把这个问题当作低置信度,在排优先级时降低它的权重。

能直接用引擎自己的来源列表,不打开页面吗?第一轮采集可以。对于你打算动手的那些行,不行。你需要读页面才能判断自家品牌是否真的该出现在那里,以及什么才算有用的贡献。

这跟排名追踪有什么区别?排名追踪告诉你自家页面出现在结果列表的什么位置。引用地图告诉你一个回答是由哪些页面拼出来的。有页面排第一却从没被引用,也有页面根本排不上名却是回答的骨架。这个差距,就是这件事值得花半天的原因。

作者: Ethan Marlowe,Auspia 的 GEO 计量负责人,负责过 500 多个提示词。他写提示词追踪、引用报告、可见性仪表盘,以及如何区分真实的 AI 可见性变化和运行之间的噪音。