基于Obsidian与GitHub Actions构建自动化内容工作流-三亩地-编程学习日记

1. 项目概述：从混沌到秩序的内容创作革命

如果你和我一样，每天被“今天写什么”、“素材在哪”、“排版怎么又乱了”这些问题反复折磨，那你一定懂那种内容创作的无力感。我做了十多年博主，从科技评测到生活分享，几乎踩遍了所有坑。最头疼的不是写不出来，而是整个创作过程像一团乱麻——灵感散落在十几个App里，草稿躺在不同设备上，发布前还要手动同步到五六个平台，一套流程下来，精力耗去大半，创作的热情早就磨没了。

“Openclaw创建内容工作流”这个项目，就是我为了终结这种混乱而发起的一次系统性自救。它不是一个现成的软件，而是一套基于开源与自动化工具，将内容创作的“灵感捕捉 → 素材整理 → 内容生产 → 多平台发布 → 数据分析”全链路打通的个人化系统。你可以把它理解为你专属的、高度可定制的“数字内容工厂”。核心目标就一个：把创作者从重复、琐碎的机械劳动中解放出来，让我们能更专注在真正的思考与表达上。

这套工作流尤其适合独立创作者、知识博主、小型团队以及任何需要持续产出高质量数字内容的人。无论你是写公众号文章、做小红书图文、录制播客还是制作视频，其底层逻辑——标准化、自动化、资产化——都是相通的。接下来，我就把这套折腾了无数个日夜，最终稳定运行了两年多的系统，从设计思路到每个螺丝钉的安装，毫无保留地拆解给你。

2. 核心设计哲学：为什么是“Openclaw”？

在动手搭建任何系统之前，想清楚“为什么”比“怎么做”更重要。我将其命名为“Openclaw”（开放之爪），寓意是希望这套系统能像灵活的爪子一样，牢牢抓取创作过程中的各种元素，同时保持“开放”的本质。

2.1 对抗数字碎片化：统一你的创作战场

我们面临的第一个敌人是“数字碎片化”。你的灵感可能在手机的便签里，参考文章在浏览器的上百个标签页中，图片素材在电脑的“下载”文件夹深处，而文稿又在石墨文档或Notion里。这种状态导致每次创作都要进行一次“全盘搜索”，效率极低。

Openclaw工作流的第一步，就是建立一个统一的、中心化的信息仓库。所有输入，无论来源，都必须流向这个仓库。这就像为你的思维修建一个专属水库，所有雨水（灵感）都必须通过管道汇集于此，而不是任由其散落蒸发。我选择用Obsidian作为这个核心仓库，因为它基于本地Markdown文件，所有权完全在自己手里，并且其“双向链接”和“知识图谱”功能，能让零散的灵感自动产生关联，孕育出意想不到的新想法。

2.2 拥抱自动化：让机器处理重复劳动

第二个核心是自动化。内容创作中有大量重复动作：将文稿同步到博客后台、转换格式发布到其他平台、下载封面图并压缩、在发布后自动推送到社交媒体……这些工作不值得消耗你宝贵的心智带宽。

Openclaw工作流大量使用GitHub Actions、IFTTT、Zapier以及Python脚本来实现自动化。例如，当我完成一篇Markdown文稿并推送到GitHub仓库后，自动化流程可以：1）自动构建静态网站并部署；2）自动将文章摘要和链接发布到Twitter和Telegram频道；3）自动备份文稿到另一个云存储。你的角色从“操作工”转变为“监工”和“设计师”，只需设定好规则，剩下的交给机器。

2.3 资产化思维：让每一份创作都产生复利

很多人把内容当作一次性的“产品”，发布后就束之高阁。而资产化思维要求我们把内容看作可重复利用、可增值的“资产”。一篇深度文章可以拆解成多条微博、一张信息图、一段播客素材；一个核心观点可以在未来的多篇文章中被引用和深化。

Openclaw工作流通过结构化标签和双向链接来实现资产化管理。在Obsidian中，我会为每篇笔记打上诸如#公众号文章、#素材-案例、#观点-数字化转型这样的标签。未来当我想写关于“数字化转型”的文章时，我可以通过一个简单的搜索，瞬间找到所有相关的过往文章、案例素材和零星想法。这极大地提升了创作效率和质量，真正实现了“知识复利”。

