我如何用 Codex 搭建了一个个人博客

这篇文章不是一篇标准教程，更像是一份实践记录。

过去我一直有一个想法：做一个真正属于自己的个人博客。它不依赖公众号，不依赖短视频平台，也不被信息流算法牵着走。它可以放长文章，也可以放类似微博、Twitter 那样的短动态；可以记录项目过程，也可以沉淀工具、想法和个人成长。

这次，我没有从“先学前端、再写代码”开始，而是选择了一条新的路径：

先想清楚网站结构和内容目标，再让 Codex 帮我一步步实现。

最终，我采用的方案是：

GitHub + Codex + Astro + Cloudflare Pages + 自有域名

整个过程下来，我最大的感受是：AI 并不是简单地帮你“生成一个网站”，而是把建站这件事从“技术优先”变成了“决策优先”。你要做的核心工作，不是逐行写代码，而是不断回答这些问题：

• 我要做什么样的网站？
• 这个网站长期用来沉淀什么？
• 哪些功能第一版必须做？
• 哪些功能可以以后再做？
• 内容怎么更新最方便？
• 数据和代码应该由谁来管理？
• 网站上线后怎么维护？

这些问题，比代码本身更重要。

一、为什么选择这个技术方案？

最开始，我考虑过很多方案：WordPress、Hugo、Hexo、Astro，也考虑过要不要买服务器。

最后我确定用 Astro + Cloudflare Pages，主要基于几个判断。

第一，我只是做一个轻型个人博客，不需要复杂后台和数据库。Astro 可以把网站生成静态页面，访问速度快，维护成本低，也不需要长期管理服务器。

第二，我希望后期可以不断调整页面和功能。相比传统博客框架，Astro 更像一个现代内容网站框架，既能写文章，也适合做个人主页、资源页、动态流、项目展示等内容。

第三，我已经决定用 Codex 辅助开发，而 Astro 的项目结构、组件化思路、Markdown 内容管理方式，都比较适合让 AI 持续维护。

第四，Cloudflare Pages 可以直接连接 GitHub 仓库。以后只要代码更新，网站就可以自动部署。这对个人博客来说非常省心。

最后形成的分工是：

• GitHub：保存网站代码、文章内容、修改历史；
• Codex：负责创建项目、修改代码、排查问题；
• Astro：负责生成静态博客；
• Cloudflare Pages：负责托管和自动部署；
• Cloudflare DNS：负责域名解析；
• 自有域名：作为长期访问入口。

这套方案的核心优势是：轻、稳、免费起步、可迁移、适合长期迭代。

二、第一版网站到底做什么？

一开始我也想过把公众号、B站、微博、小红书等平台的内容都同步到博客上。但真正开始设计时，我决定先砍掉复杂功能。

第一版不做公众号同步，不做 B站同步，不做评论系统，不做会员登录，不做数据库后台。先把最核心的内容结构跑通。

最终网站内容分成两类：

1. 长文章 Blog

长文章用于系统性内容沉淀，比如：

• AI 工具实践；
• Codex 使用记录；
• 建站过程；
• 副业探索；
• 项目复盘；
• 个人成长；
• 工具方法论。

这些内容适合慢慢写、长期留存、方便搜索。

2. 短动态 Notes

短动态是我特别想保留的一个模块。

它类似微博或 Twitter，不要求每条都很完整，可以记录：

• 一句话想法；
• 今天试了一个工具；
• 项目推进到哪一步；
• 某个临时灵感；
• 一段读书摘记；
• 一个链接收藏；
• 一次小的技术折腾。

这个模块的意义是降低更新门槛。不是每次打开博客都要写一篇长文，短动态也可以让网站持续“活着”。

所以第一版的网站结构变成了：

• 首页；
• 长文章列表；
• 长文章详情；
• 短动态时间流；
• 分类页；
• 标签页；
• 搜索页；
• 资源页；
• 关于我；
• 404 页面。

这已经足够构成一个完整的个人内容站。

三、用 Codex 建站的实际流程

这次建站不是一次提示词完成的，而是分阶段推进。

第一步是让 Codex 检查当前项目目录和 GitHub 仓库状态，确认它能正确读取本地文件。

第二步是做一个小测试：让 Codex 创建一个测试文件，再删除它。这样可以确认 Codex 既能读文件，也能写文件，还能按要求恢复仓库状态。

