用 AI 搭建个人网站：架构、Cloudflare 托管与 Obsidian 写作

个人网站可以把个人介绍、项目作品和长期写作放在一个稳定的入口。求职时，简历里的项目可以链接到具体的演示、实现过程和技术取舍，让读者进一步了解你做过什么、如何解决问题。平时学习，也可以把实验记录、阅读笔记和阶段性的思考整理成文章，方便以后回看、修正和引用。

AI 降低了搭建和修改网站的门槛。选好架构与托管方式后，一个内容型网站可以用很低的成本长期维护，把更多时间留给作品和写作。建站时值得提前考虑的，是内容如何保存、修改如何发布，以及几年后还能否方便地迁移。

下面这份通用提示词可以直接交给具备文件读写、终端和 Computer Use 能力的 AI。先上传准备公开的个人介绍、作品、文章和图片，或者提供本地文件夹路径，再复制提示词开始执行。它覆盖从整理材料到部署上线的完整流程；默认采用静态网站、Cloudflare 免费托管和默认域名，登录与首次授权需要你配合完成。这里的零成本指免费额度内的托管与默认域名，AI 工具费用另计。

请从零开始，使用我提供的材料搭建个人网站，并完成 Cloudflare 免费部署和线上验收。请实际执行文件整理、开发、构建、浏览器操作和部署，持续推进到给出可访问的网址。

我的材料与偏好
- 材料：[本次上传的附件，或本地文件夹路径]
- 网站用途：[求职作品集 / 技术博客 / 学习笔记 / 个人介绍，可多选]
- 名称与介绍：[填写；缺失时从材料提取并让我核对]
- 参考风格：[可选，网站链接或文字描述]
- 已有仓库：[可选；没有就新建]
- 公开联系方式：[可选，仅使用我指定公开的信息]
- 独立域名：[可选；默认不购买，使用平台提供的地址]

一、接收材料并确定公开范围
1. 检查上传的文件或指定目录，列出可用于网站的介绍、项目、文章、图片和附件。不能读取的文件明确指出，请我补充可读版本。
2. 如果我还没有提供材料，先集中列出需要上传的最小清单：个人介绍、一项作品或一篇文章、可选头像及联系方式。材料不足时可以先搭建本地结构，公开上线前清除占位内容。
3. 提取项目背景、本人工作、技术选择和实际成果，不编造经历或数据。简历中的电话、住址及其他未指定公开的信息不放上网。上传给 AI 的原始附件不自动进入公开仓库或网页。
4. 将整理后的公开内容和页面结构展示给我核对。普通技术选择采用合理默认值，只有公开范围、账号授权、付费或破坏性操作需要我决定。

二、选择架构并建立项目
1. 已有仓库先读项目说明、开发约定、依赖、内容目录和部署配置，保留可用的实现。
2. 从零开始优先使用 Astro 静态生成。博客评估 https://github.com/satnaing/astro-paper，作品集与主页评估 https://github.com/arthelokyo/astrowind，关联笔记评估 https://github.com/jackyzha0/quartz。检查当前维护状况、许可证和实际构建结果，选一个符合需求的基础，保留必要的许可声明。
3. 以免费托管为约束，默认不用数据库、登录系统、服务端 API 和付费服务。确实需要动态功能时先说明用途、维护与费用影响，由我决定。
4. 在独立项目目录中使用 Git 管理代码。已有仓库遵守其分支与提交约定；保留原始素材，避免覆盖其他项目。密钥、令牌、环境文件和私人材料加入忽略规则。

