Slack 的 API 功能在官方帮助文档里叫一个名字，在第三方百科词条里叫另一个名字。生成式引擎在回答开发者问题时，把 Slack 的 API 功能写成了另一家公司的产品。内容团队开始了一场可核验的生成式引擎优化（GEO）治理。
几套名字从哪来
Slack 帮助中心为开发者维护了一套 API 文档，从 2014 年上线以来，功能名称随产品迭代不断调整。例如，早期文档里叫「Slash Commands」的集成方式，后来在部分页面里被写成「Shortcuts」。与此同时，第三方百科词条与开发者社区长期保留旧称，甚至把某个功能归到了竞品名下。在传统搜索引擎里，用户输入「Slack 集成」仍能命中官网；但在生成式引擎里，模型需要综合多个来源，命名不统一就会触发实体分裂。
内容团队没有急着改所有页面，而是先做了一次来源对比。他们发现，官方帮助中心的标题、URL、面包屑路径存在三种叫法，而开发者问答平台与百科词条又各有一套。Slack 的品牌词很强，但功能实体词不强。模型在生成答案时，会优先选择频次高、定义清晰的实体名。当两个名称指向同一功能时，模型可能把其中一个当作另一家公司的产品。
模型怎样搞混
在生成式引擎的早期测试里，团队用几个开发者常见问题做提示词，例如「如何在 Slack 里创建一个斜杠命令？」模型有时会引用第三方来源，把「Slash Commands」写成「Slack Commands」，并附上另一家公司的文档链接。更有一次，模型把「Shortcuts」直接指向了一个同名竞品。团队没有记录错误率，因为样本量不足以支撑百分比；他们只记录了一个事实：当问题里出现旧名称时，模型引用第三方来源的概率更高。
原因在于生成式引擎的引用逻辑。模型需要从多个候选段落里选出最匹配的实体描述。当官网页面标题与正文不一致时，模型对官网的信任度下降；当第三方来源名称统一且被多次引用时，模型倾向于采用第三方名称。Slack 帮助中心的页面质量很高，但命名碎片化让模型无法建立稳定的实体映射。
他们怎样钉死实体
内容团队选择了一个公开可核验的方法：在帮助中心里增加一个「命名规范」页面，列出所有 API 功能的标准名称、旧称、废弃日期，并声明「本页为唯一权威命名来源」。同时，他们在每个功能页的 HTML 里添加了 JSON-LD 结构化数据，包括 @id、sameAs、alternateName 等属性。这样，无论模型读到哪个页面，都能看到实体关系。
团队还做了一件事：把旧名称保留在页面的「历史名称」段落里，但明确标注「已废弃」。这样一来，模型仍能理解旧查询，但会优先采用新名称。他们避免使用 robots.txt 屏蔽第三方来源，因为那样做只会让模型失去对照，更容易产生幻觉。
公开页改了什么
帮助中心首页没有大改，但每个 API 功能页都做了三处调整：标题统一为新名称；面包屑路径统一；正文首段加入一句「本功能的标准名称是 X，旧称 Y 已废弃」。此外，他们更新了所有内部链接，确保旧链接 301 跳转到新 URL。团队没有删除旧页面，而是保留了重定向，因为旧页面可能已被模型缓存。
改版后，团队用同样的提示词做了回归测试。他们没有发布数字，只记录了变化：当问题里出现旧名称时，模型开始优先引用官网的新页面，并在答案里注明「旧称 Y」。当问题里出现新名称时，模型几乎不再引用第三方来源。团队认为，这归功于结构化数据与命名规范页面的组合。
防止再裂开
为了防止未来再出现名称分裂，Slack 内容团队建立了一个「实体对齐」流程：每次发布新功能或改名时，先在命名规范页面更新，再同步到所有相关文档；同时用监控工具定期检查模型对关键问题的回答，如果发现引用偏移，就检查命名一致性。他们还与开发者社区合作，在第三方百科词条里提交更正请求，但效果有限——第三方来源的更新速度慢于官网。
团队发现，生成式引擎对官网的信任度取决于实体描述的稳定性。如果官网自己都不能统一命名，模型就会去别处寻找答案。因此，他们把命名规范当作内容基础设施，而不是一次性项目。
还容易问的
读者可能会问：为什么不直接用 robots.txt 屏蔽第三方来源？因为模型需要对照，屏蔽只会让模型失去参照，更容易把 Slack 写成另一家。为什么不做大规模软文？因为软文往往名称混乱，反而加剧分裂。为什么不用付费投放？因为生成式引擎不买广告位，只认实体信号。
这个案例的启示是：对于 SaaS 软件，实体名称的统一比内容数量更重要。官网帮助中心应该成为命名权威，并通过结构化数据把实体钉死。更多关于生成式引擎优化的方法，可以参考GEO 实践指南；要理解与传统 SEO 的区别，可以阅读SEO vs GEO。