自己动手，探索 GEO 策略的落地和迭代优化

先说结论

• GEO（生成式引擎优化）要解决的问题，是您的公司和观点能不能出现在 AI 助手的回答里。我们在自家官网上做了一轮，前后一个晚上，先搭测量，后改内容。
• 查了别人的方法之后，经得起复现的主要是两条：一是单次回答不可信，要看多次运行里的提及率；二是先被检索到，比怎么改写重要得多。补结构化数据、放 llms.txt 这类技术信号，大样本研究基本测不出作用。
• 我们的基线很低：两个国内引擎各问 30 个买家会问的问题，各提到我们 5 次，其中 4 次是问题里本来就写了公司名或产品名；不含品牌名的 26 个问题，各只提到 1 次。必应上 8 篇核心文章一篇也没收录。
• 我们也做错了一件事：39 篇文章「先说结论」一次全改完上线，没有留对照组，改得好不好已经无法归因。第二批 10 篇的内容补充，我们设计过对照组，最后决定不等、直接上线，原因写在第五节。
• 分工和我们其他项目一样：我们提需求、拍板、验收；Claude Code 作为执行器写代码、查资料；APSer-Atelier 作为主控负责组织，登记每一条要求、管住谁能改、登记每次发布后的验证结果。

本文说的 GEO，指让生成式 AI 助手（豆包、DeepSeek、元宝、通义、Kimi 等）在回答问题时提到、引用您的内容。它和搜索引擎优化相关，但衡量的对象从「搜索结果排第几」变成了「AI 的回答里有没有您」。

我们是一家做制造业深度定制交付的小公司，官网上有 39 篇「思考与实践」文章。9 月下旬集中发完之后，我们想知道：这些文章有没有被 AI 读到、有没有进到 AI 的回答里。本文写我们怎么自己动手测、测出了什么，以及按统计规矩改过的测量方法。

一、先搭测量：我们看哪几个数？

没有测量，后面任何改动都说不清效果。我们先搭了三样东西，都放在官网后台，只有我们自己能看。

1. AI 爬虫抓了什么。 服务端按请求的 UA 识别 AI 爬虫与搜索引擎爬虫，按文章统计谁来抓过、抓了几次、最近一次是什么时候。按 UA 识别有两头误差：伪装成浏览器的抓取认不出来；反过来，也有扫描器冒用 AI 爬虫的 UA，我们对照官方公布的 IP 段抽查后，把同一 IP 一分钟内冒用多种爬虫名的请求剔除，占原先 AI 爬虫计数的 13%。
2. 有没有人从 AI 应用点进来。 按访客的引荐域名和链接上的来源标记识别，一位访客一天算一次。从原生 App 跳转过来往往不带引荐信息 [8]，所以这个数只作参考。
3. AI 的回答里有没有我们。 我们拟了 30 个买家会问的问题，分 APS 选型、定制交付与 MOM、AI 协同开发、品牌与本地四类；每天一次，用接口开着联网搜索问两个国内引擎，记下回答里有没有提到我们、写没写出官网网址，原回答全文存档。

这三样上线后，发布后检查会拿生产上的原始日志独立再算一遍，与后台页面上的数逐项对照，对不上就不算上线成功。统计页上的数字，自己要先信得过。

二、别人的方法里，哪些经得起复现？

测量搭起来以后，我们没有直接照网上的清单去改，先查了公开研究和从业者的做法，并逐条打开来源核对。结论按证据强弱排：

有两点提醒要一并写明。一是这些研究大多在海外引擎或模拟引擎上做。GEO 开山论文报告的最高约 40% 的提升 [7]，后来的 C-SEO Bench 在更多领域上没有观察到同样的效果 [2]，不能当成国内引擎上的预期。二是国内几家 AI 助手联网时用哪家的搜索索引，都没有官方说明。

三、我们在官网上做了什么？

按时间顺序，9 月 30 日凌晨这一轮做了这些：

1. 后台上线「AI 可见度」页，并把它接进发布后检查，统计数字自动对原始日志。
2. 39 篇文章改为开头先给结论，二级标题改成读者会问的问题。
3. 每日 AI 巡检上线；同时补了 llms.txt、公司结构化数据，并在每次发布检查通过后把改过的页面推送给支持 IndexNow 的搜索引擎。
4. 发现 AI 描述我们时仍带着早年的合作平台身份，就把站内与公司定位无关的旧提法从结构化数据、导读和导航里拿掉，巡检加上「身份偏移」一项，专门数这类回答。
5. 查完别人的方法后，把巡检的汇报口径改成滚动提及率加置信区间，问题打上阶段、格式、是否含地名、是否含品牌名的标签。
6. 联系表单和留言板加一个选填项「您从哪里了解到我们」，AI 助手单列一项。访客自己说的来源，比流量统计可靠。
7. 做了一次收录排查，并给 10 篇文章补上术语定义、方案对比表、实施步骤和带出处的数字。

四、基线是什么样？

第一轮巡检在 9 月 30 日 01:37 跑完。两个引擎各 30 个问题，结果如下：

