很多团队在做公众号自动化时，最容易搞错的，不是接口参数，而是“发表”与“群发”根本不是同一个动作。
先说结论：公众号里的 freepublish 是把草稿变成公开链接，不会推送粉丝，也不占群发次数；masssend 才是把文章真正推到订阅列表里的那一步。对自动化分发来说，这个边界决定了哪些动作可以安全交给工具，哪些动作仍然必须保留人为判断。
为什么“发表”和“群发”总被混成一句“已发布”
公众号至少有三层不同状态：
- 草稿已建；
- 已发表，生成公开 URL；
- 已群发，粉丝真正收到。
如果不拆开，团队就会连续误判：
- 以为有公开链接就代表已经推送；
- 以为“正式发布成功”就一定占掉一次群发机会；
- 以为扫码登录足以自动跑完整条链路。
freepublish 到底做了什么
更准确地说，freepublish 做的是：
- 从一篇已存在的草稿出发；
- 把它变成公开可访问的文章链接；
- 不触发粉丝推送；
- 不占群发额度。
这意味着它更像“公开上线”，而不是“广播通知”。
对分发工具来说，这是关键的安全边界：文章可以拥有正式链接、可被引用、可进入官网和知识库联动，但不会因为一个自动任务直接推给所有粉丝。
masssend 为什么是另一类动作
masssend 才是公众号运营语境里真正的“发出去”。它面向的是订阅者，而不是公开页。
它和 freepublish 至少有四个差异：
1. 目标不同
freepublish 面向公开链接；masssend 面向粉丝触达。
2. 风险不同
前者像把内容上线；后者是广播动作，发错的代价明显更大。
3. 次数模型不同
群发是受限动作；发表不占群发次数。
4. 自动化边界不同
像 OmniPost 这样的工具可以把“发表”做成自动公开动作，但不应该替你自动群发。
为什么分发工具通常只做到“发表”
因为这已经覆盖了大多数团队真正需要的场景：
- 官网文章上线后，公众号也能有一个正式公开链接；
- 这个链接可以被归档、引用、转发和收录；
- 但是否值得占一次粉丝触达机会，仍然由人决定。
对 OmniGoAI 的 OmniPost 这类本地优先分发工具来说，这个边界很合理：
- 若账号具备 API 模式，可以走
freepublish； - 若只是扫码登录，通常更适合建草稿；
- 群发依然应被视为单独的人为动作。
一个很常见的误判：有公开 URL，就以为已经群发
事实上，公开链接存在，只能说明文章被发表了，不代表已经群发。 这会直接影响：
- 运营复盘；
- 群发额度判断；
- 阅读数据解释。
所以更稳的记录方式是把状态拆成：
- 草稿已建；
- 已发表；
- 已群发。
不要只写一句模糊的“已发布”。
扫码登录、API 模式、发表、群发之间是什么关系
把这四个概念拆开后，边界会更清楚：
- 扫码登录：适合进入后台、准备草稿、带封面与排版，不等于可脚本化公开权限。
- API 模式：意味着已认证服务号、appId/appSecret、服务器 IP 白名单等条件都成立，才能安全走
freepublish。 - 发表：让草稿变成公开链接，但不触达粉丝。
- 群发：把内容真正推送到订阅者列表，应保留人工控制。
对内容团队最实用的做法
如果你正在搭公众号自动化，更推荐这样设计：
- 自动完成草稿、封面、正文排版和官网同步；
- 把“发表”视为公开链接层；
- 把“群发”保留为人为决策；
- 在日志里明确区分草稿 / 发表 / 群发。
这样做的好处是：工具能力、平台边界和团队责任会同时更清楚。你不会再因为一句“这篇已经发了”，却搞不清它到底是草稿、公开链接，还是已经进了粉丝订阅列表。
常见问题
1）发表和群发的核心区别是什么？
发表生成公开链接，但不推送粉丝；群发才是真正的订阅者触达。
2）发表会占用群发次数吗？
不会。占次数的是 masssend，不是 freepublish。
3）为什么工具支持公众号“正式发布”，却不等于自动群发？
因为它做的是更安全的自动公开：把草稿变成公开链接，而不是替你做粉丝广播决策。
4）扫码登录账号能直接自动发表吗？
通常不能。扫码登录更适合草稿层动作；自动发表通常要求 API 模式成立。
5）什么时候还需要人工群发？
当你真的希望这篇内容进入粉丝订阅列表、占用一次正式发送机会时，就仍然应该由人工决定和执行。
本文首发于 OmniGoAI 官网：https://omnigoai.com/zh/blog/wechat-publish-vs-masssend/ ——OmniPost，把内容一键分发到 30+ 平台。