我用Openclaw + Claude搭了一套自动写作系统,每天省3小时

我用Openclaw + Claude搭了一套自动写作系统,每天省3小时
这是我目前最重要的一套AI工作流。从信息获取到发布,几乎不用手动完成。

一、为什么我要搭建这套系统?

AI写作系统-痛点配图

信息过载的困境

如果你也在持续关注AI,应该会有同样的感受:

信息太多了。

每天打开 X、公众号、GitHub、技术社区,都会冒出大量新内容。
AI模型更新、工具更新、Agent框架、自动化方案……

想跟上这些信息,本身就已经是一项工作。

手动写作的低效循环

更别说:

  • 整理信息
  • 找选题
  • 写文章
  • 配图
  • 发布到各个平台

如果全部手动完成,写作就会变成一件非常消耗精力的事。

我一度也在这种状态里:

想持续输出,但写作本身占用了太多时间。

一个关键问题

后来我开始思考一个问题:

如果写作这件事可以被"系统化",会发生什么?

于是,我不再把AI当成写作工具。
而是开始搭一套完整的 AI写作工作流

二、思路转变:从优化写作到优化流程

大多数人的AI写作方式

大多数人使用AI写作,是这样:

打开AI → 输入一个prompt → 生成一段文字 

这确实能提高效率。
但很快会发现:

写作真正耗时的,并不是写那一段文字。

AI只帮你完成了10%

而是:

  • 去哪里获取信息
  • 如何整理素材
  • 如何形成选题
  • 如何组织结构
  • 如何配图
  • 如何发布到不同平台

如果这些步骤都靠手动完成:

AI只帮你完成了10%的工作

我的解决方案

所以我决定换一个思路:

不再优化"写一篇文章"
而是优化"整个写作流程"

我想搭一套:

从信息输入 → 写作 → 发布
能够自动运转的系统。

三、系统全貌:我的完整AI写作工作流

经过一段时间的搭建,我现在的写作流程大致变成了这样:

AI写作系统-完整流程图

整个流程已经基本打通。

现在我每天不再手动整理信息,
也很少从0开始写一篇文章。

更像是:

在一个已经准备好的系统中完成创作。

下面简单分享一下这套系统是如何运转的。

核心工具清单(文末有详细说明):OpenClaw (AI Agent 自动化中枢)Obsidian (知识库)Telegram (消息推送)bird CLI (Twitter数据)GitHub API (开源动态)Dajiala API (公众号监控)

四、核心环节拆解:五步实现自动化

第一步:让AI自动获取信息

写作的第一步,一直是最耗时间的:找信息

以前我需要:

  • 刷X
  • 看GitHub趋势
  • 看AI新闻
  • 收藏素材

这些操作每天重复,且非常碎片化。

现在我把这一步完全交给AI。

我对 OpenClaw 说:

"我想每天自动获取这些信息:Twitter/X 上的AI热点讨论GitHub 的今日热榜(24小时内高星项目)微信公众号(新智元、机器之心、量子位)的最新文章AI垂直网站(ai-bot.cn)的今日更新"

OpenClaw 做了什么:

它自己:

  • 安装了 bird CLI 工具(用我的浏览器Token抓取X数据)
  • 写了 fetch_github_direct.py(调用GitHub API)
  • 写了 fetch_wechat.sh(接入第三方公众号API)
  • 写了 fetch_aibot.py(爬取AI网站,还加了日期过滤)

我全程没写一行代码。

现在系统每天会自动收集:

  • AI行业动态
  • 热点讨论
  • GitHub趋势
  • 技术更新

然后统一汇总。

Pasted image 20260216212724

这一步完成后,我基本不再手动刷信息。
所有内容会自动进入下一环节。

第二步:生成每日AI日报与写作素材池

信息抓取只是第一层。

真正有用的是:把信息变成可以使用的素材

现在系统每天会自动完成:

  • 信息分类
  • 核心内容提取
  • 简要总结
  • 形成日报

