输入产品域名，对照多家模型如何描述你的产品、会提到哪些竞品，以及回答引用了哪些来源。NiubiGEO 是一套 Apache-2.0 开源、可自托管的 GEO 工作台，模型调用需要使用你自己的 API Key。
先说明一件事
NiubiGEO 的结果来自你配置的模型 API。它和 ChatGPT、Claude、Gemini 等消费级网页端的回答不一定完全一致，尤其会受到具体模型、是否联网、采样和测试时间影响。使用这类工具时，更适合看“模型如何描述与引用”，不要把单次结果理解成固定排名。
NiubiGEO 解决什么问题
做产品、品牌和内容的人，越来越常遇到这几类问题：
- AI 会怎么介绍我的产品，描述是否准确？
- 不主动点名品牌时，同类问题下会出现哪些竞争产品？
- AI 回答里引用了哪些网页、评测或社区来源？
- 同一个品牌过一段时间再测，描述和引用有没有变化？
NiubiGEO 的仓库是 Albert-Weasker/niubigeo。
它通过你配置的模型 API，把这些测试保存成可以回看的工作台记录，包括：
- 产品描述
- 竞争对象
- 关键词测试
- 引用来源
- 历史对比
常见有两种测试方式：
| 测试方式 | 主要观察内容 |
|---|---|
| 输入产品域名 | AI 如何描述你的产品 |
| 关键词测试，不点名品牌 | 同类话题下会出现哪些产品 |
报告里重点看什么
跑完一次测试以后，可以优先看下面五件事。
1. 产品有没有被说对
先检查模型描述是否准确：
- 核心功能有没有漏掉
- 有没有把你没有提供的能力写进去
- 不同模型之间描述是否一致
如果多个模型都出现同一个错误描述，这通常比单个模型的一次偏差更值得关注。
2. 模型把谁当成你的竞争对象
看看模型在描述你的产品时，会同时提到哪些其他产品。
这里更值得关注的是：
- 它们是不是真正的同类产品
- 模型为什么把它们放在一起
- 提到竞品时用了什么特征或场景
3. 不点名品牌时谁会出现
关键词测试的价值之一，是观察在没有品牌提示的情况下，模型会自然提到谁。
比如你测试某个使用场景或功能关键词，可以看到：
- 哪些品牌只是被提到
- 哪些品牌得到明确推荐
- 你的产品有没有进入候选
4. 回答引用了哪些来源
如果所选模型或联网方式会返回引用，可以进一步检查：
- 官方网站
- 评测文章
- 社区页面
- 其他第三方来源
引用链接本身只说明模型参考了它，不能直接等同于“推荐原因”。
5. 多次测试有没有变化
保留历史结果以后，可以比较：
- 产品描述有没有变化
- 品牌提及有没有增加或减少
- 引用来源有没有变化
- 换模型后结论是否不同
“被提到”和“被推荐”要分开看
这两个概念很容易混在一起。
| 情况 | 怎么理解 |
|---|---|
| 只是点名 | 出现在一串产品名字里，没有说明适合谁或解决什么 |
| 给出理由 | 和需求、价格、团队规模或使用场景挂钩，并解释为什么值得考虑 |
| 附上链接 | 有官网、评测或社区页可核对，但链接本身不代表推荐理由 |
所以分析结果时，不建议只统计品牌出现了多少次。
更值得看的是：
- 出现在哪个关键词下
- AI 是怎么描述的
- 有没有给出明确推荐理由
- 引用了什么来源
不想部署，可以先看项目案例
项目仓库整理了多组真实域名案例，包括 Notion、Figma、PostHog 等。
没有 API Key 时，可以先通过这些案例了解报告结构：
例如，在 Figma 的 “Prototyping” 关键词测试里，有的模型回答只解释概念，有的会直接点名 Figma。
这个例子可以帮助理解一件事：
模型理解一个话题，不代表它一定会主动推荐某个具体品牌。
环境准备
根据项目 v0.2.0 的公开说明，可以使用 Node.js 或 Docker 部署。
| 项目 | 建议 |
|---|---|
| 许可证 | Apache-2.0 |
| Node.js | 22+ |
| 运行方式 | Node.js 或 Docker |
| 模型 API | 入门配置常用 OpenRouter API Key，以当前文档为准 |
| 版本参考 | v0.2.0 |
安装前建议先查看项目当前的 Releases。
如果准备长期运行，还要把这些成本算进去：
- 服务器
- API 调用
- 更新
- 备份
- 排错和维护时间
本机安装
1. 拉取项目
git clone --branch v0.2.0 --depth 1 https://github.com/Albert-Weasker/niubigeo.git
cd niubigeo
2. 安装依赖
npm ci
3. 创建环境配置
复制示例文件：
cp .env.example .env
然后编辑 .env，加入自己的模型 API Key，例如：
OPENROUTER_API_KEY=你的密钥
不要把真实 API Key 提交到 Git 仓库或公开发给其他人。
4. 启动服务
npm run server
启动后，在浏览器访问：
http://localhost:8787
进入工作台后，大致流程是：
- 创建项目
- 选择需要测试的模型
- 根据需要决定是否开启联网
- 运行域名测试
- 根据结果继续做关键词测试
第一次使用时，建议先只选择一个模型。先看清报告结构和实际调用成本，再逐步增加模型数量。
Docker 部署与定时监测
如果准备把 NiubiGEO 长期跑在服务器上，可以使用 Docker。
项目提供了相关文档：
如果需要定时复测，还需要按照项目文档启动监测 Worker。
Worker 正常运行后，系统才能按照计划自动重复测试并保留历史记录。
已有实例升级之前，建议先阅读仓库 docs 中的备份和升级说明。
费用怎么估算
NiubiGEO 本身开源，但实际使用仍可能产生模型和服务器费用。
| 成本项 | 说明 |
|---|---|
| 模型调用 | 模型单价 × 问题数 × 回答长度 × 模型数 × 复测次数 |
| 联网搜索 | 开启搜索时可能额外计费，具体取决于服务商 |
| 机器与维护 | 本机或云服务器，以及自己的维护时间 |
项目作者在 v0.2.0 发布说明中记录过一次实际研究：
- 覆盖约 20 个域名
- 约 204 次付费调用，包含预检
- 服务商费用大约 1 美元量级
这个数字只代表那一次研究的账单，不是固定价格，也不包括服务器和人工维护成本。
更稳妥的方式是：
- 先选择一个模型
- 先跑域名测试
- 再选少量关键词
- 观察账户实际扣费
- 确认成本后再扩大测试范围
自托管以后，数据还会不会出网
会。
“自托管”主要意味着应用和测试记录可以保存在你自己的机器或服务器上。
但调用模型时，请求依然需要发送给你配置的模型 API 服务商。
| 数据 | 去向 |
|---|---|
| 应用与测试记录 | 你的机器或服务器 |
| 模型生成请求 | 你配置的 API 服务，例如 OpenRouter 对应的模型服务 |
所以：
自托管不等于所有数据都完全留在本地。
不要使用客户隐私信息或尚未公开的业务机密做测试。
如果把 NiubiGEO 工作台暴露到公网，也应该增加必要的访问控制。
为什么两次测试结果会不一样
大语言模型本身具有一定随机性。
即使使用相同的测试条件，两次生成结果也可能不完全一致。
项目的 已知限制 也提到了这一点。
做历史对比时，尽量固定这些条件：
- 域名或关键词
- 模型
- 语言
- 是否联网
同时记录测试日期。
如果切换了模型或联网方式，测试条件已经变化，不适合只比较“品牌出现次数”。
遇到排名或汇总结果异常时，也应该打开原始回答核对。
项目发布说明中提到过部分排名冲突，因此这类数值更适合作为查找线索，不适合直接当成绝对排名。
哪些人适合用 NiubiGEO
比较适合下面这些场景：
- 已经有官方网站，希望检查 AI 是否正确描述自己的产品
- 想观察不点名品牌时，哪些竞品会自然出现
- 愿意自备模型 API Key
- 愿意阅读原始回答，而不是只看汇总分数
- 可以自行维护 Node.js 或 Docker 环境
- 希望长期保存历史测试结果
哪些情况更适合商业托管工具
如果你符合下面这些需求，商业 GEO 工具可能会更省事：
- 不希望自己部署和维护
- 需要多人协作
- 需要完整权限系统
- 希望有现成售后支持
- 希望减少服务器和 Worker 运维工作
选型时还应该特别确认：
- 数据来自模型 API，还是消费级网页端
- 模型是否联网
- 是否能查看原始回答
- 是否能打开引用来源
不要只比较一个最终“分数”。
项目资源
安装完成后，可以先选择一个自己非常熟悉的产品域名做测试。
这样最容易判断模型描述是否准确，也能快速理解 NiubiGEO 的报告结构、品牌提及和引用来源应该怎么看。