yaojingang/GEOInflow

如果团队正在被问“AI 爬虫有没有找到我们的内容”，而答案是谁也不知道，GEOInflow 值得了解一下。它把浏览器埋点、AI 搜索来源和服务器/CDN 抓取日志自托管地放在一起。代价是要维护一整套服务，并且抓取日志能证明的东西有明确边界。

解决什么问题

内容或市场团队想知道 AI 搜索产品有没有读取、引用自己的页面。现在通常的做法是：用通用网站分析看流量，用日志检索查 bot 的 User-Agent，再用一张手工维护的 URL 表对比。三套数据对“什么是 AI 访问”的定义各不相同，数字没法直接比。GEOInflow 改的是中间这一步：把抓取日志、推荐来源和内容清单导入同一个数据库，用同一组筛选条件查看。最终得到的是每个页面上“观测到的 AI 爬虫活动”，旁边是真实的 AI 来源会话和转化。

有什么不同

核心机制是爬虫目录。它把平台、产品、请求身份分开记录，又把用途和产品类型分开：训练、AI 搜索、用户触发访问属于不同用途，AI 工作台和个人 agent 属于产品类型。这一点有实际意义，“OpenAI 来过”和“这条请求路径与搜索相关而非训练”是两种强度完全不同的结论。身份、用途、产品类型等筛选在聚合和分页之前生效，卡片、表格、导出和对比使用同一条件。

这套结构也有维护成本。目录只有在管理员发布条目后才会生效，每个网站的配置也会影响展示内容。用途标签和路径观测都带着“推断”或“估算”标记，而不是事实。README 对证据边界说得很直白：抓取日志只能证明观测到的访问；收录、模型训练、答案引用、推荐排名和获客各需要各自的证据 AI 爬虫分析指南。要把时间花在解释数据上，而不只是安装。

谁值得试

适合：已有服务器或 CDN 日志的出版方、内容团队或代运营多站点的机构，希望有一个自托管、MIT 许可的地方把抓取覆盖和来源、转化数据放在一起对比。能指定专人维护爬虫目录、且本来就熟悉 PostgreSQL 与 Redis 的团队收益最大。

不适合：只想看页面浏览量的小站点。部署会拉起应用、日志 worker、分析 worker、PostgreSQL 和 Redis 部署说明，而 GEO 部分的价值取决于有没有日志和内容清单可导入。如果期待它直接告诉你“AI 答案是否引用了我们”，应先看局限说明：项目并不声称能观测引用或模型训练。若要使用 Cloudflare 访问控制，需要单独的 Zone 凭证，并提供预览与确认步骤，具体套餐、权限和可用字段要在部署环境里核对。

使用条件与边界

文档给出的快速开始是在项目根目录运行脚本，前提是 Docker Engine/Desktop 和 Compose V2，脚本会生成私有 .env 和随机密钥、构建镜像、执行迁移，并在 3002 端口启动五个服务 快速开始。日常维护是真实存在的：服务商不断更换请求身份时要更新爬虫目录、导入内容清单、查看日志并在工具内处理访问问题。

两条边界决定了预期。第一，分开计量：爬虫请求、来源会话和转化是各自独立的测量流，跨源关联保留可比性限制，不会被合并成一个数字。第二，身份不等于证明：User-Agent 匹配只能说明请求与已知条目相符，并不代表运营方核实了来源。浏览器埋点基于脚本，被拦截或用户未同意时来源覆盖会下降。地理位置解析依赖内置的 DB-IP City Lite 数据集，或按其自身条款提供的数据库 第三方声明。

HotRepo 点评

在类型为 TypeScript 的新项目榜上，GEOInflow 于 2026-10-26 被观测到以 206 个总 star 排在第 4 位；这是新项目榜的日期化快照，不是日增数据，HotRepo 也没有可比的每日历史。仓库很年轻，持续性尚无法判断。投入之前，建议先看项目的架构文档，确认爬虫目录和估算标签如何维护——这项日常工作决定看板数据是否长期可信。