3. 工作流核心架构与工具选型

一套稳定的工作流离不开合理的架构和趁手的工具。我的Openclaw系统主要由五个核心模块组成，下图清晰地展示了信息与任务在这些模块间的流动路径：

flowchart TD A[“输入层<br>灵感捕获”] --> B[“核心仓库<br>Obsidian管理”] B --> C[“加工层<br>内容生产”] C --> D[“输出层<br>多平台发布”] D --> E[“反馈层<br>数据分析”] subgraph A [输入层] A1[闪念胶囊] --> A2[网页剪辑] A3[微信收藏] --> A2 A2 --> B end subgraph B [核心仓库] B1[“Inbox（收件箱）”] --> B2[“整理与关联”] B2 --> B3[“知识图谱形成”] end subgraph C [加工层] C1[“Markdown写作”] --> C2[“素材嵌入<br>（图/表/代码）”] C2 --> C3[“初稿完成”] end subgraph D [输出层] C3 --> D1[“自动化部署<br>（GitHub Actions）”] D1 --> D2[“主站发布<br>（静态博客）”] D2 --> D3[“社交平台同步<br>（IFTTT/Zapier）”] end subgraph E [反馈层] D2 --> E1[“数据统计<br>（Google Analytics/Umami）”] E1 --> E2[“反馈整理<br>（评论/邮件归集）”] E2 --> B1[“回流至核心仓库”] end

下面，我们来逐一拆解每个环节的工具选择与设计理由。

3.1 输入与捕获：打造无处不在的灵感漏斗

目标是建立一个低摩擦、全场景的输入系统，确保任何灵感在消失前都能被迅速捕获。

核心工具：Flomo + Omnivore
- Flomo（浮墨笔记）：这是我的“闪念胶囊”。它的微信输入、快捷指令（iOS）、浏览器插件等多端入口，让我能在任何场景下，用一句话或一段语音快速记录想法。我给自己定的规矩是：记录时间不超过30秒。Flomo的每日回顾和随机漫步功能，能很好地帮助激活过去的碎片灵感。
- Omnivore：开源免费的“稍后读”和网页剪辑神器。当我浏览到有价值的文章、报道时，一键保存到Omnivore。它的高亮和批注功能非常出色，所有标注都会自动同步，并可以导出为Markdown，直接成为我的写作素材。
- 微信传输助手：作为一个临时中转站。在手机上看到图片、文字，来不及处理，先丢进“文件传输助手”，电脑端登录微信后统一处理。

实操心得：千万不要在捕获阶段追求完美格式。很多灵感死于“等我打开电脑好好写”。先完整地记下来，哪怕只有关键词，整理是后面阶段的事。

3.2 核心仓库与知识管理：构建你的数字大脑

这是工作流的心脏，所有信息在这里沉淀、关联、发酵。

核心工具：Obsidian
- 为什么是Obsidian？首先，它基于本地Markdown文件，数据完全由自己掌控，没有厂商锁定的风险。其次，它的双向链接和知识图谱是革命性的。当你创建[[数字化转型]]这样的链接时，不仅链向了目标笔记，目标笔记也会显示所有引用它的笔记，从而自动形成知识网络。
- 文件夹结构设计：
```
My-Obsidian-Vault/ ├── 0-Inbox/ # 收件箱，临时存放所有捕获的内容 ├── 1-Projects/ # 进行中的创作项目 ├── 2-Areas/ # 持续关注的领域（如“自媒体运营”、“编程”） ├── 3-Resources/ # 永久资源（如“好用工具清单”、“金句库”） ├── 4-Archives/ # 已完成项目的归档 └── 9-Templates/ # 各类模板（文章模板、视频脚本模板等）
```
- 核心插件推荐：
  - Dataview：让笔记变成数据库。你可以用查询语句自动列出所有带#待发布标签的文章，或统计本月创作数量。
  - Templater：定义自动化模板。我的“公众号文章模板”会自动生成包含标题、Front-Matter（元数据）、固定章节结构的文档。
  - QuickAdd：快速收集和创建笔记，与Flomo等工具联动，实现一键入库。

