当博客发布变成一件自动化的事：一次说干就干的流程改造

当博客发布变成一件自动化的事：一次说干就干的流程改造

说起来，程序员这个职业有一个很矛盾的地方：我们天天在写代码让别人的生活更方便，但自己的日常工作却常常充满了各种”手动操作”。比如我自己，写一篇博客要经历：写稿 → 改稿 → 登录服务器 → 创建文件 → 粘贴内容 → 执行发布命令 → 验证发布结果。这一套流程走下来，少说也要十几分钟。如果哪天特别忙，或者状态不好，光是”打开终端登录服务器”这件事，就足以让人产生拖延的冲动。

但今天，我想聊聊最近完成的一次小改造——把博客发布这件事，彻底变成了自动化的流程。现在写完文章，只要 push 上去，剩下的事情全部由系统完成。

为什么要做这件事

说起来挺讽刺的。我每天的工作就是”用代码解决重复性问题”，但自己的日常工作中，却长期忍受着一个明显的重复操作。

这个重复操作就是博客发布。

每次写完一篇博客，我的操作步骤是固定的：

1. 在本地写好 Markdown 文件
2. 用 scp 或者 rsync 把文件传到服务器上
3. ssh 登录服务器
4. 执行 hexo g -d 生成并发布
5. 打开浏览器验证文章是否正常显示

这些步骤单独看都不复杂，加在一起也挺快的，熟练了大概五分钟就能搞定。但问题在于，这个流程每天都要做一次（如果哪天特别有灵感，可能要做两到三次），而且每一步都需要人工介入。

更烦人的是，这五分钟是完全”不产生价值”的时间。我写文章本身是有意义的，但”把文章上传到服务器”这件事，完全没有任何创造性，它就是一个机械的搬运工作。作为一个程序员，我本能地觉得这件事应该被自动化。

想了很久，终于动手了

说起来，这件”自动化博客发布”的事情，我想了很久，但一直没有真正动手做。

为什么呢？仔细想想，大概有三个原因：

第一，这个事情太”小”了。

五分钟的事情，再怎么优化，也省不出半小时出来。花两天时间做一套自动化系统，回报率看起来很低。这种”投入产出比不划算”的感觉，让我一直提不起劲。

第二，原来的流程已经”能用”了。

人类对”能用”的东西有一种天然的惰性。只要这个流程还能跑，我就没有强烈的动力去改它。改着改着，如果改出 bug 了，反而更麻烦。

第三，不知道从哪里开始。

说起来是”自动化博客发布”，但脑子里有一百种实现方式，每种都有优缺点。用 GitHub Actions？还是在自己服务器上写个 Cron 脚本？还是干脆用现成的 CI/CD 平台？每一种方案都有它的复杂性，让我一直停留在”想”的阶段。

直到某一天，我发现自己在拖延博客发布的时候，心里突然有一种很强烈的不适感。那一刻我意识到：不是”能不能”的问题，是”想不想”的问题。只要真的想做，总能找到办法。

目标很简单：把”发布”变成一个后台任务

我想清楚了一件事：我不需要一个”完美”的自动化方案，我只需要一个”比现在好一点点”的方案。

现在的流程是：

1

写文章 → 手动上传 → 手动发布 → 手动验证

我想要的流程是：

1

写文章 → push到GitHub → 后台自动发布 → 自动验证

核心变化是：把”手动上传”、”手动发布”、”手动验证”这三个步骤，变成一个后台运行的自动化流程。

具体实现上，我用了 GitHub Actions。这个工具我已经很熟悉了，它的逻辑很简单：监听代码 push 事件 → 执行构建命令 → 自动部署。整个配置写下来，大概 60 行 YAML，调试加验证大概花了半天时间。

实现过程：比想象中顺利

说实话，实现过程比我预期的要顺利很多。

最让我意外的是 Hexo 和 GitHub Actions 的集成度非常好。Hexo 生成的静态文件目录是固定的（public/），GitHub Pages 的分支也是固定的（gh-pages），两者之间的对接几乎不需要额外的适配工作。

我只需要做这几件事：

第一步：写 GitHub Actions 工作流文件。

核心就是监听 push 到 main 分支的事件，然后执行 hexo generate 生成静态文件，再用 peaceiris/actions-gh-pages 把 public/ 目录发布到 gh-pages 分支。整个流程在云端运行，我不需要自己的服务器做任何事情。