第三步才是正式初始化 Astro 项目，包括：

• 配置 TypeScript；
• 配置 Tailwind CSS；
• 配置 Content Collections；
• 支持 Markdown / MDX；
• 创建长文章目录；
• 创建短动态目录；
• 创建图片目录；
• 创建首页、文章页、动态页、分类页、标签页、搜索页、资源页、关于页和 404 页面；
• 配置 SEO、Open Graph、RSS、sitemap；
• 配置 Pagefind 静态搜索；
• 实现移动端适配；
• 实现文章阅读时间、上一篇 / 下一篇；
• 生成 README；
• 安装依赖并进行首次构建。

这一步完成后，网站有了基本骨架。

但真正花时间的不是“生成网站”，而是后面的持续打磨。

四、网站不是生成出来的，是改出来的

第一版生成后，我继续和 Codex 进行了大量细节调整。

比如首页结构，一开始板块比较多，后来逐步删减，简化首屏介绍区，调整文章显示数量，统一导航名称。

短动态模块也经历了明显变化。最开始动态像普通文章一样有标题，后来我发现这不符合微博或 Twitter 的感觉，于是调整为无标题内容流，更像真正的碎片记录。

我还导入了旧站和饭否里的历史动态，处理其中的图片链接，删除示例动态，再加入自己的真实内容。长文章部分也删除了示例文章，导入了旧文章，并让系统自动读取标签。

视觉上也进行了多轮修改，包括：

• 设计网站 Logo；
• 多轮调整 Logo 细节；
• 将 Logo 接入网站顶部；
• 把关于页头像替换为 Logo；
• 调整文章详情页为单列布局；
• 统一 Blog、Articles、Notes、Timeline 等命名逻辑；
• 删除多余的页面眉标；
• 在首页加入动态标签云；
• 把标签云调整为运动球体效果；
• 再进一步改成横向长条布局；
• 调整首页左右布局；
• 隐藏标签云容器边框。

这些细节看起来琐碎，但它们决定了一个网站是不是“像自己的东西”。

我越来越觉得，用 AI 做网站，真正的关键不是一句话生成，而是持续判断、持续反馈、持续取舍。

AI 能给你很多东西，但你要负责审美、结构和方向。

五、内容更新方式，是个人博客能否长期活下去的关键

网站做出来只是第一步，能不能长期更新才是关键。

最开始，我需要在本地新增 Markdown 文件，然后运行命令、提交 Git、推送到 GitHub，再触发 Cloudflare Pages 部署。这个流程虽然可控，但对日常更新来说还是偏复杂。

于是我继续让 Codex 分析更新方式，并做了几件事：

第一，设计一键发布脚本。这样本地更新内容后，可以用脚本自动完成同步、提交、推送等步骤。

第二，解释清楚 Git 推送是增量而不是全量。也就是说，每次发布并不是把整个网站重新上传一遍，而是只推送变化内容。

第三，提供多种 Markdown 更新模板，方便以后新增长文章和短动态。

第四，进一步规划手机端更新需求。因为我不可能每次发一条短动态都打开电脑。

第五，接入 Pages CMS，让 blog 和 notes 都能通过后台编辑。

这个过程里还有一个重要决策：

确立 GitHub 作为唯一真源。

这句话很关键。

无论是本地更新、Pages CMS 更新，还是后续 Codex 修改，都应该最终回到 GitHub。GitHub 是唯一可信的内容和代码源头。这样才不会出现本地一份、远端一份、后台一份，最后互相冲突的问题。

后来确实遇到了 Pages CMS 与本机 Git 提交冲突的问题，于是又改造了一键发布脚本，让它发布前自动同步远端，尽量减少冲突风险。

这一步让我意识到：个人博客不是只有“前台页面”，还包括背后的内容生产流程。

如果更新流程太复杂，网站迟早会荒废。

六、上线部署：从临时域名到正式域名

本地网站完成后，下一步是部署上线。

我把 GitHub 仓库连接到 Cloudflare Pages，配置构建命令和输出目录。对于 Astro 项目来说，核心配置就是：

• 构建命令：npm run build
• 输出目录：dist