3.3 加工与生产：从素材到成品的流水线

这是将仓库中的“原材料”加工为“成品”的阶段。

写作与排版：坚持使用Markdown。它纯文本、格式简单、与平台无关。在Obsidian中写作，能实时看到双向链接的上下文，激发新思路。对于需要精美排版的公众号，我使用Markdown Nice这类工具将Markdown一键转换为美观的微信排版。
素材处理：
- 图片：使用Snipaste进行截图和贴图标注；用Squoosh或TinyPNG进行无损压缩；用Photopea（在线PS）进行简单的裁剪、调色。
- 图表：技术架构图、流程图使用Draw.io（集成在Obsidian中），数据图表用Obsidian的Advanced Tables插件或导出Excel数据后生成。
版本控制：整个Obsidian仓库通过Git进行版本管理，并托管在私有GitHub仓库中。这不仅是备份，更能清晰地看到每篇文章的修改历史和写作脉络。

3.4 发布与分发：一键触达多平台的自动化枢纽

这是自动化大显身手的环节，目标是“一次编写，多处发布”。

核心平台（主站）：我选择Hugo生成静态博客，托管在Vercel上。原因是免费、速度快、完全可控。Hugo能完美渲染Obsidian中的Markdown笔记（需注意双链语法转换）。
自动化部署流水线：
1. 我在Obsidian中完成文章，保存到1-Projects/Blog目录。
2. 使用Obsidian的Git插件，提交更改并推送到GitHub。
3. GitHub Actions被触发，自动执行以下操作：
  - 将文章从Obsidian格式转换为标准Hugo文章格式（一个Python脚本完成）。
  - 运行Hugo构建静态网站。
  - 将构建好的文件部署到Vercel。
4. 几分钟后，文章就在我的主站上线了。
多平台同步：
- 公众号：通过浏览器插件，将主站文章页面一键抓取到公众号编辑器，微调后发布。
- 社交媒体：使用IFTTT或Zapier。创建Applet：当我的主站RSS Feed有新条目时，自动提取标题和链接，发布到Twitter和Telegram频道。
- Newsletter：使用ConvertKit或Revue，同样通过RSS自动抓取最新博文，发送给订阅者。

避坑指南：自动化同步到社交媒体时，务必添加平台特定的标签（如#Tech、#Blogging），并定制一下推送文案，避免生硬的“新文章：《XXX》已发布”这种格式，互动率会更高。

3.5 反馈与优化：闭合循环的数据驱动

发布不是终点，而是下一个循环的起点。需要收集反馈来优化内容。

数据分析：在主站集成Umami（开源、隐私友好的分析工具）或Google Analytics，关注页面浏览量、访客来源、阅读时长等。
反馈归集：将博客评论（通过Giscus，基于GitHub Discussions）、社交媒体评论、读者邮件等，有选择地整理回Obsidian的对应文章笔记下，作为后续修改或写作新文章的素材。
定期回顾：每周或每月，利用Obsidian的查询功能，回顾发布数据好的文章和反馈多的文章，分析其共同点，总结成“高流量内容 checklist”，指导未来的选题和写作。

4. 关键配置与实操步骤详解

理论讲完，我们来点实在的。下面以“从Obsidian写作到自动发布到静态博客”这个最核心的流程为例，展示关键配置。

4.1 环境准备与工具链安装

安装Obsidian并创建仓库：从官网下载安装，新建一个文件夹作为你的知识库。建议初始就启用“核心插件”中的“模板”和“大纲”。
安装并配置Git：在电脑上安装Git。在Obsidian仓库根目录打开终端，执行git init初始化仓库。然后去GitHub创建一个新的私有仓库，将其添加为远程仓库。
```
git remote add origin https://github.com/你的用户名/你的仓库名.git
```
安装Node.js和Hugo：Hugo是基于Go的，但通常通过npm安装很方便。确保系统已安装Node.js，然后通过命令行安装Hugo（扩展版本）。
```
npm install -g hugo-extended
```
创建Hugo站点：在你喜欢的位置，运行hugo new site myblog创建一个新的Hugo站点。然后选择一个主题（如Stack），按照主题文档进行基本配置。

