English TL;DR: A robust auto-posting system is not “post on a timer.” It needs pacing rules, a quality gate, lightweight research/verification, reliable token refresh, and a daily reporting loop.
很多人做“自动发推”会走两种极端：
- 完全手动：内容质量高，但不可持续。
- 纯定时发布：可持续，但很容易变成低质噪音，反过来伤账号。
我的结论是：自动化应该服务于“高质量的稳定输出”，而不是“为了自动化而自动化”。
这篇文章讲我现在认为最靠谱的一套结构：你照着做，基本能得到一个“能长期跑”的自动发推系统。
0) 系统目标：把“发推”变成一个可控的工程系统
我把系统拆成 4 层：
- 选题层：今天发什么？为什么值得发？
- 质量闸门：不够好就不发（默认）。
- 节奏控制：日更 ≤2；间隔不是硬规则，但要有理由。
- 闭环层：每日 1 条运营日报，总结“发了什么/为什么/表现如何/明天选题池”。
重点是第 2 层：宁可少发，也不要发垃圾。
1) 节奏策略：不要把“6 小时”当成铁律
一个实用的节奏策略应该是“软约束 + 例外通道”：
- 默认：日更 ≤2。
- 通常：尽量间隔 ≥6h（减少用户疲劳 & 让你有时间做调研）。
- 例外：当内容价值明显更高（时效性强、信息密度高、可操作）时，允许加密。
这比写死“每 6 小时发一次”更像人。
2) 质量闸门：不够好就不发（默认策略）
我的质量闸门是一个简单的打分模型（你可以手动/脚本实现）：
- 信息密度：有没有具体结论/步骤/可复制的模板？
- 新颖度：是不是“大家都说过的废话”？
- 可验证性：关键事实有没有来源/数据点？
- 可执行性：读完能不能立刻做点什么？
- 一致性：是否符合账号主题（我这里主轴是 indie dev & AI）。
实操上，我通常要求发出去的内容至少满足：
- 有 1 个明确结论
- 有 1 个可复制的步骤/模板/命令
- 有 1 个“为什么”的解释（或一个链接来源）
如果做不到，直接 skip。
3) 轻量调研校验：用 2~5 分钟提高可信度
你不需要写论文式的 research，但至少做：
- 查 2 个不同来源，确认核心信息点没错。
- 如果引用版本/数字（比如“Next.js 16”），去看官方 changelog 或 release note。
- 如果是工具建议，至少自己跑一次命令确认能工作。
底线：不要转述未经验证的“二手结论”。
4) 工程实现要点（最容易踩坑的地方）
4.1 Token 续期
如果你用官方 API 发推，最容易炸的是：
- access token 过期 → 401
解决方式：
- 每次发推前检查 token 有效期
- 失败时自动 refresh，并把新 token 写回本地
4.2 幂等与冷却
即使你设置了“日更 ≤2”，也要加：
- cooldown：避免连续两次触发重复发。
- 幂等：同一个候选内容不要重复发。
4.3 失败重试 & 限流
- 限流时指数退避（1s/2s/4s/…）
- 不要无限重试
5) 每日运营日报：让系统对你透明
“自动化”的最大风险是：它在背后发生，而你失去控制感。
所以我强制要求系统每天产出一条日报：
- 今天发了几条（含链接或 tweet id）
- 为什么发（调研依据/判断点）
- 表现概览（如果能抓到：impressions/likes/retweets）
- 明天选题池（不发，只列候选）
这会让你保持“我掌控系统”的感觉。
6) 你可以怎么开始（最小可用版本）
如果你要快速上线 MVP：
- 每小时跑一次 cron（带随机抖动）
- 先生成候选 + 过质量闸门
- 通过则发布
- 每晚固定时间出日报
等你稳定运行 1~2 周，再考虑更复杂的：
- 更强的内容聚类
- 更完整的竞品/热点追踪
- 动态 A/B（不同结构/标题风格）
如果你也在做独立开发，我建议把“账号运营”当成产品的一部分：它不是玄学，是系统工程。
你也可以看看我博客里关于 SEO 的文章：
RELATED