Cloudflare Pages 首次部署成功后，会生成一个临时 Pages 域名。我先用这个临时域名测试网站功能和访问情况。

确认没问题后，再处理正式域名。

我的域名是 zhangyuxiao.com，之前在 GoDaddy 管理。为了让域名接入 Cloudflare，需要把 DNS 托管迁移到 Cloudflare。这个过程中有一个细节很重要：原来域名下如果有邮箱记录，尤其是 MX 记录，不能随便删。否则网站可能好了，邮箱却坏了。

所以我在接入 Cloudflare 时，特别检查并保留了邮箱 MX 记录。

最后完成了：

• 选择 Cloudflare Free 方案；
• GoDaddy 域名接入 Cloudflare；
• 保留邮箱相关 DNS 记录；
• 将 zhangyuxiao.com 绑定到 Cloudflare Pages；
• 将 www.zhangyuxiao.com 绑定到 Cloudflare Pages；
• 启用 SSL；
• 配置 www 跳转到主域名；
• 测试正式域名访问。

到这一步，这个博客才真正从本地项目变成了一个可以公开访问的网站。

七、这次实践给我的几个启发

1. AI 降低的是技术门槛，不是思考门槛

Codex 可以帮我写代码、改样式、修报错、配部署，但它不能替我决定网站的定位。

真正重要的决策仍然要自己做：

• 是做博客，还是做个人品牌站？
• 是先接平台 API，还是先做原创内容？
• 是先做复杂功能，还是先把更新流程跑通？
• 是保留资源板块，还是简化首页？
• 是用标题式动态，还是无标题内容流？

这些判断会直接影响网站能不能长期使用。

2. 第一版不要贪大

一开始我也想做公众号、B站、社交媒体聚合，但最后先砍掉了。

现在回头看，这是正确的。

如果第一版就做太多接口、同步、后台、评论、会员和数据库，很容易复杂到失控。个人博客最重要的不是功能炫，而是能上线、能更新、能沉淀。

第一版只要有长文章、短动态、搜索、标签、资源页、关于页，就已经足够。

3. 短动态是个人博客的重要补充

长文章需要完整思考，更新频率天然不会太高。短动态则可以承接碎片想法，让网站不至于长期沉默。

对个人博客来说，短动态不只是“微博替代品”，更像是一个公开的思考流。

很多长文章，可能就是从一条短动态慢慢长出来的。

4. GitHub 作为唯一真源，非常重要

本地、后台、AI、部署平台都只是工作方式，真正的源头应该只有一个。

我选择 GitHub 作为唯一真源后，整个项目逻辑就清楚了：

• 内容和代码都进 GitHub；
• Codex 修改也进 GitHub；
• Pages CMS 编辑也进 GitHub；
• Cloudflare Pages 从 GitHub 构建；
• 本地发布前先同步 GitHub。

这样项目不会散。

5. 建站不是一次性工程，而是长期系统

这次建站过程从初始化项目，到调整视觉，再到内容迁移、发布脚本、后台编辑、正式部署，实际上已经不是单纯“做一个网页”，而是在建立一个长期内容系统。

这个系统包括：

• 内容结构；
• 页面设计；
• 图片管理；
• 更新流程；
• 版本控制；
• 自动部署；
• 域名解析；
• 后台编辑；
• 冲突处理；
• 后续维护。

真正让我有收获的，不只是网站上线，而是我对“个人内容资产”这件事有了更清晰的理解。

八、写在最后

这次用 Codex 搭建个人博客，让我重新认识了建站这件事。

以前建站像是技术活：要懂代码、懂服务器、懂前端、懂部署。 现在建站更像是产品活：要明确定位、设计结构、拆分任务、持续反馈、控制复杂度。

AI 让普通人拥有了更强的实现能力，但也要求我们更清楚地表达需求，更果断地做取舍。

我的博客并不是一次生成出来的，而是在一次次对话、测试、修改、删除、重构、部署中逐渐成型的。

如果你也想做个人博客，我的建议是：

不要一开始追求完美，也不要一开始堆功能。

先回答三个问题：

1. 你要长期沉淀什么内容？
2. 你准备用什么方式持续更新？
3. 你希望这个网站五年后还对你有什么价值？

想清楚之后，再让 AI 帮你实现。

工具会变，平台会变，但属于自己的内容资产，值得早点开始。