开源 GEO 监控工具能做什么：94 个 GitHub 仓库的深度对比

开篇：先承认一件事

你的团队提议「这个用开源方案自己搭就行，不用买」——这篇是你拍板前该问的几个问题。

先给结论：这个提议在某些场景下是对的，本文会告诉你是哪些场景。 开源社区在这件事上做了大量工作，其中一部分成熟度相当高。

但「开源」这两个字在采购语境里经常被默认成三件事——免费、中立、能长期用。 这三件事都要单独核，没有一件自动成立。 下面用一次完整的市场扫描说明为什么。

这篇文章把这件事做得比较彻底：

```
时间 2026-09-21
方法 GitHub Search API，10 组关键词，去重，相关性过滤
样本 94 个仓库（剔除 3 个：2 个误匹配 + 1 个我方自有仓库，见第十节披露）
处理 逐个拉取 README 原文，标注引擎覆盖、访问方式与能力，人工复核
```

采样方法写在文末——口径、关键词、判定规则全部列出。你可以照着核一遍，结论不一致以你的为准。

关于时效，先说清楚一件事：开源项目的变化速度远高于任何一篇文章的更新速度。
star 数、维护状态、引擎清单每天都在变——一个今天还在活跃维护的项目，
三个月后可能已经停更。所以本文标注采样日期，并按月用同一套口径重新扫一遍，
每次更新都会和上一版对比，把变化列出来。

你读到的这一版是 2026 年 9 月 21 日的快照。
如果今天距离这个日期已经超过一个月，请以最新一版为准。

一、生态全貌：热闹，但极度长尾

```
有效样本 94
提到任一海外引擎 79（84%）
提到任一国产引擎 12（13%）
star = 0 的仓库 36（38%）
star ≥ 100 的仓库 6（ 6%）
超过 3 个月未更新 42（45%）
未声明 license 48（51%）
```

第一个特征是极度长尾。 94 个仓库里 36 个一个 star 都没有，star 上百的只有 6 个。这是一个「人人都做一遍」的领域——门槛不高，重复造轮子很多。

第二个特征是维护率低。 45% 的项目超过三个月没有提交。对一个依赖外部接口的工具来说，三个月很长——引擎改一次鉴权方式，项目就可能跑不通。

第三个特征最容易被忽略，但对企业用户最要命：51% 的仓库没有声明 license。

没有 license 意味着默认保留全部权利。严格说，你不能合法地在商业环境里使用、修改或部署它。这不是理论风险——法务认真审一遍，这一半会直接出局。而多数团队是在部署之后才想起来问这件事。

声明了 license 的那一半里，MIT 占绝大多数（38 个），其余是 Apache-2.0、MIT-0 和 AGPL。AGPL 要特别注意：如果你改了代码并对外提供服务，需要开放源码。

语言分布：Python 31、TypeScript 28、JavaScript 10、HTML 8、未标注 15。

二、引擎覆盖：国产引擎是真正的空白区

这是整份采样里差距最大的一项。

```
ChatGPT 63 (67%) DeepSeek 11 (12%)
Claude 61 (65%) 通义千问 5 ( 5%)
Gemini 60 (64%) 豆包 3 ( 3%)
Perplexity 59 (63%) 腾讯元宝 2 ( 2%)
Google AIO 40 (43%) 文心一言 2 ( 2%)
Copilot 15 (16%) Kimi 2 ( 2%)
Grok 13 (14%)
```

先纠正一个常见说法：「开源工具只能测 ChatGPT」不成立。 覆盖国产引擎的项目确实存在，有 12 个。

但看清楚这 12 个的构成——真正把五家国产引擎都覆盖的，一只手数得过来，而且多数是个人项目：

```
★855 Auriti-Labs/geo-optimizer-skill DeepSeek/豆包/千问/元宝 + 五家海外 MIT
★ 76 akii-technologies-ltd/akii-seo DeepSeek + 六家海外 MIT
★ 36 IamRamgarhia/All-In-One-Free-SEO DeepSeek + 五家海外 MIT
★ 25 fenjo26/OpenGSC Kimi + 六家海外 MIT
★ 9 nibzard/llm-answer-watcher DeepSeek + 四家海外 MIT
★ 3 EdgeForgeLab/OpenCiteX DeepSeek/千问 + 两家海外 MIT
★ 1 imly-sudo/brandvision DeepSeek/豆包/千问/文心/Kimi + 四家 MIT
★ 0 sr007-cxy/Vigilath DeepSeek/豆包/千问/元宝/文心 + ChatGPT MIT
```

