很多人说“自动化社交媒体”，想到的只是定时发布和让AI写文案。
真正困难的是：只分发已经验证的内容、不重复发帖、把故障限制在单个账户、遇到CAPTCHA时不违规绕过、只把机器不能合法完成的步骤交给人，并根据真实阅读行为继续优化。
当系统覆盖多语言、多平台和邮件时，它已经不是定时器，而是一个小型分布式系统。
1. 目标不是“完全无人”，而是“人只处理例外”
CAPTCHA、短信验证、2FA、身份验证、明确同意、开发者应用审核，本来就是平台设置的人类边界，不应当被无限重试或技术绕过。
正常链路应当是：内容 → QA → 本地化 → 正式发布 → 线上readback → 分发候选 → 各语言文案 → 投递 → 数据回收 → 下一次判断。
如果某一个中文账户需要人工验证，就只暂停这个账户。其他语言、其他平台、邮件、分析和内容生产继续运行。
Cloudflare Workflows也支持持久化多步骤执行、自动重试以及等待外部事件或人工批准。[1] 关键思想是：等待人类是一种状态，不是系统总故障。
2. 把“文章存在”与“可以分发”分开
仓库里有Markdown，不等于读者已经能访问正确的页面。翻译完成和构建成功也不够。
内容身份可以定义为 articleId × locale × contentSha，投递身份再加入 platform × campaignType。
contentSha让同一个URL的不同revision能够区分开。
最可靠的分发入口是实际读取线上HTML：确认准确locale和准确revision已经公开，再创建SNS或邮件任务。
3. timeout不等于失败，否则会生出“双胞胎帖子”
发送API请求后客户端超时，可能是真的失败，也可能是provider已经成功发布，只是响应丢失。
此时盲目重试就可能重复发帖。
Cloudflare Queues默认采用at-least-once delivery，官方文档明确说明极少数情况下消息可能重复，并建议用unique ID或idempotency key进行去重。[2]
可以用 sha256(articleId + locale + contentSha + platform + campaignType) 生成确定性key，并在receipt中设置UNIQUE约束。
模糊超时后先查receipt，再尽可能read back provider状态，确认没有产生结果后才重试。
目标不是幻想“代码永远只执行一次”，而是即使执行多次，外部效果仍收敛为一次。
4. 把故障关在最小scope里
至少把failure domain拆到 platform × locale × account。
某个账户认证失效，只阻塞该账户；某个渠道429，只进入RETRY_WAIT；某个页面需要人工验证，只标记HUMAN_ACTION_REQUIRED。
状态可以使用READY、ACTIVE、DEGRADED_BUT_RUNNING、HUMAN_ACTION_REQUIRED、BLOCKED_PROVIDER、RETRY_WAIT、DISABLED_BY_POLICY。
429遵守Retry-After，5xx采用有上限的指数退避，401/403只走官方credential refresh。CAPTCHA不进入自动无限循环。
重复请求一百次，也不会把API变成人。
5. Human Handoff Queue必须是操作说明，不是“救命”
“社交媒体坏了，请检查”不是合格handoff。
每条人工任务应写明platform、locale、account、blocker、检测时间、打开URL、需要完成的动作、不要改什么、完成后系统如何readback，以及只会阻塞哪些scope。
例如：“登录该官方账户，只完成当前CAPTCHA。不要修改资料和发布设置。完成后，下一次自动巡检会重新验证认证状态，并从canary发布恢复。”
不使用CAPTCHA solver，也不伪装challenge。人工只接手机器本来就不应越过的边界。
密码、OAuth access/refresh token、session cookie、SMS/2FA code、recovery code和private API secret都不进入GitHub或普通日志。只保存public handle、state、sanitized error、receipt ID、public post URL等非秘密运行信息。
6. 自动发布不等于engagement bot
自动发布自己的文章，与自动点赞、自动关注、自动回复、自动私信不是一回事。
X在2026年4月更新的Automation Rules允许合规的信息型自动发布，但禁止绕过rate limit、用非API脚本自动操作X网站、垃圾和重复行为，并禁止自动点赞。[3]
因此初始策略可以只开启AUTO_PUBLISH，其他engagement动作保持关闭。
Bluesky官方API支持标准post record，也能设置langs语言metadata。[4] 对多语言系统来说，文章locale与帖子语言信息应该一致。
日常分发尽量走官方API和官方认证，不把逆向内部API变成长久在线链路。
一个实用的初始channel map可以是 ja→X、en→X/Bluesky、ko→X、zh-Hans→Weibo、zh-Hant→Facebook/Threads、es・pt-BR・id・th・vi・fr→Facebook、de→Facebook/X。Instagram、TikTok、Reels等图片/视频优先平台等自动media card生成与QA稳定后再进入第二阶段。真正实施时再次核对各平台最新API与Automation Policy。
7. 12种语言不是“把一条日文文案翻译11遍”
如果每个locale都有完整正文，SNS文案也应该阅读对应locale正文后独立生成。
风格可以很短：官方站点账号对自己的文章说一句自然的话，然后附URL。
不要使用“必看”“震惊”“现在就看”等广告味表达，也不要假装成独立读者写虚假体验。
品牌身份保持一致，但语言表达应自然。
医疗、法律、投资、大额金钱、灾难、犯罪、死亡、自伤、暴力、性侵、未成年人、安全、政治和选举、强烈冲突进入serious mode：默认不加emoji、不煽动、不做超出文章的断言，也不自动增加政治背书。
8. 邮件不是“把SNS搬进邮箱”，而是同一系统的另一个adapter
邮件订阅至少应记录explicit opt-in、locale、topics、consentAt、status、unsubscribeAt、createdAt，并防止同一文章反复发送。
客服回复邮箱与批量发送基础设施应逻辑分离。Reply-To可以保留人工支持地址，而发送provider可通过adapter替换。
Gmail对大量发送者强调认证、避免未请求邮件和便捷退订，subscription message同样把unsubscribe作为核心要求。[5][6]
退订后应立即从未来campaign资格中移除。
9. 如果优化“点赞”，系统最后就会学会讨点赞
文章站真正重要的指标更接近：
- site visit
- meaningful reading
- next article
- return visit
- newsletter signup
campaign可区分NEW、UPDATED、TRENDING、POPULAR、EVERGREEN。
一个错别字不值得触发UPDATED。POPULAR与TRENDING最好复用已有的一方阅读数据，不再制造第二套“热门榜”。
发布时间也应通过 locale × country × platform × weekday × hour 的真实表现逐步学习，而不是凭印象永久固定。
10. 实际使用方式：不是“发帖”，而是推进状态
完整流程是：准确locale revision上线 → production HTML readback → 生成投递identity → 阅读locale正文生成短文案 → policy与serious mode验证 → idempotency key入outbox → 官方API发送 → receipt与public readback → 归因阅读行为 → 下一轮campaign判断。
每个adapter先做一个canary：认证readback、dry run、1篇真实文章、receipt、公开帖子readback、语言检查、去重检查和analytics attribution。
确认后再扩大。
运营者应通过一个current-status入口看到整体状态，而不是手工翻十几个日志文件。
架构上也不要为了分发再造第二套内容工厂或第二scheduler。把它作为 PRODUCTION_VERIFIED之后的post-publication child 接在现有publication owner之后，并尽量复用已有durable runtime/state store。
好的自动化不是从不失败。
它是在失败时知道哪里坏了、只影响很小的范围、知道如何合法恢复、必要时只把那一个动作交给人，并在恢复后不重复副作用地继续运行。
删掉“发布”按钮只是序章。
真正的自动化连失败的那一天也一起设计。
资料来源
- Cloudflare — “Cloudflare Workflows” (updated 2026-09-18) Used for durable multi-step execution, automatic retries, persistent state, and waiting for external events or human approval. The article does not imply that a separate workflow or scheduler must be created when an existing stateful runtime already provides the needed function developers.cloudflare.com
- Cloudflare — “Delivery guarantees” (Cloudflare Queues, updated 2026-04-21) Used for the fact that Queues uses at-least-once delivery by default, rare duplicate delivery can occur, and unique IDs / idempotency keys are recommended when duplicate processing would create unintended effects developers.cloudflare.com
- X Help — “Automation rules” (updated 2026-04) Used for the distinction between compliant informational automated posts and prohibited behavior such as rate-limit circumvention, non-API website scripting, spam/duplicative use, and automated likes help.x.com
- Bluesky Protocol Services — “Creating a post” Used for official post creation, returned post identifiers, and language metadata through the langs field docs.bsky.app
- Gmail Help — “Email sender guidelines FAQ” Used for current high-volume sender requirements around authentication, unwanted mail, and easy unsubscribe support.google.com
- Gmail Help — “Learn about bulk email best practices” Used for explicit consent, clear sender identity, non-deceptive content, unsubscribe, and reasonable sending frequency support.google.com
