个人网站、博客与文档，为什么正在变成同一种产品？
当个人网站开始承载文章、项目复盘与资源库，它需要的不只是发布页面，而是一套连接品牌表达、时间脉络和结构化知识的内容系统。
Orbit Studio 从零开始时，我只是想搭一个能够代表个人工作室的网站。首页先被做出来，后来才逐渐加入博客和内容。
一开始，一个文章列表、一个详情页，再加上 Markdown，听起来就够了。但真正开始整理内容后，事情很快发生了变化：有些文章是仍在推进的实践笔记，有些是需要保留上下文的项目复盘，还有一些不是文章，而是以后会反复查询的字体资料和工具清单。内容开始需要分类、更新、互相引用，也开始出现中英文版本和交互组件。
这时我意识到，我需要的已经不只是“一个可以发布文章的页面”，而是一套能够长期承载内容的系统。
这也是我越来越难把个人网站、博客和文档看成三种完全不同产品的原因。
三种网站，原本解决三个问题
传统上，它们的分工很清楚。
| 形态 | 主要回答的问题 | 常见结构 |
|---|---|---|
| 个人网站 | 我是谁，我做过什么 | 首页、关于、项目、联系 |
| 博客 | 我最近写了什么 | 文章流、标签、时间归档、RSS |
| 文档 | 一个主题应该如何被理解和使用 | 内容树、侧栏、目录、搜索、版本 |
这三种结构并没有消失。真正发生变化的是：当一个人开始长期在网上积累内容，他往往会同时需要三者。
个人网站需要建立第一印象；博客需要保留作者的声音和时间脉络；文档需要让旧内容继续可查、可理解、可更新。只选择其中一种结构，通常都会遗漏另外两种价值。
内容一旦开始积累，时间就不再是唯一入口
普通博客习惯按发布时间排列文章。这对“最近发生了什么”很有效，却不一定适合“以后怎样找到它”。
例如，一篇关于字体选择的文章，发布当天是一篇博客；半年后，它更像一份参考指南。如果继续补充授权信息、字体预览和 CSS 字体栈，它甚至会逐渐变成一个小型工具。
内容的价值会随时间改变：
一次发布
↓
持续被搜索和引用
↓
根据新信息更新
↓
与其他文章形成主题
↓
成为知识结构或工具这时，只有发布日期和标签已经不够。读者还需要知道：
- 这篇内容属于哪个主题；
- 它和哪些文章相关；
- 应该先读什么、后读什么；
- 哪些结论仍然有效；
- 哪些数据已经更新；
- 有没有更适合直接查询的资源页。
这正是文档系统擅长解决的问题。
AI 改变的不只是写作速度，也改变了内容维护方式
过去，一个人维护网站时，页面数量和更新成本往往直接相关。文章越多，整理、改写、翻译和检查链接就越困难。
现在，Coding Agent 可以直接参与文件式内容工作流：
- 从项目记录中提炼文章；
- 根据统一结构整理 Markdown 或 MDX；
- 检查中英文内容是否成对；
- 更新多个页面之间的链接；
- 根据代码和决策记录修正文档；
- 把一次调研沉淀为文章、方法和资源表。
这并不意味着 AI 会自动产生好内容。它真正降低的是“维护结构”的成本。作者仍然需要决定什么值得写、哪些判断能够公开、什么是事实、什么只是阶段性推断。
当维护成本下降后，个人网站就有机会从一组静态页面，变成一个持续生长的内容产品。
MDX 让文章与工具之间的边界也变模糊了
Markdown 适合写作，但个人内容往往不只包含文字。项目复盘可能需要时间线，设计文章可能需要图片对比，资源页可能需要搜索和筛选。
MDX 的价值不是让作者在文章里随意写 React，而是允许内容在必要时拥有更合适的表达方式：
- 普通文章继续使用标题、段落、列表和表格；
- 决策内容可以使用 Callout 和对比卡片；
- 图片密集的内容可以使用 Gallery；
- 资料库可以加入筛选和预览；
- 项目实践可以嵌入可交互的领域组件。
Orbit Studio 的字体库就是一个例子。它仍然属于 Blog 的 Resources，但已经不再是普通文章，而是一个可以按场景、语言和授权方式筛选的内容工具。
内容不必为了交互能力离开写作系统，网站也不必为了增加一个工具就新建一套平行的数据结构。
Orbit Studio 最后形成了两层，而不是一种页面
Orbit Studio 的首页和 Blog 承担完全不同的任务。
Orbit Studio
├── 品牌层
│ └── 单屏首页、主张、氛围和记忆点
└── 内容层
├── Notes：实践笔记与技术选择
├── Reflections：项目复盘与长期思考
└── Resources：工具、资料与可查询内容首页需要低信息密度。它不应该为了“看起来完整”，堆满尚未成熟的项目、能力列表和行动按钮。它负责让人记住 Orbit Studio 是什么，以及 Leon 为什么在做它。
Blog 则需要稳定的阅读结构。侧栏、文章目录、前后关系、移动端导航和内容分组，都比首页的视觉表现更重要。
这带来一个对我很重要的判断：
品牌首页与内容系统可以共享同一个网站，但不必共享同一种页面逻辑。
如果让首页完全服从文档主题，品牌表达会变弱；如果让所有文章都使用首页的动态背景和海报式布局，阅读体验又会受到影响。真正合理的做法，是让它们共享品牌、域名、语言和内容来源，同时各自完成自己的任务。
不是每个个人网站都需要文档系统
把博客做成知识库并不天然更高级。结构越多，维护规则也越多。
如果你只想偶尔发布随笔，文章彼此独立，时间流就是最自然的入口，那么普通博客已经足够。Astro、Next.js 的简单内容模板，甚至现成的托管博客，都可能比完整文档框架更合适。
当下面这些情况开始反复出现时，文档能力才真正有价值：
- 内容形成了稳定主题，而不只是时间归档；
- 经常更新旧文章，而不是只发布新文章；
- 需要系列导航、侧栏或目录；
- 同时维护教程、复盘、资料和工具；
- 文章中需要可复用的交互组件；
- 需要多语言或多个内容版本；
- 希望同一份内容继续服务搜索、OG 或机器可读输出。
判断标准不是文章数量，而是内容之间是否已经出现了结构。
个人网站正在成为个人的内容产品
个人网站过去更像一份可以访问的简历，博客更像公开日记，文档则属于软件和组织。
但对长期创作的人来说，这三种边界正在变得模糊。网站需要表达身份，内容需要保留作者的观察，知识又需要被组织和持续维护。
我最终没有在“个人网站”和“文档站”之间二选一。Orbit Studio 的首页继续负责建立记忆，Blog 负责长期积累。
意识到自己需要的是内容系统，只解决了第一个问题。接下来更现实的问题是：Fumadocs、Nextra、Rspress 和 Starlight 之间，到底应该怎么选？