三、完成网站与内容工作流
1. 根据真实材料完成首页、个人介绍、作品展示、文章列表和正文页；不需要的栏目省略。
2. 采用克制配色和清晰排版，适配手机与桌面。长标题、长链接、表格和代码不能撑破页面。导航、折叠和按钮支持键盘操作。
3. 代码按语言高亮；提示词自动换行。两者都支持一键复制和下载，保留缩进与换行；长提示词默认折叠，折叠时仍可复制和下载。
4. 使用本地 Markdown 保存文章，建立标题、日期、简介和草稿状态等必要字段。若我使用 Obsidian，配置它直接编辑网站内容目录，核对附件路径、标准链接和草稿的公开规则。
5. 配置页面标题、描述、站点地图、RSS（有文章时）和 404 页面。图片压缩并提供尺寸与替代文本，避免引入不必要的统计、外部字体和追踪脚本。
6. 写好 README，说明安装、启动、构建、添加文章和替换图片的方法。

四、本地验收
1. 使用项目锁文件和匹配的运行环境安装依赖，执行生产构建并修复错误。
2. 启动本地预览，在真实浏览器检查首页、文章直链、刷新、导航、图片、深浅色（如有）、手机布局、复制、下载和折叠。核对下载文件与原文一致。
3. 检查最终公开内容，移除占位文字、无效链接、私人附件和密钥。给我本地网址做视觉与内容验收，再进入正式发布。

五、GitHub 与 Cloudflare 免费部署
1. 我确认本地版本可以发布后，完成 Git 提交，并使用我的 GitHub 账号建立或连接仓库。默认私有仓库；需要改为公开时先征求我的同意。通过平台正规授权连接所需仓库，不索取或打印我的密码及令牌。
2. 使用 Computer Use 打开 Cloudflare 控制台。登录、验证码、服务条款和首次账号授权需要我处理时，明确指出当前页面和所需动作，完成后继续。
3. 核对当时的 Cloudflare 官方文档和免费方案限制，使用 Workers Static Assets 托管静态产物，使用 Workers Builds 连接 GitHub 自动部署。默认使用 workers.dev 地址，不买域名，不开付费套餐或附加服务。如果免费路径不可用，停在具体障碍并说明可选办法，不自动付费。
4. 从实际仓库确定项目根目录、Node 版本、包管理器、构建命令和输出目录。编写适合当前项目的 Wrangler 配置，纯静态项目指向正确的静态产物目录；不要添加无用的 Worker 脚本。先执行构建与部署 dry-run，确保配置可用。
5. 在控制台选择正确的仓库与发布分支，填写构建和部署参数，核对服务名与仓库配置一致。部署使用项目安装的 Wrangler。首次成功后，确认该分支的新提交会触发自动构建与部署。
6. 本提示词授权你在我确认本地版本后完成约定的免费公开部署。遇到付费、扩大权限、覆盖现有服务或修改已有域名时单独询问；不要为常规构建和检查反复等待确认。

六、线上验收与交付
1. 等待部署日志明确成功，打开实际分配的网址。检查首页、文章直链与刷新、图片、样式、导航、404、RSS 和 sitemap；核对 canonical 等绝对地址使用最终站点地址。
2. 检查是否仍有占位内容、私人文件或调试信息。发现问题后修复、重新构建并验证对应线上结果。
3. 在发布说明或 DEPLOY.md 中记录服务名、公开网址、仓库与发布分支、构建和部署命令、产物目录，以及免费方案的适用范围。
4. 写清以后如何用 Obsidian 或编辑器更新文章，如何提交并确认自动上线，如何撤回文章和恢复上一版本。公开过的内容可能已有缓存与副本，撤回页面不等于删除全部传播记录。
5. 最后给我网站地址、仓库地址、本地项目路径、验证结果，以及仍需我处理的事项。无法完成的步骤明确标记，不把本地预览或构建成功当成线上发布成功。

我的个人网站部署在 Cloudflare，文章保存在 GitHub 仓库，平时直接用 Obsidian 编辑。内容和代码进入发布分支后，由 Cloudflare 自动构建上线。这套流程不需要购买云服务器，也不需要单独维护一个写作后台。

