为什么搭建个人网站

这是我第一次搭建属于自己的独立网站。在此之前，我也会记录技术问题和学习过程，但这些内容往往分散在不同地方，缺少一个能够长期积累的入口。独立站点对我的价值，不是追求一个更复杂的展示页，而是获得稳定的 URL、可自主组织的内容结构，以及一个可以持续维护的记录方式。

先确定维护边界

这个站点选择 Astro 生成完全静态的页面，文章使用 Markdown 保存，搜索则由 Pagefind 在构建后生成静态索引。这个组合的核心不是技术名称，而是清晰的运行边界：访问时不需要数据库、CMS、运行时应用服务器或远程搜索服务。文章、样式和索引都在构建阶段确定，部署结果就是一组静态文件。

这种选择也意味着我接受一个明确的维护方式：内容修改进入版本库，每次变更通过构建与检查生效。首阶段不引入后台编辑器和动态接口，避免在内容还很少时就承担账号、数据库、运行时故障和额外安全面的成本。

AI 参与，但不代替决定

搭建过程中，AI 的角色是协助查找官方文档、拆解实施任务、编写测试与代码，并对变更做独立评审。这些工作能够加快信息整理和反复验证，但不会自动获得更宽的权限。站点要使用哪些真实资料、文章表达什么、变更是否合并，以及何时发布，仍然由我决定。

具体实施上，任务尽量按可验证的小步骤推进。新规则先通过失败测试证明缺失，再写最小实现让测试通过；遇到构建错误时，先确认错误发生在哪一层，而不是通过放宽校验让问题消失。这样做会多一些前置工作，但能够留下可重复执行的证据。

让内容错误显式失败

文章的 Frontmatter 不只是几个便于展示的字段，它也是公开页面的数据契约。标题和描述必须非空，日期必须有效，更新日期不能早于发布日期。slug 使用稳定的小写英文 ID，因为它将成为公开 URL 的一部分；分类与标签也使用注册表中的稳定 ID，显示名称可以调整，引用关系和 URL 不会因此改变。

如果文章引用了未注册的分类或标签，或两篇文章使用了相同的 slug，构建应当指出文件、字段和失败原因。这里不设默认分类，不自动改写 ID，也不跳过有问题的文章。让错误尽早暴露，比带着一个看似能运行、实际数据已经偏离的站点继续前进更可靠。

验证与发布权限

本地验证的统一入口是：

npm run verify

这条命令将串联类型检查、代码风格、单元测试、集成测试、静态构建与产物验证。它提供的是当前本地工作区的证据，不能代表 GitHub 上的检查、Cloudflare 预览或生产环境已经通过。变更进入合并前，还需要检查 diff、Pull Request 预览和实际构建日志。

验证命令也是站点维护契约的一部分。当后续增加页面、分类或搜索能力时，新检查应进入同一个入口，使本地与持续集成执行相同的基本流程。这样才能在变更规模增长时，仍然清楚知道哪些结论有自动证据，哪些环节还需要人工检查。

计划由 Cloudflare 根据 Git 分支构建预览与生产版本，但连接仓库、配置项目、合并主分支和发布都是明确的生产权限。AI 可以准备代码和本地验证结果，但不会因为本地测试成功就自动执行这些操作。

继续用真实内容迭代

第一篇文章的意义，是把站点从一组结构和规则变成真正可维护的内容起点。后续迭代会从真实的写作需求出发：当文章数量增长、阅读和检索中出现具体问题时，再补充必要的功能。这样的节奏可以让每一次复杂度增长都有明确原因，也让这个第一次搭建的个人网站，通过持续写作而不是预先假设，逐步形成自己的结构。