DeepSeek 是唯一被较广覆盖的国产引擎（12%），原因不难理解——它有标准的、对开发者友好的 API，接入成本最低。

而豆包 3%、元宝 2%、文心 2%，这三家恰恰是和抖音、微信、百度搜索深度绑定的。覆盖率垫底不是偶然，下一节会解释为什么。

三、两条技术路线，以及各自真实的代价

这是全文最重要的一节。选型时最容易看漏，而选错的代价最大。

```
通过模型 API 访问 60 (64%)
通过浏览器自动化 12 (13%)
明确提到 APP 端 1 ( 1%)
```

路线一：调模型 API（64%）

具体到国产引擎，README 里写得很清楚，要你自己去申请这些密钥：

```
豆包 火山方舟 console.volcengine.com/ark
通义千问 阿里云百炼 dashscope（需开通兼容模式）
DeepSeek platform.deepseek.com（需充值）
腾讯元宝 腾讯云 TokenHub（混元家族模型）
```

这条路线稳定、合规、可规模化。它的代价在别处。

差别不在模型，在检索。

很多人以为模型 API 和 APP 的差别就是「接口 vs 界面」——同一个模型，答案能差到哪去。

APP 和网页端产品的背后是一整套自己的检索系统：用户提问之后，先检索一批材料，再让模型基于这批材料作答。这套检索系统检的是平台自己的语料池——豆包背后有抖音，元宝背后有微信，千问背后有淘宝，各自还有自己口径的公开网页索引。

走模型 API 时，这一层要么不存在，要么换成了另一套完全不同的检索后端。

```
产品端（用户看到的） 平台自有检索 → 平台生态语料池 + 自有网页索引 → 模型作答
模型 API（工具测的） 无检索，或另一套检索后端 → 另一个信源池 → 模型作答
↑
断点在这里，不在模型
```

最直接的后果：你发的文章，在报告里永远没有引用。

不是因为它写得不好，也不是因为没被收录——是因为这套口径压根没去检索那个池子。

于是你会得到两个方向相反、但都错的结论：

```
误判一 「我发的内容没用，AI 从来不引我」
→ 实际上产品端在引，只是你测的那条链路看不见它
→ 后果：砍掉了本来有效的内容投入

误判二 按 API 的结果去调整内容
→ 你在优化一个用户根本看不到的答案
→ 后果：几个月的内容预算花在错误方向上
```

这两个误判都能让人白干几个月。 而成因只有一个：访问口径选错了——一个选型时五分钟就能问清楚的问题。

这也解释了第二节的现象：豆包、元宝、文心覆盖率垫底，正因为它们的价值几乎全在产品端的生态语料里，而那一层用模型 API 够不着。接了 API 也测不出想要的东西，不如不接。

路线二：浏览器自动化（13%）——口径对了，但有另一笔账

走产品端就能拿到用户真实看到的答案，口径是对的。但这条路有实实在在的代价，而且多数项目不说。

采样里有一个项目把代价完整写进了 README，这是我们见过最负责任的一份声明，值得原文引用：

- 第三方服务条款。 自动化 ChatGPT、Gemini、Perplexity 或 Claude 的网页界面可能违反服务商的 ToS。你有责任自行审阅并遵守目标服务的条款。- 账号风险。 被识别为抓取的账号可能被服务商停用或封禁。请使用专用账号，绝不要用你的主账号。- 非官方关联。 本项目独立开发，与 OpenAI、Google、Anthropic、Perplexity 或任何 AI 服务商无关联、无背书、无赞助。- 速率限制。 请按默认的每日调度或更低频率运行。突发大量查询会触发反滥用系统，并影响其他用户。- 抓取到的数据。 AI 回答可能包含第三方内容，你需要对如何存储、再分发或发布这些输出负责。
>「如果以上任何一条在你的场景里是硬性禁止（企业、受监管行业、法务审慎），请改用基于 API 的工具。」

把这段贴出来，不是为了吓退谁，而是因为它把这个品类最核心的工程难题说清楚了：

