用 OpenClaw 打通公众号文章/个人网站自动发布

前几天晚上，我本来只想写一篇 1500 字的小文，结果真正耗时间的不是“写”，而是后面的机械动作：改格式、做封面、上传草稿、再搬到个人网站。等全部弄完，已经快凌晨了。

第二天我就给自己定了一个目标：文章可以慢慢打磨，但发布流程必须标准化。于是我把这件事拆成四段：自动写稿、自动封面、公众号草稿发布、个人网站同步。现在这条链路跑顺后，日更压力真的小了很多。

先说结论：自动化重点不是“替你思考”，是“替你搬砖”

很多人一听“自动写文章”，第一反应是担心质量。这个担心没错。我的做法不是把脑子交给 AI，而是把重复动作交给流程。选题、观点、案例，还是我来定；格式检查、封面生成、发布动作，交给工具做。

这套方法特别适合三类人：

• 写技术内容的开发者
• 要兼顾输出和交付的产品经理
• 想长期更新但总被发布细节拖住的内容创作者

第一步：把写作要求固化到任务文件

我用的是 /.openclaw/tasks/daily_wechat_article.md。这个文件不是随手写的 prompt，而是一份“可执行标准”。里面把关键约束都写死了，比如：

• 文章主题范围和风格（案例引入，再讲方法）
• front matter 必填字段（title、slug、date、summary 等）
• 输出路径固定为 articles/article-{slug}.md
• 文章索引 articles/00-moc-articles.md 要自动更新

这一步看起来普通，但它决定了后面是不是稳定。因为从“每次临时口述需求”变成了“每次执行同一份任务协议”。

第二步：封面不再手做，交给发布脚本

我原来最容易卡住的就是封面。现在流程里已经把这个步骤内置了：写完 Markdown 后，发布脚本会自动生成封面图，再上传微信素材。

我现在只盯两件事：

• 标题和摘要是否准确（它会直接影响封面提示词）
• 标签是否合理（会影响整体视觉方向）

这样做的好处很直接：不用再在“写完文章后”切换到另一个设计流程，写作注意力不会被打断。

第三步：公众号和个人网站用同一条主线串起来

很多人卡在“多平台发布”，本质是每个平台都单独操作。我这里是把两边串成同一条链路。

公众号这边，文章进入草稿箱后会带上 contentSourceUrl，指向个人网站文章地址。
网站这边，不是手工复制文章，而是用双仓触发自动同步：

• 在 yanxi-notes 的 .cnb.yml 里，只有 articles/article-*.md 变更才会触发下游构建
• 触发的是 yanxi-hugoplate 仓库的 api_trigger_ob_articles 事件
• Hugo 仓在 CI 里自动拉取 Obsidian 仓文章，rsync 到 content/cn/post/generated
• 然后构建站点、上传 COS、刷新 CDN

这意味着什么？
意味着你不再“发布两次”，而是“发布一次，自动分发两端”。

第四步：我现在的日常操作非常简单

现在我每天的发文动作基本只有这几步：

1. 在任务文件里补一句当天重点（比如选题方向）
2. 让 OpenClaw 生成文章草稿并落盘到 articles/
3. 快速人工校对：标题、开头、案例、结尾 CTA
4. 进入公众号草稿箱做最后审稿
5. 等站点流水线自动完成发布

真正省下来的，不只是 20 分钟，而是“上下文切换成本”。以前一篇文章要在写作、设计、发布、部署四种模式里反复切换；现在更多时间可以留给内容本身。

这套流程里最值得注意的三个细节

第一个，slug 要稳定。
一旦发布后再改 slug，会影响历史链接和搜索收录，最好第一次就定好。

第二个，front matter 一定规范。
你后面不管是做索引、做自动发布、还是做站点同步，都是靠这些字段驱动的。

第三个，不要追求“完全无人值守”。
我的经验是：机器负责 80% 重复动作，人负责 20% 判断和质感，这个比例最稳。

最后一句

如果你已经在写内容，但经常被发布流程拖住，建议别再继续优化“手工操作速度”，而是先搭一条最小可用流水线。你会很快发现，持续输出的关键不是意志力，而是流程设计。