迁移 absolute-press

2022 年以来，我一直在被 vuepress 坑，然而由于博客已经达到了相当大的体量，迁移成本非常高，我一度以为本博客要永久埋葬在 vuepress 里了。但是 2026 年 AI/agnet 光速发展，从前被认为是不可能的迁移，现在也看到了新的希望。

2026 国庆假期，我的其他项目进展也差不多了，token 放着也是浪费，于是就开始了新博客框架的编写。

设计

泛前端项目的一些约束，比如 ts full typing、禁 any 和 as unknown as、工具链就不多说了。直接基于 my-solid-template 开搞即可。

首先，先让 AI 把我的 blog review 一遍，总结出到底用了哪些 vuepress-theme-hope 的特性和迁移时注意的点，方便我和 AI 测试。

然后我大概定了几个规矩：

  1. 性能第一。
    • 这几年把 React、Vue、SolidJS（甚至还有 svetle）等几个前端框架都尝试了一遍，最终结论是 vue 的表达能力太差，我不想再写 vue 组件了。同时我非常重视性能，SolidJS 的性能在各个前端框架里绝对是碾压级别的（甚至比 lit 还能打），并且我认同 SolidJS 理念、自己也写了几个 SolidJS 小玩具，因此就决定基于 SolidJS 开发框架。
      • 我以前写的一堆 vue 组件也全部迁移到 SolidJS。
    • 我倾向于 Rust 工具链，所以选了 rolldown。后面想起来 vite v8 默认就用的 rolldown，于是直接升级到 vite v8。
  2. 在性能基础上提了一些 SEO 要求，然后 AI 就帮我选了 Astro 那种 island 和 MPA 架构。本来我以为会回到 MDX 的老路，现在有了（看起来）更好的解法，那还是先试试吧。
  3. 尽可能降低迁移成本。
    • 我自己的博客里最有价值的是 markdown 文档，这些变更我肯定都要看一遍。如果迁移改了太多东西，不好 review。因此新的博客框架也是走 markdown-it 渲染 + markdown-it 插件 + shiki 代码高亮 + katex 渲染公式那一套，保证兼容老 vuepress-theme-hope 的各种语法，比如 ::: code-tabs ::: details 等容器。
    • algolia 搜索、giscus 评论区等也都重新实现一份，不能丢。

编写与测试

实施就全部交给 AI，让它指挥 subagnet 去重写、写完做视觉验证、然后把我的 blog 迁移过去。由于 AI 读了很多 vuepress-theme-hope 源码，所以写出来的东西真的很有 vuepress 内味。

当然目前我用的 AI 只能做到「写出来」，没法做到「写得好看」。所以之后还需要非常多的人类反馈迭代；同时也必须要用其他模型对框架代码进行二次 review。

测试：初期主要还是靠多模态 VLM 自己去做视觉验证。等到博客基本成型，样式相对稳定以后，再让 AI 写 e2e 测试。覆盖率上去以后就基本能甩手了。

一些奇思妙想

absolute-press 框架里融合了我的一些新的构想。

文章关联图

现在你可以在博客的每个文章末尾（giscus 评论区之前）看到一个叫「相关文章」的板块，里面是一堆布朗运动的点（文章）和线（关联）。这就是我的文章关联图的设计。

传统博客站经常会在这个区域放两个「上一篇」「下一篇」的按钮，让人读完一篇文章以后可以接着读下一篇；但我的博客并不是普通的按“文章”维度的产出，不同的文章之间字数和信息量差别非常大；而且我觉得单纯使用「上下篇」在引导方面也做得不太好。因此我搞了个关联图，希望读者可以跳转到与当前文章关联性较大的其他文章继续阅读 对原本就谜语的博客更是雪上加霜。

实现上，这个关联是构建时遍历文章中出现的站内链接获取的，最多展示两层关联（点的数量具有上限，不然全部堆在一起观感不太好）。渲染用的 d3.js，天生就是用来做这种带有动画的小玩意的，性能也不差。

我非常喜欢在博客里使用链接相互引用，因此这个关联图还是相对准确的。当然我也不知道实际观感如何，所以如果有看到这里的朋友可以给一些反馈，谢谢。

使用文章关联图的一个缺点就是，那些没有引用外部、也没有被外部引用的文章就很难出现在读者的视野中，这更为本博客增添了一层神秘面纱，当你读完了所有主要文章后，结果还发现有一大堆散落各处的小文章等待你的探索……

反正如果你希望阅读所有文章，可以在 sidebar 里扫，sidebar 就类似 vscode 那种侧边栏，绝大部分的文章都在里面（为什么说绝大部分呢，因为我还有一些隐藏文章只能从其他文章的链接里进去，敬待诸君探索）。

开发过程中的踩坑

CSS 竞技地狱

最初 AI 写出的 CSS 全部耦合在一起：markdown 本身样式优先级反而最高，island/component 样式必被 markdown 样式覆盖；站点 CSS 和主题 CSS 在同一个层级对轰。

之后我测试时发现不太对劲，指出了许多样式问题，然后 AI 的解决方法是继续在这上面堆屎（reviewer 原话：现状已经是军备竞赛，全库约 40 组 selector 纯为对轰而生，注释里 10 处在解释 specificity 决斗）。

必须要人类介入了！指挥 AI 重写了整个框架的 CSS，用 @layer 分层，彻底避免了覆盖和竞争问题。并且由于有 e2e 测试，重写后基本不需要花时间验证。

[WIP]