# 餐饮 GEO 实施调研与控制台设计

调研日期：2026-09-26。范围是餐饮生成式引擎优化（GEO），不覆盖云打印。本文汇总既有已核实资料、中国落地限制和一体化控制台设计。凡未实测或只有厂商宣传的内容均标注“待验证”。

## 1. 结论

1. 国外 GEO/AI Visibility 产品已形成“问题监测、品牌提及、引用来源、竞品对比、爬虫可达性、内容修复建议”的产品模式。代表产品包括 Profound、Semrush AI Visibility Toolkit、Ahrefs Brand Radar、Peec AI、Otterly.AI、Scrunch AI、BrightEdge、Conductor 和 Goodie。它们主要覆盖 ChatGPT、Gemini、Perplexity、Google AI Overviews、Claude、Copilot 等境外渠道。
2. 中国没有可直接买到的成熟餐饮 GEO 闭环。豆包、DeepSeek、Kimi、腾讯元宝、百度 AI 搜索的真实产品问答缺少稳定公开监测 API；裸 LLM API 不能替代真实搜索路径，因为它缺少检索、地图、点评、内容平台排序和本地化信号。
3. 餐饮落地的核心不是单次“写文章”，而是固定问题库、固定平台矩阵、固定时间窗的测量，再结合官网技术审计和本地生态信息一致性修复。测量、修复、复测、经营数据对照必须闭环。
4. 中国餐饮信任源优先级应围绕高德、百度地图、大众点评、美团、小红书、抖音、知乎、百度百科组织。官网 schema、llms.txt 和 AI 爬虫规则是辅助信号，不是全部。
5. 控制台 MVP 必须先服务人工/半自动探测，而不是承诺全自动抓取国内 AI 平台。自动化只能在条款允许、频率可控、账号合规的前提下逐步验证。

## 2. 学术与官方依据

### 2.1 GEO 定义与上限

ArXiv 2311.09735《GEO: Generative Engine Optimization》在 KDD 2024 发表，提出 GEO 框架和 GEO-bench，并在受控实验中说明内容优化最多可提升 40% 可见性。该数字是特定基准的条件结果，不能外推为任何客户的承诺。证据：`evidence/arxiv-geo-paper.md`。

### 2.2 内容质量与可验证性

2026 年后续研究把 GEO 从“提示词技巧”推进到评测与防御：

- E-GEO 关注电商场景的测试床，说明 SKU、属性、交易意图与普通内容 SEO 不同。证据：`evidence/arxiv-e-geo.md`。
- GEO-Bench 统一评测排序操纵攻击，显示效果与隐蔽性存在权衡。证据：`evidence/arxiv-geo-bench.md`。
- Counter-GEO-Bench 评测信息失真型 GEO 防御，说明平台会反制虚假、诱导和失真内容。证据：`evidence/arxiv-counter-geo-bench.md`。

因此白帽路线只能做：真实信息、可验证来源、结构化表达、本地生态一致性和用户体验改进。

### 2.3 官方探针通道

| 通道 | 已核实能力 | 对控制台意义 |
|---|---|---|
| Gemini API + Google Search grounding | 返回联网回答与内联 URL citation，搜索调用计费 | 可作为境外对照探针，不适合当成中国真实产品矩阵 |
| Perplexity API | 官方文档说明一次调用返回 web-grounded answer 和 citations | 可补充境外 AI 搜索监测 |
| OpenAI 爬虫与用户触发通道 | 官方文档区分 GPTBot、OAI-SearchBot、ChatGPT-User | 网站审计应分别检查索引、检索和用户实时访问 |
| 国内真实产品端 | 公开稳定监测 API 待验证 | 必须用人工/半自动面板积累数据 |

证据：`evidence/probe-gemini-grounding.md`、`evidence/probe-perplexity-docs.md`。

## 3. 国内外产品对比

| 能力 | 国外商业产品 | 中国现状 | 餐饮控制台取舍 |
|---|---|---|---|
| Prompt 监测 | 有商业 prompt 库、监测排期和趋势图 | 无统一公开 API | 固定 50 问库，人工/半自动记录 |
| 品牌提及 | 支持提及率、情绪、答案位置 | 无平台官方指标 | 记录是否提及、位次、错误信息 |
| 引用来源 | 聚合 AI 引用域名 | 产品端来源不稳定且跨平台差异大 | 抽取引用 URL，识别地图/点评/社媒域名 |
| 竞品可见性 | 常见标准能力 | 缺少自动 API | 同一问题记录竞品是否出现 |
| 爬虫可达性 | 对 OpenAI/Google/Perplexity 等较完整 | Bytespider 和中文生态常被忽略 | 检查境外与字节爬虫规则 |
| 本地生态 | 弱 | 高德/百度/点评/美团/抖音/小红书是关键 | 做 NAP、营业时间、菜单、价格带一致性检查 |
| 经营归因 | 多止步可见性 | 无现成方案 | 结合 POS/预订/电话/优惠码等客户数据 |