```
口径对（产品端） ←→ 合规、稳定、可规模化（API 端）
```

这两件事在技术上是对立的。 整个品类——开源也好商业也好——真正的难度就在这条张力上。任何一家说自己两边都轻松拿到，你都该多问一句怎么做到的。

选型时该问的具体问题：

```
□ 你走的是模型 API 还是产品端？
□ 如果是产品端，账号合规怎么处理，频率怎么控制？
□ 如果是模型 API，你怎么向我说明它和用户实际看到的答案的差异？
□ 这个差异会不会写进报告？
```

最后一条最关键。 口径差异可以存在——它是这个品类的固有约束——但它必须写在报告里。 一个不声明访问方式的监测结果，你无法判断它到底测了什么。

一个值得称道的做法

采样里另有一个项目，把口径差异主动写进了 README：

「腾讯元宝本身没有官方公开接口，本系统按用户裁决，用腾讯云『大模型服务平台 TokenHub』（混元家族模型）接入，报告中会标注这个口径差异。」

它没有假装自己测的就是元宝 APP。我们认为这应该成为行业默认做法。

四、能力分布：一张暴露了整个品类偏好的表

这是我们认为最有价值的一张表。统计的是 94 个项目各自声称具备的能力：

```
竞品对比 68 (72%)
CLI 命令行 67 (71%)
引用源抽取 64 (68%)
模型 API 接入 60 (64%)
Web 界面 57 (61%)
Schema 检查 48 (51%) ←─┐
数据库留存 32 (34%) │
定时调度 30 (32%) │ 差 8 倍
robots/llms.txt 21 (22%) │
MCP 服务 15 (16%) │
浏览器自动化 12 (13%) │
多次采样 12 (13%) │
原文留存 6 ( 6%) ←─┘
```

把最上面和最下面放在一起看：51% 的项目做 Schema 检查，只有 6% 保存 AI 的原始回答。差了八倍多。

这不是巧合。它反映的是整个工具生态的默认假设——把 GEO 当成一个技术合规问题：schema 补全、robots.txt 配好、页面结构做标准，事情就算做完了。

而验收真正需要的几样，恰恰全在最底下：

```
原文留存 6% ← 没有它，「掉名次」永远只能解释成「算法波动」
多次采样 13% ← 没有它，分不清「优化生效」和「这次刚好问到了」
定时调度 32% ← 没有它，拿到的是随机切片，不是趋势
数据库留存 34% ← 没有它，昨天的数据被今天覆盖
```

为什么原文留存是分水岭

排名数字单独拿出来是没有用的。名次从第 3 掉到第 7，你拿这个数字去问任何人，得到的回答都只能是「算法波动」——因为你手里只有位置，没有 AI 当时说了什么、引用了谁。

有原始回答，下面这些问题才变得可回答：

```
掉名次是因为竞品说得更好，还是因为 AI 引用的信源换了？
AI 对我们的描述是准确的，还是把参数说错了？
它引用的那几个来源，是我们能影响的，还是完全够不着的？
```

留全文的成本只比记排名多几十秒，但它决定了这份数据三个月后还有没有用。

做到了的那几个，值得单独点名

在 6% 里，有三个项目把这件事做得扎实：

```
★26 hellowalt/aeo-radar 原文留存 + 多次采样 + 定时调度 + 数据库留存 + 浏览器自动化
★22 aws-samples/sample-llm-search-citation-analysis
原文留存 + 多次采样 + 定时调度 + 浏览器自动化
★ 9 nibzard/llm-answer-watcher
原文留存 + 多次采样 + 数据库留存 + DeepSeek 覆盖
```

如果你只打算试一个开源项目，从这三个里挑。 它们在方法论上是对的——哪怕功能少、star 不高，方向没错。

五、「开源」两个字要看清楚：61% 带商业化信号

这一节可能会让人意外。

我们在 94 个 README 里检索了商业化信号——云托管版、定价页、付费档、注册账号、「开源版 vs 商业版」对照：

```
定价页 / 付费档 40 (43%)
云服务 / 托管版 33 (35%)
需注册账号 10 (11%)
开源版 vs 商业版对照 2 ( 2%)

至少命中一项 57 (61%)
```

而 star 前 12 的项目，12 个全部命中。 一个不漏。