我对 OpenClaw 说:

"每天早上9点,把这些信息整理成’卡片式日报’,分类展示:📚 公众号精选🔥 X 全网突发🚀 GitHub 黑马🧠 AI 行业动态"

OpenClaw 做了什么:

它设置了一个定时任务(Cron Job)

每天早上9点,自动:

  1. 执行所有抓取脚本
  2. 用AI解析和总结内容
  3. 生成格式化的日报
  4. 同时推送到两个地方:
    • Telegram(手机立即查看)
    • Obsidian(永久归档到笔记库)
Pasted image 20260216213216

最大的改变

写作不再从0开始

当我准备写一篇内容时,
已经有整理好的素材与结构参考。

写作从"构思"
变成了"加工"。

第三步:在 Obsidian 中用 AI 完成写作

我现在的写作中枢放在 Obsidian

所有日报、素材、想法都会自动进入这里,
形成一个持续积累的内容库。

素材库已经就绪

每天早上9点,OpenClaw 已经把整理好的日报:

  • 推送到 Telegram(即时查看)
  • 自动写入 Obsidian(永久归档)

我打开 Obsidian,素材已经躺在那里等我了。

我如何在 Obsidian 中写作:

这里我用的是 Claudian 插件(Claude 模型直接集成在 Obsidian 中)。

我对 Claude 说:

"基于今天日报中的’AI Agent 零代码实现’这个话题,帮我生成一篇公众号文章的初稿。

从我的素材库中调取相关案例,按照这个结构展开:为什么需要零代码我的实现过程实战案例工具清单"

Claude 在 Obsidian 中完成:

  • 检索我的素材库(已发布内容、金句库、案例库)
  • 生成结构化初稿
  • 自动引用相关笔记链接
  • 保持我的写作风格

写作角色的转变

在真正写文章时:

AI(Claude)会辅助完成:

  • 初稿生成
  • 结构整理
  • 内容扩展
  • 语言优化

而我只需要做一件事:

最后的思考与判断

写作从过去的"体力活",
变成了现在的"决策型工作"。

这也是我最明显的感受变化。

第四步:配图与多平台发布自动化

写完文章并不代表结束。

还需要:

  • 配图
  • 排版
  • 发布公众号
  • 同步小红书
  • 同步X

这些曾经是最耗时间的重复操作。

Pasted image 20260216213600

自动化实现

现在这一步也被逐渐自动化:

  • AI生成配图
  • 自动适配不同平台
  • 自动发布或半自动发布

闭环形成

于是,完整流程就形成了闭环:

信息输入 → 写作 → 发布 基本实现自动运转 

五、这套系统带来的改变

搭建这套AI写作工作流之后,
最大的变化不是写得更快。

而是:

写作变得稳定了

  • 过去写作靠情绪与时间
  • 现在写作靠系统

信息焦虑明显减少

  • 不再担心错过信息
  • 因为系统每天都在自动获取

输出不再依赖意志力

  • 只需要在系统里完成最后一步

某种程度上,这更像是:

给自己搭建了一支AI内容团队

结语:AI改变的是工作方式

在这个过程中,我逐渐意识到一件事:

AI真正改变的不是写作
而是一个人的工作方式

我现在做的,也不只是用AI写文章。

而是在搭一套:

属于自己的AI工作系统

它会随着时间不断迭代,
也会成为未来所有工作的基础设施。

Read more

OpenClaw 架构深度拆解:工程优雅的本地优先 AI Agent,为何难入企业级生产环境?

OpenClaw 架构深度拆解:工程优雅的本地优先 AI Agent,为何难入企业级生产环境?

