我要的是一张表

做 GEO 诊断，最终交付客户的其实就是一张表：行是用户会问 AI 的问题，列是各家 AI 模型，每个格子记录——你的客户出现了吗？排第几？描述准不准？

再配上两份附件：AI 引用了哪些平台（内容该往哪铺），AI 反复推荐了哪些竞品（对手是谁）。

我不懂代码，这套工具是我指挥 Claude Code 用 Python 搭的，本地跑，数据存 SQLite，报告出 CSV 和一张单页 HTML。从验证想法到四个模块全部跑通，实际用了一天。下面讲两个核心模块的设计思路。

模块一：问题库——AI 负责量，人做闸门

问题不能瞎编，我按三个维度设计：

四类意图：决策类（“哪家靠谱”）、对比类（“枯山水 100 平多少钱，贵不贵”）、怎么办类、本地类（“苏州东山附近有做民宿庭院改造的吗”）。

两个地域范围：这是实战里踩出来的。给苏式园林客户做诊断时我发现，它的客源是全国的——北京有人会问”想弄中式园林的院子，找苏州团队做异地设计施工多少钱一平”。所以问题库分”本地”和”全国”两套，判断标准就一条：客源是否跨城市。

成交度打分：每个问题标 1—5 分的成交距离。这样最后的缺口清单可以按成交度排序，客户先补离成交最近的内容，钱花在刀刃上。

工作流是：LLM 批量生成候选问题 → LLM 判重 → 人在 Excel 里定稿，只有人工确认过的问题才进诊断。AI 负责量，人做最后的闸门。这次 demo 定稿了 71 条。

这里踩过一个大坑：让 LLM 一次性给 40 条问题判重，它把 39 条判成了重复，差点把问题库删光。后来改成两阶段——先粗分组，再逐对严格复核（地域、预算、风格、人群任何一个不同都不算重复），并且加了一条保险丝：要归档的数量超过总数 30%，整批放弃。我的经验是：LLM 做增量判断比全局判断可靠得多，不可逆的批量操作一定要配比例保险丝。

模块二：诊断矩阵——自动去问，自动拆解

诊断运行器做的事很直白：对每一个”问题 × 模型”的组合，用真实浏览器把问题发给 AI（为什么必须真实浏览器，我单独写了一篇），抓回完整回答，然后再用一个 LLM 把回答严格拆解成结构化数据：

  • 回答里推荐了哪些具体公司（“XX 造园”这种占位符不算）；
  • 我的客户有没有被提到、排第几、描述准确还是错误；
  • 引用了哪些网页，各属于什么平台（知乎、抖音、头条、黄页……）。

全部落库。任何一条失败只记日志跳过，不中断整轮，事后可以单独补跑失败的题并入原来的批次——这点很重要，因为网页自动化一定会有失败。

实战里的坑

豆包会静默风控。 固定 8 秒间隔连跑 80 多条之后，豆包把发送按钮悄悄禁用了——页面没有任何提示，怎么点都发不出去，几小时到隔天自动解除。后来改成 20—45 秒随机间隔，单账号一天控制在 60 题以内。

假成功比失败更可怕。 有时抓到的”回答”其实是自己发出去的提问气泡（回显），数据看起来齐齐整整，全是假的。后来加了防护：提取到的内容跟提问一样就判失败。做自动化，最要防的不是报错，是不报错的错。

这套工具跑出来的第一份真实报告——64 题、802 条引用、客户 0 次提及——就是上一篇文章里那个案例。工具不神奇，但它把”你在 AI 眼里存不存在”这件事，变成了一张可以复测、可以对比的表。