4.2 Obsidian与Hugo的协同配置

这是最关键的一步，需要让两者和谐共处。

在Obsidian仓库中规划文章目录：我在1-Projects/下创建Blog文件夹，所有待发布和已发布的博客文章草稿都放在这里。

创建文章模板：在Obsidian的9-Templates/下创建Blog-Post.md模板，内容如下：

--- title: "{{title}}" date: {{date:YYYY-MM-DD}}T{{time:HH:mm:ss}}+08:00 draft: true # 初稿时为true，完成准备发布时改为false tags: [] categories: [] --- # {{title}} <!-- 这里是正文开始 -->

这个Front-Matter（两个---之间的部分）是Hugo用来识别文章元数据的。

配置Obsidian Git插件：安装社区插件“Obsidian Git”，设置自动拉取、推送和备份的时间间隔（如每30分钟）。这是实现自动化的基础。

编写格式转换脚本：由于Obsidian的双向链接语法[[ ]]与Hugo不兼容，需要转换。在仓库根目录创建一个Python脚本convert.py：

import os import re import shutil from datetime import datetime def convert_obsidian_to_hugo(obsidian_path, hugo_content_path): for root, dirs, files in os.walk(obsidian_path): for file in files: if file.endswith('.md'): obsidian_file_path = os.path.join(root, file) # 读取Obsidian文件内容 with open(obsidian_file_path, 'r', encoding='utf-8') as f: content = f.read() # 转换1: 将Obsidian双链 [[目标]] 转换为Hugo短码或普通链接 # 这里简单转换为普通链接，复杂情况可用短码 content = re.sub(r'\[\[([^\]]+)\]\]', r'[\1](\1)', content) # 转换2: 处理标签 #tag 为Hugo格式（如果需要） # Hugo通常用Front-Matter的tags字段，这里可忽略或移除行内标签 # content = re.sub(r'\s#([a-zA-Z0-9_]+)', '', content) # 移除行内标签 # 确定Hugo中的目标路径和文件名 # 例如，将文件复制到hugo的content/posts目录下，保持同名 relative_path = os.path.relpath(obsidian_file_path, obsidian_path) hugo_file_path = os.path.join(hugo_content_path, 'posts', relative_path) # 确保目标目录存在 os.makedirs(os.path.dirname(hugo_file_path), exist_ok=True) # 写入转换后的内容到Hugo目录 with open(hugo_file_path, 'w', encoding='utf-8') as f: f.write(content) print(f"Converted: {obsidian_file_path} -> {hugo_file_path}") if __name__ == "__main__": # 你的Obsidian博客文章目录 OBSIDIAN_BLOG_PATH = "/path/to/your/Obsidian/Vault/1-Projects/Blog" # 你的Hugo站点content目录 HUGO_CONTENT_PATH = "/path/to/your/hugo/site" convert_obsidian_to_hugo(OBSIDIAN_BLOG_PATH, HUGO_CONTENT_PATH)

注意：这是一个基础示例。实际应用中，你可能需要处理更复杂的双链情况（如带别名[[目标|别名]]）、嵌入图片路径转换等。建议先在小范围测试。

4.3 构建自动化部署流水线（GitHub Actions）

在Hugo站点的仓库（不是Obsidian仓库）中，创建.github/workflows/deploy.yml文件：

name: Deploy Hugo Site to Vercel on: push: branches: [ main ] # 当主分支有推送时触发 workflow_dispatch: # 允许手动触发 jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Checkout Code uses: actions/checkout@v3 with: submodules: recursive # 如果主题是子模块，需要这个 fetch-depth: 0 - name: Setup Hugo uses: peaceiris/actions-hugo@v2 with: hugo-version: 'latest' extended: true - name: Run Conversion Script (Optional) run: | # 这里可以放置从Obsidian仓库拉取文章并运行转换脚本的命令 # 例如，如果你的转换脚本和文章在同一个仓库的特定目录 python scripts/convert.py # 注意：更常见的做法是，Obsidian通过Git推送到一个“源”分支， # 然后这个Action从“源”分支获取文件，转换后构建。 # 这里假设转换后的Markdown文件已经存在于当前仓库的content/posts目录。 - name: Build Hugo Site run: hugo --minify - name: Deploy to Vercel uses: amondnet/vercel-action@v20 with: vercel-token: ${{ secrets.VERCEL_TOKEN }} # 需要在GitHub仓库Settings中设置此Secret vercel-org-id: ${{ secrets.VERCEL_ORG_ID }} vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }} working-directory: ./ vercel-args: '--prod' # 部署到生产环境

