把个人网站做成长期内容系统

这个项目一开始看起来只是一个个人网站，但我更想把它做成一个能长期使用的内容系统。

它不是为了堆很多页面，也不是为了做一个一次性作品集。真正的目标是：让我有一个可以持续写作、整理技术文章、记录项目、归档生活片段的地方，而且维护成本足够低，低到我愿意一直用下去。

为什么做这个项目

很多内容会被时间流冲走。社交平台适合即时表达，但不适合长期整理；笔记软件适合私有记录，但不天然适合公开展示；纯博客系统又容易在配置、主题、插件和迁移里消耗太多精力。

所以这个网站的定位是一个折中点：

内容用 Markdown 保存，方便迁移和版本管理。
页面由 Astro 静态生成，速度快，部署简单。
编辑体验尽量接近日常写作，不要求每次都打开代码编辑器。
分类、标签、归档和搜索把内容重新组织起来，而不是让文章散落在时间线里。

我希望它像一个慢慢生长的工作台：技术文章、项目复盘、生活记录都能放进来，但每一类内容都有清楚的位置。

项目目标

这个项目的核心目标有四个。

第一是低维护。网站不应该需要一整套复杂后端，也不应该依赖很重的数据库和管理面板。内容本身是最重要的，技术栈要服务写作，而不是抢走写作的注意力。

第二是可持续写作。写一篇文章、改一段描述、补一个项目状态，应该足够轻。内容结构越清楚，后续越容易继续写。

第三是可检索。个人网站内容一多，首页时间线就不够用了。搜索、标签和归档不是装饰，而是以后找回旧内容的入口。

第四是可演进。今天它可以只是一个个人站；以后如果想加专题页、英文内容、项目日志、RSS 优化或更强的编辑工作流，当前架构要能接得住。

技术栈

当前技术栈主要由几部分组成：

Astro：负责页面路由、内容集合和静态生成。
TypeScript：让内容 helper、搜索索引和页面数据处理更可靠。
Tailwind CSS：提供基础样式能力，同时保留少量全局 CSS 处理正文排版。
Markdown / MDX：作为主要内容格式，方便写作、review 和迁移。
Keystatic：提供内容后台，让编辑文章不完全依赖代码编辑器。
Cloudflare Pages：负责部署和托管，适合静态内容站点。
GitHub Actions：跑测试、类型检查和构建，保护主分支。

这套选择的重点不是“技术新”，而是组合起来足够轻：内容存在仓库里，页面可以静态生成，部署链路简单，出了问题也容易定位。

整体架构

网站大致分成四层。

Markdown 内容
  -> Astro Content Collections
  -> 页面、搜索索引、标签和归档
  -> Cloudflare Pages 部署

第一层是内容。文章、生活记录和项目都放在 src/content 下，每一种内容都有自己的 collection schema。

第二层是内容模型。Astro Content Collections 负责校验 frontmatter，比如标题、描述、日期、标签、草稿状态和项目技术栈。

第三层是展示和索引。页面根据 collection 生成列表页、详情页、标签页、归档页和搜索数据。搜索不是临时扫页面，而是根据内容构建结构化索引。

第四层是发布。代码进入 PR 后跑 CI，合并到主分支后再由部署平台发布。

这种架构的好处是边界清楚：写内容时关心 Markdown，开发页面时关心组件和数据流，发布时交给自动化。

内容模型

现在网站主要有三类内容。

notes 用来放技术文章、思考和较完整的笔记。Git 和 Docker 这类文章就属于这一类。

journal 用来放更生活化的记录。它不需要像技术文章一样结构很重，但仍然保留日期、标签和草稿状态。

projects 用来放项目。它更像作品卡片加 case study，除了标题、描述和日期，还会记录状态、技术栈和相关链接。

这三类内容共享一些基础字段，但不会强行套成同一种结构。技术文章需要标签和正文层级；项目需要状态和技术栈；生活记录需要更轻的表达空间。内容模型越贴近实际写作，后面越不容易变形。

内容编辑体验

一开始只用 Markdown 就足够，但长期看，内容编辑需要一个更友好的入口。

Keystatic 在这个项目里承担的是“轻量内容后台”的角色。它不把内容搬到数据库里，而是在仓库内容之上提供编辑界面。这样既保留了 Git 管理内容历史的能力，也让日常修改标题、摘要、标签和正文更顺手。

我希望编辑体验满足几个原则：

写文章时不需要理解页面实现。
frontmatter 字段尽量有约束，减少手写出错。
草稿可以留在仓库里，但不会出现在公开页面。
内容修改仍然可以通过 Git diff review。

这比传统 CMS 更轻，也比纯手写 Markdown 更适合长期维护。

搜索、标签和归档

当内容少的时候，首页列表就够了。但只要文章开始积累，就需要新的入口。

搜索解决的是“我记得写过，但忘了放在哪”的问题。它会覆盖标题、描述、标签和正文摘要，让内容可以被关键词找回。

标签解决的是主题聚合。比如 Git、Docker、开发流程、工具这些标签，可以把分散在不同时间写下的内容重新串起来。

归档解决的是时间维度。它不负责推荐，只负责提供一个稳定的历史视图。对个人网站来说，归档页很重要，因为它让内容有一种慢慢沉淀的秩序感。

这三个入口加在一起，让网站不再只是“最新文章列表”，而更像一个可以被反复访问的资料库。

自动化与发布流程

这个项目的发布流程尽量保持简单：

本地修改
  -> 提交到功能分支
  -> Pull Request
  -> CI 检查
  -> 合并到 main
  -> Cloudflare Pages 发布

CI 会检查测试、Astro 类型诊断和生产构建。它不是为了追求流程感，而是为了避免一些低级问题进入主分支，比如内容 schema 错误、页面构建失败、搜索 helper 行为被改坏。

对个人项目来说，自动化还有一个隐性价值：减少心理负担。只要每次合并前有固定检查，就不用靠记忆判断“我是不是漏跑了什么”。

取舍：为什么没有做得更重

这个项目刻意避开了一些更重的方案。

我没有一开始就接数据库，因为目前内容量和交互需求都不需要。Markdown 文件更容易备份、迁移和 review。

我没有做复杂权限系统，因为现在主要是个人使用。Keystatic 已经足够覆盖内容编辑需求。

我没有把搜索做成后端服务，因为当前站点规模下，静态搜索索引更简单，也更符合静态站点的部署方式。

我也没有把设计做成很强的营销页风格。这个网站的核心是阅读和整理，不是转化。视觉上更适合安静、稳定、可长时间阅读。

这些取舍背后的原则是：先让系统长期可用，再考虑复杂能力。一个个人网站最怕的不是功能少，而是维护成本高到自己不愿意再打开。

下一步

接下来我希望继续补三类能力。

第一是阅读体验。技术长文需要更好的目录、正文层级和代码块体验，让读者不迷路。

第二是内容工作流。后台使用手册、写作规范、标签规范和文章模板都可以继续完善，让后续写内容更省力。

第三是项目表达。每个项目不只是一张卡片，而应该逐渐形成完整 case study：目标、架构、过程、取舍、结果和后续计划。

如果这个网站能持续降低记录和展示的摩擦，它就不只是一个页面集合，而会变成一个长期可维护的个人知识空间。