为什么发布后必须用 recordId 对账：别把旧草稿当成本轮成果

先说结论：OmniPost 发布后，应该核对“本轮返回的 recordId 对应记录后来变成了什么”，而不是“列表里有没有一条看起来差不多的记录”。 如果跳过 recordId，对内容分发最常见的误判就是：把上一次留下的草稿、历史同标题记录，或者旧的公开链接，当成这一次发布的成果。

这条规则看似只是实现细节，实际上决定了你的日志、巡检和补发流程是否可信。尤其在多平台发布、失败重试、审核中回查和同标题去重并存时，“我看到一条像它的记录”并不等于“这就是本轮动作生成的那条记录”。 这也是 OmniGoAI 的 OmniPost 在正式发布实践里反复强调 recordId 的原因：发布后先唯一定位对象，再判断对象状态。你可以把它和发布状态和运营数据有什么区别：什么时候查 status，什么时候看 metrics以及被限频后别重发：如何用 publish_draft 补发已有草稿一起理解。

先记一句话：核验对象必须唯一，recordId 就是那把钥匙

最稳的顺序只有四步：

发布返回后，先保存本轮 recordId；
后续只用这个 recordId 去查 posts、publish-status 或回查结果；
确认这条记录的 stage、postUrl 和真实状态；
不要因为列表里已有旧草稿或同标题记录，就认定本轮成功。

你真正要回答的问题不是“这个平台历史上有没有这篇内容”，而是“刚才那次发布动作到底落成了哪条记录”。只有对象先唯一化，状态判断才站得住。

为什么“列表里有记录”不等于“本轮发布成功”？

因为列表通常只回答“这里存在历史记录”，并不自动回答“哪一条属于你刚才这次发布”。

在真实分发里，下面几种情况常常会同时出现：

上一次失败后已经留下草稿；
同一标题昨天发过；
今天这次尝试又生成了新的失败记录；
正式发布没完成，但本地或平台里已有历史对象；
平台审核慢，你看到的仍是旧状态。

这时如果你只做模糊判断，比如“posts 里有 zhihu 记录”“我看见一条同标题文章”“草稿箱里确实有它”，那其实是在用相似性代替唯一性。而发布核验最怕的，正是这种“看起来差不多”。

recordId 到底解决了什么问题？

recordId 的作用只有一个：把“这一次动作”绑定到“后续要核验的那一条记录”上。

它让你能明确回答：

刚才那次 publish 到底生成了哪条记录；
这条记录后来进入了 draft、reviewing 还是 published；
你现在看到的 postUrl 是本轮产出的，还是旧记录遗留；
列表里的那条内容到底是不是本轮对象。

如果没有这个锚点，状态判断就会变成“猜哪一条最像”。一旦任务里出现失败重试、限频补发或人工重跑，这种猜测迟早会出错。

最常见的三种误判，几乎都因为没按 recordId 对账

1. 把旧草稿当成本轮成果

这是最典型的坑。比如昨天知乎正式发布失败，但平台里留下了草稿。今天你又重新 publish，一看 posts 里有一条知乎草稿，就以为“本轮至少建稿成功”。

问题在于，那条草稿很可能根本不是今天这次动作生成的，而是昨天失败后留下的旧对象。如果不按 recordId 对账，你无法证明这条草稿和今天这次尝试之间存在一一对应。

2. 把旧的公开链接当成本轮成功

有些平台存在同标题或同主题的历史文章。你在列表或回查里看到一个公开链接，就以为本轮已经对外可见。

但更稳的判断应该是：

这个链接是不是从本轮 recordId 对应的记录里拿到的；
这条记录是否已经离开 draft；
这条记录的状态是否在本轮动作后更新。

否则你很可能是在拿上一次已发布内容的链接，给这一次失败的发布“背书”。

3. 把多条相似记录里最像成功的那条当答案

在失败重试、审核中回查或平台缓存存在时，经常会同时出现：

一条旧记录是 published；
一条新记录是 draft；
还有一条失败记录没公开链接；
它们标题几乎一样。

如果没有 recordId，你就会开始凭印象挑一条“最像成功”的来写日志。这样会直接污染运行报告、自动巡检和后续补发决策。

一个最稳的发布后核验顺序

第一步：发布返回后立刻记下 recordId