不含品牌名的问题里，两个引擎提到我们的都是同一题：精密铸造企业用什么生产管理软件。这与我们在精铸行业的交付经历对得上，但只是一次观测，不能当成结论。

爬虫这一侧：9 月 28 日 17:11，一个 AI 爬虫把 30 篇文章各抓了 1 次，之后没再来；百度爬虫同一天把 8 篇核心文章各抓了 1 次；必应爬虫只抓过 1 次文章页。按文章标题查，必应上 8 篇一篇也没收录，只收了首页、关于、联系、两个产品页和一篇较早的文章。百度和夸克的查询被人机验证拦下，我们没有代过验证，留给人手动查。

五、怎么测才不自欺？

我们按查到的研究，改了四处测量口径。

1. 看滚动窗口，不看某一天。 每题每天仍只问 1 次，费用不变。公开研究测得同日重跑与跨天的波动幅度相近 [1]，所以按 28 天累计，可以近似看作每题问了 28 次。
2. 带上置信区间。 例如 5 / 30 这个数，95% 置信区间是 7% 到 34%，区间很宽，说明样本还少。一次都没提到时，写「低于 3/n」，不写 0%。
3. 把含品牌名的问题单独看。 问「某公司是做什么的」，AI 提到这家公司是应该的；真正反映可见度的，是不含品牌名的问题。
4. 对照组，设计了但没用。 我们原本把 20 篇文章按主题两两配对，随机一篇改、一篇不动，各对应一个买家问题，先记两周基线再比。算下来不划算：不含品牌名的问题几乎都提不到我们，两组的提及率都接近零，差值会长期落在噪声里，要等上一两个月才可能看出点什么。我们决定不等，10 篇直接补齐上线，代价是之后的变化同样没法归到这次改动上，只能看整体的滚动提及率。

我们也清楚这套测量的边界：巡检用的是接口加联网搜索，和用户在 App 里看到的回答不是一回事，有厂商研究测得，同一款 AI 助手的接口回答与网页版回答里提到的对象，相似度约 0.48，同一方式内部约 0.7 [10]。提及率从接近零的地方起步，短期内很可能看不出变化；测不出效果，也是一个要照实记下来的结论。

六、这一轮做错了什么？

• 全量改、没留对照。 39 篇「先说结论」一次全部上线，之后提及率有没有变化，都无法归到这次改动上。这是我们这一轮最大的教训。第二批我们权衡后仍然没留对照，是明知代价的选择，见上一节。
• 一度把单次观测当基线。 第一轮巡检出来时，我们差点拿「提到 5 次」当基线往下比；按滚动窗口看，它只是一个观测点。
• 一开始只数了「提到没提到」。 提到我们的回答里，有 4 条同时提到了我们早年深度使用的一个低代码平台，把我们和它连在一起。被提到、但对我们是做什么的说偏了，比没被提到更需要处理，所以后来加了身份偏移这一项。

七、主控在这件事里做了什么？

写代码、查资料的是 Claude Code；作为主控的 APSer-Atelier 负责组织，平台的来历见《APSer-Atelier 从哪里来》：

这里说的 APSer-Atelier 主控包括两部分：面对我们的主控会话（一段 Claude Code 或 Codex 对话），负责组织和派出；Atelier 平台，负责登记每一件事、挂起待拍板、记下要求、按规矩放行并留下记录。

• 登记每一条要求。 这一轮提出的每件事，当场登记，做完挂上验证记录再结案。
• 管住谁能改。 改官网代码之前，必须先在 Atelier 上持有这件事；交接到新会话时，新会话要重新持有才能提交，否则提交被拦下。
• 登记发布后的验证结果。 每次上线后的检查结果都登记在案；推送之后没跑检查，钩子会拦住，不让这一轮就此结束。

八、接下来按什么顺序做？

1. 先解决被检索到。 在百度搜索资源平台验证网站、接入收录推送；在必应站长工具里看 AI 相关的引用数据。
2. 拿到引用来源。 换用能返回引用来源的接口，并接入更多国内引擎，记录官网有没有出现在来源里。有研究发现，不含品牌名的问题里，官网出现在来源里时，被提到的比例从约 3% 升到约五成；研究出自测量工具厂商，是关联不是因果 [9]。
3. 看补过内容的 10 篇有没有被引用。 这 10 篇已补齐定义段、对比表、步骤和带出处的数字；拿到引用来源后，先看它们有没有出现在 AI 的来源里。
4. 站外同一组事实。 公司所在地、主营、产品名这组事实，争取在更多独立来源出现，不追发稿篇数。
5. 每月复查收录，每周看滚动提及率。 只有超出前几周正常波动的变化，才算值得关注。

以下是我们的看法

GEO 眼下的说法很多，能经得起复现的很少。对一家小公司来说，最实在的做法是先把自己的测量搭起来，用统计的规矩去看数，改动时想清楚能不能归因；留不留对照，要看样本够不够，不够就老实承认看不出来。这和我们给客户做系统的习惯一样：先能核对，再谈改进。

这一轮的数字都来自官网后台和巡检记录，截至 9 月 30 日。之后的滚动提及率变化，我们会照实补记，测不出效果也会写。

参考来源