很多人听到“个人网站”，第一反应是：我又不是程序员，做它有什么用？是不是还要买服务器、学代码、配置一堆环境？
如果只是想做一个能长期更新的个人博客，现在不必先把这些技术都学会。你可以把需求、素材和判断告诉 WorkBuddy，让它处理项目创建、页面修改、构建检查和部署配置；遇到账号登录、浏览器授权、付款和公开内容确认时，再由你亲自完成。
这篇文章用一套可以复现的流程，把个人博客从第一句话讲到正式网址：WorkBuddy 负责开发，Astro 负责生成静态页面，GitHub 保存代码和文章，Cloudflare Pages 根据 GitHub 的推送自动构建，最后再绑定自己的域名。
个人网站对普通人有什么用
个人网站不一定要做成复杂的产品。一个结构清楚的博客，就能先解决下面几件事。
把经历放在一个地址里
工作经历、项目链接、学习记录和联系方式，往往散落在社交平台、网盘和电脑文件夹里。个人网站可以把它们集中起来，别人想了解你时，打开一个网址就够了。
用作品证明自己做过什么
简历里的“熟悉 AI 工具”“可以独立完成项目”很难单独证明。你可以在网站的项目页写清楚：遇到了什么问题、用了什么工具、自己做了哪些决定、最后得到什么结果。过程比一句自我评价更有说服力。
留下一份不依赖单个平台的记录
平台账号可能改版，推荐机制也会变化。博客文章和项目记录放在自己的域名下，至少有一份可以自己维护、备份和迁移的版本。它不保证每篇文章都有流量，但能让积累不只停留在收藏夹里。
逼自己把想法说清楚
把一件事写成文章，通常要重新确认它是什么、自己学到了什么，以及哪些经验还值得复用。这个过程本身就是整理知识，而不只是发布内容。
这套流程分别用什么
| 工具 | 在流程中的工作 |
|---|---|
| WorkBuddy | 根据自然语言创建页面、修改代码、运行检查，并协助完成 Git 和部署操作 |
| Astro | 生成以 Markdown 文章为主的静态博客页面 |
| GitHub | 保存代码、文章和历史版本；仓库可以设为私有 |
| Cloudflare Pages | 连接 GitHub，在推送后自动构建和发布网站 |
| Cloudflare Registrar | 注册并管理自己的域名 |
Cloudflare 官方文档说明，Pages 的 Git 集成可以连接 GitHub 仓库，在分支推送后自动构建和部署，也支持为提交生成预览部署。详见 Git integration 和 GitHub integration。
整条链路可以记成：
说清需求 → WorkBuddy 创建和检查 → GitHub 保存版本 → Cloudflare Pages 构建 → 域名访问开始前准备
先准备三个账号：
- WorkBuddy
- GitHub
- Cloudflare
再准备一些不必很完整的素材：网站名称、你的名字或昵称、一句话介绍、头像、想分享的内容方向和联系方式。资料没有整理好也没关系，先用临时文字把页面做出来，之后再替换。
账号密码、验证码、银行卡信息和完整访问密钥不要交给 Agent。它可以替你处理技术步骤，但账号归属和敏感操作仍然由你确认。
第一步：让 WorkBuddy 创建第一版
打开 WorkBuddy，新建一个工作空间，把下面的需求一次发给它。第一版先控制范围，不要一开始就加入会员、评论、支付和复杂后台。
请帮我从零创建一个个人博客网站。
我的情况：
- 我不懂编程和服务器
- 请尽量替我完成可以自动完成的工作
- 只有在需要登录、浏览器授权或付款时，再提醒我操作
- 不要一次给我大量技术解释，优先直接执行
网站要求：
1. 使用当前稳定版 Astro。
2. 使用纯静态网站方案，不需要数据库。
3. 网站使用中文，支持手机和电脑访问。
4. 包含：首页、文章、项目、关于我。
5. 首页展示个人介绍、最近文章和项目。
6. 文章使用 Markdown 管理。
7. 支持浅色和深色模式。
8. 不增加登录、会员、评论和支付功能。
9. 添加网站图标、基础 SEO 和 404 页面。
10. 将个人资料集中放在一个容易修改的配置文件中。
11. 后续部署到 Cloudflare Pages。
请先完成网站创建和本地预览。
完成后检查构建、手机端显示、页面和图片是否报错，告诉我预览地址。
不要让我手动修改代码。WorkBuddy 完成后会给出一个本地预览地址。先按手机和电脑各看一遍，再用具体描述提出修改意见，例如：
首页看起来太像程序员模板，请改得更适合普通职场用户。手机上的标题太大，请缩小一些；首页内容太多，请删掉不重要的模块。请增加一个项目展示区域，项目卡片需要显示项目名称、我负责的内容和访问地址。你负责说清楚“哪里不合适、想达到什么效果”，WorkBuddy 负责寻找文件、修改代码和检查结果。先选定一版 UI，再继续接入 GitHub，修改会更容易追踪。
第二步：把网站保存到 GitHub
本地预览能打开以后，把代码放进 GitHub。它既是备份，也是后面自动部署的入口；以后改错了，还可以查看历史版本。个人博客的仓库可以先设为私有，等确定哪些内容适合公开后再决定是否开放。
继续把下面的提示发给 WorkBuddy：
请把当前个人博客保存到我的 GitHub。
要求：
1. 创建名为 personal-blog 的仓库，默认设为私有仓库。
2. 默认分支使用 main。
3. 检查并完善 .gitignore。
4. 不要上传 node_modules、密码、Token、密钥和环境变量。
5. 完成 Git 初始化、提交和推送。
6. 推送完成后检查 GitHub 仓库文件是否完整。
7. 需要登录 GitHub 时，提醒我完成浏览器授权。
8. 除了登录授权，不要让我手动执行命令。
如果当前环境无法自动创建仓库，请先说明原因，再告诉我最少的手动步骤。弹出 GitHub 登录页面时，自己完成一次浏览器授权即可。不要把访问令牌复制进文章、截图或公开仓库。
第三步：用 Cloudflare Pages 自动发布
代码进入 GitHub 后，把仓库连接到 Cloudflare Pages。这里选择 Git 集成，不使用手动上传或 Wrangler Direct Upload。这样以后每次向 main 分支推送，Cloudflare 都会重新构建并更新网站。
在 WorkBuddy 中发送：
请帮助我把 GitHub 中的 personal-blog 仓库部署到 Cloudflare Pages。
要求：
1. 使用 Cloudflare Pages 的 GitHub 自动部署。
2. 不使用手动上传和 Wrangler Direct Upload。
3. 生产分支使用 main。
4. 框架选择 Astro。
5. 构建命令使用 npm run build。
6. 构建输出目录使用 dist。
7. 需要登录或授权 GitHub、Cloudflare 时提醒我操作。
8. 部署完成后检查首页、文章、图片和手机端。
9. 把最终的网站地址告诉我。
10. 除了必须由我确认的授权，其他步骤尽量直接完成。如果 WorkBuddy 需要你打开 Cloudflare 控制台，主要路径是：
Workers & Pages
→ Create application
→ Pages
→ Connect to Git
→ 选择 GitHub
→ 选择 personal-blog 仓库确认这四项：
| 设置项 | 值 |
|---|---|
| Production branch | main |
| Framework preset | Astro |
| Build command | npm run build |
| Build output directory | dist |
Astro 的 Cloudflare Pages 部署文档也使用 npm run build 和 dist，并说明连接 Git 后，提交新的代码会触发重新构建。可以查看 Deploy an Astro site 和 Build configuration。
第一次部署完成后，会得到一个类似 personal-blog.pages.dev 的地址。先打开首页、文章、图片和手机端，确认无误再绑定域名。Git 集成通常还会为分支或提交提供预览地址，适合在正式发布前检查改动。
第四步：绑定自己的域名
pages.dev 地址可以长期使用，但独立域名更容易记，也更适合放在简历、作品集和个人简介里。选域名时尽量短、容易拼写，少用难以解释的数字和连字符，例如：
yourname.com
yourname.me
yournamenotes.com如果想把注册和 DNS 放在同一个后台，可以在 Cloudflare Registrar 搜索并注册域名。购买时的联系方式、付款和隐私选项由你自己确认。
注册完成后，告诉 WorkBuddy：
我已经在 Cloudflare 注册了这个域名：
【填写域名】
请帮助我把它绑定到刚刚创建的 Cloudflare Pages 项目。
先检查项目名称和域名配置，只有在必须由我点击或确认时，再告诉我具体操作步骤。
绑定后请检查 HTTPS、首页、文章链接和手机端访问。Pages 控制台的入口通常是项目 → Custom domains → Set up a domain。Cloudflare 的自定义域名文档说明了 Pages 项目的绑定方式；如果绑定的是根域名，通常需要把域名的 DNS 或名称服务器交给 Cloudflare 管理，具体以控制台提示为准。
上线后第一批文章写什么
不必等到“足够专业”才开始。第一批文章可以从已经发生过的事情写起：
我为什么开始做个人网站
说清楚你想记录什么、希望谁看到，以及准备怎样更新。读者不需要一份宏大宣言，只需要知道这个网站有什么用。
我怎样用 WorkBuddy 做出第一版
记录需求、UI 选择、修改过程和遇到的错误。这本身就是一篇可以展示的 AI 实践文章。
我的常用工具和工作方法
只写自己实际用过的工具，说明它解决了什么问题、有什么限制，不要把产品介绍原样搬过来。
一次真实的项目复盘
可以是工作项目、学习计划，也可以是一次部署故障。写清楚背景、判断、处理过程和结果，哪怕最后没有完全成功，也比空泛的心得有价值。
如果你还没有选题，可以先参考用 AI 做一个免费导航站的完整流程，把其中真正做过的步骤换成自己的记录。
后续更新仍然交给 WorkBuddy
GitHub 和 Cloudflare Pages 连接好以后，更新文章不需要重新配置服务器。把素材发给 WorkBuddy，让它先整理、检查，再提交到仓库：
请把下面的素材整理成一篇个人博客文章。
要求：
1. 保留我的真实观点，不要编造经历、数据或结论。
2. 删除重复内容和没有信息的套话。
3. 使用自然、简单的中文，标题要准确说明文章要解决的问题。
4. 增加读者容易理解的小标题、必要的链接和图片 alt。
5. 保存到当前 Astro 博客的文章目录，保持现有 frontmatter 格式。
6. 发布前先按项目约定完成去 AI 味和事实核对。
7. 在本地运行检查和构建，修复明显的排版或链接错误。
8. 先把改动展示给我确认；我确认后再提交并推送到 GitHub 的 main 分支。
9. 推送后检查 Cloudflare Pages 是否自动部署成功，并告诉我文章地址。
文章素材：
【粘贴你的素材】以后的更新可以缩短成：
记录想法 → 发给 WorkBuddy → 整理文章 → 推送 GitHub → Cloudflare 自动更新有几件事不能完全交给 AI
WorkBuddy 可以处理技术工作，但下面几件事最好由网站所有者自己决定：
- 注册账号、完成浏览器登录和授权；
- 购买域名、付款和填写真实联系方式；
- 哪些文章、照片和项目资料可以公开；
- 是否把 GitHub 仓库设为公开；
- 上线前最后检查文字、链接和隐私信息。
把技术工作交给 AI，不等于把账号和判断权也交出去。每一次授权前看清楚它要访问的仓库和服务，每次发布前再打开正式网址检查一遍。
从第一篇文章开始
个人网站不需要一开始就做得复杂。先放上个人介绍，整理一个做过的项目，发布第一篇文章，再把网址写进简历。页面可以慢慢改，内容也可以慢慢积累。
它的价值在于：几年以后，你仍然能用一个自己的地址找到那些经历、作品和想法。