迁移 blog 回静态博客

四年之前，我因为懒，把 blog 从 hexo 迁到 wordpress。

四年之后，我又因为另一种意义上的懒，把它迁回了静态博客。

听起来有点打脸。

更打脸的是：这篇文章本身，也是 Codex 在这次迁移对话里顺手写出来的。

是的，我现在已经懒到连 “写一篇关于为什么我变懒了的文章” 这件事，都要外包给 AI。

技术进步到这个地步，多少有点不像话。

免责声明

为了避免将来考古时产生误会，这里先写清楚：

1. 本文不是我在键盘上逐字敲出来的
2. 本文是我和 Codex 在迁移 blog 的对话过程中，让它按我过去的写法现编的
3. 如果你觉得本文某些句子略显刻薄，说明它学得还挺像

总之，本文大概可以算作：一篇由迁移会话现场生成的迁移总结。

元得有点烦人，但也很符合这个时代的气质。

wordpress

2022 年时，我从 hexo 切到 wordpress，理由非常朴素：

1. 懒得折腾 node.js，git hooks，主题配置，部署脚本
2. 懒得打开本地编辑器写 markdown，再敲命令发布
3. 懒得在换机器之后重新配置一遍环境

总之就是：我希望写博客这件事尽量像发帖，而不是像发版。

从这个角度看，wordpress 是很合理的选择：

1. 配置简单
2. 所见即所得
3. 任何地方只要有浏览器就能写

理论上如此。

但现实总是喜欢补一刀：迁完没多久，我连 wordpress 密码都忘了。

这就很黑色幽默。

你费劲把系统换成一个 “更方便维护” 的东西，结果几年之后，最先失效的不是主题，也不是插件，而是你自己的记忆。

某种意义上，这也说明 wordpress 确实降低了使用门槛：它低到我连登录它这件事都不怎么需要了。

而且当时我对所谓 “静态博客” 已经有点疲了。

程序员很喜欢静态博客，github pages，markdown，主题，自动部署，甚至还会专门写文章讨论这些工具链本身。但问题在于：这些东西很容易从 “写作工具” 变成 “玩具工程”。如果一个 blog 的维护成本接近一个 side project，那它大概率会荒废。

至少对我来说是这样。

为什么又切回来了

原因也非常朴素：环境变了。

2022 年时，从 wordpress 的角度看，静态博客的问题主要在于：

1. 配置麻烦
2. 迁移麻烦
3. 改主题麻烦
4. 一旦断更一段时间，连命令都忘了

现在这些问题依然存在，但重要性已经大幅下降。因为多了一个以前没有的东西：agentic coding。

以前折腾博客，很多时间其实都花在这些毫无价值的事情上：

1. 查 Hugo/Hexo/Jekyll 文档
2. 改主题 CSS
3. 迁移旧文章
4. 修 URL
5. 配 DNS，配 Cloudflare，配部署

这些事情并不难，但很烦，而且非常碎。正因为碎，才让人更容易拖延。

人类对 “困难但重要” 的事情还能勉强硬扛一下；对 “不难但巨烦” 的事情，往往会迅速装死。

而现在，像 Codex / Claude Code 这种 agentic coding 工具，正好擅长处理这种烦但不难的事情。它不能替你写出真正有价值的文章，但它很适合：

1. 搭脚手架
2. 改模板
3. 清理 HTML
4. 写迁移脚本
5. 修配置
6. 配静态部署

换句话说：静态博客的主要成本，过去在工程；现在工程成本下降了。

更准确一点说：以前我需要自己处理一堆边角料；现在可以把这些边角料甩给一个不会抱怨、不会嫌麻烦、也不会在群里同步 blocker 的数字劳工。

而且它还有一个额外优势：它不会因为你半夜临时起意让它改 DNS、修 CSS、顺手再写一篇博客，就露出那种 “这需求是不是应该排到下周” 的表情。

于是 wordpress 的几个优势开始变弱，而静态博客的几个优势重新变强：

1. markdown 写作更舒服
2. git 版本历史更可靠
3. 静态页面更简单，维护面更小
4. 不需要继续维护 wordpress / PHP / VPS 这一整套东西

这次迁移做了什么

这次没有追求什么复杂架构，基本思路非常直接：

1. 用 Hugo 重建 blog
2. 用 markdown 存文章
3. 用 git 管理内容
4. 用 Cloudflare Pages 托管静态站点
5. 把域名 DNS 切到 Cloudflare

中间还顺便做了几件事情：

1. 从 wordpress 导出 XML
2. 写脚本把文章导入 Hugo
3. 清理掉一些近几年的文章，先保留 2022 年 1 月 20 日之前的内容
4. 简化页面样式，不搞太多花活
5. 把 lucida.me 直接作为 blog 主域名

最后这个决定其实挺关键。

