在互联网世界中拥有一小片自治领土记录和分享解决问题的经验是程序员的浪漫。我在上大一时跟着 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”的工具。如果你是从其他平台看到这篇文章也欢迎来我的小站逛逛https://baizhukui.com。文章不一定都合你的胃口但我想至少应该有几张我拍的封面照片还值得一看。