商业产品的市场份额、企业案例和供应商宣称数据不能直接当事实。接入前必须重新验证官网、合同范围和数据出口。

## 4. 开源实现模式

已核实的参考项目见 `docs/geo-tooling-landscape.md` 和对应 `evidence/` 快照：

| 项目 | 可借鉴模式 | 不直接照搬的原因 |
|---|---|---|
| Auriti-Labs/geo-optimizer-skill | CLI 审计、0-100 分、修复建议 | 以境外通道为主，缺少中国餐饮生态 |
| yaojingang/GEORank | 中文工作台、网站体检、AI 问答判定、关键词扩展 | 需要核实现有版本和真实产品端能力 |
| ansvisor/ansvisor | 自托管监测、引用/提及/竞品建模 | 面向境外引擎，本地生态不足 |
| cxcscmu/AutoGEO | 提取引擎偏好并改写内容，区分可见性与效用 | 研究型方案，不能绕过平台反制和事实审查 |
| AnswerDotAI/llms-txt | llms.txt 规范 | 社区提案，平台采纳度不一致 |

可复用的架构不是某个界面，而是五层栈：探针测量、技术审计、内容优化、生态铺设、持续监测。

## 5. 中国平台矩阵与探针限制

### 5.1 真实产品矩阵

首发矩阵限定为：

1. 豆包
2. DeepSeek
3. Kimi
4. 腾讯元宝
5. 百度 AI 搜索
6. 高德/百度地图类本地入口（按问题类型使用）

每次记录必须包括平台、问题、时间、城市、门店、回答截图或原文、品牌是否提及、位次、竞品、引用源、准确性异常。

### 5.2 半自动边界

允许：

- 运营按 SOP 在真实 App/Web 查询；
- 把答案文本粘贴到控制台解析引用和判定品牌；
- 上传截图留档；
- 按周或月复测；
- 对异常结果人工复核。

不允许：

- 用裸模型 API 冒充产品端结果；
- 高频爬取注册墙后内容；
- 伪造评价、隐藏文字、注入不可见指令；
- 把一次抽样包装成稳定市场份额。

## 6. 餐饮实施步骤

### 阶段 0：签约前诊断

1. 确认品牌、城市、门店清单、主打品类、客单价、目标场景。
2. 选定 3-5 家竞品。
3. 审计官网 HTTPS、AI 爬虫、llms.txt、JSON-LD、标题、描述、OG。
4. 检查地图、点评、社媒的名称、地址、电话、营业时间、菜单、价格带。

### 阶段 1：基线测量

1. 使用餐饮 50 问库，覆盖附近推荐、品类搜索、场景、竞品替代、时段、外卖、家庭聚餐、商务宴请等。
2. 每题至少覆盖豆包、DeepSeek、Kimi、腾讯元宝、百度 AI 搜索。
3. 记录品牌提及率、位次、竞品份额、引用域名、错误信息。
4. 输出《AI 可见性基线报告》，不得只给平均分。

### 阶段 2：技术修复

1. 修复错误 NAP、营业时间、菜单、价格和闭店状态。
2. 为门店页添加 Restaurant/LocalBusiness、address、geo、openingHours、servesCuisine、priceRange、acceptsReservations 等结构化数据。
3. 检查 GPTBot、OAI-SearchBot、ChatGPT-User、PerplexityBot、Googlebot、bingbot、Bytespider 等 robots 规则。
4. 提供 llms.txt 与核心事实页链接，但不把 llms.txt 当排名保证。

### 阶段 3：内容与生态

1. 建立“一店一事实库”：门店、菜单、招牌菜、价格、停车、包间、营业时间、预订方式。
2. 按场景扩展内容：附近午餐、周末家庭聚餐、夜宵、商务宴请、生日聚会、游客店。
3. 覆盖地图、点评、百科、知乎、小红书、抖音等信任源；只做可验证真实信息。
4. 为评价引导制定合规 SOP，不购买虚假评价。

### 阶段 4：复测与归因