这个工作流实现了：代码推送 → 自动安装Hugo → （可选）转换文章格式 → 构建静态网站 → 部署到Vercel。

你需要先在Vercel上关联你的GitHub仓库项目，然后在GitHub仓库的Settings -> Secrets中配置VERCEL_TOKEN、VERCEL_ORG_ID和VERCEL_PROJECT_ID。

4.4 发布流程的SOP（标准作业程序）

当一切就绪，你的日常发布流程将变得极其简单：

写作：在Obsidian的1-Projects/Blog下，用模板新建笔记，开始写作。插入图片时，直接粘贴到笔记同名的附件文件夹（Obsidian自动管理）。
定稿：文章写完，检查无误后，将Front-Matter中的draft: true改为draft: false。
提交：在Obsidian中，使用Git插件，填写提交信息（如“发布文章：Openclaw工作流详解”），然后点击推送。
触发自动化：推送操作同步到GitHub，触发GitHub Actions工作流。
等待与验证：大约2-5分钟后，打开你的Vercel站点域名，刷新即可看到新文章。同时，你设定的IFTTT等自动化工具会将新文章通知同步到社交媒体。

至此，一个从本地写作到全球发布的自动化闭环就完成了。你只需专注于第一步的创作。

5. 常见问题与故障排查实录

在搭建和运行这套系统的过程中，我遇到了不少坑。这里把典型问题和解决方案记录下来，希望能帮你节省时间。

5.1 图片路径问题

问题：在Obsidian中插入的图片，发布到Hugo后无法显示。
原因：Obsidian支持相对路径和绝对路径，但Hugo对图片资源的存放位置有特定要求（通常放在static目录下）。两者的路径解析方式不同。
解决方案：
1. 统一管理：在Obsidian中，使用附件功能，将图片放在与笔记同名的文件夹内。在转换脚本中，将这些图片同步复制到Hugo站点的static/images/posts/文章名/目录下。
2. 路径重写：在转换脚本中，不仅转换文本，还要查找Markdown中的图片语法![]()，并将其中的路径重写为Hugo可识别的绝对路径（如/images/posts/文章名/图片.png）。
3. 使用图床：更一劳永逸的方法是使用图床（如SM.MS、Imgur或自建）。在Obsidian中，可以使用PicGo插件，截图后自动上传到图床并将Markdown图片链接插入笔记。这样链接是公网URL，在任何平台都能显示。

5.2 双向链接转换失败

问题：Obsidian中丰富的[[内部链接]]在Hugo中变成死链或显示异常。
原因：Hugo原生不支持Obsidian的双链语法。
解决方案：
1. 简单转换：如上面的脚本所示，转换为普通Markdown链接[链接文本](目标文章)。但这要求目标文章的URL路径是确定的。
2. 使用Hugo短码：创建Hugo短码来模拟双链效果。例如，创建layouts/shortcodes/link.html：
```
{{ $page := .Site.GetPage (.Get 0) }} {{ if $page }} <a href="{{ $page.RelPermalink }}" class="internal-link">{{ default $page.Title (.Get 1) }}</a> {{ else }} <span class="broken-link">{{ .Get 0 }}</span> {{ end }}
```
  然后在转换脚本中，将[[目标]]转换为{{< link "目标" >}}，将[[目标|别名]]转换为{{< link "目标" "别名" >}}。这种方式更强大，但转换脚本更复杂。
3. 妥协方案：如果双链不是必须的，可以在发布前，将重要的双链手动改为普通链接，不重要的直接移除。这适合发布导向的笔记，而内部知识库则保留Obsidian的原生双链。

5.3 自动化流程中断