无论你通过 CLI、MCP 还是 HTTP 调用，发布结果里最重要的不是一句泛泛的 success，而是每个目标对应的本轮记录标识。这一步越晚补，越容易丢。

第二步：只对这条 recordId 做后续回查

后面的所有判断，都应该围绕这条记录展开，而不是围绕“同标题”“同平台”“大致同一时间”展开。

最值得确认的是：

当前 stage 是 draft、reviewing 还是 published；
有没有 postUrl；
这条记录是否仍停留在编辑器链接；
是否有 reviewStatus 或平台回查结果。

第三步：把“动作结果”和“真实状态”分开看

发布返回的即时结果，回答的是“这次动作刚执行完时系统认为发生了什么”；后续回查回答的是“平台现在真实把这条记录当成什么”。

所以最稳的方式是：

先按 recordId 找到本轮对象；
再看这条对象现在的状态；
最后决定日志里写“已发布”“审核中”“仅草稿”还是“失败”。

如果你把这些层次揉成一句“我看到有记录，所以应该发成了”，后面就很难解释为什么又冒出了补发、下架或重复草稿。

为什么多平台分发更离不开 recordId？

因为同一篇文章在一个批次里，可能同时得到完全不同的结果：

zhihu：本轮 recordId 对应 reviewing；
csdn：另一条 recordId 对应 published；
juejin：返回失败记录，原因是标签没命中；
cnblogs：返回 published，但还没做下一次状态回查。

如果你不按每个平台本轮各自的 recordId 去看，最容易发生两种混乱：

拿 A 平台的确定性心态去判断 B 平台；
拿旧记录去填补本轮还没核实的空白。

OmniPost 把 per-target 结果拆开，本质上就是在保留“每个平台各自那条对象”的边界。recordId 是把这个边界真正落到执行层的关键字段。

recordId 和 publish status 是什么关系？

两者不是替代关系，而是先后关系：

recordId 负责告诉你：要看哪条记录；
publish-status 负责告诉你：这条记录现在处于什么状态。

如果你直接查 publish status，却没有先确认对象是谁，那么即使拿到 published、draft 或 offline，也可能只是历史上另一个相似对象的状态，而不是本轮动作对应对象的状态。

所以更稳的顺序永远是：先用本轮 recordId 对账定位对象，再读取这条对象的 publish status，最后决定本轮结论。

一个适合自动化和人工复核共用的简单规则

你可以把它写成团队固定 SOP：

发布结果出来后，先记住每个平台本轮返回的 recordId；
后续所有核验都围绕该 recordId 展开；
日志中不写“看起来成功”，只写“recordId 对应状态是什么”；
如果只找到旧记录、旧草稿或相似标题，但无法证明它对应本轮 recordId，结论必须保守；
只有当 recordId 对应记录进入明确的非草稿态，或拿到可核验的公开链接，才把它记为本轮有效成果。

这条规则最大的价值，不是多做一步，而是让发布结果从“主观判断”变成“对象可追踪的事实”。

常见问题

为什么不能只看标题和平台名来核对发布结果？

因为同标题、同平台并不能保证是同一条发布记录。历史草稿、失败重试和旧的公开内容都可能长得很像。

recordId 最适合在什么时候保存？

就在发布结果返回的当下。越晚补记，越容易在后续列表增长后分不清本轮对象。

有了公开链接，还需要 recordId 吗？

需要。公开链接也可能来自旧记录。更稳的做法是先确认这个链接属于本轮 recordId 对应的那条记录，再把它记为本轮成果。

什么时候可以把本轮结果写成“已发布”？

当且仅当本轮 recordId 对应的记录已经进入明确的非草稿态，并且你能核对到 stage、状态或公开链接时，才适合这样写。

如果只看到旧草稿，但找不到本轮 recordId，该怎么处理？

结论应该保守。你可以写“发现历史草稿，但尚不能证明其对应本轮发布动作”，而不是直接报成功。

如果你正在把多平台正式发布、回查和日志做成一条稳定的内容流水线，OmniGoAI 的 OmniPost 可以帮你把对象、状态和平台结果拆得更清楚：https://omnigoai.com/zh/download/omnipost/ 。真正让发布流程稳定的，从来不只是“能发出去”，而是发出去之后，你还能准确证明哪条记录才是这一轮真正的成果。