把多平台发布做成状态机后，如何避免重复投稿？

同一篇内容要发到十几个平台时，团队最先遇到的问题通常不是“怎么写”，而是“这篇到底发过没有”。

有人看到编辑器里有草稿，就认为已经提交；有人收到平台短信，就把它记成发布成功；还有人只在备注里贴了一条链接。几天后，另一个执行者接手，同一篇文章又被提交一次。平台可能因此判定重复、降低推荐，团队也无法回答一个简单问题：这篇内容目前在哪些渠道公开，哪些还在审核，哪些已经被退回？

我们在设计一套 GEO 内容分发流程时，最初也把“发布”理解成一个按钮。真正接入多个国内媒体平台以后才发现，它更接近一个跨平台状态机。

一、一个“已发布”字段为什么不够

最简单的数据设计，是在文章上增加一个布尔字段：published=true/false。

这个设计在单一官网里勉强可用，进入多平台场景后很快失效。因为同一篇文章在不同账号上可能同时处于这些状态：

• 在公众号已经公开；
• 在科技媒体等待编辑审核；
• 在内容社区被退回；
• 在另一个平台只保存了草稿；
• 某个平台的企业账号还没通过资质审核，根本不能投稿。

如果文章只有一个“已发布”字段，任何一个平台成功都会掩盖其他平台的真实进度。反过来，如果字段仍是“未发布”，执行者又可能重复提交已经在审核中的稿件。

因此，真正需要管理的对象不是“文章是否发布”，而是：

一篇冻结文章，在一个明确的平台账号上的交付状态。

这也是我们后来把数据模型改成“文章 × 平台账号”的原因。

二、把平台进度建模成明确状态

我们最终保留了八个状态：

1. 未发布；
2. 平台草稿；
3. 已提交；
4. 审核中；
5. 已发布；
6. 已退回；
7. 发布失败；
8. 已取消。

这里最容易混淆的是“已提交”“审核中”和“已发布”。

已提交只证明平台接收了内容；审核中说明内容仍在平台流程里；只有获得公开页面或其他可核验结果，才能标记为已发布。我们要求已发布记录至少保存公开链接，或者保存平台后台能够核验的状态说明。没有公开链接的平台，也不能靠猜测补一个地址。

为了防止重复投稿，已提交、审核中和已发布三个状态都会阻止再次发布。同一篇文章与同一平叴账号之间还设置唯一约束，即使前端重复点击、网络重试或任务重复投递，也不能生成第二条交付记录。

这不是为了把流程做复杂，而是把原来散落在聊天记录、浏览器标签和个人记忆里的信息，变成所有人都能理解的产品状态。

三、API 发布与人工发布必须使用同一本账

多平台分发还有一个常见误区：把“智能体发布”理解成智能体控制浏览器，模拟人工填写所有平台。

浏览器操作可以帮助完成一次验证，但很难成为稳定的产品能力。验证码、滑块、登录过期、页面改版和不同电脑环境都会增加维护成本。更稳妥的顺序是：

1. 平台提供正式发布 API 时，优先走 API；
2. API 需要企业认证和 OAuth 时，先完成授权，再由发布任务执行；
3. 平台没有开放接口时，才进入人工渠道管理；
4. 无论执行方式是什么，结果都回到同一份文章渠道账本。

API 任务还需要幂等键。它相当于一次发布请求的唯一编号：任务超时后可以查询原请求结果，却不能不加判断地再发一次。对于会产生公开内容的外部写操作，系统还要保存请求摘要、平台返回的稿件号、公开链接、失败原因和执行时间。

人工发布也不能只写一句“已处理”。执行者应当选择真实状态，并填写平台稿件号、审核说明或公开链接。这样 API 渠道与人工渠道才能进入同一个项目视图，而不是形成两套互不相认的流程。

四、真实跑一遍后，状态模型暴露了哪些问题

在一次实际的多渠道验证中，我们登记了 23 个外部媒体渠道。截至本次盘点：14 个渠道已经形成公开内容，3 个已投稿等待编辑审核，4 个仍受账号注册或资质审核限制，2 个投稿被退回。

这组数字本身不是运营成绩，它更像一次产品可用性检查。过程中暴露了几个此前容易忽略的问题。

第一，旧数据不等于结构化数据。有些平台已经发布过内容，但信息只写在账号备注里，没有对应的文章交付记录。系统如果只查新表，就会把它显示成“从未发布”。正确做法不是批量改成成功，而是根据公开链接或平台后台证据逐条回填。

第二，注册成功不等于可发布。企业入驻、账号认证、开发者认证、应用审核和内容发布权限可能是不同的流程。产品界面必须说明当前卡在哪一层，而不是统一显示“审核中”。

第三，被退回不等于系统失败。平台给出的定位不匹配、内容深度不足或推广信息过重，都是下一轮选题和内容设计的输入。退回记录应当保留原因，同一稿件不应反复提交碰运气。

第四，文章状态必须按平台展示。只在账号页写“这个账号发过文章”，仍然无法判断某一篇具体文章是否已经投过。用户真正需要的是文章详情里的渠道矩阵，以及平台账号详情里的历史文章列表。

五、客户端应该怎样呈现

我们认为，一个可用的发布管理界面至少要回答四个问题：

• 这篇文章在哪些平台公开了？
• 哪些平台正在审核，不能重复提交？
• 哪些平台失败或被退回，下一步该做什么？
• 哪些平台具备 API 能力，可以交给发布任务执行？

因此，文章页适合使用“平台、账号、状态、稿件号、公开链接、更新时间、下一步”的列表，而不是把所有操作按钮挤在一张超宽表格里。默认视图只展示最重要的信息，详情再展开审核说明、失败原因和执行证据。

状态更新也需要即时反馈，但不应把提示长期塞在页面底部。短消息可以在当前窗口中央以半透明提示层显示，数秒后自动消失；真正需要用户处理的错误，则保留在对应任务或渠道记录里。

六、衡量发布产品，不能只看发了多少篇

当系统具备多平台发布能力后，最容易出现的新问题是追求“铺了多少渠道”。但发布数量并不能证明内容有效，更不能证明它影响了 AI 回答。

更有价值的产品指标包括：

• 渠道状态完整率：每次提交是否都有结果记录；
• 重复提交拦截率：系统阻止了多少次误操作；
• 发布成功率与平均审核时间；
• 退回原因的结构化分布；
• 公开链接与原始内容版本的对应关系；
• 发布前后是否使用同一组问题、平台和判定规则完成复测。

内容分发只是 GEO 工作流中的执行环节。只有把发布版本、渠道结果和后续复测连接起来，团队才能判断一次行动是否值得继续，而不是把“文章发出去了”当成项目完成。

结语

多平台发布看起来像一个自动化问题，真正落到产品上，它首先是一个状态与责任边界问题。

先明确一篇文章在一个账号上的真实状态，再决定由 API、发布任务还是人工执行；先阻止重复提交，再追求更多渠道；先保存可核验结果，再讨论自动化覆盖率。

当这些基础对象清楚以后，智能体才能成为可靠的执行者，而不是一个不断点击网页、却无法解释结果的黑盒。