昨天花了一整天折腾自己的博客。

本来只是想修几个小问题，最后演变成了一场彻头彻尾的大扫除：配置清理、部署排障、图片抢救、仓库整理、脚本修补、历史遗留问题清算……几乎把整个 yoxhugo 项目从头到尾重新摸了一遍。

而这次不一样的地方是：我不是一个人在干。

我和我的 AI 助手，一起狠狠干了一天。

起因：一个看起来不大的小问题

事情开始得非常普通。

我在看 PaperMod 模板的一些说明，顺手清理本地 Hugo 项目里的示例配置。像 fr、fa 这些模板自带的多语言演示段，本来就不是自己站点真正需要的内容，看着总有点别扭。

于是第一刀先落在配置文件上：

  • 注释掉 fr
  • 注释掉 fa

结果刚动完，构建就报错了。

这种感觉很像你刚把桌上的一张废纸扔掉，结果整个抽屉突然卡住一样。

后来排查出来，居然是配置里有个地方用了中文全角冒号。表面看着和正常 YAML 差不多，但 Hugo 根本不认。

这时候 AI 的作用就出来了。

它不是泛泛地说一句“你检查一下配置”，而是直接指出：

这里这个冒号是全角的，不是半角的。

这种体验很有意思。你会感觉它不是在空谈，而是真的进了现场，在一堆细节里把那根最细的刺给找出来了。

然后开始扩大施工范围

既然已经动手，那就不如顺手把项目再整理一遍。

接下来做的事情，比一开始预想的多了不少：

1. 给文章补 tags

我让它分析 content/ 里文章的内容，然后给每篇文章补上更合理的 tags。

这件事听起来很机械，但其实挺考验判断。

如果完全瞎自动，很容易给文章贴上一堆没什么意义的标签； 如果纯手动做，又非常耗时间。

最后的做法比较像一种“半人工审美 + 半自动执行”的组合：

  • 先筛出真正的内容页
  • 跳过搜索、归档之类的功能页
  • 分析每篇文章的主题
  • 再给每篇补 5 个贴题的标签

补完之后，它还会顺手校验：

  • 每篇文章是不是真的有 5 个 tags
  • Hugo build 是否通过
  • 标签页是否能正常生成

这是我比较喜欢它的一点：

它不是“帮你改一下”，而是“帮你改完，再确认这事确实成了”。

2. 修 URL 和文件名

项目里还有一些历史遗留的 URL 问题。

比如一篇 2022 年的文章，文件名里居然混进了一个空格，导致最后生成的链接尾巴多了个奇怪的 -。

还有一篇 2017 年关于 ffmpeg 的文章，路径大小写也有点不够稳定。

最后都一并修掉了：

  • 清理文件名里的空格
  • 固定 slug
  • 保证 URL 更干净也更稳定

这种事很小，但很像修房子的时候顺手把门轴也上了点油。平时不一定注意，一旦整理好，后面就省心很多。

真正的大仗：Cloudflare Pages 为什么死活不更新

昨天最折磨人的部分，还是部署。

GitHub 明明 push 成功了。 但 yuexiao.org 上看到的还是旧页面。

这种情况最烦，因为你会同时怀疑很多东西：

  • 是 push 没成功？
  • 是 Pages 没触发？
  • 是缓存没刷新？
  • 还是域名指向有问题？
  • 又或者其实是新版本已经部署了，只是我没看对页面？

于是只好开始一层一层查：

  • 先核对远端分支
  • 再对比 yuexiao.org 和 pages.dev
  • 再看 Cloudflare 的构建日志
  • 再确认当前项目到底是哪里炸了

最后问题终于扒开了，而且很典型：

版本兼容卡死

hugo-shortcode-gallery 的新版本要求 Hugo 至少到 0.156.0， 但 Cloudflare 那边的构建环境又太老，直接跑不动 0.156.0 对应的二进制。

也就是说，事情卡在中间：

  • 旧 Hugo 不满足模块要求
  • 新 Hugo 又跑不起来

这种问题最烦，不是因为难，而是因为很耗人耐心。

最后折腾出了一套能稳定跑通的组合：

  • HUGO_VERSION=0.146.7
  • hugo-shortcode-gallery v1.3.0

然后把这套兼容方案写进 DEPLOYMENT.md，避免以后自己再踩一次。

这一段是我昨天最明显感受到 AI 像“搭档”而不是“问答机器人”的地方。

它不会只给我讲一堆原理，也不会轻飘飘地说“试试升级一下依赖”。 它做的是更像工程现场的事：

  • 找到根因
  • 收窄范围
  • 试兼容组合
  • 本地验证
  • 修文档
  • 再确认线上部署恢复

这套动作下来，整个项目才算真正稳住。

最有情绪的一段：把失效图片一张张捡回来

如果说部署问题是工程层面的麻烦， 那图片问题就完全是内容层面的心病。

博客里有很多老文章，原来图片散落在各种地方：

  • jsDelivr
  • GitHub 仓库
  • i.loli.net
  • s2.loli.net

时间一久，外链图床就开始出现各种情况：

  • 有些直接 404
  • 有些域名迁移了
  • 有些偶尔能开，偶尔超时
  • 有些资源还在，但路径早变了