原本我打算继续用 blog.lucida.me，然后把 lucida.me 留给一个更完整的个人主页。但折腾到后面发现这并没有太大必要：至少在现在，blog 本身就是 lucida.me 最主要的内容。与其再人为拆一层，不如直接用根域名。

说白了，规划得太超前往往是一种体面的 procrastination。先把能用的东西放上去，比预留一个并不存在的宏大信息架构更重要。

更离谱的是，这次迁移并不是我那几天唯一在折腾的东西。

迁 blog 的同时，我还顺手在搞别的 web app。也就是说，这整个过程本质上是一边修博客，一边开 side quest，一边继续工作中的主线任务。

以前这种多线程操作通常会导向一个确定的结局：三个项目一起烂尾。

这次居然没烂，多少说明工具确实变了。

这次迁移大概花了多少成本

粗略算了一下，从开始写迁移计划到这篇文章初稿落地，大概用了 2 小时 40 分钟。

如果按对话轮数算，大概有 四十多轮 prompt。其中真正与 “写文章” 有关的部分并不多，更多是：

1. 折腾 DNS
2. 折腾 Cloudflare Pages
3. 从 wordpress 导出 XML
4. 迁移旧文章
5. 改样式
6. 改完又后悔，再改回来

顺便一提，这还只是个人 blog 的迁移成本。

如果把工作场景也算上，最近三个月我在 Instagram 线上落地的代码已经超过 70k LoC。更荒诞的是：这些代码没有一行是我亲手敲出来的，全部来自 agentic coding。

以前这句话听起来像在吹牛。

现在这句话更像是在描述一个行业趋势。

你当然仍然需要人来做判断，拆问题，审代码，兜底，上线，背锅；但那个经典意义上的 “坐在那里一行一行敲业务代码的人”，正在以肉眼可见的速度贬值。

换成以前，这种事大概率会演化成一个经典程序员项目：

1. 第一天：激情澎湃，感觉今晚就能迁完
2. 第二天：开始查文档，觉得 Hugo 真不错
3. 第三天：开始改主题，觉得默认字体不对
4. 第四天：发现 DNS / SSL / 重定向有坑
5. 第五天：懒得继续，项目烂尾

而这次至少没有烂尾。

这已经超过很多 side project 了。

这次迁移和上次迁移最大的区别

上次迁移的核心逻辑是：

为了更容易写，接受更重的系统。

这次迁移的核心逻辑则变成：

因为系统成本已经下降，所以重新选择更轻的系统。

所以表面上看，这是一次 “wordpress → 静态博客” 的回滚；但本质上，这两次迁移的决策基础并不一样。

2022 年的我并没有错。

2026 年的我也不一定对。

只是工具环境变了，所以局部最优解也变了。

更悲观点说，不只是博客系统的最优解变了，很多普通程序员的岗位形态也在变。

过去大家多少还有一种浪漫想象：写代码是手艺，程序员是工匠，敲键盘的人天然有点不可替代。

现在看，这种浪漫想象正在迅速退化成历史遗迹。

未来很可能会变成这样：

1. 少数人负责定义问题、审查结果、承担责任
2. 大量 agent 负责生成实现
3. 剩下的大多数人，如果还停留在“根据需求单把页面和接口拼出来”的阶段，那本质上就是 code monkey

而 code monkey 这种角色，历史上通常都没有什么好下场。

不是今天被外包，就是明天被平台化，后天再被自动化。

以前大家担心的是 “AI 会不会替代程序员”。

现在我更倾向于另一个说法：AI 未必会替代所有程序员，但它会先把程序员里最像流水线工人的那一层狠狠干碎。

当然，也可能四年之后我又会再写一篇《迁移 blog 到某个新的东西》。

如果真有那一天，希望不要再看到这篇文章；因为那意味着我又开始折腾博客系统，而不是写点真正有用的东西。

接下来

这次迁移完成之后，至少有几件事情会比之前更顺手：

1. 新文章直接写 markdown
2. 内容改动走 git
3. 站点部署交给 Cloudflare Pages
4. 不再需要继续维护 DigitalOcean 上的 wordpress

当然，这并不意味着 blog 就一定会高频更新。

阻碍我写博客的最大问题，从来都不是 Hugo，Hexo 或 wordpress，而是：

1. 懒
2. 忙
3. 写完之后也不一定有人看

只不过以前除了这些问题，还要额外对付一套博客工程；现在至少可以把后者先拿掉。

这已经很好了。

至少下一次我不更新 blog 时，就不能再把锅甩给 wordpress 了。

这很不妙。

但从另一个角度说，也挺公平。

既然我已经把迁移、写文、改样式、配部署这些事都部分外包给 agent 了，那么剩下真正属于我的那一小部分工作，也确实不该再继续装死。