公众号“发表”和“群发”到底差在哪？为什么扫码登录只能建草稿

先说结论：微信公众号里的“发表”不是“群发”，而且扫码登录也不等于拿到了自动发表权限。 freepublish 解决的是“把草稿变成公开链接”，不会推送给粉丝，也不占群发次数；真正把内容送进订阅列表的是群发。对内容自动化来说，更关键的一层边界是：只有 API 模式下，工具才可能安全地自动发表；如果只是网页扫码登录，最稳妥的终点通常只能是建草稿。

这也是很多团队第一次接入公众号自动化时最容易误判的地方：看到工具能扫码登录、能上传封面、能保存草稿，就自然以为“那应该也能顺手正式发出去”。但对 OmniGoAI 的 OmniPost 这类本地优先工具来说，公众号的安全边界一直是分层的：草稿、发表、群发不是一回事；扫码登录和 API 模式也不是一回事。把这些边界混在一起，最后最容易出问题的不是技术接入，而是权限判断。

如果你正在把公众号纳入内容流水线，建议顺手结合这几篇站内文章一起看：

• https://omnigoai.com/zh/blog/wechat-publish-vs-masssend/
• https://omnigoai.com/zh/blog/wechat-mp-api-draft-guide/
• https://omnigoai.com/zh/blog/wechat-cover-auto-upload/

公众号里的“发表”和“群发”到底分别是什么？

很多团队口头上说“把公众号发出去”，实际上可能指的是三种不同动作：

1. 把文章存进草稿箱；
2. 把文章变成一个公开可访问的链接；
3. 把文章推送给粉丝。

这三步如果不拆开，后面的自动化设计几乎一定会误配。尤其是第二步和第三步，表面上都像“正式发布”，但平台语义完全不同。

发表（freepublish）

freepublish 的核心作用是：

1. 以已有草稿为基础；
2. 让文章生成公开链接；
3. 不推送给粉丝；
4. 不占用群发次数。

也就是说，发表更像“把文章公开上线”，而不是“把文章广播出去”。这一步很适合进入自动化，因为它把内容变成了一个稳定的公开资产：

• 可以被外部引用；
• 可以加入官网内链、知识库和客服回复；
• 可以作为多平台分发时的来源链接；
• 但不会因为一次无人值守任务，直接打扰所有粉丝。

群发（masssend）

群发才是运营同学习惯理解的“今天把这篇发给粉丝”。它意味着：

• 内容会进入订阅消息列表；
• 影响对象是全部订阅者；
• 发送机会和运营节奏更敏感；
• 一旦发出，纠错空间远小于公开链接层。

所以哪怕两者最后都让文章“对外可见”，风险等级和自动化适配度也完全不同。发表适合作为安全公开动作，群发更像必须保留给人工的传播决策。

为什么扫码登录只能安全停在草稿层？

这是很多人最想当然的一步：既然工具已经能扫码进入公众号后台，为什么不能顺手自动发表？

答案在于：扫码登录解决的是“进入后台会话”，不是“获得稳定、可脚本化的正式接口能力”。

扫码登录最擅长做的是草稿层动作，例如：

• 建草稿；
• 上传封面；
• 把正文和排版准备好；
• 让编辑在后台继续检查和修改。

这些动作依赖的是后台登录态，而不是正式接口权限。对自动化来说，这已经很有价值：内容团队可以把“准备文章”这一步自动化掉，大幅减少重复劳动。

但如果把目标升级到“自动发表”，问题就变了。公众号的正式发表不是单纯模拟后台点按钮那么简单，它要求的是一条更稳定、更可审计的公开发布路径。仅有扫码登录时，OmniPost 会把正式发布请求降级成 MANUAL_PUBLISH 或草稿路径，本质上是在保护你不要把高影响动作交给不稳定的网页登录态。

为什么只有 API 模式才能自动发表？

因为 API 模式提供的是公众号里少数真正适合脚本化的正式发布边界。

通常这意味着三件事同时成立：

1. 账号本身满足条件，例如已认证服务号；
2. 你手上有正确的 appId / appSecret；
3. 服务器公网 IP 已加入白名单，接口调用是被微信明确允许的。

只有这三层准备好，工具才能把“正式发布”落到 freepublish 这个安全动作上。此时它做的依然不是群发，而是把草稿转成公开链接。

