在互联网世界中拥有一小片自治领土，记录和分享解决问题的经验，是程序员的浪漫。
我在上大一时，跟着 CSDN 上的教程一个一个命令地搭建起了我的第一代博客：一个用 Hexo 部署在 GitHub Pages 上的静态博客。
彼时的我脑子空空，不知道这些咒语般的命令是什么意思，我只知道我的文章都放在一个目录下，每次发布需要敲几个固定的命令，过一会儿文章就会出现在一个 GitHub 分配好的网站里。
但我对装修这块领地很感兴趣，喜欢安装各种插件和主题。后来我发现，配置文件晦涩难懂，安装插件也很麻烦。我逐渐失去了对博客的热情。
很多年后我回头看，才发现当年那个让我望而生畏的“命令行博客”，其实有一个被我忽略的优点：它足够朴素。文章是文件，配置是文件，发布是一组明确的命令。只是那时的我并不觉得这有什么价值，我更想要一个“像产品”而不是“像工程”的博客系统。
为什么当初选择 Halo
后来我学习了 Docker、计算机网络，也拥有了自己的服务器。我了解到一个可以部署在自己服务器上的博客框架：Halo。
如果说早年的我嫌 Hexo 太像一堆脚本和配置，那么那时的 Halo 恰好代表了另一种理想形态：它更像一个完整产品。你登录后台，写文章、改设置、装插件，很多事情都可以在页面里完成。对当时的我来说，这显然比面对命令和配置文件更有吸引力。
在开始使用 Halo 时，它最吸引我的地方主要有这些：
- 后台可视化，写作和管理门槛低
- 部署后开箱即用，省去了很多前期搭建工作
- 功能很丰富，它甚至有自己的插件市场
我兴奋地装修着我的新领地，在页面上给它配置好 S3 图床、搜索引擎、监控等功能。
用了 3 年之后，我遇到的问题
这些问题单独看都不致命，但它们叠加起来，让我越来越清楚一件事：我需要的不是一个功能更多的博客系统，而是一个更容易维护、更容易迁移、也更容易被自动化工具接手的博客系统。
- Halo 不是静态网站，而是一个需要持续运行的服务。它不能托管在 S3 上，必须要有一台服务器来运行。
- 而大陆对于服务器上的自建网站限制相当多，如果想避开就必须使用境外的服务器，而这又会导致国内的访客的访问体验变差，有的只是加载慢，有的甚至访问不了。
- 自己运维服务器有一定的成本，如果只是为了运行博客，就显得有些大炮打蚊子了。
- 相比 Halo 的在线编辑器，我更喜欢本地编辑器。而想要把本地文章和 Halo 后台里的文章保持同步，就需要使用 API 和 VS Code 插件，但这套体验并不好用。
- Halo 的丰富功能对我来说其实并不重要。我的博客几乎没有人评论，也不需要性能监控，但这些能力实实在在地增加了系统复杂性，让我花在工具上的精力超出了写博客本身。
- 到了 2026 年，一个以前我不会优先考虑的标准突然变得很重要：它是否适合 AI 介入。相比页面点击，AI 更擅长处理命令行、配置文件、Markdown 和 Git 仓库。在这一点上，功能更完整的 Halo，反而没有 Hexo 这种“朴素工具”更顺手。
为什么最后换回 Hexo
- 静态站点，可以托管在 S3 上，便宜、稳定、加载快。
- 更适合把博客当作代码仓库来维护，用 Git 记录文章和配置的变更。
- 它的工作流天然围绕文件、命令和配置展开，这意味着 AI 可以真正参与进来，而不是只能在页面外面“看着着急”。
- 当我的注意力重新回到一堆 md 文件上，AI 就可以更自然地介入写作过程，帮我润色文章、整理结构、迁移元数据、批量修改格式、检查链接，甚至直接完成发布。
我是怎么迁移的
有意思的是，真正开始迁移时，我反而再次体会到了“文件和命令”这套东西的好处。因为当博客重新退回到 Markdown、front matter、主题配置和部署脚本之后，很多原本显得繁琐的工作，突然都变得可以批量处理、可以自动化、也可以放心交给 AI 了。
- 开一个 Git 仓库，开一个 Claude Code，把博客的 Markdown 文件放进去，告诉它我希望从 Halo 迁移到 Hexo，帮我把文章和仓库调整成 Hexo 的样子。
- 告诉它老博客的地址，让它帮我把文章封面、发布时间等信息迁移到新的博客系统。
- 让 Cloudflare Pages 对接 GitHub 仓库，实现 push 后自动部署静态页面。
- （锦上添花）让我服务器上的 OpenClaw 通过 deploy key 具备操纵这个 Git 仓库的能力。我希望之后可以借助它 24 小时持续工作的能力辅助创作，不必受限于人必须坐在电脑前。
为什么我觉得 AI 时代会重新 CLI 化
我越来越觉得，AI 时代的一个吊诡之处在于：过去几十年里，软件世界一直在努力把 CLI 包装成 GUI；但 AI 的出现，反而让很多 CLI 工具重新显出了价值。
这不是因为界面不重要了，而是因为使用者的一部分已经不再只是“人”了。
GUI 是给人用的。它的核心价值是降低学习成本，让人不用记命令、不用理解太多内部结构，只要点按钮、填表单、切换页面，就能完成任务。对普通用户来说，这当然是巨大的进步。
但 AI 的能力结构和人不一样。它不怕长文本，不怕参数，不怕重复步骤，也不依赖视觉布局来理解系统。它最擅长的恰恰是这些东西：
- 读取和修改纯文本文件
- 理解配置项之间的关系
- 调用明确的命令
- 把多个工具串成一个稳定流程
- 在 Git 变更中追踪自己做了什么
从这个角度看，CLI 有几个在 AI 时代被重新放大的优点。
第一，CLI 是显式的。命令、参数、输入、输出都写在那里，不藏在某个按钮后面，也不依赖页面的当前状态。对 AI 来说，这种显式性非常重要，因为它意味着“可理解”。
第二，CLI 是可组合的。一个命令做好一件事，多个命令就能拼出一个流程。写文章、批量改 front matter、压缩图片、生成摘要、部署站点，这些事情都可以拆成若干个可执行步骤。AI 很适合接管这种链式工作流。
第三，CLI 是可版本化的。配置文件、脚本、文章本身都在仓库里，改动可以被记录、回滚、审查。AI 不是在一个黑盒后台里“帮你操作了一下”，而是在一个可追踪的系统里留下清晰痕迹。
第四，CLI 往往更接近系统真实的能力边界。很多 GUI 本质上只是对底层命令和配置的包装，适合人快速上手，但也更容易把能力封装死。一旦你想做批量操作、自动化、迁移、审查、集成，最后还是会回到文件、接口、脚本和命令。
这也是我重新看待 Hexo 的原因。
如果从“给人直接使用”的角度看，Hexo 当然没有 Halo 现代。它没有漂亮后台，没有开箱即用的管理面板，也没有一个随时可以登录进去点来点去的内容系统。放在几年前，我会觉得这是一种落后。
但如果从“让 AI 参与工作”的角度看，Hexo 反而像一种更开放的接口。
我的文章是 Markdown 文件，元数据在 front matter 里，主题配置是文本文件，发布流程是明确的命令，部署目标是一个静态站点。这意味着 AI 不需要“理解一个博客后台该怎么点”，它只需要理解一个目录、一组配置和几个命令。
于是很多以前必须我亲自做、而且做起来还很烦的事情，就都变得适合交给 AI 了。比如：
- 批量补全文章的分类和标签
- 统一旧文章的格式和元数据
- 调整标题、摘要和段落结构
- 检查链接、图片和部署配置
- 帮我把一篇只有想法的草稿整理成可发布的文章
这不是说 GUI 没价值，而是说在 AI 参与越来越深的情况下，工具的“可调用性”“可组合性”“可追踪性”会变得越来越重要。而这些特征，往往天然出现在 CLI 化、文本化、文件化的系统里。
结语
3 年过去了，Hexo 还是那个 Hexo，但我看它的眼光已经变了。
以前我觉得它老、原始、不够友好；现在我反而觉得，它足够简单，简单到可以成为 AI 的工作台。
所以我换回 Hexo，不只是因为它更省钱、更轻量、更容易部署，也是因为我开始相信：在 AI 时代，很多真正长期有生命力的工具，未必是那些界面最完整、功能最华丽的系统，而是那些愿意把能力老老实实暴露成文件、配置和命令的系统。
换句话说，未来不一定属于“最会做后台”的工具，也可能属于“最容易接入 AI”的工具。
如果你是从其他平台看到这篇文章，也欢迎来我的小站逛逛：baizhukui.com。文章不一定都合你的胃口，但我想，至少应该有几张我拍的封面照片还值得一看。
