AI 写完文章自动推公众号:我做了这套发布 skill,每次省 40 分钟

写完文章,还要手动排版、传图、调样式——这步每次都要花半小时以上。我做了一套 skill,让 AI 直接把写好的文章推到微信公众号草稿箱,图片自动上传、样式自动套用,一行命令搞定。

你在浪费多少时间在排版上

自媒体人最懂这种痛苦:文章写完了,最耗时间的不是写作,是发布。

微信公众号不支持外链图片,每张图都要手动上传。封面图要单独上传成永久素材。正文里的代码块、引用块、高亮段落,都要在编辑器里一个个调样式。最后还要加头部的星标提示、底部的关注引导二维码。

一篇文章,光发布就要 30-45 分钟。

我用的是 OpenClaw 搭建的 AI 内容创作工作流——从信息采集、写作、配图,到最后的发布,全部自动化。这篇分享其中发布这一步是怎么做的。

整体架构:两层分工

这套系统分两层:

article-writer 负责内容生产:从 X/Twitter 采集资讯、生成截图、AI 配图、写 Markdown 文章,所有素材存在本地目录。

wechat-article-publisher 负责发布:读取 article-writer 的产出,自动完成图片上传、HTML 渲染、草稿创建全流程。

AI自动发布流程图

整个发布流程只需要一行命令:

python3 scripts/publish.py --article-dir ~/Documents/openclawworkspace/articles/2026-03-07/主题/

执行完就能在公众号草稿箱看到排版好的文章,之后自己审核没问题就可以发布。

图片处理:全自动上传,不用手动一张张传

微信公众号最大的麻烦就是图片。它不认识 OSS 链接、不认识任何外链,所有图片必须是微信自己 CDN 的地址。

脚本的处理逻辑:

扫描文章目录里所有图片 → 逐个通过 upload-img 接口上传到微信 → 拿回微信 CDN URL → 替换 Markdown 里对应的图片链接。

上传过的图片会缓存在 meta.json 的 wechat_image_map 字段里,下次修改文章重新发布时,已上传的图片直接用缓存,不重复上传。

封面图走另一个接口(永久素材 add_material),会返回 media_id——这是创建草稿时微信要求的格式。

整个过程对你完全透明,只需要确保图片放在文章目录里,其余全自动。

图片上传缓存机制示意

渲染引擎:Markdown 变成微信 HTML

微信只认 HTML,不支持 Markdown,而且不支持 CSS class——所有样式必须内联写进每个标签里。

但我不想每次都手动写 HTML。所以渲染器做了一件事:把标准 Markdown 自动转成带完整内联样式的 HTML,同时识别我设计的「隐藏标签」,套用对应的定制样式区块。

隐藏标签是这样工作的——在 Markdown 里插入 HTML 注释:

这里是导读内容

渲染器看到这个注释,就会把里面的内容渲染成带蓝色左边框的导读框。在飞书、GitHub 等普通 Markdown 渲染器里,这些注释完全不可见,不影响阅读。

一套 Markdown,适配所有平台。飞书看是干净的文档,微信看是精美排版的文章。

隐藏标签渲染效果对比

目前支持的样式标签:蓝色导读框、加粗高亮句、圆角卡片列表、提示词代码卡片、蓝色总结区块、引导关注提示区块。

渲染器还会自动加 header 和 footer:header 包含星标提示、封面图、署名;footer 包含结尾标记、关注二维码。这些不需要写在文章 Markdown 里。

草稿管理:首次创建,后续自动更新

第一次发布,脚本创建新草稿,把返回的 media_id 写入 meta.json。

后续修改文章后重跑脚本,它检测到 meta.json 里有 media_id,自动走更新草稿接口,不会产生重复草稿。

草稿管理流程

三种模式:

  • 首次发布:创建新草稿,media_id 写入 meta.json,发微信预览通知
  • 修改更新:检测到 media_id 存在,自动更新草稿,不产生重复
  • 强制新建:加 --force-new 参数,忽略缓存,创建全新草稿

图文笔记另走一套流程

文章(长文)和图文笔记(以图片为主体的帖子)在微信里是两种完全不同的内容类型,必须走不同的接口。

这是我踩过的坑:一开始用同一个脚本发图文,结果微信把它创建成了文章类型,发出去格式完全乱掉。

原因在于:图文消息必须用永久素材接口上传所有图片,普通的 upload-img 接口只适合文章内图片。脚本层面区分后,两种内容类型都能正确创建对应格式的草稿。

图文和文章的发布接口区别

你需要手动做什么

这套自动化处理的是排版和上传,发布决策还是你自己来:

  1. AI 写完文章,自动触发发布脚本
  2. 脚本把文章推到草稿箱,微信发预览通知
  3. 你在公众号后台审核内容,确认没问题
  4. 点发布

步骤 1-2 全自动,步骤 3-4 由你决定。

总结

  • 一行命令发布:publish.py 完成图片上传、HTML 渲染、草稿创建全流程
  • 图片全自动处理:扫描目录 → 上传微信 CDN → 替换链接,带缓存不重复上传
  • 隐藏标签系统:6 种样式标签,一份 Markdown 适配多平台
  • 智能草稿管理:首次创建,后续自动更新,不产生重复草稿
  • 图文和文章分开:两种内容类型走不同接口,格式不会乱
  • 最后审核你来:内容发布决策始终在你手里

