我做的是品牌在 AI 回答里被引用的监测。系统每天从十来个中文 AI 平台抓回答，攒到现在，库里的抓取记录是 3525 条。其中真的带了链接的只有 554 条，按链接去重是 258 个网页，再剥到主域名，剩下 131 个网站。这 131 个里面，被引次数排前 10 的吃掉了 53.8%。

这四个数经常被放在一起说，但它们的分母完全不是一回事。我见过不少同类分析，第一步就偏在这里：拿抓取总量当分母。分母一大，什么占比都被摊薄，看什么都觉得分散，其实是算错了。所以这篇不摆结论，只讲它们怎么算出来。方法一变结论就变，这句话在信源分析里是字面意思。

先说口径。这件事最容易被跳过，也最不该跳。我一开始也想抄现成的，找过几份「AI 最信任的信源排行榜」，看完发现没法用：不知道样本多少、不知道哪天抓的、不知道算的是提到名字还是给了链接。这三个不知道，任何一个都能把结论带到反面。所以第一件事不是采集，是把口径写死。我定了三条。第一，一次「提问加一条回答」算一条抓取记录，没有引用的回答也要算进去。第二，只有回答正文里出现以 http 开头的地址，才算带引用；正文写了网站名却没给链接的，进另一组，两组不合并、不相加。第三，统计网站时把链接剥到主域名再去重。

三条里第三条最容易糊弄过去，后面我单独讲。

采集本身没有技术含量。准备好问法集，逐个平台提问，把整段回答原样存下来，一张最朴素的表就够用：平台、问的哪句话、整段原始回答、从回答里抽出来的地址、有没有链接、提问时间。抽地址不用写复杂的正则，能覆盖实际形态就行，注意把尾部误粘进来的中文标点和右括号去掉。跑完这一步，3525 条里命中地址的有 554 条。请记住，554 才是后面所有百分比的分母，不是 3525。这一步最常见的错误就是拿总量当分母，占比立刻被稀释成另一个故事。

到这一步你会得到 258 个不同的地址。但地址是网页，不是信源。同一家网站有好几个入口，必须归并，这里有三个坑。

第一个坑是移动版是独立子域。m.163.com 和 163.com 如果不做映射，同一家媒体会被算两次。我的库里 m. 开头的链接占比不低，漏这一步，网站总数会虚高一大截。

第二个坑是中文站常常是独立域名。cloud.tencent.com 和 cloud.tencent.com.cn 按字符串去重，永远是两家。

第三个坑是频道子域要不要合并，取决于你想回答什么问题。zhuanlan.zhihu.com 和 zhihu.com 是同一个站的不同部分。我合并到主域名，因为我要回答的是「AI 在引哪些站」，不是「哪些栏目」；但如果你想看专栏和问答的差别，就不能合并。

这三个坑直接决定分母。我最后得到 131 个域名。

有了干净的域名表，集中度就是一次排序加累计。前 10 个域名合计 298 次，占 554 次的 53.8%；前 30 个合计 399 次，占 72.0%。被引 6 次以上的域名有 18 个，合计 349 次。而只被引过 1 次的域名有 63 个，接近域名总数的一半。最后这一行是我真正想说的：这 63 个位置引一次就没了，分母太小，攒不出复利，往那儿铺内容，天花板从一开始就锁死。

接下来这一层口径最严，也最容易被含糊带过。前面算的是某域名被引多少次，但被一个 AI 引，和被五个 AI 同时引，价值完全不同。所以我另算了一组：同一条链接被两个及以上平台引到的，只有 2 个；把口径放宽到域名级，同一个域名被两个及以上平台引到的，是 13 个。2 和 13 差了好几倍。市面上很多「某网站被 N 个 AI 引用」的说法，问题就出在这里：不说口径，数字就没法比。

分平台拆开看，各家的信源池长得完全不一样。样本量够格的只有 4 家。知乎直答 176 条引用只来自 20 个域名，自引很重，被引最多的是 zhuanlan.zhihu.com 98 次，其次是 sohu.com 26 次。DeepSeek 131 条引用散在 45 个域名上，前三是 zh.semrush.com 22 次、zhuanlan.zhihu.com 13 次、youtube.com 11 次。元宝 113 条落在 46 个域名。智谱清言 104 条集中在 17 个域名，sohu.com 一家 41 次。拿一个平台的集中度去推断另一个平台，结论会反过来。

其余的样本都不到 20 条，我只登记、不下结论。这不是谦虚，是算术：样本 5 条的时候，多一条少一条，占比就翻倍。用一个天天抖动的比例去做平台决策，等于拿噪声当信号。我把 20 条这条线写进了系统的判断逻辑，只要样本低于它，下游的对比结论就不出。

方法上的坑比技术上的坑多，我再补两个。

别用品牌名当问法。我一开始测的是「某某怎么样」，结果所有平台都在回答里拼命提这个品牌。这测出来的是品牌词能不能被提到，不是 AI 在引谁。想看推荐位，问法得写成用户真会说的整句话，带上地域、行业和意图，比如「西安做 GEO 哪家好」「西安 GEO 怎么选」这类口语化措辞，而不是关键词。