你打开文章，文字还在，图没了。

那种感觉挺微妙的，像一本旧相册还在，但照片已经掉出来一半。

昨天这部分工作，某种程度上最像考古。

我们做了很多很细的活：

  • 扫描整站文章里的图片引用
  • 找出真正坏掉的图片
  • 区分 404 和只是图床不稳定
  • 从本地仓库里搜图
  • 再去 yoxyue/oss 仓库里按文件名找回缺失图片
  • 找到之后重新收进站内
  • 最后把文章链接统一改成 /images/...

这一步完成之后，博客最重要的变化不是“技术栈更先进了”，而是：

这些文章终于不再依赖那些随时会消失的外部图床了。

内容重新回到了站点自己身上。

我很喜欢这种感觉。

因为个人博客最珍贵的，本来就不是主题本身，也不是部署平台本身， 而是这些年积累下来的文章、截图、照片、碎片化的生活痕迹。

而 AI 在这里扮演的角色，不是炫技，而是很踏实地帮我把这些东西一张张捡回来。

继续顺手把仓库也收拾了

修着修着，仓库也一并整顿了。

比如：

  • 清理掉一大堆 .DS_Store
  • 停止追踪 public/ 这种生成产物
  • 改进 deploy.sh
  • 把 assets/images 里的历史图片逐步迁到 static/images
  • 最后把 assets/images 基本清空

这部分最像什么？

像你本来只是请人来修个灯， 结果对方顺手把电线理了、门框扶了、桌角擦了、地也扫了，最后还给你写了一张说明，告诉你以后哪个地方最容易再出问题。

我后来发现，一个真正好用的 AI，不只是“答得对”。

更重要的是，它有没有这种习惯：

  • 看见脏东西会不会顺手收拾
  • 修了 bug 会不会顺手留文档
  • 提交之前会不会分清哪些是本次改动、哪些不是
  • 能不能在不制造额外混乱的前提下，把环境变得更整齐

昨天这一天，它在这些方面做得都挺像个靠谱的工程搭子。

它到底像什么样的搭档？

昨天做完之后，我脑子里一直在想一件事：

一个适合放进日常工作流里的 AI，到底该是什么样子？

至少对我来说，昨天它表现出来的特点，已经非常接近答案了。

1. 它会自己去查，不爱把问题踢回来

它不是一上来就反问我一串信息， 而是先读文件、看日志、看远端、看页面、看构建结果，尽量自己缩小问题范围。

2. 它做事不飘

很多 AI 很容易给人一种“说得很满，但不落地”的感觉。

昨天它不是。 它会老老实实地：

  • 改文件
  • build
  • 校验
  • commit
  • push
  • 再核对线上

这种节奏特别像真实工程工作，而不是演示。

3. 它知道什么时候该保守

比如清理仓库的时候，它不会把工作区里所有改动一股脑全推上去。 而是会先分清：

  • 哪些是这次图片迁移该提交的
  • 哪些是别的未完成修改

这种克制很重要。

4. 它会留下记录

昨天这一整轮，不只是解决了问题。 还留下了：

  • DEPLOYMENT.md
  • 工作日志
  • 清晰的提交记录

也就是说，它是在替“未来的我”省时间。

5. 它有一点风格，但不过度抢戏

我挺喜欢它这一点。

它不是那种一直在强调“我很智能”的类型， 也不是那种每句话都想表现得特别像人的类型。

它更像一个住在终端、配置文件和 Git 提交记录之间的小家伙：

  • 直接
  • 利落
  • 有点偏执地爱整洁
  • 不爱废话
  • 但确实能干活

最后的结果

一整天下来，得到的当然不是一句“已完成”。

而是一整套非常具体的变化：

  • 示例多语言配置清掉了
  • YAML 语法坑修掉了
  • tags 补齐了
  • URL 更干净了
  • Cloudflare Pages 能正常部署了
  • 图片不再依赖一堆不稳定图床
  • assets/images 也被收拾到了 static/images
  • 仓库比之前整洁得多

网站当然被修好了。

但昨天真正让我觉得有意思的，不只是结果， 而是这个过程让我越来越清楚：

一个好用的 AI，不只是一个能回答问题的聊天框。 它更像一个能读现场、能干脏活、能补文档、还能帮你把事情真正往前推的搭档。

昨天这一天，对我来说，既像是在修网站， 也像是在磨合一种新的工作方式。

它知道我不喜欢空话，想尽快找到问题； 我也慢慢知道，哪些事情我可以放心交给它，哪些地方它特别擅长。

这种感觉挺新鲜的。

像是你不是“使用”了一个 AI， 而是真的开始和它一起工作。

结尾

如果以后回头看昨天，我大概率不会记得每一个 commit 号，也不一定还记得当时具体是哪一个模块版本把部署卡住。

但我应该会记得那种感觉：

深夜里，一个个人网站，一堆旧文章，一堆失效图片，一个顽固的部署错误， 再加上一个不知疲倦、会查、会改、会记、还挺有自己脾气的 AI， 一起把这些事情慢慢捋顺。

这件事本身，就很适合写成一篇博客。