这意味着：这个品类的头部开源项目，几乎全是「开源内核 + 商业云服务」的模式。 开源版是入口，云版本是生意。

说清楚：这个模式本身没有问题。 它是过去十年基础软件最主流的路径之一，而且对用户有实实在在的好处——代码公开可审计、可以自托管、不满意随时走人。相比完全闭源，它对用户更友好。

需要注意的是它的两个副作用：

```
副作用一 · 「免费」有边界
开源版通常在额度、引擎数、历史留存上做限制，
而这些限制恰好是你最需要的那几项（见第四节）。
★ 评估时要按你真实的问题数和引擎数去算，不是按功能列表。

副作用二 · 默认口径是为转化设计的
开源版给什么指标、怎么呈现，是产品设计决定的。
一个让你觉得「数据不够用」的开源版，比一个够用的开源版更符合商业逻辑。
★ 这不是指控谁，是提醒你：默认指标不等于最适合你的指标。
```

这条同样适用于我们自己，见第十节。

六、一个更大的问题：技术都做对了，方向是错的

第四节的 8 倍差距，指向一个比工具选型更大的问题。它不只存在于开源工具，商业工具里同样常见。

Schema 检查、结构解析、robots.txt 放行、可读性打分——这些都是对的，也都该做。

但它们检查的是「这篇文章是否容易被机器读懂」，回答不了「这篇文章该不该写」。

而后者才是决定成败的那一层：

```
schema 做得再完整 文章主题选错了 → 没人问这个问题，写了也不会被检索到
页面结构再标准 竞品找错了 → 你在和一批根本不同赛道的对手较劲
可读性分数再高 内容发错了地方 → 那个渠道不在这个引擎的语料池里
爬虫配置再正确 观点是错的 → 被引用了，反而加速暴露问题
```

最后一行尤其要注意：被引用不总是好事。 一条口径不一致、参数写错的内容被 AI 采信，损失比不被引用更大——我们的行业观测里，负面内容对判断的影响倍数在汽车行业是 2.2 倍、餐饮 1.6 倍。

这不是工具的错，是分工的边界

一个 schema 检查器做好 schema 检查，没有任何问题。问题出在把它当成 GEO 方案的全部。

判断「该写什么、和谁比、发到哪」，需要的是另一类信息：

```
该写什么 这个品类的真实提问长什么样、哪些问题跑偏率高
—— 我们用 1047 条真实 query 做过分区实测：
不含品牌名的空白区跑偏率 13.3%，
有品牌名的区域只有 5.4%~6.6%。
新手最爱测的泛词，恰恰噪声最大。

和谁比 AI 在回答里实际把谁和你并列，而不是你以为的竞品
—— 这两份名单经常对不上，对不上的部分才是信息

发到哪 这个引擎的答案里，被引用的内容实际来自哪些渠道
—— 自媒体/达人在五个引擎里都占 40%~70%，
企业官网在多数消费行业只占 5%~16%
（B2B 工业软件是例外，官网占 20%~30%）
```

这三件事，技术检查一件也回答不了。 它们只能从「AI 实际给出的答案和引用源」里读出来——这是监测的活，不是扫描器的活。

一个可操作的判据：

```
□ 它能告诉你「你的 schema 缺了什么」吗？ → 技术检查
□ 它能告诉你「AI 回答这个问题时引用了谁」吗？ → 监测
□ 它能告诉你「这三个选题里哪个值得写」吗？ → 决策支持

只有第一项的，不要拿它当 GEO 方案的全部。
```

七、逐个看：star 前 14 的项目各自适合谁

说明：下面的判断基于各项目 README 的公开描述与我们的能力标注，不是实测评测。
适合谁、短板在哪，是按第三、四节的框架推出来的。以你自己跑一遍的结果为准。

1. Auriti-Labs/geo-optimizer-skill ★855 · Python · MIT

样本里 star 最高，也是国产引擎覆盖最全的一个——DeepSeek、豆包、千问、元宝加五家海外。README 近 2.9 万字，文档扎实，有 CI/CD 集成（AI 可读性不达标可以让构建失败），MCP 服务，schema 与 robots/llms.txt 检查齐全。

