把 1.0 的所有 post 都重写了一遍

把 1.0 的所有 post 都重写了一遍。看着旧标题里的乱码，像在打扫前任房客留下的房间。 1.0 是一年前刚学 Astro 时搭的。当时对 View Transitions API 还一无所知，所有过渡都靠 CSS opacity 配合 setTimeout 硬写。Tag 系统半途而废，分类只有「tech」「life」「misc」三种，根本没法体现思考的颗粒度。文末的「相关阅读」是手动维护的，每次新写一篇文章都要回头改 5 个旧文章的链接。 重写不是否定过去——是承认那时候的我，确实只能做到那样。每一篇文章的旧标题都还在 git history 里存着，不会真删。它们是档案，不是负债。但看着它们，仍然会有一种轻微的不适感——那种「我那时候怎么写成这样」的不适，是成长的副作用。 倒是想到了一个更深的问题：博客的版本号，到底是给读者看的，还是给自己看的？我猜是后者。只有作者自己知道 v2 比 v1 多了哪些看不见的细节——比如这次多了一个把每个 vibe 自动写入 SQLite 的小工具，多了一个基于 FTS5 的站内搜索，多了一个不依赖第三方评论服务的自部署评论系统。读者只看到「新版变好看了」，但好看背后的工程量他们不会数。 1.0 到 2.0 的跨越里，最大的收获不是技术上从 Astro 4 升到 Astro 5（升级本身只花了半天），而是认知上的：「博客不是文章列表，是思考的外化」。每篇文章不只是 URL，是某个时间点我对某个问题的判断。判断会过期，但过期本身也有价值——它让我看到自己的思维是怎么演化的。 所以我没打算做 v3。不是因为 v2 已经完美，而是因为从 v2 到 v3 需要的不是再写一遍，而是去读自己 v2 里没读懂的那些主题，再写一篇新文章。版本号的更迭应该是思考的更迭，不是界面的更迭。 2026 年看整个个人博客生态的变化也印证了这一点。Astro 5 已经把 View Transitions API 做成了开箱即用的一行配置，SvelteKit、Next.js 也都跟上；FTS5 在 SQLite 3.9 之后已经成为标准模块；连 MCP 这种「让 AI agent 操作博客」的工具都是 2025 年底才出现的。一年前需要自己拼凑的能力，现在都是 baseline。这反过来又降低了重写的门槛——新版本和旧版本之间的「技术债差」在变小，「思考差」在变大。所以未来博客的版本号可能不再是「技术大改」的标记，而是「认知阶段」的标记。