ai-visibility-monitor：先挑出可赢取的买家查询，再跑引用监测

所有 AI 可见度监测都绕不开一个前置问题：监测哪些问题。商业工具用行业模板和提示词库帮你猜，这个仓库（WorkSmartAI-alt/ai-visibility-monitor，MIT 协议，Python 3.10 以上的 CLI）选了另一条路——把问题清单接到你已有的搜索资产上：从 Google Search Console 里找出排在五到二十名、也就是「够得着却还没拿到」的买家查询，优先在这些题目上检查 AI 引擎引不引用你。搜索端快要赢的题，往往也是 AI 端最该先看的题，这是它全部设计围绕的一个判断。

四个脚本，各管一段

工程形态上是四个独立小脚本，而不是一个大而全的系统。citation_check.py 负责引用检查：对买家查询在 Claude、ChatGPT、Perplexity 三家引擎上跑，看你的域名有没有被引用、排在第几位，默认每条查询跑两次取平均——在开源工具里内置双次采样，这个默认值值得表扬，虽然幅度仍然偏小。缺哪家 API 密钥就跳过哪家引擎，工具不会因此罢工。

其余三个脚本各管一段。gsc_pull.py 拉搜索后台数据，重点抓五到二十名的临近位置查询——这就是「可赢取查询」的数据来源。ga4_pull.py 从分析后台切出 AI 引荐来源的流量切片，把「被引用」和「来了多少人」两本账放在一起。prereqs_sweep.py 做前置体检：检查站点的 robots.txt 与 llms.txt 对 AI 爬虫的放行口径——引用监测跑出来全线挂零的时候，第一嫌疑往往不是内容不行，而是门根本没开，robots 配置的门道见AI 爬虫 robots 配置卡。

为什么搜索端快要赢的题值得优先拿到 AI 端去测？我们的理解是两层。第一层是意图重合：能在搜索端排到前十附近的买家查询，本身就是验证过有真实需求、有商业意图的题目，拿它们当监测提问集，天然避开了「凭空想问题」的悬空感。第二层是资产复用：这些题你已经在搜索端投入过内容，若 AI 端恰好也引用你，等于一份内容两处收租；若 AI 端不引用你，差距点就找得非常具体——同一道题，搜索端第三名、AI 端零引用，要补的东西就藏在这个落差里。

双次取平均这个默认值也要两面看。比单次采样可靠是肯定的：AI 回答的随机性不小，跑两次能滤掉一部分偶然。但它离「稳」还有距离，理想口径是多采样报区间。实务上我们的建议是：对进入正式监测的题目，把轮次密度提上去，用「多天同向」来补「单轮样本小」的不足，趋势判读的纪律见指标与运营手册。

从一条查询扩出一圈邻题

它有一个名为 expand 的扩展功能：围绕你给定的查询自动生成一批邻近查询，按「可赢性」评分排序，推荐出近期值得打入的题目清单。这解决的是监测提问集的冷启动——你从五条种子查询出发，工具帮你扩成一圈邻题，每条都带着优先级。当然，扩出来的题仍要过人脑：自动生成的邻近查询是不是你客户真实的问法，工具不知道，你知道。

来源结构比总数更值得看

来源表面分类是它另一个实用设计。把引用你的 URL 按社区、问答、媒体、博客等类别归堆，并配行业基线做对照，看的是「你是被谁引用的」这个结构问题。总数相同、结构不同的两个品牌，后续打法完全两样：引用集中在社区的，经营社区帖的杠杆最高；引用集中在媒体的，数字公关的方向更对症。行业基线的价值在于校准预期——某些行业天然被社区来源主导，拿别的行业的结构当目标会白费劲。

顺着分类还有一个小而狠的功能：定位被反复引用的高杠杆社区帖。与其泛泛地「去做社区运营」，不如精确地知道是哪个帖子在被各家引擎反复借用，然后决定是参与它、替换它还是围绕它补充内容。加上基于历史数据的引用率轨迹追踪，这组功能让它在「诊断」上比同类开源脚本多走了一步。

UGC 占比高这个信号也要会读。社区来源被引用多，说明口碑资产在起作用，这是好事；但社区内容你控制不了，帖子里的过时信息、错误信息同样会被反复搬运。所以来源结构报告的下一页，永远是那份高杠杆帖子清单——逐条核对内容是否仍然准确、是否需要你去补充更正，这个维护动作比新发十个帖子更值钱。

上手顺序与维护预期

推荐的接入顺序是先把体检跑在前面。第一步 prereqs 体检，确认门开着；第二步用少量种子查询跑引用检查，验证三家引擎的密钥都通、输出符合预期；第三步用扩展功能把题库扩到几十条的量级，人工筛掉不像真实问法的；第四步才定频次、上定时，把它变成日常监测。跳过前两步直接全量跑，最常见的结果是密钥配置错了几天没人发现，采回一堆空结果。

维护预期也要按开源早期项目来设：仓库星数还在两位数，迭代节奏取决于维护者，遇到问题要做好读源码的准备。好消息是它结构简单——四个互相独立的小脚本，坏一个不影响另外三个，最坏情况下你还可以只保留 citation_check 一个脚本继续跑核心检查。工具的可持续性风险与数据带走方案，在采用任何个人开源项目前都值得过一遍。

口径与适用边界

口径上要说满的是：三引擎引用检查走的是各家 API（Anthropic、OpenAI、Perplexity 的接口），测的是接口返回，不是消费端界面答案，两个入口的回答并不等价，原理见API 监测与网页端监测对比卡。所以它的读数适合看相对趋势与逐题排查，不宜直接当成「用户看到什么」的口径。引用率本身作为指标的定义与分母，见引用率术语卡。

适用的画像很清晰：已经在做搜索优化、手里有现成的搜索后台与分析后台账号、且有人愿意跑命令行的团队。它最聪明的用法是当 AI 端的「第一公里」工具——用搜索资产筛出优先题目，查出门没开的问题，再把确认有价值的题目扩进正式监测，交给更重的工具或流程长期跟踪。部署形态想再轻一步的，可以看零服务器的 llm-visibility-tracker；想要整改侧技术审计的，看SearchStack AEO。反过来，没有搜索数据积累的新站，它「从已有资产出发」的前提就不成立，先做内容与技术底子，再谈精细监测。