1
2
3
4
5
6
7
8
9
10
11

- name: Generate Site
  run: npx hexo generate
  env:
    TZ: Asia/Shanghai

- name: Deploy
  uses: peaceiris/actions-gh-pages@v3
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: ./public
    publish_branch: gh-pages

第二步：处理好主题 submodule。

我的 Hexo 博客用的是主题 submodule 方式引入的，这需要在 checkout 步骤加一个参数：

1
2
3
4
5

- name: Checkout
  uses: actions/checkout@v4
  with:
    submodules: recursive
    fetch-depth: 0

第三步：配置 Node.js 缓存。

Hexo 的依赖不多，但每次都重新安装还是挺浪费时间的。GitHub Actions 的 setup-node 步骤自带 npm 缓存，加一行配置就能自动复用之前安装过的包：

1
2
3
4
5

- name: Setup Node
  uses: actions/setup-node@v4
  with:
    node-version: '20'
    cache: 'npm'

第四步：处理时区问题。

Hexo 默认使用 UTC 时区。我写文章用的是北京时间，如果不设置时区，文章的发布时间会比实际晚 8 小时。加一行 env: TZ: Asia/Shanghai 就解决了。

整个过程大概花了两个小时，其中一半时间是在排查一个 submodule 没有正确克隆的小问题。

现在的状态：写完就 push，剩下的不用管

改造完成之后，现在的博客发布流程变成了这样：

1

写文章 → git add . && git commit -m "写完了" && git push

然后 GitHub Actions 自动完成：

• 克隆代码（含 submodule）
• 安装 npm 依赖
• 生成 Hexo 静态文件
• 发布到 GitHub Pages
• 发送构建通知

整个过程大概两到三分钟，我不需要盯着屏幕。写完文章，push 上去，该干嘛干嘛去。

验证的时候，只要打开博客地址看一下就好了。如果文章正常显示，说明整个流程跑通了；如果有问题，GitHub Actions 会发邮件通知。

这个改变带给我的真实感受

说起来挺有意思的。这件”自动化改造”本身花了我半天时间，但这件事带给我的心理变化，比省下来的时间更有价值。

第一个感受：心理负担减轻了很多。

以前每次写完博客，都会感受到一股隐隐的”还需要做一件事”的压力。这个压力不大，但持续存在。自动化之后，这个压力消失了。写完文章的那一刻，我知道它”会自动发布”，不需要我再做任何操作。

第二个感受：对”写文章”这件事本身更专注了。

以前写文章的时候，心里会时不时冒出”写完之后还要发布，好烦”这种念头。这个念头虽然不会阻止我写作，但它会分散注意力。现在这个念头消失了，我发现自己更容易进入”心流”状态。

第三个感受：发布的频率可能会提高。

以前”发布 = 一次手动操作”，所以在心理上会不自觉地累积好几篇再发。自动化之后，发布变成了一次”push”，成本极低，我发现自己在写作上更有动力了。

这次改造的一点反思

回顾这次自动化改造，我发现了一件有意思的事：我之前过度高估了”实现难度”，过度低估了”自动化的心理价值”。

在动手之前，我在脑子里把这件事想得很复杂：GitHub Actions 配置、安全问题、版本管理、多设备同步……各种担心。但真正动手之后，发现这些”担心”大部分都是纸老虎——GitHub Actions 文档很完整，Hexo 的生态也很成熟，大部分问题 Google 一下就能找到答案。

反而我之前完全没有预料到的是：自动化带来的最大价值不是”省时间”，而是”减少心理负担”和”提高写作意愿”。这两件事对我的日常工作影响，比省下来的那几分钟时间大得多。

这让我想起了一句话：最值得自动化的，不是那些耗时最长的事情，而是那些你最不想做的事情。

写在最后

周五晚上十点，我坐在电脑前，写完了这篇文章。

按”旧流程”，我现在还需要：登录服务器 → 创建文件 → 粘贴内容 → 执行发布 → 验证结果。这大概要花我五到十分钟。

但”新流程”下，我只需要做一件事：

1

git push

然后这篇文章会在两分钟后自动出现在博客上。

这一刻，我感受到了一个很微妙的满足感。不是因为省了十分钟，而是因为我知道——我做了一件正确的事情：让机器去做它擅长的事，把人的时间留给真正需要人的地方。

这大概就是自动化的意义吧。

作者：小六，一个周五晚上把博客发布自动化了、心情很好的普通打工人