问题：GitHub Actions执行失败，网站没有更新。
排查步骤：
1. 查看日志：进入GitHub仓库的“Actions”标签页，点击失败的工作流，查看详细的错误日志。这是最直接的线索。
2. 常见错误：
  - Hugo版本不兼容：确保工作流中指定的Hugo版本与本地开发环境一致，特别是是否都需要extended版本。
  - 依赖缺失：如果使用了自定义的Hugo模块或主题，确保在工作流中正确配置了submodules: recursive或执行了hugo mod get。
  - 路径错误：检查转换脚本或构建命令中的文件路径是否正确，尤其是在GitHub Actions的虚拟环境中。
  - 密钥失效：检查Vercel的部署密钥（VERCEL_TOKEN等）是否在GitHub Secrets中正确配置且未过期。
3. 本地测试：在本地终端，切换到Hugo站点目录，尝试运行hugo --minify看是否能成功构建。这能排除大部分环境问题。

5.4 信息过载与维护负担

问题：工具太多，流程复杂，感觉维护这套系统本身就成了负担。
核心建议：迭代式搭建，从简开始。不要试图一天就搭建好所有环节。
1. MVP（最小可行产品）：先从最痛点开始。如果你最大的问题是写作环境杂乱，那就先只搭建Obsidian核心仓库+Markdown写作流程。如果问题是发布麻烦，就先实现Git手动推送+半自动发布。
2. 固化一个环节，再扩展下一个。当“写作-发布”主流程稳定运行两周后，再考虑添加“灵感捕获”或“社交媒体自动同步”。
3. 定期精简：每季度回顾一次，哪些工具很少用了？哪些自动化流程其实没必要？果断砍掉。系统的核心是为你服务，而不是你伺候系统。

6. 进阶优化与个性化扩展

当基础工作流跑顺后，你可以尝试以下进阶玩法，让系统更智能、更贴合你的需求。

6.1 利用API实现深度集成

自动同步到Notion数据库：如果你用Notion做内容规划，可以写一个脚本，当Obsidian中某篇文章的Front-Matter里status变为published时，自动调用Notion API，在指定的数据库里创建一条记录，包含标题、链接、标签等信息。
语音写作集成：通过Drafts（iOS/macOS App）的语音转文字功能快速记录灵感，并配置其动作，一键发送到Obsidian的Inbox文件夹。
阅读数据回流：将Umami或Google Analytics的API接入，定期（如每周）将热门文章的数据自动写入对应Obsidian笔记的Front-Matter中，方便后续分析。

6.2 构建内容日历与看板

在Obsidian中，使用Dataview插件可以动态生成强大的内容看板。

```dataview TABLE status AS "状态", date AS "日期", file.tags AS "标签" FROM "1-Projects/Blog" WHERE status != "archived" SORT date ASC ```

这段代码会生成一个表格，列出所有非归档状态的文章及其状态、日期和标签。你还可以用WHERE status = "idea"来筛选所有灵感，用WHERE date > date(today) - dur(7 days)来查看本周完成的任务。这比任何外部项目管理工具都直观，因为数据和写作环境是一体的。

6.3 设计个性化的分析仪表板

在Obsidian中创建一个“创作仪表板”笔记，利用Dataview查询来展示关键数据：

## 本周创作统计 ```dataview LIST FROM "1-Projects/Blog" WHERE date(file.ctime) > date(today) - dur(7 days) ``` ## 待发布文章 ```dataview LIST FROM "1-Projects/Blog" WHERE status = "ready" ``` ## 高频标签 ```dataview LIST rows.file.link FROM "1-Projects/Blog" FLATTEN file.tags as tag GROUP BY tag SORT length(rows) DESC LIMIT 10 ```

打开这个笔记，你就能对自己的创作情况一目了然。

搭建Openclaw内容工作流，就像为自己量身定制一套顺手的创作装备。它不会让你立刻成为写作高手，但能确保当你灵感迸发时，工具不会成为绊脚石；当你想要复盘时，所有资料都触手可及。这个过程本身，也是对个人创作习惯的一次深度梳理和优化。最重要的是，这套系统完全属于你，你可以随着需求的变化不断调整和进化它。

日记详情

基于Obsidian与GitHub Actions构建自动化内容工作流