夜雨聆风你是否有这样的困扰：
每天想给公众号读者推送有价值的 AI 资讯，但找内容、整理、写作、排版、发布——这一套流程走下来，半小时就没了。一天两天还好，日复一日，很难坚持。
最近我折腾出一套全自动工作流，可以每天自动抓取 AI 领域最值得看的信息，自动整理成中文摘要，自动推送到公众号草稿箱，我只需要点一下「发布」。整个过程不需要人工介入。
这篇文章，就是对这套工作流的完整复盘。
---
一、整体架构：五个模块组成的信息管道
我把整个流程拆成了五个模块：
1. 信息源聚合——抓取 Twitter/X 和播客中的 AI 开发者动态 2. 内容生成——AI 解读并翻译，整理成中文摘要 3. 格式转换——Markdown 格式转换为微信公众号支持的 HTML 4. 草稿推送——通过微信公众号 API 将文章推入草稿箱 5. 定时触发——每天早上 8 点自动运行
整个流程跑在云服务器上，由 OpenClaw Agent 统一调度。用户（也就是我）只需要在手机上收到推送通知后，确认发布即可。
---
二、信息源聚合：Twitter/X 与播客的双轨采集
做 AI 资讯类内容，最核心的问题就是：信息源从哪来？
我的方案是盯住「人」而不是盯住「媒体」。在 AI 这个领域，真正有价值的信息往往先从一小群核心开发者的 Twitter/X 和播客里流出来，而不是从新闻网站。
具体来说，我维护了一个 AI Builders 列表，核心成员包括：
- Anthropic 的工程师（Felix Rieseberg、Alex Albert 等） - 主流 VC 的 AI 方向合伙人（First Mark Capital 的 Matt Turck、YC 的 Garry Tan） - 头部 AI 产品的负责人（Replit 的 Amjad Masad、Box 的 Aaron Levie、Linear 的 Nan Yu）
每天这些人的 Twitter/X 动态和播客内容会被自动抓取，作为原材料输入后续流程。
为什么要同时看 Twitter 和播客？因为两者信息密度不同——Twitter 适合快速扫描热点，播客适合深度理解一个观点。两者结合，能在广度和深度之间取得平衡。
---
三、内容生成：大模型如何「消化」原材料？
原材料是英文的 Twitter 推文和播客内容，受众是中文读者。这里需要一个「翻译+摘要+润色」的过程。
这个过程由大模型完成，但并非简单翻译。我给模型的指令包含几个关键要求：
第一，全中文输出。 用户打开公众号，不需要看到英文。
第二，每条内容必须附带原始链接。 这是科普内容的基本规范，读者如果想深入了解，必须能直接跳转原文。
第三，保留关键术语的英文原词。 比如 MCP (Model Context Protocol)、Agent、RAG 这些词在中文语境下已经有固定用法，直接写英文反而更准确。
第四，给出有价值的「中文摘要」而不是机翻。 大模型要做的是理解和重组，把英文语境下的观点用中文重新表达出来，而不是逐字翻译。
这个环节的输入是一个结构化的 JSON，包含了所有抓取的内容、大模型需要遵循的提示词模板、以及用户的历史偏好设置。模型读取这些信息后，输出最终的中文摘要文本。
---
四、格式转换：Markdown 到微信公众号 HTML
微信公众号编辑器不支持标准的 Markdown，如果手动复制粘贴，格式会乱得一塌糊涂。
我的解决方案是写了一个格式转换脚本，在推送之前自动完成以下转换：
- 标题层级：`#` → `
`，`##` → `
`，`###` → `
` - 加粗：`文字` → `文字` - 链接提取：将「
🔗 原文链接
HTML 链接 - 段落处理：换行符自动转换为 `` 标签 - 末尾附加版权信息：标注内容来源公众号
转换后的 HTML 直接用于创建草稿箱文章，确保在手机端打开公众号后台时排版是正确的，不需要二次编辑。
---
五、草稿推送：微信公众号 API 的正确打开方式
这是整个流程中最容易出错的环节。微信公众平台的开发接口有一套严格的规范，稍有不慎就会踩坑。
第一个坑：IP 白名单。
微信公众号平台要求调用 API 的服务器 IP 必须在白名单里。但云服务器的出口 IP 往往是动态的，每次请求可能是不同的 IP。最简单的解法是把整个 IP 段加入白名单（如 39.102.0.0/16），或者为服务器绑定一个固定 EIP。
第二个坑：封面图的 media_id。
创建草稿时需要传入 `thumb_media_id`，这是封面图的唯一标识。但微信对素材类型有严格区分——通过临时素材接口（media/upload）上传的图片只能用于临时场景，不能用于草稿箱；必须通过永久素材接口（material/add_material）上传，才能获得有效的 media_id。
第三个坑：access_token 的有效期管理。
微信的 access_token 有效期是 2 小时，如果每次请求都重新获取，会触发频率限制。正确做法是本地缓存 token，在过期前自动刷新。
解决了这三个坑之后，推送就变成一个简单的 API 调用：把标题、作者、正文 HTML、封面 media_id 打包成 JSON，POST 到草稿箱接口，微信返回 media_id 表示创建成功。
整个过程从内容生成到草稿出现在公众号后台，不超过 30 秒。
---
六、定时触发：让机器替你守早晨
定时任务用的是 Linux 原生的 cron 工具，每天早上 8 点（北京时间）自动触发。
触发后，整个流程按顺序执行：信息抓取 → 内容生成 → 格式转换 → 草稿推送。全程无人值守，也不需要打开电脑。
执行完成后，公众号草稿箱里就会出现一篇排版好的文章，封面图、标题、正文、原始链接一应俱全。我只需要打开公众号后台，预览一下，确认没问题，点「发布」。
从每天花半小时，变成了每天花 30 秒。
---
七、这套工作流的核心价值是什么？
说了这么多技术细节，我想回到一个更根本的问题：这套自动化到底解决了什么问题？
首先，是「持续性」的问题。 一个人能坚持做一件事三天，靠意志力；能坚持三个月，需要习惯；能坚持三年，必须靠系统。当一个流程被自动化之后，「做下去」这件事本身就变得非常廉价。
其次，是「注意力」的问题。 每天找内容、翻译、整理，这个过程消耗的是一个人的注意力资源。把这些精力省下来，可以用在真正需要判断力的事情上——比如选哪个选题更有价值，比如写哪段话读者更容易理解。
第三，是「规模化」的可能性。 当一个流程被跑通之后，复制到其他领域几乎不需要额外成本。同样的架构，可以用来做科技资讯、跨境电商资讯、AI 产品评测——只需要换一套信息源和提示词模板。
---
八、未来的进化方向
目前这套工作流已经能稳定运行，但还有不少可以升级的地方：
多平台同步：现在只推送到微信公众号，未来可以扩展到微博、知乎专栏、少数派等多个平台，一次生成，多平台发布。
智能选题：目前是「所有内容都要」，未来可以加入评分机制，让 AI 自己判断哪些内容更值得进入摘要，实现真正的智能筛选。
互动数据反馈：发布后自动追踪阅读量、点赞、在看数据，把效果数据回传给 AI 作为后续选题的参考。
图文并茂：目前的封面图是 AI 生成的，未来可以让 AI 根据每篇文章的内容动态生成不同的配图，实现真正的千人千面。
---
结语
技术不是目的，解放注意力才是。
我用大模型、API 自动化和定时任务，搭建了一套每天早上自动运行的「AI 资讯 pipeline」。它让我在每天早晨睁开眼的那一刻，就能在公众号后台看到一篇已经排版好的文章，等待我点下「发布」。
这件事最有意思的地方在于：搭这套系统本身花了我大半天时间，但之后的每一天，它都在为我节省时间。复利效应非常明显。
如果你也在做内容创作类的工作，不妨思考一下：你的流程里，有哪些环节是机械重复的？这些环节，恰恰是最适合交给机器去做的。
把机器能做的工作交给机器，把真正需要人来做的事情——判断、选择、创造——留给自己。
这是我用一年多时间折腾各种 AI 工具下来，最重要的一条心得。
