迁移做了什么#

从提交记录看，这次迁移大致分成几个阶段。

首先是把博客主体迁移到 Astro Firefly。新的项目结构把页面、布局、组件、样式、内容和配置拆得比较清楚，文章内容统一放在 src/content/posts 下，由 Astro content collection 管理。相比旧的 Hexo 结构，这种方式对类型约束和后续维护都更友好。

然后是处理迁移后的兼容问题。旧博客已经被搜索引擎和外部链接引用过，所以迁移不是把文章搬过来就结束。需要保留自定义域名部署，处理 GitHub Pages 是否能检测到部署变化，清理旧 Hexo 生成物，同时避免把无关的历史产物继续带进新项目。

再之后是修复 Astro 检查里暴露的问题。迁移类工作很容易出现路径、路由、frontmatter、生成文件之间的小偏差。AI 在这里的价值不是神奇地一次性写对所有东西，而是能快速阅读错误、定位相关文件、提出最小修改，再用 pnpm check、构建或其他命令验证结果。

最后还有一些内容和配置优化，例如壁纸、导航和已有文章的整理。这类工作通常不难，但非常消耗耐心。AI 比较适合承担这种“保持注意力”的工作：持续看上下文，持续比较差异，持续把改动收束到明确的目标。

AI 让繁琐工作变快了#

以前做博客迁移，我通常会打开很多文件来回确认：

• 文章 frontmatter 字段是否和新框架匹配。
• 旧链接是否还需要保留。
• 生成目录哪些该保留，哪些该忽略。
• 构建脚本和部署脚本有没有互相影响。
• 新主题的配置项应该放在哪里。

这些事情本身没有太多创造性，但每一项都可能出错。AI 介入之后，最有用的地方是它可以把这些小步骤串起来，不需要我每次重新解释项目结构。

比如看到 Astro content schema 后，它会知道新文章至少需要 title 和 published，也会知道 tags 是数组、category 是单个字符串。看到 .gitignore 和历史 Hexo 产物后，它会更自然地判断哪些文件不应该继续进入版本控制。看到 GitHub Pages 相关提交后，它能把部署问题和仓库结构联系起来，而不是孤立地看某一个脚本。

这类效率提升很朴素，但很实在。它减少的是那些“明明知道要做，但做起来很费心”的部分。

迁移之后更重要的是沉淀#

博客迁移完成后，我反而意识到另一个问题：如果 AI 在日常开发里已经能帮我完成排查、修改、验证，那这些过程本身也应该沉淀下来。

过去写技术博客往往需要一个额外动作：项目做完了，再抽时间回忆过程，整理思路，补充上下文。这个动作一旦拖延，就很容易丢失细节。实际最有价值的内容，往往就在刚刚解决问题的那一刻：

• 为什么会遇到这个问题。
• 排查时看了哪些文件和日志。
• 哪个方案最后有效。
• 哪些尝试被证明不合适。
• 以后遇到类似问题应该怎么更快处理。

AI 正好掌握这些上下文。如果能在一次任务结束后，直接让 AI 把过程整理成文章，再保存到博客仓库里，技术沉淀就会从“额外负担”变成“顺手完成”。

新增写作沉淀 skill#

所以这次又新增了一个 write-blog-post skill。它的目标不是简单生成一段 Markdown，而是把“AI 工作过程中的总结”变成符合这个博客规范的文章文件。

这个 skill 做了几件事：

1. 判断用户是不是想把总结、排查记录、实现经验沉淀成博客。
2. 定位 suqishuo.cn 这个 Astro 博客仓库，避免在当前业务项目里误生成文章。
3. 读取现有文章的分类和标签，优先复用已有 taxonomy，不随意制造近义分类。
4. 按 Astro content schema 生成 frontmatter。
5. 把文章保存到 src/content/posts，并拒绝覆盖已有文件。

为了让它能在其他项目里使用，还给脚本增加了 --blog-root 参数，也支持 SUQISHUO_BLOG_ROOT 环境变量。这样即使我正在 Android、后端或其他项目目录里工作，只要说“把这个过程沉淀成博客”，AI 就可以把当前上下文整理成文章，并写入固定的博客仓库。

这一步很关键。因为知识沉淀不应该依赖我正好打开了博客项目，也不应该要求我手工复制内容、补 frontmatter、选分类、起文件名。越顺手，越可能坚持。

一点感慨#

这次博客迁移让我更清楚地感受到，AI 对个人开发者最直接的帮助，不一定是生成多么惊艳的代码，而是把大量零散的工程劳动变得可控。

迁移博客、清理旧文件、修复构建、调整部署、写迁移记录、再把记录沉淀为 skill，这些事情单独看都不大。但它们堆在一起，就会变成一件很容易拖延的事。

AI 的价值在这里体现得很明显：它能持续接住上下文，帮我把任务从“想做”推进到“做完”，再从“做完”推进到“记录下来”。这比单纯节省几行命令更重要。

以后我希望更多类似的工作都能形成这样的闭环：

1. 用 AI 完成繁琐但必要的工程任务。
2. 让 AI 总结关键过程和经验。
3. 通过 skill 自动写入博客。
4. 把一次解决问题，变成下一次更快解决问题的材料。

博客迁移只是开始。真正值得长期投入的，是让每一次实践都更容易留下痕迹。