这套系统目前运行在我的 Ubuntu 服务器上,通过 OpenClaw 调度。AI 写完文章后自动推到草稿箱,我审核没问题就直接发。

如果你也在用 OpenClaw 搭建内容创作工作流,评论区交流。

参考链接

  • 微信公众平台开发文档:https://developers.weixin.qq.com/doc/offiaccount/Getting_Started/Overview.html
  • OpenClaw 官方文档:https://docs.openclaw.ai

Read more

ROS新手必看:5分钟搞定rqt工具箱核心插件配置(附无人机调试实战)

ROS实战:从零到一掌握rqt工具箱,打造你的机器人数据可视化中枢 如果你刚开始接触ROS,面对海量的节点、话题和消息数据,是不是感觉像在黑暗中摸索?命令行里的文本输出虽然精确,但缺乏直观性,调试一个简单的PID参数可能都要反复重启节点、查看日志,效率低下。这正是rqt工具箱设计的初衷——为ROS开发者提供一套基于Qt的图形化“瑞士军刀”,将复杂的数据流变成一目了然的图表和图形界面。 我记得第一次用rqt_plot可视化无人机角速度数据时,那种“原来如此”的顿悟感。不再需要去解析冗长的命令行数字,期望值与实际值的曲线对比直接在屏幕上展开,超调、震荡、响应延迟变得肉眼可见。rqt不仅仅是几个工具,它更像是一个可自由拼装的工作台,你可以把计算图、参数配置、数据曲线、日志信息全部整合在一个窗口里,形成专属的调试仪表盘。本文将带你超越基础的“点击操作”,深入理解rqt的插件化架构,并结合作者真实的无人机调试经验,展示如何高效配置核心插件,解决常见的“灰色加号”等棘手问题,最终让你能灵活运用rqt应对各种机器人开发场景。 1. 重新认识rqt:不止于工具集,而是可视化框架 很多人把rq

基于深度学习的无人机航拍小目标检测算法研究

基于深度学习的无人机航拍小目标检测算法研究

本项目针对无人机航拍场景下的小目标检测问题,基于 YOLO11 系列模型,在 VisDrone 2019 数据集上进行训练与优化,并提供了完整的检测系统桌面应用,支持图片、视频、摄像头的实时检测与训练指标可视化。 一、项目概述 无人机航拍图像具有目标尺度小、密集分布、多尺度混合等特点,传统检测算法难以取得理想效果。本项目采用 Ultralytics YOLO11 框架,结合 VisDrone 数据集进行训练,实现了对行人、车辆等 10 类交通相关目标的高效检测,并配套开发了基于 PyQt6 的桌面应用,便于模型验证与日常使用。 二、数据集 2.1 数据集简介 本项目使用 VisDrone 2019-DET 数据集,由天津大学机器学习与数据挖掘实验室 AISKYEYE 团队发布,对应 ICCV 2019 "Vision

用YOLOv12官版镜像做无人机巡检项目分享

用YOLOv12官版镜像做无人机巡检项目分享 在电力巡检一线干了五年,我见过太多这样的场景:飞手操控无人机绕着高压铁塔盘旋,屏幕里画面晃动、细节模糊,肉眼辨认绝缘子裂纹得反复放大三遍;后台算法团队却在抱怨——“模型跑不起来”,不是显存爆了就是推理卡顿,更别说在机载边缘盒子上实时运行。直到把整套系统换成 YOLOv12 官版镜像,整个流程变了:从起飞到识别缺陷,全程无需人工干预;单帧处理压到 2.4ms;连最老款的 Jetson Orin NX 都能稳稳跑满 30FPS。 这不是参数堆砌的纸上谈兵,而是我们刚在南方某省电网完成的实测项目。今天不讲论文、不列公式,就聊一件事:怎么用现成的 YOLOv12 镜像,把一套靠谱的无人机智能巡检系统真正跑通、落地、用起来。 1. 为什么是 YOLOv12?不是 v8、v10,也不是 RT-DETR 先说结论:它解决了无人机巡检中最痛的三个硬约束——低延迟、小体积、强鲁棒性。

机器人架构搭建核心准则:先论文论证,后工程落地

机器人架构搭建核心准则:先论文论证,后工程落地

原创声明:本文为原创技术干货,基于真实工程实践总结,未经授权严禁转载与篡改。 本文写给那些正在或将要主导机器人架构的技术决策者与一线工程师——无论你是CTO、架构师,还是嵌入式开发、算法工程师,只要你关心如何让机器人项目不再烂尾,这篇文章值得你读完。 注意:文中反复出现的“论文”,特指“工程论文”(区别于学术论文),是一份写给团队自己的工程蓝图。请务必读完第二部分的定义,再决定是否认同。 核心观点 在机器人架构设计与实施过程中,先完成系统性论文论证,再开展工程化架构落地,是保障项目可行、流程闭环、资源高效利用的核心前提,也是区分专业机器人架构师与无序开发的关键标准。 金句:先论文后落地,本质上是用确定性的逻辑推导,去对抗不确定性的物理世界。 一、行业普遍认知误区 当前机器人领域从业者普遍存在开发误区:直接跳过前期规划与逻辑论证,盲目开展硬件采购、框架搭建、代码开发与接口调试,将功能拼接等同于架构设计。这种模式缺乏顶层逻辑支撑与可行性验证,本质是无方向的盲目实施,也是多数机器人项目停滞、返工、烂尾的核心诱因。 这种开发就像农村自建房,凭感觉垒砖,从不考虑地质勘测和结构力学