编辑计划
SEO编辑计划：AI观察与发布前核验
在editorialPlan页面中，人工批准某一版本是默认做法。自动发布按站点开启，并且仍要经过检查。先分清哪些是AI引擎的观察，哪些是发布前还要核验的内容。
草稿已经准备好，editorialPlan页面里也出现了关于Google和AI引擎的观察。问题很具体：怎样用SEO编辑计划的批准，把AI引擎的观察和发布前仍需核验的内容分开？我们的默认做法是由人对某一版本进行批准。不会因为某条观察看起来有利，就把草稿发到线上。批准的作用正在这里：把“已经观察到的”和“已经核验过的”分开。自动发布按站点开启，并且仍要经过检查，所以它不能替代核验这一步。在editorialPlan页面里，每份草稿都要先确认哪些观察针对Google、哪些针对AI引擎，然后才能批准。还要记住，Gemini和Google AI Overviews不是同一次观察。
把editorialPlan页面设为批准点
RankAI的操作建议是：不要把editorialPlan页面当成笔记仓库，而要把它当成草稿从“已观察”走向“已批准”的地方。关于Google和AI引擎的观察只是阅读材料，本身不等于放行。对某一版本的人工批准才是收尾的一步，而且只有在每条观察都归类之后才能做。
可以点名的观察范围
公开页面提到ChatGPT、Perplexity、Gemini、Grok和Google AI。Claude和Grok只有在连接之后才测量。Gemini和Google AI Overviews不是同一次观察，即使谈的是同一个话题，也要分开记录。在editorialPlan页面里读到的内容，就放在这个范围内理解。
批准草稿的三个步骤：别把观察和核验混在一起
- 按引擎归类每条观察。可核验的标准：editorialPlan页面的每一行都写明对应的引擎，Gemini和Google AI Overviews作为不同条目出现。如果一条观察归不到具体引擎，它还不能算可用的观察。
- 标明测量状态。可核验的标准：对Claude和Grok，草稿要写明是否已经连接；在连接之前，观察不存在，也不能支撑批准。对其他点名的引擎，观察就是页面上已有的那条。
- 把还要核验的内容单独列出。可核验的标准：凡不是来自已记录观察的要点，都写成待核验项，写明负责人和关闭条件。只有待核验清单为空，或已被明确接受，草稿才能批准。
- 批准的是版本，不是想法。可核验的标准：人工批准记录在草稿的特定版本上。批准之后如果正文改了，版本就变了，批准不会自动沿用。
自动发布为什么不能了结这件事
自动发布按站点开启，并且仍要经过检查。也就是说，对某一版本的人工批准仍是默认做法，自动化不会把一条观察变成一次核验。即使自动发布已经开启，editorialPlan页面里仍要保留“已观察”和“待核验”的区分。
容易被忽略的一点是：关于AI引擎的观察描述的是那个引擎在某个时刻返回了什么，而不是页面应该写什么。按我们的操作建议，editorialPlan页面应有两个概念上的栏位：一边是观察，带引擎和日期；另一边是待核验项，带负责人和关闭条件。只有第二栏为空或被明确接受时，才给出批准。第二个要点是交叉阅读：不要用关于Gemini的观察去证明Google AI Overviews上的选择，因为它们是不同的观察。第三个要点是版本可追溯：批准之后如果改了正文，草稿就回到核验状态。这些做法不是通用标准，而是一种方法，让editorialPlan页面里“看到的”和“核验过的”之间的差别变得可见。
需要记住的一个限制
上述方法并不保证AI引擎的观察完整或有代表性，它只说明批准之前怎样在editorialPlan页面里组织这些观察。API返回的答复不是人看到的屏幕画面，每次读观察时都要记住这一点。
关于怎样设置计划和批准的完整说明，见深入页面。