Preview 通过为什么还发不出去：OmniPost 渲染检查和发布校验的区别

先说结论：OmniPost 的 preview 通过，只能证明你的标题、段落、列表、引用、代码块和链接在渲染层看起来正常；它并不能证明这篇文章已经满足正式发布所需的元信息、账号状态和平台规则。 如果你把 preview 当成“马上就能发出去”的信号，后面在 publish 阶段遇到报错时，就很容易误判成工具不稳定。

更准确地说，preview 解决的是“这篇内容看起来对不对”，而 publish validation 解决的是“这篇内容现在能不能发”。对 OmniGoAI 的 OmniPost 来说，这两层检查都重要，但它们拦截的问题完全不同。前者主要挡掉排版事故，后者主要挡掉缺字段、登录态失效、平台必填项缺失和正式发布条件不满足。

如果你在搭一条官网到知乎、CSDN、掘金、博客园的稳定分发链路，真正该做的不是省掉其中一层，而是先用 preview 检查渲染，再把 publish validation 当成独立关卡来对待。 这样你才能解释“为什么这次能发”“为什么这次发不出去”，而不是每次靠运气。

先理解边界：preview 看的是渲染，publish validation 看的是可发布性

最常见的误区，是把这两个动作都理解成“检查文章有没有问题”。这个说法太粗，会把两层职责混在一起。

更实用的理解方式是：

1. preview 负责检查内容呈现是否正常；
2. publish validation 负责检查平台发布条件是否满足；
3. 正式发布 才是把文章真正送到目标平台。

这三步的关系像是“排版校对 → 出版资格校验 → 真正上架”。如果你只做第一步，就等于确认了书排得不错，但没有确认 ISBN、封面、授权和上架渠道是否齐全。

这也是为什么在 OmniPost 的 CLI、MCP、HTTP 三种接入方式怎么选 这类工程文章里，我们一直强调“写作完成”与“发布准备完成”必须拆开。它们不是一个里程碑。

preview 实际会帮你发现什么问题

preview 的价值非常具体，而且不可替代。

它最适合在正式发布前发现下面这类问题：

• 标题是否被截断、换行或层级异常；
• H2/H3、小列表、引用块、代码块是否渲染正常；
• 导语、FAQ、结尾 CTA 是否读起来顺；
• Markdown 里的链接、强调、分隔线有没有明显破损；
• 平台适配稿在改写后，结构有没有被压坏成一坨纯文本。

换句话说，preview 更像一次“内容展示层验收”。

对于技术文章尤其如此。你明明已经写完正文，但一旦平台稿在改写时把小标题拍平、把列表打散、把代码块弄坏，最终就会变成一篇阅读体验很差的文章。preview 能在这一步把问题拦下来，而不用等文章发出去才发现排版翻车。

publish validation 实际在拦什么

publish validation 的重点根本不是“好不好看”，而是“能不能提交正式发布”。

它通常会额外检查这些内容：

1. 目标平台账号是否还处于有效登录态；
2. 正式发布所需字段是否已经补齐；
3. 某平台特有元信息是否有效；
4. 当前模式是建草稿还是直接发布；
5. 平台侧规则、频率限制或去重规则是否允许继续。

这一步里，最典型的平台就是掘金。对掘金来说，preview 就算完全正常，也不代表你已经补齐：

• 分类；
• 至少 1 个平台已有标签；
• 摘要；
• 非草稿态发布结果。

如果你想看更细的掘金场景，可以继续读 掘金正式发布核对清单 2026：分类、标签、摘要与非草稿态。那篇文章讲的是掘金这一平台为什么对 metadata 特别敏感；而本文讲的是更上层的边界：preview 通过，并不等于 publish validation 通过。

为什么 preview 通过后仍然会发布失败

这其实不是矛盾，而是两层检查在检查不同对象。

最常见的几类情况包括：

情况一：正文没问题，但正式发布字段缺失

这是最常见的一类。文章本身排版很好，preview 也看不出问题，但到了正式发布阶段才发现缺分类、缺摘要、缺标签、缺封面或缺目标参数。

这里最容易出现的误判是：你觉得“文章不是已经好了吗”。但对平台来说，一篇可阅读的文章 和 一条可提交的发布请求 不是同一对象。

情况二：内容没问题，但账号状态失效

preview 有时只依赖本地渲染器或通用内容层，而正式 publish 需要真的进入平台登录会话。于是你会看到：文章预览正常，但 publish 返回 NEED_LOGIN、会话失效、账号过期之类的结果。

这不是 preview 失效，而是你把“内容层检查”错当成了“账号层检查”。

情况三：平台规则不在 preview 这一层判断

有些限制天生就是 publish 阶段才显露出来，比如：

• 知乎的频率限制；
• CSDN 的当日篇数限制；
• 掘金的正式发布 metadata 要求；
• 某些平台对去重、审核和状态回写的限制。

这些都不是渲染器该做的事，所以 preview 不会帮你兜底。

情况四：preview 检查的是“看起来像文章”，publish 检查的是“像一次合法发布请求”