2026 年,AI Agent 赛道早已从概念炒作进入工程化落地的深水区。无数项目沉迷于堆功能、炒概念,把 Agent 做成了花里胡哨的聊天玩具,却始终解决不了最核心的问题:执行不可靠、状态不可控、结果不可复现。而近期开源的 OpenClaw,却以一套极简、清晰、职责分离的分层架构,成为了业内公认的 “最干净的 Agent 运行时” 参考设计。 它以本地优先为核心理念,在工程层面做出了极佳的示范,解决了当前绝大多数 Agent 框架普遍存在的竞态 bug、上下文溢出、执行混乱等痛点;但与此同时,它的执行模型也带来了巨大的安全攻击面,在企业级场景的安全与治理上,存在致命的短板。 本文将从核心定位、五层架构全拆解、工程设计亮点、企业级安全短板、实践启示五个维度,深度解析这个本地优先的 AI Agent 系统,帮你吃透它的设计精髓,同时规避落地过程中的安全风险。 一、OpenClaw 的核心定位:

By Ne0inhk
RUST异步微服务架构的最佳实践与常见反模式

RUST异步微服务架构的最佳实践与常见反模式

RUST异步微服务架构的最佳实践与常见反模式 一、项目优化前的问题分析 1.1 任务调度不合理 💡在第21篇项目中,用户同步服务的任务调度使用了Cron调度器,但Cron调度器的精度有限,可能导致任务执行延迟。此外,任务的并发度没有配置,可能导致任务积压。 1.2 I/O资源限制不足 订单处理服务的TCP连接队列大小没有配置,可能导致连接失败。数据库连接池的大小没有配置,可能导致数据库连接耗尽。 1.3 同步原语使用不当 实时监控服务中,Redis连接没有使用连接池,可能导致连接开销过大。任务结果的处理没有使用批量操作,可能导致上下文切换过多。 1.4 错误处理不完善 任务失败的处理逻辑不够完善,没有进行任务重试和错误统计。服务之间的通信没有进行超时管理和错误处理。 二、异步架构设计模式的应用 2.1 命令查询分离(CQS) CQS是一种架构设计模式,将系统的操作分为命令和查询两种类型。命令用于修改系统状态,查询用于获取系统状态,两者互不干扰。 在项目中,我们可以将用户同步任务视为命令操作,将系统状态查询视为查询操作: // 用户同步任务(

By Ne0inhk
掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

🔥我的主页:九转苍翎⭐️个人专栏:《Java SE》《Java集合框架系统精讲》《MySQL高手之路:从基础到高阶》《计算机网络》《Java工程师核心能力体系构建》《RabbitMQ理论与实践》天行健,君子以自强不息。 1.事务 AMQP(高级消息队列协议)实现了事务机制,主要用于确保消息的原子性发布和确认。换言之,它允许你将多个操作(如发送消息、确认消息)绑定在一起,要么全部成功,要么全部失败 发送消息 @RestController@RequestMapping("/producer")publicclassProducerController{@Resource(name ="transRabbitTemplate")privateRabbitTemplate transRabbitTemplate;@Transactional@RequestMapping("/trans")publicStringtrans(){ transRabbitTemplate.convertAndSend(""

By Ne0inhk
Spring Boot 实战:MyBatis 操作数据库(上)

Spring Boot 实战:MyBatis 操作数据库(上)

—JavaEE专栏— Spring Boot 实战:MyBatis 操作数据库(上) 摘要 本文深度解析了 Spring Boot 环境下 MyBatis 的集成与应用。通过回顾传统 JDBC 的局限性,详细展示了 MyBatis 在日志配置、CRUD 操作、自增主键返回及多表查询中的实战用法。同时,文章深入探讨了 #{} 与 ${} 的底层预编译差异及安全风险,并分享了企业级开发中的数据库命名规范与 Druid 连接池配置,助力开发者构建稳健的持久层架构。 文章目录 * Spring Boot 实战:MyBatis 操作数据库(上) * 摘要 * @[toc] * 1. 为什么持久层开发需要 MyBatis? * 1.1 传统 JDBC 的局限性 * 1.2

By Ne0inhk