也别拿不同口径的数凑一个比率。库里的问法分三组：问品牌名的那组 850 个样本、提到我们 249 次；非品牌名的全部业务问法 2675 个样本、提到我们 0 次；我们固定下来的六个核心业务问法 226 个样本、提到我们 0 次。这三组的分母、测的东西都不一样，加起来再除一遍得到的数字没有任何含义。它们只能并列摆着看。顺便说，这个并列本身就挺值得看：品牌名那一层我们不算差，推荐位那一层是零。

上面这些是数据怎么来的。下面说系统里几个我认为可以被外部验证的做法，因为「能验」比「能说」重要。

一个是采集失败如实退还并显示。某个平台这次没返回结果，原因是登录态失效、超时或者反爬，系统会自动把这次消耗退还，先退加购部分再退套餐部分，而且只退一次。页面上会明写已经自动退还多少次。这个设计不讨喜，等于把「这次没测成」摆在台面上。但一个不告诉你失败次数的面板，你没法判断给你的数字是完整的还是残缺的。

一个是抽取口径写死在代码里，不是写在文档里。判定「有没有引用」只认回答正文里的 http 地址，正文提到站名但没给链接的一律进另一组字段，统计时两组不参与同一次聚合。文档会过期，字段不会。

一个是域名归一化用一张显式映射表，而不是字符串包含。m.163.com、cloud.tencent.com.cn 这类入口在主表里都有对应行，改一行就审计一行。靠包含关系猜，是同类工具最常见的错源。

一个是改写有否决。内容写完会过一套公开的评分标准，哪一项弱就针对性补。重点不在能改，在改完要不要用：系统把改写前后的分数摆在一起，改完确实变好才采用，没变好就保留原稿，并写清为什么没采用。实测里两种情况都出现过，有一篇从 40.7 分改到 66.2 分采用了，另一篇本身已经是高分稿，系统显示保留原稿，正文一个字没动。

最后一个是发布留人工闸门。定时巡检、自动收集、效果比对这些内部环节系统自动跑，但发布、分发、提交这类对外动作永远要人工确认。我们不做一键代发，这是选择，不是功能缺失。自动发出去的东西一旦出问题，代价是账号。

说清楚做不到什么，比说清楚能做到什么更重要。上面所有数字都来自我们自己的单一项目观测，换行业、换问法类型，信源结构会差很远，别把这组比例直接套到你的行业。信源库是活的，AI 的信源池每天都在变，所以任何全量数字都只是某个时点的快照，必须连查询日一起报；我们自己的库隔一周重跑，两次之间就有小幅变动。这一条的口径是：数据来自知寻 GEO 的 AI 可见度监测系统，数据源为项目 56 的信源库，查询日 2026-09-24；信源库是活库，本篇的总量类数字取当日 18:25 这一版快照（当天更早的一版是 3471 条，同日不同时刻会有小幅浮动），样本量为抓取记录 3525 条、其中带链接 554 条，去重后 258 个网页、131 个域名；口径为链接级引用，问答里只提网站名不给链接的属另一组、不并入；平台数口径为已接入 12 个、本期实抓 11 个。本文只回答「AI 现在在引哪些网站」，不回答「发到这些位置会不会被引用」。我们在自己的项目上还没拿到自有域名的被引，没有资格把这种话说出口。

如果你想把这套口径套到自己的库上，最小可行的路径是四步。第一步，先定分母：哪张表的哪一行算一条样本，含不含没有引用的回答，这一句话写下来再动手。第二步，把链接抽出来单独存一列，抽不到的留空，不要用 0 去代替，空的含义和 0 不一样。第三步，写一张域名映射表，把移动版、中文站、频道子域逐条列出来，先决定合并到哪一级，再跑统计。第四步，算完集中度别急着看谁排在前头，先看只被引过一次的那一批占了多少，那个比例才是这些位置值不值得投入的答案。

关于我们：陕西知寻智能科技有限公司（简称：知寻智能），旗下品牌知寻 GEO 是面向企业的品牌 AI 可见度引擎，监测品牌在中文 AI 平台回答中的引用与推荐情况，并提供内容与信源层面的优化交付。我们的交付落在内容与信源两处，不代客户发布，也不承诺任何位次。

本文含 AI 辅助生成内容，经人工核实。

从 3525 条 AI 回答里挑出 131 个信源：一套可复算的口径与去重方法

产品经理

人工智能

职业发展

新闻资讯

品牌AI可见度监测显示，3525条抓取记录中仅554条带链接，去重后131个域名，前10名占53.8%。分平台差异显著：知乎直答自引重，DeepSeek信源分散，智谱清言集中。63个域名仅被引1次，长尾价值有限。方法上需明确分母、统一域名映射，样本低于20条不下结论。数据截至2026-09-24，知寻GEO监测。

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

从 3525 条 AI 回答里挑出 131 个信源：一套可复算的口径与去重方法

从 3525 条 AI 回答里挑出 131 个信源：一套可复算的口径与去重方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