面向在 GitHub 上托管的公开软件仓库做生成式引擎可见性GEO方向的诊断与报告。品牌是RepoGEO先说说背景做开源的人多半经历过两件事一是传统搜索里能不能被找到二是现在越来越多人根本不在搜索引擎里问而是在对话框里问——「这个库稳不稳」「和某某比差在哪」「适合我上生产吗」。模型回答这类问题时读的大多是公开页能抓到的文字About、README、有时还有package.json一类生态文件。这里只要缺一块、对不上号摘要就容易发空或者把版本、定位、和竞品差异拼错。这不是维护者偷懒而是**没人专门管「机器怎么读我的仓库」**这件事通用 SEO 工具也不贴着 GitHub 公开仓的字段和惯例来做。所以RepoGEO作者做了一个垂直一点的东西只接公开仓规则能说清楚为什么扣分跑完还能隔几天再扫一次看改没改。产品叫 RepoGEO定位是 GEO——生成式引擎可见性——把「对外可读、可摘要」这件事做成可反复执行的清单。为什么是我们、为什么是现在行业里不缺「写 README 的建议帖」缺的是能落地、能复扫、能放进工作流的闭环。我们希望满足几件事公开仓边界划死产品才不会在权限、合规和适配上拖垮。私有仓、组织内权限、非 GitHub 托管当前都不在范围里。诊断要拆开两层一层是规则元数据完不完整、README 有没有把「是什么、给谁用」说清楚、生态描述文件和 GitHub 上展示是否打架、发布和维护信号、安全政策有没有、文档出口是否一致——这些都能对应到具体改法。另一层是模型提示用固定规模的题目把「选型对话里常被问到的」东西结构化进报告而不是堆一篇泛泛而谈的软文。收费上走「免费轻量 订阅深度」的主路径高阶交付走询价避免「一次性买断」和订阅权益长期打架。细节以官网定价和条款为准这里只交代产品思路。对维护者到底有什么用如果你只关心一句话它帮你找出「AI 在读你仓库时容易读歪的地方」并给你一张能改的清单。往细了说免费档会先给一版轻量结果适合随手测一个仓、转给同事看。需要认真磨对外叙事、做竞品对比、把深度结论留下来的时候再考虑 Pro——深度跑次有月度上限和订阅绑定这是刻意的设计用来控成本也逼我们把单次报告做得够厚。还有一个我们挺在意的点叫「治理」报告里的条目可以标成已处理或忽略同一仓库在一段时间内可以再扫前端能看哪些是新增的、哪些修掉了、哪些还在。单次分数好看不如第二次比第一次好重要这是持续运营 GEO 时最真实的手感。理想用户画像上我们更先服务独立维护者和十来人以里的小团队——决策链短痛点多是「怕被 AI 说错」而不是先要一套采购流程。公司化 DevRel、商业化开源团队是下一档通常要多仓、对标和材料导出跟上了才好接。技术栈不是脚本糊一下工程上是Next.js 全栈诊断、账号、工作区、支付回调都在一套应用里。后台任务走Inngest数据用PostgreSQL和Redis。后面若上「按榜单批跑、沉淀知识库」那一支规划里会用Python 做 ETL和 Web 共用库表避免两套系统各写各的。另外有个开源的GEO.skillsrepogeo/geo-skills把公开仓 GEO 的规则和可选 Lite API 说明放进 Agent 技能包给用 Cursor / 别的 Agent 的人自己接。往后会往哪走路线图里MVP 跑稳之后会往调度、Top 采样、行业向的聚合与基准走让用户能绑定多个仓、看历史快照。再往后才有竞品包、通知、协作导出、谨慎开放的只读 API 一类增值。增长侧会和站外技术文章、项目申报目录并行——CSDN、掘金、Medium 这类渠道用来讲清楚 GEO 是什么、和 SEO 差在哪链接带回诊断入口用 UTM 看转化。内部做过一些营收量级的敏感性测算例如付费规模在几百到两千计费单位时的粗算 MRR 区间仅供团队对齐真实数字要看续费、成本和定价怎么迭代。品牌上Repogeo做主站、结账和法务页的 canonicalGitHubGeo更适合做内容站或栏目名因为名字里沾第三方商标词根页脚该写的免责声明不能省也不宜做得像官方。底线写清楚GitHub是 GitHub, Inc. 的商标。Repogeo 是独立项目和 GitHub 没有隶属关系也没有官方背书——正式表述以站点上审过的版本为准。不卖「改完模型一定引用你」这种话能说的是把公开信息整理到机器好解析、好摘要的状态降低被误述的概率。处理的都是公开数据限流、缓存和隐私政策在合规文档里写死了。结语若你手里有一个真正对外维护的公开库可以先用轻量诊断扫一眼不必一次改完但至少知道 AI 在读你时最可能栽在哪几块。RepoGEO 想做的就是把这件事从「随缘」变成可重复的习惯。产品入口与定价以官网repogeo.com当前页面为准。开源技能包https://github.com/repogeo/geo-skills