我用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

【2025保姆级】Open-WebUI五大功能区首曝!第一篇:管理员面板深度拆解,手把手讲解&配置AI管理中枢

【2025保姆级】Open-WebUI五大功能区首曝!第一篇:管理员面板深度拆解,手把手讲解&配置AI管理中枢

【2025保姆级】Open-WebUI五大功能区首曝!第一篇:管理员面板深度拆解,手把手讲解&配置AI管理中枢 * 一、引言 * 二、用户 * 2.1 概述 * 2.2 权限组 * 三、竞技场评估 * 四、函数 * 五、设置 * 5.1 通用 * 5.1.1 身份验证 * 5.1.2 功能 * 5.2 外部连接 * 5.2.1 OpenAI API * 5.2.2 Ollama API * 5.2.3

By Ne0inhk
用Coze打造你的专属AI应用:从智能体到Web部署指南

用Coze打造你的专属AI应用:从智能体到Web部署指南

文章目录 * 一、Coze简介 * 1.1 什么是Coze? * 1.2 核心概念 * 二、Coze产品生态 * 三、智能体开发基础 * 四、Coze资源 * 4.1 插件 * 4.2 扣子知识库 * 4.3 数据库资源 * 五、工作流开发与发布 * 六、应用开发与发布 * 七、Coze的API与SDK * 八、实战案例 一、Coze简介 1.1 什么是Coze? Coze 是字节跳动开发的 AI Agent 平台,作为一款人工智能开发工具,它可以帮助开发者通过低代码甚至零代码的方式快速构建应用程序。此外还提供了相关的API和SDK,可以集成到我们自己开发的项目业务中。 1.2 核心概念 * 智能体:

By Ne0inhk
Flutter 组件 spry 适配鸿蒙 HarmonyOS 实战:轻量化 Web 框架,构建高性能端侧微服务与 Middleware 治理架构

Flutter 组件 spry 适配鸿蒙 HarmonyOS 实战:轻量化 Web 框架,构建高性能端侧微服务与 Middleware 治理架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 spry 适配鸿蒙 HarmonyOS 实战:轻量化 Web 框架,构建高性能端侧微服务与 Middleware 治理架构 前言 在鸿蒙(OpenHarmony)生态迈向全场景分布式协同、涉及设备端侧 API 暴露、轻量化资源服务镜像及严苛的跨端 RPC 通信背景下,如何实现一套既能保持极低内存足迹(Footprint)、又能提供类似后端(Node.js/Koa)般丝滑开发体验且具备全异步处理能力的“端侧 Web 基座”,已成为决定应用分布式自治能力与全栈同构效率的关键。在鸿蒙设备这类强调 AOT 极致效能与背景任务严格限制的环境下,如果应用依然采用重量级的 HTTP 服务端,由于由于进程级的上下文切换开销,极易由于由于“算力溢出”导致鸿蒙应用在作为服务端响应时发生明显的电量损耗。 我们需要一种能够解耦路由逻辑、支持

By Ne0inhk

10、Vue3中Vuex从入门到实战:手写迷你Vuex,掌握前端状态管理核心

Vue3中Vuex从入门到实战:手写迷你Vuex,掌握前端状态管理核心 在Vue3项目开发中,组件化让代码复用和维护更高效,但跨组件、跨页面的数据共享却成了高频痛点——用户登录信息、全局权限、公共计数器等数据,如果靠组件传参层层传递,代码会变得混乱不堪。这时候,Vuex就成了前端状态管理的“大管家”,帮我们集中式管理共享数据。本文将从前端数据管理的痛点出发,带你吃透Vuex的核心用法,甚至手写一个迷你Vuex理解其底层原理。 一、前端数据管理:为什么需要Vuex? 现代Web应用由组件、数据、路由三大核心构成,组件内部的私有数据用ref/reactive管理即可,但共享数据的管理却需要更规范的方式。 我们先试想一个简单场景:用全局变量存储共享数据。 window._store ={}// 全局存储数据 这种方式看似简单,但存在致命问题:window._store不是响应式的,修改数据后Vue组件无法自动更新视图。如果我们用Vue的响应式API包裹全局数据,并提供统一的修改方法,这就是Vuex的雏形——本质是“响应式的全局数据 + 规范化的修改规则”。 二、Vuex是什

By Ne0inhk