如果从头搭建一个以文章、作品和个人介绍为主的网站，我会优先选择静态生成，再用 AI 完成页面定制和部署配置。这里把本站的技术选型、可以直接使用的仓库，以及 AI 与 Computer Use 的协作方式放在一起说明。

个人网站的内容通常在发布时发生变化，适合提前生成 HTML，再交给托管平台分发。读者访问时直接取得页面，浏览器负责导航、搜索和动画等交互。页面有动效，并不要求服务端每次重新渲染。

采用这种结构，文章、图片和样式都可以纳入 Git 管理。修改记录、内容备份和发布版本使用同一个来源，更新网站只需要提交文件。数据库、账号系统和在线编辑后台可以等实际需要出现后再加。

Cloudflare 提供运行和分发网站的基础设施，开发者负责仓库、构建配置和内容。纯静态站点可以使用 Workers Static Assets；需要服务端能力的应用，则在同一平台运行 Worker 脚本。两者都不需要自行管理操作系统、Nginx 或常驻进程。Static Assets 文档

本站目前的具体实现如下：

本站包含 Worker 运行时；面向普通博客，我更推荐依赖更少的 Astro 静态站点。React 适合需要较多自定义交互的项目，框架选择应当跟着页面需求走。本站使用的 vinext 基于 Vite 实现 Next.js API，具体兼容性与部署方式要对照项目版本检查。

使用已有模板，可以直接获得文章路由、归档、RSS、搜索和基础排版，再集中调整自己的内容与视觉。选择时，我会先看内容目录是否清楚、构建能否跑通、许可证是否允许修改，以及发布是否依赖额外服务。

下面三个项目分别适合不同方向，链接指向它们的公开仓库；功能依据项目文档核对，正式采用前仍要在自己的环境构建一次。

这几个仓库使用 MIT 许可证，修改发布时应保留相应许可声明；模板里的照片、字体和示例文章还需要分别检查授权。选择模板也不等于接受全部默认功能，例如访问统计、评论和第三方嵌入，都应按需求决定是否保留。

把选型和仓库检查交给 AI 时，可以这样要求：

目标：搭建以文章和作品展示为主的个人网站。
候选仓库：[仓库链接]
我的需求：[内容类型、页面结构、需要的交互]

阅读 README、许可证、package.json 和部署配置。
检查 Node 版本、包管理器、内容目录、构建命令、输出目录，
以及是否依赖数据库、服务端运行时或外部付费服务。

优先评估静态生成，说明哪些需求确实需要服务端能力。
给出保留、删除和新增的功能范围，再启动本地预览。
使用仓库现有的锁文件，不同时引入另一套包管理器。
验收后，把启动、构建和发布步骤写进 README。

如果已有网站，先让 AI 检查现有仓库。只要内容组织和部署方式还能满足需求，局部修改通常比迁移整个技术栈更省事。

Vibe coding 适合快速调整版式和交互，但需要明确的输入材料。我会准备自己的介绍、作品描述、文章和参考站点，并指出参考对象中希望借鉴的部分，例如信息密度、字体比例或导航方式。材料越具体，AI 越少依靠占位文案拼凑页面。

实施可以分成三轮：先确认页面结构和真实内容，再调整视觉，最后处理动效与性能。每轮都打开可运行的页面检查，发现问题后给出位置、现象和期望行为。一次同时改布局、内容和技术栈，会明显增加定位问题的难度。

基于当前仓库修改个人网站。
内容材料：[自我介绍、作品、文章、公开联系方式]
视觉参考：[链接，以及具体希望借鉴的部分]

先完成首页、文章列表和正文页，使用真实内容。
保留现有内容管理与部署方式，按页面逐步修改。

设计要求：克制的配色、清楚的标题层级、适合中文的正文宽度。
手机端检查导航、长标题、长链接和代码块。
代码按语言高亮；代码与提示词都能复制，提示词自动换行。
交互支持键盘焦点，动效遵循减少动态效果设置。

