对比
共享日历与发布队列：两件不同的事
日历记录的是要做什么、什么时候做；队列记录的是哪一版已经批准、按什么检查执行。把两者混为一谈，就会把“排上了”当成“可以发了”。
共享日历和发布队列解决的不是同一个问题。周一早上，编辑团队打开日历，看到周四排了一篇关于 AI 可见性的文章。这条记录写的是谁写、什么时候交、属于哪个编辑计划，但没说最终会发出什么。队列里放的则是已经批准的具体版本，随时可以执行。把两者混在一起，就容易以为“进了日历”等于“可以上线”。其实不是。
RankAI 的默认设置是人对某一版本作出批准。自动发布按站点打开，并且仍然要经过检查。队列执行已经批准的内容，日历组织还需要生产的内容。
两条轴：组织与执行，状态与期限
区别不只是“计划”和“发布”。还有第二条轴：谁掌握状态，谁掌握期限。日历里的状态是“撰写中”“审阅中”“已批准进入队列”，期限是编辑日期。队列里的状态是“待批准”“已批准”“已发布”，期限是执行时间。两个工具归不同的人管：日历归协调编辑计划的人，队列归管执行的人。如果同一个人同时管两边，风险就是拿编辑期限当发布许可。
RankAI 的三步操作
这是 RankAI 给出的操作建议，不是通用标准。目的是把两个工具分开，又不增加多余步骤。
1. 写日历条目
填好的日历条目可以是这样：“周四 14 日 — 文章：AI 可见性与编辑计划 — 作者：Giulia — 状态：撰写中 — 期限：周三 13 日交初稿 — 备注：还缺搜索引擎数据复核”。注意缺了什么：没有任何已批准版本的指向。它描述的是一件要做的工作，不是一段要执行的内容。
2. 写队列条目
填好的队列条目可以是这样：“文章 AI 可见性 — 版本 3 — Marco 于 5 月 13 日批准 — 站点：主博客 — 自动发布：该站点已开启 — 检查：已通过 — 执行：5 月 14 日 09:00”。这里版本有编号，批准有记录，执行时间和编辑期限分开。
3. 认出没有版本的草稿
没有可识别版本的草稿，比如一个共享文档，标题只写“文章草稿”，没有编号、没有批准日期、没有指定审阅人。它进不了队列：人批准时所针对的那个具体对象不存在。判断标准不是“文件在不在”，而是“有没有一个某人批准过的版本”。
常被忽略的一点是，日历和队列的记忆不一样。日历记的是意图：我们想做什么、什么时候做。队列记的是决定：哪一版被批准了、经过了哪些检查。删掉一条日历记录，不该抹掉已发布版本的痕迹；队列里执行了一条，日历也不该在没人核实结果的情况下自动标成“完成”。RankAI 把这两层分开：人对某一版本的批准是执行的前提；自动发布按站点开启后，仍要经过检查。实际操作中，把东西从日历挪到队列之前，先问自己：“我手上有没有一个可识别、已批准的版本？”答案是没有，就说明你还在组织，还没到执行。这样能避开两个对称的错误：把草稿当成终版发出去，或者把一条还没有批准内容的记录一直挂在队列里。
对 AI 可见性意味着什么
编辑计划里一旦包含面向 AI 可见性的内容，队列就成了已批准版本被执行的地方。RankAI 的公开页面提到 ChatGPT、Perplexity、Gemini、Grok 和 Google AI。Claude 和 Grok 只有在连接之后才测量。Gemini 和 Google AI Overviews 不是同一次观察。所以队列条目不能只写“发出去”，还要写明发在哪个站点、经过哪些检查，因为执行才让编辑计划和这些被点名引擎的观察之间产生可核对的关系。
可核实的边界：这套做法不判断一个版本“好不好”，也不保证队列条目一定带来可见性结果。它只确定一件事：日历和队列不能当同义词用。完整工具说明见功能详解页。