第三代站点是迄今为止最大的升级，因为在新站点中，我不再使用现成的主题，而是尝试自行构建一个全新的站点。当然，代码编写主要由Agents完成，我只负责阅读文档、指定需要完成的功能与设计。
兜兜转转又到Hugo
在建站之初，我使用Hugo作为站点生成器，随后迁移至Astro，在大约一年的体验后，我又回到了Hugo。其中的原因有很多，也包含了我的一些想法转变，从最终的体验看，我认为Hugo仍旧是SSG（静态站点生成器）的最佳选择之一，尤其是构建小型站点和个人博客。
至于Astro，体验也相当不错，但是在愈发深入的了解中，我觉得它并不总是适合构建个人博客，至少与我目前的需求有些错位。在我们将Astro当作SSG前，它首先是一个Meta-Framework（元框架），它包含了大量的功能，能够使用不同语言的组件，但是仔细想想，一个个人博客真的用得上吗？
Astro的Meta-Framework定位让项目起步非常棘手，你需要自行实现几乎所有的上层功能，Astro能够预先提供的功能是很有限的。实际上，第三代博客的建造开始于今年2月，我尝试从零开始使用Astro构建一个站点，在接近五个月的时间里，各项功能不断被打磨与重构，然而最终还是成为了废案。灵活可变也带来了更多的修改空间、更大的不可控性，这是一个LLM主导项目不愿遇到的情况。
Astro还会遇到一个AI时代特有的问题，疯狂的供应链投毒，尤其是Astro基于Node.js，而Node.js正是供应链投毒的重灾区。以前的投毒需要作案者潜伏多年，而现在的投毒，或许只需要对Claude Mythos 5简单说一句话。
Hugo正好满足我的需求。它专为构建静态站点而生，内置了大量基础功能。更重要的是，它以Go编写且以单一二进制文件形式发布，快且安全。在这个独特且前所未有的时代，Node.js和它庞大的包生态正在从一个百宝箱变为危险又泥泞的毒沼。对于非相关专业、想要建站或是迁移站点的站长，我建议使用Hugo或者类似的站点生成器，至少应该离Node.js远一些。
驱动LLM
作为有过一些编程基础的人，在AI时代，我已经完全退化为只会编写提示词的生物。以我这些天指挥Agents的体验来看，Hugo在AI时代也活得很好。
Astro有其类HTML的语法优势，还有TypeScript的加持。相比之下，Hugo所使用的Go Template则一直被人诟病“语法反人类”，但是没有关系，因为LLM确实也不是人！Hugo在漫长的岁月中积攒了足够多的社区资料与开源主题，这些语料足以让Agents编写出功能正常的Hugo站点。
至于代码是否优雅且可长期维护，多拷打它们几轮，总会变好的。
类似定位的SSG还有Zola，但是我并不推荐Zola，即使它使用Rust编写。Zola起步太晚、生态太小，这类小众的工具在AI时代注定是更容易消亡的那个。Hugo可以凭借着“资料丰富、Agents使用率上升、产生更多语料并促进项目发展”的数据飞轮起飞，而Zola大概率会在第一步倒下。有种AI时代React和Vue.js的既视感。
Hugo的构建速度在Agents手上是一个极大的优势，对于本项目，一次带有缓存的严格构建仅需一秒不到的时间，在网络畅通的情况下，一次全新构建也仅需30秒。Agents能够很方便地通过构建获得明确的反馈，而不是浪费大量时间在等待测试结果上。一个包含完整测试套件的Astro站点，我的上一个Demo，运行一个完整的Biome+Astro+Vitest+Playwright流程，需要大约2分钟。
对于Agents，我们完全可以在提示词中要求使用最严格的构建参数：hugo --environment production --cleanDestinationDir --panicOnWarning --printI18nWarnings --printPathWarnings --printUnusedTemplates --minify --gc，这足以在构建期发现大部分样式以外的问题。
除此之外，还可以适当引入辅助工具，例如负责格式化Go Template的gotmplfmt、负责格式化其他文件的Prettier/Biome/Oxfmt、负责端到端测试的Playwright等等。当然，部分工具是基于Node.js生态的，是否值得引入取决于个人需求。
不需要JavaScript
作为一个“极端”的站长，我总是愿意在站点中测试各种新的想法与需求。而在这个全新的站点上，我决定不再让前端页面出现JS。实际上整个项目也没有使用JS或TS。
“前端0JS”的目标有些极端，但是对我、对Agents而言，这是一个极好的鞍具。严格一刀切能够让我们专注于已有功能的打磨，而不是尝试用“无所不能”的JS实现天花乱坠的功能。在项目中期，我也曾考虑过适当使用JS以改善体验，但是转念一想，开了这个口子就可能越开越大，最后还是将这个目标坚持了下来。
对于普通的站点与站长们，我认为倒也不用同样极端地实行“0JS”方针，一些核心功能，例如即时评论系统，或者一些改善体验的功能如主题切换按钮，这些是值得留下的。而很多需要JS的花里胡哨的功能，例如音乐播放器或是Live2D，就应该思考是否必要了。
至于有观点认为“无JS其实没有很重要”，我认为这个观点还是太绝对了。对大部分用户而言，页面上是否使用了JS确实无关紧要，但是总有些人出于隐私需要禁用JS，总有激进的开发者喜欢Plain HTML，对他们而言，无JS其实很重要。
非即时交流
纯静态前端，自然是无法做到即时评论系统的。即使是非常另类的“近即时”方案，例如留言表单发送邮件，触发评论提交与自动构建，也需要一定的时间，还可能引入其他风险。
在与LLM的头脑风暴后，我最终采用“表单+手动新增评论”的方案。这个方案最大的缺点就是非实时，留言者无法在留言后立刻看到自己的发言，但是我觉得这并不是什么问题。除此之外，表单的体验与一般的评论系统基本无异。
这个方案最大的好处就是参与感，因为所有被展出的评论不再是数据库里的一条数据，而是以Markdown的形式，存放于项目中。你的每一条可展示的评论，都会成为这个站点的一部分，你正在参与对我的文章的“再创作”。
为了体现出站点评论系统的区别，也为了下面提到的轻量化，我没有对评论部分进行过多的样式设计，让它们贴近正文的观感。
国人似乎不太习惯使用电子邮件，这是移除表单的最大阻碍，如果可以的话，其实我想只保留一个mailto链接，这样就不需要额外的表单服务商了。其实设置得当的mailto链接搭配能够打开链接的程序或是网页端，例如Gmail，体验并不会比表单差多少。
读书的体验
我对博客设计的看法，也是促成“0JS”目标达成的一大原因。我使用过很多主题，也造访过很多其他站点，但是能让我“读得舒适”的博客并不多，所以我希望这个站点能有纸质书籍般的体验。
纸张给人的感觉是轻量的，所以我将这个站点也变得很轻量。首页传输大小约22KB，整体设计简单克制，让内容成为站点核心。我曾造访过一个博客，首页传输大小约20MB，与下载一个普通软件无异。显然个人博客不需要这么重，即使是有自己的美学追求，想要引入额外的字体，5MB也已经非常富余了。
本站文章页的大小肯定会超过首页，但是在“0JS”的约束、主题设计的克制与AVIF的先进性能帮助下，最大的一篇文章也不会超过1MB，应该是可以接受的吧？
为了带来更舒适的阅读体验，我参考Flexoki设计了一套颜色，在通过无障碍指标的同时，保证阅读的舒适性，页面整体更柔和、不刺眼。由于“0JS”的约束，我无法实现手动的主题切换，所以我干脆只设计了一套亮色主题，也就是说我并不推荐你在暗光甚至无光环境下访问本站点。光线不充足的情况下盯着屏幕对眼睛也不好。
我认为最重要的调整是排版。很多站点的设计非常好看、非常有想法，但是它们更像是一个展品，展示的是站点本身，文字成了被忽略的部分。大部分博客的默认字体大小并不适宜阅读，行间距、每行字数也没有仔细调整，或许在现代互联网上，这种现象很常见，但是阅读体验不佳也是客观存在的问题。在此站点上，我提供了更大的字体与行间距，每行字数也被控制在最佳范围内，希望你读得开心。
前面提到了引入额外字体，但是我没有这样做，引入一种字体增加的2MB足以毁掉我为轻量化所做的所有努力。曾经我也以为各大系统的默认字体，尤其是Windows，奇丑无比。然而将默认字体放大后，其实它们没有这么不堪，我认为我使用的字体栈，足以提供良好的阅读体验。如果你认为字体显示效果一般，可以尝试安装思源黑体与思源宋体，或是在浏览器中指定自己喜欢的字体。
除此之外，还有更多的设计与小细节，等待各位读者体验。
更简单一点
因为本站点主要发布动画观后感，以季度为单位，曾经的我总是想设计一套完善的分类系统，让站点能够像图鉴一样结构清晰、易于查询。但是后面我意识到，其实尽情使用标签就足够，之前设计的复杂的参数查询、父子标签等等，都只是因为标签用得还不够多。
现在我给TV动画打上了“总览+季度”两个标签，后续有需要还可以拓展，不过我想目前的分类已经足够清晰。
页面也可以更简单，除了文章页、标签页，剩下的话其实都可以放在关于页，不需要更多的拆分；同样的，我在设计站点顶部的导航时也遇到了很多问题，小小的一行空间很难容纳我曾经设想的各种页面和路径，但是现在我全部移除了。
页面所能容纳的元素是有限的，读者的注意力也是有限的，将有限的资源分配给真正重要的部分，应该是很合理的策略。不是所有人都追求极致的简单，但是起码不应该打扰到读者正常的阅读。
痛点
此站点做了很多尽力而为的优化以改善体验，但是备案仍然是无法逾越的高墙，没有备案意味着难以使用国内云服务商的各种服务。目前此站点部署于Vercel，因为在总结大量前人的经验后，Vercel在默认状态下的可联通性应该是优于Cloudflare和Netlify的。至于“优选”这种违反ToS的操作，还是等以后真的走投无路再做吧。
至于其他部分，我个人没有感受到什么不适，或许这很大程度上是因为我的需求比较简单，两年多的沉淀让我意识到，我只是需要一个存放并展示想法的地方，文字本身才是最重要的。
沿途风景
在设计与构建这个站点，包括被弃用的Astro Demo时，我拜访了很多站点以获取灵感，以下是一个我认为值得记录下来的站点列表：
本站的诸多灵感来源，甚至可以说是新项目的起点，我在其中得到了很多站点优化的经验。站点的其他内容也非常有趣。
如果想要快速吸收这位站长的经验，可以直接查看站点的CHANGELOG页面，都是些非常值得参考的记录。
本站的部分样式来源，单纯依靠文字排布的设计很合我口味，充分体现了文字之美。
由于我是一个没什么设计天赋的人，所以我一开始的目标就是基于现有的项目二次改进。上一个Demo仿照的是Bear Blog。
一个Tufte样式的个人站点，使用Typst编写内容、Python构建，非常独特且有个人风味。不过我没有采用宽大的侧边栏布局，因为我的文章很少使用注释。
顺带一提，作者开源的Tufted-Blog-Template主题，附带非常新手友好的指引，推荐非技术背景、无经验的新手站长尝试。
一个非常有想象力和设计性的横向阅读的站点，模仿了大开本纸媒的分栏设计。这个横向、分栏的设计只能在大屏幕上工作，多少有点可惜。
尾声
由于我已经不再使用主题，目前版本的博客可能以不断微调的形式持续下去，类似宣称自己是“最后一代Windows”的Windows 10，我相信这一次能够坚持得比之前更久，因为Hugo生成的站点并不会要求我每天更新依赖，不使用主题意味着也不需要我紧跟上游变动。我要做的只有静静发布文章，不时要求Agents在站点上实现一些奇思妙想罢了。