每轮完成后启动项目，用浏览器实际打开、滚动和点击。
复现并修复发现的问题，再交给我检查视觉。
完成与改动范围匹配的构建或测试，保留可回退的 Git 记录。

本站的手机视口、字体和背景绘制都调整过多轮。动效需要单独关注绘制频率、像素密度和资源加载，桌面上的流畅表现不能代替手机验证。对以阅读为主的网站，正文出现的速度、滚动响应和导航稳定性，应当优先于装饰效果。

文章页面也要放入真实长文检查。长标题、代码块、图片和目录会暴露空页面看不出来的问题；只用几句占位文字调版式，往往要在第一次正式发布时返工。

我把网站仓库直接作为一个 Obsidian vault 打开。本站文章位于 outstatic/content/writing/，图片位于 public/writing-media/。Obsidian 和 AI 修改同一批文件，写完后不需要再复制到网站后台。

文章默认使用 .md，顶部的 frontmatter 保存标题、日期、主题和发布状态。Fumadocs 在构建时读取这些文件，页面、目录和 RSS 从同一套内容数据生成。MDX 只用于需要嵌入组件的文章，普通写作保持 Markdown 即可。

这里需要预先处理三件事。第一，Obsidian 的新建笔记和附件位置要对应仓库的内容目录。第二，链接语法要与站点兼容，本站使用标准 Markdown 链接。第三，图片路径要同时适用于编辑器和浏览器：本站会在渲染时把 public/writing-media/ 转换成网页使用的 /writing-media/。

这些目录属于本站约定，使用 AstroPaper 或 Quartz 时应当按对应项目配置。Obsidian 本身可以打开已有文件夹作为 vault，与 Cloudflare 之间的发布由 Git 和构建流程完成。

检查当前仓库的文章目录、附件目录和 frontmatter schema。
配置 Obsidian，使它直接编辑站点使用的 Markdown 文件。

请完成新建文章位置、附件位置、链接格式和图片路径适配。
排除 node_modules、构建产物和其他不需要浏览的目录。
按当前站点的实际字段生成一份可复制的文章模板。

用一篇带图片、链接和代码块的文章验证：
Obsidian 中可阅读，本地网页中内容完整，图片和链接可访问。
分别检查草稿能否进入列表、能否通过直链打开。
写清楚新增文章、预览、发布和撤回的操作步骤。

版本同步可以交给 Git 客户端或 Obsidian Git 插件。开始修改前先同步仓库，结束后检查差异，再提交这一轮内容，避免编辑器和 AI 同时修改同一篇文章导致覆盖。公开仓库里的草稿同样公开，发布状态只控制网站展示。

Computer Use 让 AI 操作实际浏览器，适合完成控制台中的仓库连接、表单配置和部署检查。代码与配置文件交给编码工具处理，Cloudflare 控制台交给浏览器操作，这样的分工比较直接。

准备好 GitHub 和 Cloudflare 账号，先把网站放进自己控制的仓库，确认本地构建通过。再让 AI 整理部署参数：仓库、发布分支、项目根目录、Node 版本、构建命令、产物目录和服务名称。这些信息应当来自实际文件。

本文以 Workers Static Assets + Workers Builds 为部署路径。以输出到 dist 的 Astro 静态项目为例，安装项目所需的 Wrangler 开发依赖后，可以使用以下配置：

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-personal-site",
  "compatibility_date": "2026-09-22",
  "assets": {
    "directory": "./dist"
  }
}

name 替换为自己的服务名，assets.directory 指向构建产物。这个例子不需要 main 指定 Worker 脚本；已有服务端框架的项目要保留它自己的运行入口，不能直接覆盖成这份静态配置。静态资源配置文档

