对比
如何验证一项功能是否真的可用
在把一项功能写进编辑计划之前，先确认它真的可用，而不只是被提到。本文给出可操作的验证标准和检查清单。
在 AI 可见度的编辑流程里，把一项功能写进编辑计划之前，先要确认它真的可用，而不只是被提到。验证从一个具体问题开始：这项功能在我们的环境里是否已开启，是否能产生可观察的结果？在 RankAI 上，默认做法是人对某一版本进行批准；自动发布按站点开启，并且仍然要经过检查。公开页面提到 ChatGPT、Perplexity、Gemini、Grok 和 Google AI。Claude 和 Grok 只有在连接之后才会被测量。Gemini 和 Google AI Overviews 不是同一次观察。这些内容应当作为验证标准使用，而不是当作宣传清单。
规则：可用，还是只是被提到
一项功能可用，是指我们能指出它在哪里开启、受哪项检查约束、在我们的编辑流程里产生什么可观察的结果。它只是被提到，是指它出现在公开页面或某段描述里，但我们的环境里没有可观察的结果。这个区分是操作性的：只有当验证能给出可记录的结果时，编辑计划才可以引用这项功能。
示例说明，并非实际观察
以下为示例说明，并非实际观察。情形 A：“自动发布”功能对某个站点开启，并受检查约束；结果记为可用，因为我们知道它在哪里开启，也知道哪一步人工批准仍然有效。情形 B：某项功能在公开页面被提到，但没有接入我们的环境；结果为“不可用”，因为流程里缺少观察。情形不明：功能已开启，但结果无法与另一次观察区分，例如 Gemini 与 Google AI Overviews；这种情况下不能声明可用，应暂停写入编辑计划。
这是 RankAI 的操作建议，不是通用标准：在把一项功能写进编辑计划之前，先填一张表，三个字段必填——在哪里开启、受哪项检查约束、产生什么可观察的结果。三个字段中任何一个为空，这项功能就属于“只是被提到”，不进入计划。如果两次不同的观察被混淆，例如 Gemini 和 Google AI Overviews，表格要标为“不明确”，验证暂停，直到把两次观察分开。这个标准可以避免编辑计划把名字的出现当成流程里真正可用。
编辑计划的验证清单
- 写下这项功能，以及它在编辑流程中应当起作用的位置。
- 指出它在哪里开启、受哪项检查约束。
- 记录在我们环境里可观察到的结果。
- 把并不重合的观察分开，例如 Gemini 和 Google AI Overviews。
- 结果无法区分时停下来，标为“不明确”，不写入计划。
可验证的边界：这套流程不判断某项功能是否提升 AI 可见度，只判断它在我们的编辑流程里是否可用。完整背景见：深入阅读页。