2022 年搭第一个博客的时候，我的目标很简单：有个地方发文章。
四年后这个站有 118 篇文章、6 个栏目、7 部书系、262 个标签。它还叫博客，但我对它的期待早就变了——我不再想要一个「按时间倒序排列的文章列表」，我想要一份能查阅、能重读、文章之间能互相指路的出版物。
这个转变不是某天想通的。是 118 篇文章堆到一定程度，旧结构撑不住了，才被迫改的。
这篇记录我现在的理解，也是这个系列的总纲。
01 博客和出版物的区别
博客的默认结构是时间轴。最新的在最上面，往下滑是越来越旧的东西。这个结构有个隐含假设：文章是一次性的。
出版物不是。出版物假设你会回头翻，假设第 3 章和第 17 章有关系，假设有人从中间开始读也能读得懂。
我第一次意识到这个问题，是发现自己想引用三个月前写的东西，却想不起那篇叫什么。站内搜索能搜到，但我当时压根没想到去搜——我根本不记得自己写过。
折腾个人博客三年，我终于想明白了什么里我写过一件事：写了两百多篇又删掉了一百多篇。删掉的大部分是「一次性」的。留下的那些，值得被组织起来。
02 内容系统的三层
现在的结构是三层，各管一件事：
栏目（Category）回答：这是什么类型的文字。
技术、教程、思考、随笔、工具、游戏。只有 6 个，从 10 个精简下来的。分类太多等于没有分类——这是我犯过的错，10 个分类里有 4 个长期只有两三篇文章。
栏目不是文件夹，是编辑口径。博客配置三层架构：框架层、站点层、内容层的职责划分里我把它叫「三层」，现在看，内容层这一层最关键：它决定了读者在什么语境下遇到这篇文章。
书系（Series）回答：这篇和哪些篇是一伙的。
这是最近才补上的一层。之前只有 4 部书系、21 篇文章有归属，剩下 97 篇全是散的。这次新建了「个人出版物」「AI 开发工作流」「选择与放弃」三部，把散落的文章按主题串起来。
书系是有阅读顺序的。从零开始 → 使用指南 → 博客手记，一个人照着走能把这个站从头用到尾。
标签（Tag）回答：这篇提到了什么。
262 个。太多了，我知道。标签是最容易失控的一层，因为它没有成本，写一篇加三个，四年下来就成了这样。
我现在的做法是：不再主动增加标签。已有的留着当检索入口，新的尽量复用。真正该增加的是书系和文章之间的关系，不是标签。
03 为什么保留 Archive
Archive 是这个站里访问量最低的页面之一。我留着它，因为它承担一个不可替代的功能：证明时间是连续的。
2022 到 2026，每个月写了几篇，哪几个月是空的，一眼能看出来。有一次我翻 Archive，发现 2025 年 11 月到 2026 年 1 月只有两篇——那三个月我在做别的事。这个信息，文章列表给不了我。
为什么我选择自建博客里我说在乎数据所有权。Archive 是这件事的具体形态：不是我拥有文章文件，是我拥有它们的完整时间线。
04 双向链接为什么值得做
[[像这样的语法]]，鼠标悬停能预览目标文章的开头。
技术上不复杂，一个 remark 插件加一份标题映射表。难的是养成用的习惯。118 篇里只有 24 篇用了它，65 处链接——这个数字低得难看，是这次改造最想补的部分。
双向链接的作用不是「让网站看起来更高级」。是强迫我在写的时候想：这句话和什么有关。
写着写着发现自己在引用半年前的某篇，说明这两篇之间确实存在关系，只是我之前没意识到。这种发现，比任何标签系统都准。
双向链接只是工具里我提醒过自己别神化它。现在补一句：也别因为它只是工具就不用。
05 Frontmatter 怎么设计
现在一篇文章的头部长这样：
title: ''
description: ''
pubDate: 2026-09-09
category: '思考'
growth: bloom
tags: ["..."]
series: ''
seriesOrder: 1
seriesId: ''几个带着教训的字段：
- description 一定写。 它出现在首页、书系页、搜索结果里，是文章真正的门面。标题起得好不如描述写得准
- growth（seed / bud / bloom）。 标记这篇文章的成熟度。seed 是刚冒头的想法，bloom 是我愿意为之负责的结论。这个字段让我能诚实地对待旧文章——不是所有文章都该被同等信任
- seriesOrder 要显式写。 靠日期推断顺序在书系里会出错，因为写作顺序 rarely 等于阅读顺序
- pubDate 的时区。 踩过最大的坑。裸日期会被 JS 按 UTC 零点解析，北京时间早上八点前构建，当天文章上不了线
博客写作语法指南和云图札记博文写作规范里有完整规范，那两篇是长期维护的文档型内容，不是一次性文章。
06 为什么要做 Changelog
站点有 40 多个版本记录。做这个的初衷很朴素：我想知道这个站变成现在这样，中间发生了什么。
Changelog 对外是透明度，对内是记忆。改版三年后，我早就记不清 v1.3 长什么样了，但翻一下记录就知道那次是把蓝色主题换成绿色，为什么换，换了之后哪里不满意。
博客本身是这个站最大的项目，它值得有项目日志。
07 一百多篇文章怎么管
四个笨办法：
- 每篇都写 description。 三个月后我自己也记不住标题背后是什么
- 定期回头改。 发现旧文章说错了，直接改，加 updatedDate。不改的话错误会一直留着
- 文档型内容单独对待。 博客写作语法指南这种，维护比发布重要
- 删。 一次性内容该删就删，我删过一百多篇
第 2 条是我这两年才开始做的。以前觉得发布完就不该动，现在觉得正好相反——发布只是开始。
08 搜索
用的 Pagefind，构建期生成索引，纯前端检索，没有后端。
选它的理由很简单：静态站不应该为一个搜索框引入服务端。博客搜索方案横评：客户端索引 vs 服务端搜索 vs 第三方服务里对比过三种方案，结论对个人站来说没什么悬念。
Astro 5 Content Layer 迁移实录，我的博客构建快了 5 倍记录了另一次提速。118 篇的构建时间从四十多秒降到八秒左右——这个数字在文章破两百之前都还能接受。
09 图片、字体和性能
博客图片优化实战：体积减少 60% 的量化对比和字体这件事，我折腾了三轮是这部分的详细记录。
简单说三条经验：
- 图片走构建期转换，生成 WebP 和 srcset，不要手动压缩
- 字体自托管，不挂 CDN。Google Fonts 在国内的不稳定性不值得赌
- 中文字体是性能杀手。子集化或者接受首屏 FOUT，二选一
10 部署
GitHub Actions 构建，产物分发到 CDN，全站无后端。
这条链路跑了两年多，中间翻过车：博客 FOUC 闪屏事故复盘：样式加载顺序引发的 200ms 白屏Cloudflare Pages 部署 404 排查：三篇文章消失的始末。两次都是部署窗口期的缓存问题，排查时间比修复时间长。
Astro 博客部署运维进阶：从手动发布到自动化流水线和GitHub Actions 跑了半年，这些坑我替你踩过了是这条链路的完整记录。
这个系列的其他文章
按阅读顺序：
- 为什么我选择自建博客——为什么要自己搭
- 折腾个人博客三年，我终于想明白了什么——前三年的教训
- 云图札记的数字园丁计划——从博客到数字花园
- Grove 架构全景：从一行 Markdown 到浏览器里的页面——完整技术架构
- Astro 5 Content Layer 迁移实录，我的博客构建快了 5 倍——构建提速
- 博客搜索方案横评：客户端索引 vs 服务端搜索 vs 第三方服务——搜索选型
- Astro 博客部署运维进阶：从手动发布到自动化流水线——部署链路
- GitHub Actions 跑了半年，这些坑我替你踩过了——CI 踩坑
- 118 篇文章以后，我重新理解了博客——这次改造的收尾
最后
这个站现在的问题不是文章不够，是文章之间的关系还不够密。262 个标签解决不了这个问题，7 部书系也只能解决一部分。
剩下的部分，只能靠一篇一篇去补链接。慢，但没有捷径。