进入 Cloudflare 的 Workers & Pages → Create application → Import a repository，连接 GitHub 后选择仓库。授权范围选到需要部署的仓库即可。使用 npm 的静态项目，构建命令通常为 npm run build，部署命令为 npx wrangler deploy；使用其他包管理器时，按项目锁文件和脚本调整。控制台部署、构建配置

可以把整个过程交给具备浏览器操作能力的 AI：

请先检查本地仓库，确认构建通过，并整理部署参数。
仓库：[我的 GitHub 仓库]
生产分支：[发布分支]
Cloudflare 服务名：[服务名]

使用已连接的浏览器进入我的 Cloudflare 账号，
在 Workers & Pages 创建应用并连接这个仓库。
按项目实际情况填写根目录、Node 版本、构建和部署命令。
核对控制台服务名与 wrangler 配置中的 name 一致。

默认使用免费方案和 workers.dev 地址。
登录、验证码和首次账号授权由我完成。
若需要付费、购买域名或扩大权限，先说明具体原因。
配置完成后展示参数，等我确认再触发首次正式部署。

部署后打开默认网址，检查首页、文章直链、图片和导航。
直接访问子页面并刷新，确认路由正常。
查看构建日志和浏览器错误，记录对应的提交版本。
将后续更新和恢复上一版的步骤写进 DEPLOY.md。

本站的构建命令同样是 npm run build，但静态资源目录为 dist/client，并保留 vinext 的 Worker 入口。Cloudflare 控制台服务名与 wrangler.jsonc 的 name 也需要一致，避免自动构建和本地手动部署指向不同服务。这些参数应随仓库保存，不能只留在一次聊天里。

接通 Workers Builds 后，推送到配置的生产分支会触发构建和部署。可以再改动一处正文，完整验证一次“提交—构建—线上更新”，确认以后发布文章也能走通这条流程。Workers Builds

在免费额度内，这套方案可以不产生托管费用。AI 工具的订阅或调用费用、可选的独立域名，需要另行计算。下面是截至 2026 年 9 月 22 日查到的主要边界：

静态资源与 Worker 脚本使用不同的计费规则；SSR、API 和让请求先执行 Worker 的配置都会影响用量。免费额度也不覆盖任意附加服务，开通存储、图片处理或其他产品前应分别核对价格。静态资源计费、Workers 价格、构建额度

独立域名可以等网站稳定更新后再买。默认地址已经能够访问网站，个人域名主要提供更稳定、便于传播的地址。购买时同时比较首年价和续费价，并核对是否为溢价域名、能否转出，以及账号支持的付款方式。Cloudflare Registrar 注册说明

域名注册商、DNS 服务和网站托管可以分别选择。域名在其他注册商购买，也可以把 DNS 交给 Cloudflare 管理，无须同时转移注册商。使用 Workers Custom Domain 时，先让域名在 Cloudflare 中处于有效状态，再进入 Worker 的 Settings → Domains & Routes → Add → Custom Domain 绑定，Cloudflare 会为其创建对应 DNS 记录并管理证书。Custom Domains

切换域名后，还要更新站点基础 URL、canonical、RSS、sitemap 和分享卡片里的绝对地址，并确定默认地址与独立域名之间的跳转策略。绑定成功后，用实际读者会使用的网络打开首页和文章直链，再检查一次资源加载。

上线验收包括构建通过、部署成功和线上页面可用三个层面。正文能打开后，还要检查文章列表、RSS、图片和子页面刷新；发生问题时，先核对当前域名、服务名、生产分支和部署对应的提交，确认自己正在检查正确的版本。

修改页面仍然在本地预览，内容和配置经 Git 留下记录，确认后进入发布分支。恢复旧版本时，也要同步处理仓库中的错误改动，避免下一次自动部署又把问题带回来。

网站可以持续调整，但写作与发布的步骤应当尽早固定。完成第一版后，实际用 Obsidian 写一篇文章，插入图片，经 Git 推送并确认线上更新；这次完整发布能检验网站是否已经具备日常使用的条件。