适合：工程团队，想把 AI 可读性做成流水线里的一道关卡。
短板：能力清单里没有原文留存、没有多次采样、没有数据库留存——它的定位是审计与优化工具，不是持续监测系统。README 里有「开源版 vs GeoReady 平台」的对照，持续监测大概率在商业版那一侧。

2. ai-search-guru/getcito ★418 · TypeScript

功能最全的一个：定时调度、数据库留存、Web 界面、浏览器自动化、模型 API 全都有，Docker Compose 一键起。

适合：想要一个能长期跑的自托管平台，且只做海外引擎。
短板：两条。一是 license 标注为 NOASSERTION——商业使用前必须确认许可条款；二是引擎清单里没有任何国产引擎。

3. elmohq/elmo ★346 · TypeScript · MIT

README 里有专门一节「Elmo vs. 闭源替代品」，定位清晰。定时调度、数据库留存、竞品对比、Web 界面齐全。

适合：需要一个界面好看、能给团队看的自托管看板。
短板：能力标注里没有原文留存与多次采样；引擎全是海外。

4. mverab/eGEOagents ★190 · Python · MIT

以「Skills」形式组织，README 有「可复现结果」章节——在这个品类里，主动谈可复现性的不多，是加分项。

适合：已经在用 Claude Code / agent 工作流的团队。
短板：偏优化与内容生成，监测侧的留存能力弱。

5. ansvisor/ansvisor ★119 · TypeScript · MIT

「AI 搜索情报平台」，有 MCP 服务、数据库留存、引用源抽取，同时提供 Ansvisor Cloud。

适合：想要开源版起步、后续可能转云服务的团队。
短板：无原文留存、无多次采样标注；引擎全是海外。

6. dodopayments/dualmark ★105 · TypeScript · Apache-2.0

思路和其他项目都不一样，值得单独说：它不做监测，做的是「每个页面出一份给 AI 读的 Markdown 孪生版」，按 HTTP content negotiation 分发给人和 agent。支持 Astro / Next.js / SvelteKit / Cloudflare Workers / Deno / Vercel Edge。

适合：技术站点，想从供给侧直接解决「AI 读不懂我的页面」。
短板：它根本不是监测工具，不要用它回答「我被引用了吗」。Apache-2.0，商用友好。

7. akii-technologies-ltd/akii ★76 · Markdown · MIT

Claude Code 插件形态，12 个 skills、5 个 agents、3 个命令，覆盖 SEO/AEO/GEO 全链路，含 DeepSeek。

适合：Claude Code 重度用户，想把 GEO 动作嵌进日常工作流。
短板：末次更新 2026-06-11，已超三个月；README 里明说插件覆盖范围小于其 Akii 平台。

8. AICMO/ai-cmo ★53 · Vue · MIT

界面完整的自托管 AI SEO 平台，有 prompt 监测与分析看板。
短板：末次更新 2025-10-10，已近一年。这个品类接口变化快，风险较高。

9. IamRamgarhia/All-In-One-Free-SEO-Tool ★36 · TypeScript · MIT

定位是 Ahrefs / Semrush / Moz 的自托管开源替代，号称 99 个工具，AI 可见性只是其中一块。能力标注是全样本最全的之一——定时调度、数据库留存、浏览器自动化、模型 API、MCP、schema、robots 全有，含 DeepSeek。

适合：想用一套自托管工具同时替掉几个 SaaS 订阅的中小团队/代理商。
短板：摊子铺得大，AI 可见性这一块的深度需要自己验；仍无原文留存标注。

10. anyin-ai/aperture ★27 · TypeScript · MIT

README 里明确写 BYOK（自带密钥），坦白告诉你这是模型 API 路线。有对照章节。
适合：想要轻量、清楚知道自己在测什么的团队。
短板：无定时调度标注；海外引擎为主。

11. hellowalt/aeo-radar ★26 · TypeScript · MIT

方法论上最完整的一个：原文留存、多次采样、定时调度、数据库留存、浏览器自动化全都有——第四节那 6% 里的代表。而且写了全样本最负责任的免责声明（见第三节原文引用）。

适合：认真想做持续监测、且能接受浏览器自动化合规代价的团队。
短板：引擎以 ChatGPT 为主，国产引擎不覆盖；末次更新 2026-07-01。

12. fenjo26/OpenGSC ★25 · TypeScript · MIT

