40toRetire
主题

项目 · Log

和 AI 一起搭个人网站

从域名、静态网站到发布流程：我如何与个人 AI 助理协作，搭建一个能长期记录和更新的网站。

2026年8月4日

40toRetire-TopAI协作个人网站技术方案

所属项目： 40toRetire-Top
本文类型： 技术方案 / 搭建记录

我有技术背景，也能判断一个方案是否合理；但这次并不是按传统方式，从零开始一个人写完网站。

更接近真实情况的是：我先说清楚自己要什么——有一个属于自己的长期记录空间，内容能持续发布，有独立域名，维护别太麻烦；然后让个人 AI 助理协助把需求拆成可以执行的步骤、完成大部分实现和检查。我负责关键选择、权限确认、费用确认，以及最后的验收。

这不是一份“零基础一键建站”教程。该弄明白的地方还是要弄明白，只是不用先把所有工具都学一遍。先想清楚要做什么，在关键步骤愿意多问一句、认真确认，就可以开始。

先确定：我需要的不是一个功能很多的网站

一开始我只定了几个原则：

  • 内容优先，写作不应被复杂后台打断；
  • 每篇文章都能长期保存、方便迁移；
  • 有自己的域名，不把入口完全交给某个平台；
  • 发布流程足够轻，未来愿意一直更新；
  • 不为了“看起来专业”过早加入评论、会员、数据库和各种插件。

按这些原则往下选，最后做成了一个静态网站，而不是一套需要长期伺候的复杂系统。

整个方案，分成五层理解

写作（Markdown）
        ↓
Git 保存版本和历史
        ↓
Astro 构建静态网页
        ↓
云服务器上的 Nginx 提供访问
        ↓
独立域名 + HTTPS

1. 域名：给长期记录一个固定入口

域名不是技术炫耀，而是一个稳定的地址。平台会变化，账号规则也会变化；独立域名至少让内容的入口仍由自己掌握。

网站启用了 HTTPS，读者访问时会通过加密连接打开页面。具体的域名后台、解析记录和证书配置属于基础设施细节，不在这里展开。

2. 服务器：只负责稳定地把页面交给访客

网站运行在一台云服务器上。因为它是静态站点，服务器不需要处理复杂的登录、下单或实时数据库请求，主要职责很简单：保存构建后的网页文件，并把它们通过 Nginx 提供给访问者。

这也是我选择静态站点的原因之一：结构简单些，日常要操心的事就少些。

3. 网站：用 Astro 把内容变成网页

网站本身用 Astro 构建。它适合这种“内容为主”的场景：页面在发布时就生成好了，读者打开时直接获得网页，不需要等待一套复杂的后端临时处理。

文章使用 Markdown 保存。一篇文章就是一个文本文件，包含标题、摘要、日期、标签和正文。它们分别归到“思考、学习、旅程、项目”四个栏目中。

好处是内容不被锁在某个后台里：即使未来更换工具，Markdown 文件仍然是清晰、通用、可迁移的原始内容。

4. 版本：用 Git 留下可回看、可恢复的历史

网站源代码和文章都由 Git 管理，并保存在私有代码仓库中。

对我来说，Git 不只是开发者工具：它更像内容的版本档案。文章修改过什么、某次调整为什么发生、误改后如何回退，都有迹可循。AI 助理可以协助执行检查和整理改动，但提交什么、发布什么，仍然需要人确认。

5. 发布：把“写完”变成一个稳定的闭环

一篇文章完成后，大致经过以下流程：

  1. 用 Markdown 写入对应栏目；
  2. 本地构建网站，检查页面能否正常生成；
  3. 提交到 Git，保存一个可追溯版本；
  4. 在服务器构建新的静态文件；
  5. 切换到新版本，同时保留旧版本以便出现问题时回退。

我不想把“发一篇文章”变成一件要研究半天部署的事。流程顺下来以后，注意力就能放回内容，不必每次更新都担心把网站弄坏。

AI 在其中做什么，人又必须做什么？

这次搭建里，AI 助理主要帮我做了这些事：

  • 把“我想有一个长期记录网站”拆成域名、内容结构、网站、服务器和发布流程；
  • 根据需求生成代码和页面，并解释每一部分在做什么；
  • 协助检查构建结果、排查报错、整理文档；
  • 在写作时把一段想法整理成可发布的草稿。

但有些事不能外包：

  • 这个网站究竟记录什么、哪些内容值得公开；
  • 域名、服务和工具的费用是否接受；
  • 登录、权限授权、安全设置等关键操作；
  • 最终是否发布，以及发布后的内容是否代表自己。

有技术基础的人，用它可以少花点时间在重复的事情上；没有技术基础的人，也可以让它把陌生的步骤讲得更明白、带着往下做。但网站要做成什么样、哪些内容能公开、钱要不要花，最后还是自己拿主意。

有些东西，我刻意不放进这篇文章

为了让方案可参考，同时不暴露不必要的信息，以下细节不公开：

  • 服务器地址、登录方式、端口与系统配置；
  • 域名后台、DNS 记录和证书配置；
  • 代码仓库地址、权限策略、部署脚本和内部目录；
  • Token、密钥、Webhook 及任何账号信息。

这些信息对理解方案并不必要，却可能带来安全和隐私风险。真正值得复用的是架构思路与协作方法，而不是照抄一套内部配置。

如果你也想开始

不需要一开始就拥有完整的技术方案。可以先回答四个问题：

  1. 你想长期留下什么内容？
  2. 你希望读者如何找到它？
  3. 你愿意为它投入多少维护成本？
  4. 哪些事情愿意交给 AI 协助，哪些必须自己确认？

想清楚这些后，再让 AI 帮你把方案缩到第一版能跑起来的样子。先有一个愿意持续写下去的地方，比先攒出一套复杂系统更重要。

网站还会慢慢改。但现在更重要的，是它已经有地方接住下一段想记下来的东西。