对比
RankAI 会取代 CMS 吗？两者分工不同
RankAI 不取代 CMS。CMS 负责管理和发布内容，RankAI 负责准备并批准版本。默认需要人工批准某一版本，自动发布按站点开启，并且仍要经过检查。
不会，RankAI 不取代 CMS。CMS 负责管理和发布内容；RankAI 负责准备并批准版本。具体来说：CMS 里有一篇已经写好的文章，但在发布之前，你希望某个版本先由人批准。RankAI 默认要求对某一版本进行人工批准。自动发布按站点开启，并且仍要经过检查。所以 CMS 不会消失：内容仍然在 CMS 里管理和发布。RankAI 介入的是发布之前的那一步，也就是待批准的版本，以及该站点是否开启了自动发布。与其问“谁取代谁”，不如问“谁做什么”。
准备与发布：两个不同的角色
有用的区分是“准备版本”和“发布”。RankAI 不是 CMS，也不取代 CMS：CMS 仍然是内容被管理和发布的场景。RankAI 处理的是待批准的版本；如果某个站点开启了自动发布，它也涉及自动发布，而自动发布仍要经过检查。我们不给 RankAI 安上“内容目的地”这种功能：事实只谈到版本批准和按站点自动发布。设计工作流时，应当沿用这个说法。
四步操作流程（RankAI 的建议）
这是 RankAI 提出的操作建议，不是通用标准。它的作用是说明 CMS 和 RankAI 各自做什么。
- 确定要批准的版本。在 CMS 里找到需要经过人工批准的内容。例如：文章《AI 可见性指南》在 CMS 里是草稿。
- 批准该版本。由一个人批准这个具体版本。例如：编辑批准文章的第 3 版。
- 按站点决定自动发布。确认该站点的自动发布是开启还是关闭。例如：“主博客”站点关闭自动发布；“newsletter”站点开启自动发布。
- 在 CMS 里发布。CMS 仍然是管理和发布的地方。例如：已批准的版本由 CMS 发布到“主博客”站点。
简单填一下：已批准版本 = 第 3 版；CMS 目的地 = 主博客；谁来发布 = CMS；自动发布 = 该站点关闭，所以需要手动一步。
容易被忽略的一点是：批准针对的是某个版本，而不是笼统的“内容”。如果批准之后 CMS 里的版本变了，原来的批准不会自动覆盖新版本。因此我们的操作建议是：写明被批准的是哪个版本，并逐个站点确认自动发布是否开启。这不是给内容指定“目的地”，而是对批准和发布做检查。另外，自动发布仍要经过检查：它不是一按就免检的开关。把两个角色分开，就不会要求 CMS 做它不做的事，也不会要求 RankAI 做它没有声明的功能。
一个可核实的边界
边界在这里：我们可以说，默认是对某一版本进行人工批准，自动发布按站点开启，并且仍要经过检查。我们不能说 RankAI 取代 CMS，也不能说它代替 CMS 管理发布。想进一步了解流程和检查，请看功能说明页。