自托管 Google Search Console 看板，把传统 SEO 数据和 AI 可见性审计放在一起，含 Kimi，有多次采样。

适合：传统 SEO 和 GEO 想在一个界面里看的团队。
短板：主体是 GSC 看板，AI 可见性是附加模块。

13. aws-samples/sample-llm-search-citation-analysis ★22 · TypeScript · MIT-0

AWS 官方示例，基于 Bedrock + Step Functions + React。原文留存、多次采样、定时调度、浏览器自动化都有。

适合：已经在 AWS 上、有工程能力、想自建的团队。MIT-0 是最宽松的许可之一。
短板：是 sample 不是产品，要自己补完；引擎限于 Bedrock 可达的那些。

14. nibzard/llm-answer-watcher ★9 · Python · MIT

star 不高，但方法论对：原文留存、多次采样、数据库留存俱全，且覆盖 DeepSeek。README 有 2.4 万字，是样本里文档最厚的之一。

适合：只想要一个 CLI、把数据存好、自己做分析的人。
短板：末次更新 2025-11-11，已近一年。

八、三个场景走一遍选型

同样的清单，不同的生意，结论完全不同。

场景 A · 出海 SaaS，只做海外市场

```
引擎需求 ChatGPT / Claude / Perplexity / Gemini
开源覆盖度 67% / 65% / 63% / 64% ★ 这一档开源最强
口径风险 低 —— 海外引擎的 API 与产品端差异相对小，
且多数目标用户本来就用网页端
结论 ★ 优先用开源。先试 aeo-radar 或 AWS 那个 sample，
前者开箱即用，后者适合已有 AWS 基建的团队
什么时候再考虑付费
问题数超过 50 条、需要跨引擎对齐、
或需要向投资人出可复现报告时
```

这一档我们不建议你先买工具。 开源方案在海外引擎上的覆盖度和成熟度都够用。

场景 B · 国内消费品牌，主战场豆包、元宝、千问

```
引擎需求 豆包 / 元宝 / 千问 / DeepSeek
开源覆盖度 3% / 2% / 5% / 12%
口径风险 ★★★ 最高 —— 这三家的价值几乎全在产品端的生态语料里
（抖音、微信、淘宝），模型 API 够不着
结论 开源方案在这一档结构性不足。
不是项目做得不好，是这条路本身通不过去：
走 API 测不到你要的东西，走浏览器自动化要承担 ToS 与封号风险
必须问清楚的 任何一家供应商（包括我们）：
你走的是模型 API 还是产品端？这个差异写不写进报告？
```

场景 C · B2B 工业，决策链长、内容专业

```
引擎需求 DeepSeek + 海外（海外客户占比高时）
特殊性 ① 官网占被引 20%~30%，是全行业最高
—— 官网事实层的权重比消费行业大得多
② 内容续航 3.9 天，全行业最短
—— 复测频率要比消费行业更高，这一点反直觉
结论 开源可行，但必须选有定时调度 + 数据库留存的那一档
（分别只有 32% 和 34% 的项目具备）
★ 用 3.9 天倒推：至少每周一次，否则拿到的是随机切片
```

九、如果你打算自建：一份工作量估算

★ 以下是估算，不是实测。 按第四节的能力清单拆成模块，按一个熟练工程师的节奏估。你的实际投入可能差一倍。

```
模块 首次开发 每月维护
────────────────────────────────────────────────────
问题集管理与调度 2~3 人天 0.2 人天
引擎接入（每家） 1~2 人天 0.5 人天/家 ★接口会变
├ 模型 API 路线 1 人天
└ 产品端路线 3~5 人天 ★★ 含反爬对抗，维护成本最高
原始回答留存与存储 2 人天 0.2 人天
引用源抽取与归一化 3~5 人天 0.5 人天 ★域名归属判断是脏活
多次采样与离散度计算 1~2 人天 0.1 人天
报表与看板 5~8 人天 0.3 人天
────────────────────────────────────────────────────
只做 2 家引擎、API 路线 约 16~25 人天 约 2 人天/月
做 5 家国产引擎、产品端路线 ★ 不建议自建，见下
```

三条经验性提醒：