1. 每月同口径复测；重大改版后做事件复测。
2. 报告可见性、流量代理、经营结果三层。
3. 流量代理用品牌搜索、地图访问、点评访问、官网访问、 referral。
4. 经营结果用 POS 新客、预订、电话、优惠码、外卖新客等客户数据。
5. ROI 公式：`(月增量收益 - GEO 服务费) / GEO 服务费`。收益必须标明客户数据来源。

## 7. 测量口径

### 7.1 最小记录字段

| 字段 | 口径 |
|---|---|
| 问题编号 | 与问题库版本绑定，例如 R50-001 |
| 类别 | 场景/品类/竞品/时段/外卖/本地服务 |
| 问题 | 原样用户问法，不改写成品牌暗示 |
| 平台 | 豆包、DeepSeek、Kimi、腾讯元宝、百度 AI 搜索等 |
| 探测日期 | ISO 日期；同轮次保持同时间窗 |
| 品牌 | 被测品牌 |
| 门店 | 连锁客户必须落到门店 |
| 城市 | 本地推荐必填 |
| 品牌是否提及 | 是/否，答案原文必须留档 |
| 位次 | 数值位次；无法判断时留空 |
| 竞品被提及 | 分号/逗号分隔 |
| 引用源 URL | 逗号分隔；保留原始 URL |
| 准确性异常 | 名称/地址/电话/营业时间/菜单/价格错误 |
| 截图 | 必须可追溯到探测记录 |

### 7.2 核心指标

```text
提及率 = 品牌被提及探测点 / 总探测点
平台提及率 = 该平台品牌提及点 / 该平台探测点
首位率 = 第 1 位提及点 / 品牌被提及点
声量份额 = 品牌提及点 / (品牌 + 竞品提及点)
引用率 = 带引用源的探测点 / 总探测点
错误率 = 至少一项事实异常的探测点 / 总探测点
```

指标必须分平台、城市、门店、类别和时间窗查看。聚合值只用于管理总览。

## 8. 控制台架构

### 8.1 MVP 模块

| 路由 | 功能 |
|---|---|
| `/` | 工作流总览、项目数、探测点、提及率、审计均分 |
| `/projects` | 创建和管理品牌、行业、城市、竞品、平台矩阵 |
| `/audit` | 运行官网审计，展示得分、分项、AI 爬虫和修复建议 |
| `/probe` | 维护探测记录，支持 CSV 导入、手动新增、异常标记 |
| `/reports` | 按项目/时间窗生成提及、平台、类别、位次、竞品、引用视图 |
| `/research` | 展示本文结论、工具清单和实施红线 |

### 8.2 技术决定

1. 后端用 FastAPI + SQLite，降低单机部署成本。
2. 前端用无构建静态页面，控制台先服务运营，不做营销站。
3. 数据库文件放 `data/geo_console.db`，备份时复制数据库并校验大小/完整性。
4. 审计复用 `tools/geo_audit_cn.py` 的逻辑，控制台必须加公网 URL 校验，禁止探测 localhost、内网、链路本地地址和任意 scheme。
5. 报告逻辑与 `tools/geo_report.py` 保持同一口径，不允许出现两套提及率定义。
6. 公网部署必须启用访问码；服务进程只监听 127.0.0.1，由 nginx 反代。

## 9. 风险与红线

1. 不承诺固定排名、永久效果或平台推荐。
2. 不购买/伪造评价，不隐藏文本，不注入模型不可见指令。
3. 自动化探针必须先核对平台条款；官方 API 优先。
4. 报告必须区分“可见性提升”和“经营收益”，后者需要客户数据。
5. llms.txt 是改进项，不是排名开关。
6. schema 不会自动抵消错误 NAP 和差口碑。
7. 国内平台界面、本地化和排序更新快，结论必须带日期和截图。
8. AI 平台可能出现错误门店、错误营业时间或张冠李戴；错误率要单独汇报。

## 10. 二轮验证记录

首轮验证以正常用户路径为主：项目创建、探测录入、报告生成、站点审计、研究页渲染。第一轮执行中发现并修复：启动未建库、错误访问码提示误导、隐藏登录层遮挡页面、保存探测后项目选择重置、移动端横向溢出。修复后第一轮复测通过。

第二轮换角度验证：未认证访问、伪造会话、错误访问码、内网 URL、畸形 URL、CSV 缺列、空表、重复行、超限文件、SQL 注入文本、XSS 实渲染、位次边界、32 并发写入、服务重启持久化、移动端渲染。结果为 21/21 API 测试通过，两轮 Chrome 验收和生产 HTTPS 验收通过。证据与缺陷记录见 `docs/console-deployment-2026-09-26.md` 和 `evidence/console-tests/`。