用 OpenClaw + 飞书打造 AI-Native 博客运营系统

背景

运营博客对于我这个还在职的人来讲，什么都是麻烦事，不仅是写文章时的手足无措（即使有AI），而且将碎片化的知识或灵感记录下来也是非常棘手，我有非常多的想法都想着：“回去我要把这个写个博客”，但做起其他想做的事的时候，写博客这件事就迟迟不推进，到最后就不了了之了。这些事情说大不大，但特别消耗精力，而且一忙起来就忘了。

我一直在思考，能不能把这些内容创作的运营工作效率提高？让我只专注于创作本身，其他事情交给 AI 来处理。

最近用 OpenClaw + 飞书搭了一套 AI-Native 的内容创作方案，效果比预期好。这篇文章就是记录我是怎么做的，以及为什么选择这个组合。

为什么是 OpenClaw + 飞书

我的需求

对于博客的内容创作运营，我需要解决这几件事：

1. 信息监控 — 定时检查我关心的技术领域有没有新动态
2. 内容管理 — 写完文章后自动推送到博客仓库
3. 数据汇总 — 定期汇报博客的运营状况
4. 读者互动 — 及时收到读者的反馈和留言

现有方案的痛点

在搭这套方案之前，我试过几种不同的方式：

• 独立脚本 + Cron: 各种 Python 脚本分散在不同地方，管理成本高，而且缺乏统一的交互入口
• ChatGPT/Gemini API: 需要自己处理认证、消息路由、部署，成本和维护难度都上去了
• 自建 Agent 框架: 就是重新发明一个 Claude Code，工程量巨大

核心问题是：没有一个统一的入口来承载这些自动化任务。

OpenClaw 解决了什么

经过一段时间的探索，我发现了 OpenClaw。它本质上是一个 AI Agent 托管平台，解决了几个关键问题：

• 消息入口统一: 各种渠道（飞书、Discord、Telegram、WhatsApp）都能接入
• Agent 生命周期管理: 自动处理对话、记忆、心跳
• 工具生态: 内置了飞书文档、云盘、权限等 Skills，开箱即用
• 灵活部署: 可以自己托管，不用交”智商税”

换句话说，OpenClaw 帮我省掉了 80% 的基础设施工作，让我能专注在业务逻辑上。

为什么选飞书

原因很简单：它是我日常沟通的主力工具。

飞书的好处是：

• 文档能力强大，写 Blog 草稿可以直接在飞书里完成
• 机器人接入简单，消息收发都很自然
• 有开放的 API，文档、云盘、权限都能程序化了

再加上 OpenClaw 内置了飞书的 Skills，这组合几乎是顺理成章的。

整体架构

我的自动化方案核心是：飞书作为交互入口，OpenClaw 作为 Agent 的大脑，Git 作为知识存储。

┌─────────────┐      消息       ┌─────────────┐      调用      ┌─────────────┐
│   飞书      │ ◄─────────────► │  OpenClaw   │ ◄─────────────► │  博客仓库   │
│  (入口)     │                 │   (Agent)   │                 │  (内容存储)  │
└─────────────┘                 └─────────────┘                 └─────────────┘
       │                               │
       │                               ▼
       │                        ┌─────────────┐
       │                        │   飞书 API  │
       │                        │ (Doc/Drive) │
       │                        └─────────────┘
       │                               │
       ▼                               ▼
┌─────────────┐                 ┌─────────────┐
│  读者反馈   │                 │  运营数据   │
└─────────────┘                 └─────────────┘

模块划分

模块	职责	实现方式
消息入口	接收用户指令，返回结果	飞书机器人
Agent 核心	理解意图、规划任务、执行操作	OpenClaw
内容管理	博客文章的创建、推送、分支管理	Git + 飞书 Doc
定时任务	周期性检查和汇报	OpenClaw Heartbeat
知识管理	存储运营笔记、素材库	飞书云盘

核心场景实现

场景一：Heartbeat 自动检查

我在 OpenClaw 里配置了 Heartbeat，每隔一段时间自动跑一次检查：

• 读取飞书文档里整理的素材库
• 检查有没有需要处理的读者反馈
• 生成运营周报推送到飞书

# HEARTBEAT.md

## OKR Check
1. 读取 okr/current.md 检查当前进度
2. 生成周报推送到飞书

## 信息监控
- 搜索最新技术动态
- 更新素材库

这里的核心理念和 ResearcherZero 一样：Human in the loop。AI 做信息收集和整理，最终决策权在人手里。

场景二：文章创作流程

写一篇新博客的流程是这样的：

1. 在飞书里构思: 用飞书文档写草稿
2. 告诉 Agent 需求: “帮我把这篇文档整理成博客格式”
3. Agent 处理:
   • 读取飞书文档
   • 按 style-guide.md 的风格调整
   • 生成 Hexo 格式的 Markdown
   • 创建新分支、提交、推送到远程
4. 自动提 PR: 分支推送后自动生成 PR 链接

人类: 帮我把这篇 "关于 Context 设计的新思考" 发布到博客

Agent:
→ 读取飞书文档 "关于 Context 设计的新思考"
→ 按 style-guide.md 调整格式
→ 生成 source/_posts/arch-design-context-v2.md
→ git checkout -b feature/context-v2
→ git add . && git commit -m "feat: 添加 Context 设计 v2"
→ git push -u origin feature/context-v2
→ 已创建 PR: https://github.com/Tom-0727/xxx/pull/xxx

场景三：知识库联动

我还在飞书知识库里维护了一个素材库，包括：

• 读到一半的技术文章
• 还没消化的论文笔记
• 临时想到的写作灵感

当 Heartbeat 触发时，Agent 会：

1. 扫描素材库
2. 根据最近的写作方向筛选相关内容
3. 生成写作建议推给我

Git 工作流规范

为了保证协作顺畅，我定了几条简单的规则：

规则	说明
禁止直接 push main	所有修改必须走分支
分支命名	feature/文章标题 或 fix/问题描述
提交信息	使用 Conventional Commits 格式
PR 必须	合并前必须经过审核

这样即使是我自己用，也能保持良好的工程习惯。

总结

用 OpenClaw + 飞书搭了这套自动化方案后，我的博客运营体验提升了好几个档次：

• 创作更专注: 不用管发布流程，只管写
• 运营更持续: Heartbeat 保证了持续的信息监控
• 协作更规范: Git 分支 + PR 流程不会乱

不过这套方案还在迭代中。目前已经跑通了基础的发布流程，接下来想优化的地方是：

• 让 AI 更主动地生成写作建议
• 接入更多数据源（Twitter、GitHub Trending）
• 尝试用语音输入来触发任务

不追求一步到位，先让系统跑起来，再慢慢变强。

---

如果你也在用飞书，而且想给自己的博客整一套自动化运营方案，欢迎参考这个思路。有什么问题随时交流。