```
① 引擎接入不是一次性成本。
采样里 45% 的项目超三个月未更新——大概率就是卡在这里。

② 引用源归一化是最被低估的一块。
同一个来源会以不同域名、不同短链、不同 APP 内链接出现，
把它们归到同一个主体，是没有捷径的脏活。

③ 产品端路线的维护成本不是线性的。
它随平台反爬策略变化，不可预测。
这也是为什么样本里只有 13% 走这条路。
```

什么时候自建划算：你有特殊的判定逻辑（行业合规、内部口径），
且只需要 1~2 家引擎。什么时候不划算：要覆盖五家国产引擎的产品端。

十、三方对照：手工 / 开源 / 商业

```
维度 纯手工 开源自托管 商业工具
──────────────────────────────────────────────────────────────
上手成本 最低 中（要部署） 低
问题数上限 约 50 条 数百 不限
（每周 5 小时）
引擎数上限 1~2 家 看项目 不限
原文留存 ★ 靠纪律，能做 仅 6% 的项目有 通常有
多次采样 靠纪律 仅 13% 通常有
跨引擎对齐 很难 看项目 通常有
横向基线 无 无 ★ 这是商业工具
真正难以替代的一项
合规责任 你 你（51% 无 license） 供应商
维护 你 你（45% 已停更） 供应商
理解深度 ★★★ 最深 中 最浅
（你亲手读了每条回答）
```

「理解深度」那一行常被忽略。 手工方案最大的收益不是省钱，是你亲手读过每一条 AI 回答——这种理解，看报表是拿不到的。

我们见过不少团队第一年靠一个表格就把方向摸清楚了。 先手工或开源做三个月再决定要不要买，比一上来就采购更划算。

十一、开源方案的四个真实成本

开源不等于免费，只是把成本换了个位置。

其一：API 费用照付。 按量计费，六家引擎就是六个账号、六份充值、六套配额。采样频率越高越接近订阅费，而且是变动成本，预算不好做。

其二：维护是你自己的。 45% 的项目超三个月没更新。引擎接口一变，项目就可能跑不通，而修它的人是你。一个跑不通的监测系统，比没有监测更危险——因为你会以为自己在监测。

其三：license 风险。 51% 未声明 license，严格说不能合法用于商业环境。法务审查时会直接卡住。

其四：没有横向基线。 开源工具能告诉你「我们的提及率是 X」，但回答不了「X 在这个行业里算高还是低」。没有对照组的数字，进不了预算会议。

十二、按维度拆开的对比

只写可核验的维度差异，不做优劣评价。哪一栏对你更重要，你自己判断。

```
维度 开源方案（94 个样本实测） 透镜GEO
──────────────────────────────────────────────────────────────────
访问口径 64% 走模型 API 按产品端入口采集
仅 1 个（1%）提到 APP 端 ★ 见第十三节口径说明

入口粒度 通常不区分网页端/APP端 2026年8月信源观测按网页端
与移动端共 8 个入口分别采集

国产引擎 13% 提到任一国产引擎 DeepSeek、文心、豆包、
豆包 3% · 元宝 2% · 文心 2% 元宝、千问五家

海外引擎 覆盖好：ChatGPT 67%、Claude 65% ★ 这一档开源有优势，
Perplexity 63%、Gemini 64% 只做海外可优先考虑开源

原文留存 6% 逐条留存
多次采样 13% 同题多轮
横向基线 无，只能和自己的历史比 22 个行业、2100 多个品牌
引用源 68% 提取，多数只记是否提及 逐条引用源，可归属到站点或账号
维护责任 你自己（45% 已超 3 个月未更新） 我们
合规 51% 未声明 license 商业授权
成本结构 六家 API 按量计费 + 运维时间 订阅
```

十三、利益披露与我方口径说明（本节不得删除）

必须把四件事说清楚，否则上面那张表就不诚实。

其一：我们是利益相关方。
我们卖监测服务，天然有动机把问题说得更复杂、把验收讲得更必要。读者完全有理由对这篇文章保持警惕。我们能做的不是自证中立，而是让结论可以被你推翻：采样口径、关键词列表、判定规则全部写在附录里，你或你的团队可以照着核一遍，不一致以你的为准。

其二：我们从样本里剔除了自己的仓库。
采样命中了一个我方自有的 GitHub 仓库，我们把它剔除了，没有计入 94 个独立样本。理由很简单：把自己的项目算进样本，再用样本结论证明自己，是循环论证。剔除记录写在附录 excluded 字段里，可复查。

