你现在看到的 Hexvork，前身叫雨砚Blog。
那是 Hexo + Butterfly 主题搭的，2025 年前后上线，用了不到1年。前前后后写了4篇文章，换过几版主题配色，域名也从 yuyano.com 折腾到现在的 hexvork.com。说实话，那时候对”网站”这件事的认知很浅——博客就是 Markdown 扔进去、hexo g && hexo d 部署完，完事了。
Hexo 就是那种 很省心 的框架。你装好主题、配好 _config.yml，之后唯一的变化就是往 source/_posts 里塞文件。省心，但封闭。
一、Hexo之旅
Hexo 的设计哲学说白了就是：快速上线，简单维护
生成、部署、渲染，全在它自己的体系里跑。主题配置锁死在 YAML，Markdown 渲染靠插件链，URL 规则也是框架帮你定好的。当你需要的只是”写博客”这件事，它一点毛病没有，甚至很好用。
但当你想做点”出格”的事情，Hexo 就开始让你难受了。
要么找插件。插件还不一定有人维护——你想用的那个插件，last commit 可能是两年前，issue 里一堆报错没人回。
要么改源码。Node.js 的 Hexo 内部逻辑，生成器、处理器、渲染器套了好几层，翻起来真的折磨。
有一说一，Hexo 的”开箱即用”至今没有第二个静态博客框架能追上。十分钟上线一个能看的博客，但到了 2026 年，当 AI Agent 能直接帮你写组件、改路由、生成结构化内容的时候——Hexo的优势似乎就发挥不出来了。
你没很难让 AI 帮你改主题布局，因为它能看到的就是一堆嵌套的pug文件、 YAML 和 EJS 模板片段；你很难让 AI 帮你加新功能，因为插件体系不是你说了算的；你甚至不能精准找到报错点，因为Hexo是一步错，步步错，一长串的报错信息直接涌现出来打你个措手不及。
二、转到 Astro
转 Astro 的契机其实很偶然。
当时看到二叉树树的astro-fuwari博客，觉得它的主题和代码结构都挺好，定制化还更好，就想着要不迁移过去？
那就试试呗。
但是，被astro-fuwari束缚住的感受让我很难受，因为现在网上的 Astro 网站，几乎千篇一律都是fuwari，显得我的博客毫无特色，于是我动用AI打造出来了现在的网站
Astro 的第一感觉：这才是”我的网站”，不是”框架的网站”。
Astro 给你的不是一个闭合的模板系统，而是一个前端框架。你能直接写 .astro 组件、.ts 路由、TailwindCSS 原子类——所有东西你都能碰、都能改。想改布局就改组件，想加路由就新建文件，想自定义 Markdown 渲染就写个 Remark 插件。每一步都是标准的前端操作，不是对着 Hexo 的 _config.yml 猜”这个参数到底有没有用”。
而且AI Agent 能看懂你的全部代码。你打开 Trae / Cursor，AI 能看到完整项目结构——组件、路由、样式、配置——然后直接帮你改。我这种只在周末 Vibe Coding 的人，靠 AI Agent 硬是把一个个人博客折腾出了接近商业站点的 SEO/GEO 配置。
三、Astro带给我的启发
这一段不是教程，只聊聊建站过程中真正刷新认知的东西。
Sitemap深度优化
以前用 Hexo 的时候，Sitemap 就是一个插件——装上、启用、然后忘了。它生成了什么、格式对不对、搜索引擎能不能正常解析，我完全不知道。
到了 Astro，@astrojs/sitemap 虽然是零配置集成，但你会自然地去关注它到底生成了什么——因为你已经在有意识地管理站点路由结构了。robots.txt 也要顺手写好，把 Sitemap 地址声明进去，再配合 Cloudflare 的 _headers 做缓存策略。
这些事情单拎出来都不难。但在 Hexo 体系里你根本不会想到要去做——框架帮你”屏蔽”了这些细节，换个说法就是：你也失去了理解这些细节的机会。
LLMs.txt
LLMs.txt 是 2024 年才冒出来的东西，说白了就是一个专给大模型和 AI 搜索引擎读的网站索引文件。你的网站有 LLMs.txt，AI 在回答用户问题的时候，就有更大可能引用你的文章内容。
听起来很虚是吧？但实际效果挺实在的。
我在 Astro 里写 llms.txt.ts 也就三十几行，从 astro:content 的 posts collection 动态拉取文章列表，生成 Markdown 格式的索引。以后发新文章自动更新，零维护成本。后来还顺手装了 astro-llms-md，准备做 llms-full.txt 全文版，给 AI 提供更深的内容入口。
这个功能在 Hexo 那边要实现，要么等社区出插件（大概率没有，连讨论都没有），要么自己在 GitHub Actions 里写脚本手动生成。而 Astro 这边就是一个 30 行的 .ts 端点，直接跑在构建流程里，跟写一篇文章差不多轻松。
这些事情在 Hexo 里也能做，但你会觉得是在”跟框架打架”——绕插件、改源码、hook 构建流程。在 Astro 里，你会觉得是在”搭建自己的基础设施”——心态完全不一样。
四、心里的蜕变
名字换了，域名换了，框架换了。但最核心的变化其实是心态：从 **“用博客框架写文章”**变成了 “用前端工具搭建自己的内容平台”。
以前发文章：打开 VS Code → 写 Markdown → hexo g && hexo d，没了。
现在发文章：顺手优化一下组件响应式、调整 SEO meta 字段、给 LLMs.txt 加个新参数——不觉得是额外工作，反而乐在其中。
五、建站建议
如果你现在还在用 Hexo，且觉得”挺好的，够用”——那就继续用。
Hexo 不差。它做到的”开箱即用”，至今没有第二个静态博客框架能超越。不是每个人都想当”全栈博主”，大多数人确实只需要一个能写文章的地方。
但如果你想掌控博客的每一个细节，想让 AI Agent 帮你开发和维护，想真正理解一个现代网站是怎么运作的——上 Astro 吧。
学习成本有，但不高。我一个只在周末 Vibe Coding 的人，靠 AI Agent 帮忙，几个月下来已经把全站搞得像模像样了——Sitemap、LLMs.txt、CSP、预取、结构化数据，该有的都有。
希望我能在Astro的路上越走越远。