我们如何构建面向客户安全的发布工作流

大多数社交自动化之所以失败，是因为它们将“发布”视为全部工作。

对于客户工作而言，发布仅仅是最后一步。真正的核心在于决定哪些内容可以自动化，哪些内容需要人工审批。

在 Belac Media，我们为需要减轻运营压力的澳大利亚团队构建系统。我们的目标是在确保客户安全的同时，消除行政琐事。

我们不问可以安排多少条帖子。我们问的是：

• 哪些内容带有声誉风险？ • 哪些内容需要客户审批？ • 适用哪些平台规则？ • 哪些内容需要证明或证据？ • 哪些内容需要数字凭证？

风险等级决定了系统设计的逻辑。低风险的文章分享可以通过 API 完成；而受监管的产品则需要严格的审核关卡。

我们使用三种发布模式：

• Draft（草稿）：系统准备内容但不进行提交。
• Queue（队列）：内容已获批准，但在队列中等待最后的人工检查。
• Auto（自动）：通过预先批准的模板或规则直接发布。

这避免了将每个客户和平台都视为相同风险等级的错误。

如何选择工具：

• 对于其处理良好的社交渠道，使用像 Postiz 这样的调度器。 • 对于具有简单端点的平台，使用直接 API。 • 仅在平台封锁 API 访问时，才使用浏览器辅助。

浏览器自动化是脆弱的。如果平台会检测是否为真人，不要试图通过伪装成真人来构建你的整个业务流程。使用浏览器工具进行辅助起草，但将核心自动化保留在支持它的平台上。

每个脚本都必须留下凭证。凭证应包括：

• 源文件和客户名称 • 标题和平台 • 帖子或草稿 URL • 发布状态和时间戳 • Canonical URL

凭证可以防止混乱。如果平台接受了帖子但评论失败，凭证能帮你追踪发生了什么。它们还能防止在重试过程中产生重复帖子。

最后，保持内容的实用性。不要在空洞的推广帖子中生硬地插入客户链接。应将链接放在能为内容增值的地方。

我们的工作流遵循以下步骤：

1. 用 Markdown 起草源文章。
2. 添加标题、标签和 Canonical URL 等元数据。
3. 生成平台 payloads。
4. 在提交前进行 dry-run。
5. 默认以未发布的草稿形式提交。
6. 立即存储凭证。
7. 仅在规则允许时发布。

面向客户安全的发布，并不是为了让机器发布更多内容，而是为了让重复性任务变得可靠，并明确何时必须由人工介入。

Source: https://dev.to/thedoctorau/how-we-build-client-safe-publishing-workflows-2i82