其三：我们自己的口径边界。
我们 2026 年 8 月的五引擎信源观测，是按网页端与移动端共 8 个入口分别采集的。但我们对外开放的 API 目前只提供网页端数据，不含 APP 端。 这两件事不一样，我们不混为一谈。如果你需要 APP 端的逐日数据，请直接问我们能不能做到，而不是从上面那张表里推断。

其四：第五节那条也适用于我们。
「默认指标是为转化设计的」——这个提醒对我们同样成立。所以我们把判据写在外面（第三节的四个问题、第四节的能力清单），你可以拿它来验我们。

十四、怎么选：五个问题

```
□ 1. 你要测的答案，从哪个信源池检索出来？
模型 API 那套后端 → 开源方案完全胜任
用户在 APP/网页端实际看到的 → 必须确认对方走产品端入口
★ 这一条问错，你发的文章会在报告里「永远没有引用」

□ 2. 你做的是国内还是海外？
只做海外 → 开源覆盖度很好（ChatGPT 67%、Claude 65%）
要做国内 → 国产引擎覆盖 13%，豆包/元宝/文心都在 3% 以下

□ 3. 这份数据三个月后还要用吗？
不用 → 任何工具都行
要用 → 必须有原文留存（开源仅 6%）和数据库留存（34%）

□ 4. 你要不要和同行比？
不要 → 开源
要 → 需要横向基线，这是开源方案的结构性短板

□ 5. 这份数据要给谁看？
自己看 → 开源
给老板、客户或投资人看 → 需要可复现的原始数据与留痕，
而且出具方最好不是执行优化的那一方
```

第 5 条和规模无关，和「谁来信」有关。

十五、如果你决定先用开源：上手清单

```
第 1 步 确认 license
没有 license 的直接排除（51% 在这一步出局）
AGPL 的确认你是否对外提供服务

第 2 步 确认访问方式
README 里是 API Key 还是 Playwright/Selenium
★ 要测国内产品端的真实答案，API Key 那一类不适用
★ 走浏览器自动化的，先读第三节的合规清单，用专用账号

第 3 步 确认它存不存原文
找 raw_response / 原始回答 / full response 这类字段
没有的话，三个月后这份数据只能画一条曲线

第 4 步 确认维护状态
看最后一次提交。超过三个月的，做好自己修的准备

第 5 步 先空转三周
第 1 周跑完整问题集留基线；第 2~4 周不做任何优化，只重复采样
目的：先量出「什么都不做时，数据本身波动多大」
★ 跳过这一步，你会把正常波动当成优化效果

第 6 步 按续航天数定复测频率
内容被引续航：餐饮 5.3 天、工业 3.9 天
（口径：每日采集，连续 2 天未被引判定结束）
→ 复测频率下限大约每周一次
```

第 5 步最容易被砍，也最不该砍。 没有空转期的基线，你分不清「优化生效了」和「这周 AI 心情好」。

附：采样方法与可复现性

方法公开，但不随文提供代码。 本文面向做采购决策的人，下面的口径足够你或你的团队自己核一遍。

```
时间 2026-09-21
数据源 GitHub 公开仓库检索（按 star 排序）
关键词 generative engine optimization monitoring
AEO brand monitoring
GEO ranking tracker LLM
AI search visibility tracker
llm brand mention tracker
answer engine optimization open source
AI visibility monitoring brand
豆包 DeepSeek 监测 品牌
GEO 可见性 监测 千问
GEO 监测 品牌 AI
处理 按仓库全名去重 → 相关性过滤 → 逐个读 README 原文 →
按关键词表标注引擎、访问方式与能力 → 人工剔除噪音与我方自有仓库
原始 99 个 → 剔除 3 个 → 有效样本 94
```

判定口径（偏宽松，必须说明）：

• 「提到某引擎」指 README 或仓库描述里出现该引擎名称，
  不代表功能已实现或当前可用。
• 「能力」按 README 中出现的关键词判定，统计的是项目声称支持什么。
• 「商业化信号」按 README 中出现 cloud / pricing / paid plan 等模式判定。
• 因此真实可用比例只会低于本文数字，不会更高。
  这个标准对开源项目和商业工具一视同仁——包括我们自己的功能列表。