这是最值得记住的一句话。preview 的对象是文档，publish validation 的对象是请求。两层都叫“检查”，但检查对象不同，所以结果当然可能不同。

一个更稳的顺序：先 preview，再补字段，再发布，再核验结果

如果你想把多平台分发做成可重复的日常流程，而不是每次手动补洞，下面这个顺序最稳：

第一步：先确认正文本身成立

检查标题、导语、小标题、列表、引用、FAQ、结尾 CTA 是否完整。对于官网稿和平台改写稿，都先把内容本身做扎实。

第二步：做 preview，自检渲染结果

重点看这些点：

1. 标题是否自然；
2. H2/H3 是否还在；
3. 列表、引用、代码块是否正常；
4. FAQ 是否还保留了可引用的问答结构；
5. 结尾引流文案是否自然。

这一步只回答一个问题：现在的内容看起来对不对。

第三步：补齐 publish 所需元信息

这一步才开始处理“能不能发”的问题。典型动作包括：

• 选择目标平台；
• 检查登录态；
• 补摘要；
• 补分类和标签；
• 根据平台决定是否带封面、是否删外链、是否保留来源链接。

第四步：执行正式发布

把 publish 当成真正的状态跃迁，而不是 preview 的附属动作。你应该明确知道这一步传了哪些字段，为什么这个平台此刻可以发，为什么另一个平台可能只能草稿或只能跳过。

第五步：核验发布结果，而不是只看一次 success

正式发布完成后，还要继续确认：

1. 状态是 published、reviewing，还是仍停在 draft；
2. 链接是否已经离开草稿编辑页；
3. 是否已经拿到后续可追踪的文章结果页。

只有到这里，才能把结果记成“已发布”或“审核中”。

哪些错误最不该归咎给 preview

团队在复盘发布失败时，最容易出现一个坏习惯：凡是 preview 成功、publish 失败，就把原因记成“preview 不准”。这会把问题越修越偏。

更准确的归因应该是：

• 渲染问题 才归 preview；
• 字段缺失 归发布参数准备；
• 登录问题 归账号状态；
• 平台限频或审核问题 归平台发布层；
• 结果回写与公开链接确认 归发布后核验。

只有这样拆层，下一轮自动化才能真的变稳。否则你会一直在错误的地方加补丁，比如去强化 preview，却对 category、tags、summary、account health 这些真正的失败点视而不见。

为什么这层边界对 AI Agent 特别重要

如果你只是偶尔手工发一篇文章，混淆 preview 和 publish validation 最多让你多试两次。但如果你在做 AI Agent 驱动的内容流水线，这个边界会直接决定流程是否可维护。

因为 agent 需要知道：

1. 哪些错误可以靠改内容修复；
2. 哪些错误要靠补元信息修复；
3. 哪些错误属于平台登录或频率限制；
4. 哪些结果该记为失败，哪些该记为跳过，哪些该记为审核中。

如果你把所有失败都压成一句“发布失败”，那就等于把 agent 后续决策能力全部废掉了。

这也是 OmniPost 流程里 preview 自检和正式发布核验必须同时存在的原因：前者帮助你修内容，后者帮助你修发布链路。 两者缺一都不稳。

把这件事说得更直接一点

如果你只记一句话，记这句就够了：

preview 证明的是“文章看起来可以读”，publish validation 证明的是“这次请求现在可以发”。

前者面向内容呈现，后者面向平台约束。把这两层混为一谈，几乎一定会让你的自动化发布流程在某个平台上反复撞墙。

常见问题

FAQ 1：preview 通过以后，还一定要单独补分类、标签、摘要吗？

如果目标平台的正式发布要求这些字段，就一定要。preview 不会替你证明这些元信息已经齐全，尤其是掘金这类 metadata 敏感平台。

FAQ 2：为什么 preview 正常，但 publish 仍然提示 NEED_LOGIN？

因为 preview 检查的是内容层，而正式 publish 需要真实的平台登录态。两者不是同一层能力。

FAQ 3：是不是 preview 没什么用，直接 publish 就行？

不是。preview 最擅长提前拦住排版事故和结构损坏，尤其适合平台改写稿。如果跳过 preview，你更可能把格式问题直接带进正式发布。

FAQ 4：什么样的错误应该算 publish validation 的问题？

分类、标签、摘要、封面、账号登录态、平台限频、去重、草稿/正式状态判断，这些都属于 publish validation 或其相邻的发布层问题，而不是 preview 问题。

FAQ 5：正式发布后为什么还要查一次结果状态？

因为“保存草稿成功”“请求提交成功”“真正进入 published/reviewing 状态”不是同一件事。只看一次成功提示，证据强度不够。

如果你正在把官网文章同步到知乎、CSDN、掘金、博客园，最值得先做的不是把 preview 当成万能信号，而是把 preview、publish validation 和发布后核验拆成三层常规动作。这样你的分发流程才会从“有时能发”变成“为什么能发、为什么没发都说得清”。想把这套流程落到本地优先的多平台发布工具里，可以从 OmniPost 下载页 开始。