这也是为什么在 OmniPost 的能力边界里，微信公众号即使显示支持自动正式发布，也必须再往下看一层：那说的是 API 模式下的 freepublish，不是扫码模式下的后台模拟群发。

一个常见误区：有公开链接，就以为今天已经群发过了

这是公众号自动化里最常见的误读之一。

文章有 URL，只能说明它已经被发表成公开页；它不代表这篇内容已经被推送给粉丝。 这会直接影响团队的三类判断：

1. 状态记录会错位：

你写“已发布”，但别人并不知道是草稿、公开链接还是群发。

1. 群发额度判断会错位：

你担心今天的发送机会被占掉了，但实际上发表并不会占用群发次数。

1. 效果归因会错位：

公开页有阅读，不等于这些流量来自粉丝推送；它也可能来自官网、社群转发、搜索引擎或其它平台引用。

更稳妥的做法是把状态分成三层写：

• 草稿已建；
• 已发表（公开链接已生成）；
• 已群发。

不要再用一个含糊的“已发布”把三件事混成一件事。

为什么自动化更适合做到“发表”，而不是“群发”？

因为发表解决的是内容资产上线问题，群发解决的是传播决策问题。

对内容流水线来说，前者天然适合工程化：

• 文章写完后先做质检；
• 官网上线；
• 生成公众号草稿；
• 在具备 API 模式时转成公开链接；
• 再同步到知乎、CSDN、掘金、博客园等平台。

这是一条围绕“内容准备完成、公开资产就绪”的流水线。

而群发更像另一种决策：

• 今天是否值得占一次发送机会；
• 标题和摘要是否适合直接面向粉丝；
• 这篇是否需要再过一轮人工终审；
• 当前是否有更优先的排期内容。

这些问题不该因为文章已经生成成功就被自动替你回答。对于大多数团队来说，“自动发表 + 人工决定是否群发”反而是公众号自动化里最合理的分工。

什么时候最该认真区分扫码登录和 API 模式？

答案很简单：一旦你要做定时内容任务或无人值守发布，就必须区分。

因为两者决定的不是接没接上公众号，而是你的自动化能安全走到哪一层：

• 扫码登录：更适合草稿准备；
• API 模式：可以走到 freepublish；
• 群发：仍应视作人工控制动作。

这也是为什么很多看起来“已经快成功了”的公众号自动化，最后会卡在正式发布这一步——不是工具不会写文章，不是工具不会登录，而是平台本身就把能力边界切在了这里。

给内容团队的实际建议

如果你正在搭公众号自动化，建议直接按下面的分层设计：

1. 把正文、封面、草稿、官网同步做成自动化。
2. 把发表视为公开链接层，而不是粉丝触达层。
3. 只有在 API 模式准备完整时，才启用自动发表。
4. 把群发单独留给人工决策，不要塞进无人值守任务。
5. 日志里分别记录草稿、发表、群发三种状态。

这样做的好处是，团队不会再因为一句“这篇已经发了”而争论半天：到底是进了草稿箱、变成了公开页，还是已经真正出现在粉丝订阅列表里。

如果你想把官网发布、公众号草稿/发表和中文平台分发串成一条稳定流水线，可以试试 OmniGoAI 官网的 OmniPost 下载页： https://omnigoai.com/zh/download/omnipost/ 。它更适合把公众号当成一个有明确“草稿 / 发表 / 群发”边界的平台，而不是一个只有“发没发出去”两种状态的黑盒。

常见问题

公众号里的“发表”和“群发”最核心的区别是什么？

最核心的区别是：发表生成公开链接，但不会推送给粉丝；群发才是真正触达订阅者的动作。 所以发表更适合作为自动化边界，群发更适合保留给人工判断。

为什么扫码登录已经成功了，工具还是不能自动正式发布？

因为扫码登录只说明工具进入了后台登录态，不代表拿到了稳定、可脚本化的正式接口能力。草稿层动作适合用扫码登录做，但自动发表通常需要 API 模式。

API 模式下的“自动正式发布”是不是就等于自动群发？

不是。API 模式下能自动做的是 freepublish，也就是把草稿发表成公开文章链接；它不等于群发，也不会自动把内容推给粉丝。

团队日志里应该怎么记录公众号状态？

建议至少拆成三层：草稿已建、已发表、已群发。这样后续做复盘、查额度和看效果时，才不会把公开页流量误判成粉丝推送结果。