前言

我一直都想做一个自己的个人博客。

一方面，是因为平时工作里会遇到很多值得记录的内容，比如技术方案、踩坑过程、架构思考、工具使用心得。如果不及时写下来，过一段时间基本就会忘掉。另一方面，我也一直觉得，技术人最好还是有一个属于自己的线上空间，而不是把内容全部分散在不同平台里。

但问题也很现实。

我是以后端开发为主，前端不是我的主战场。真让我从零开始设计页面、搭前端工程、处理文章系统、接入部署、再绑域名，这件事不是做不了，而是会很慢，而且很容易在过程中把热情消耗掉。

后来我换了一个思路：

不要求自己先把前端全部学会，而是借助 AI，把第一版博客先做出来。

事实证明，这条路是完全可行的。

这篇文章，我想把整个过程尽量讲清楚：我是怎么一步步做成的、过程中具体做了哪些事、踩了哪些坑，以及 AI 到底帮我解决了什么。

我的实际起点

先说一下我的真实情况，这样这篇文章会更有参考价值。

  • 我是后端开发，不是专业前端
  • 我能看懂前端代码，也能改一点，但不想从零手搓整套页面
  • 我想尽快把博客上线，而不是一直停留在“准备中”
  • 我希望这个网站后面可以持续写内容，慢慢沉淀成自己的知识库

所以我的目标并不是做一个多炫技的网站，而是：

先做出一个能上线、能写文章、能持续维护的个人博客。

这个目标看起来不华丽，但它非常重要。因为很多事情最后做不成，不是因为技术太难，而是一开始目标太大，导致迟迟无法落地。

我是怎么使用 AI 的

我没有把 AI 当成“一键生成网站”的工具，而是把它当成一个前端搭子、一个工程助理。

整个过程中，我自己主要负责三件事。

1. 我来定方向

网站最终长什么样、保留哪些模块、整体风格偏什么，这些事情还是要我自己来决定。

2. 我来验证效果

AI 可以帮我生成代码、解释报错、给出方案，但页面是不是我真正想要的、项目能不能正常运行、结果是不是靠谱，最后还是要我自己确认。

3. 我来持续反馈

真正有效的方式，并不是让 AI 一次全部做完，而是这样一个循环：

提需求 -> AI 生成方案或代码 -> 本地运行看效果 -> 再继续微调

这种工作方式其实很适合后端开发，因为它和我们平时做接口、改逻辑、排查问题的节奏非常像。

整体落地路线

这次做博客，我大致是按下面这条路线走下来的：

  1. 先做一个本地静态页面原型，确定整体风格
  2. 把原型迁移成 Astro 项目
  3. 把文章系统改成 Markdown 管理
  4. 用 Git 管理代码，并上传到 GitHub
  5. 接入 Vercel，打通自动部署链路
  6. 在腾讯云购买域名，并完成 DNS 解析
  7. 把博客从“展示页”逐步做成“个人知识库”

接下来我按这个顺序展开讲。

第一步：先确定页面样式，而不是一上来先选框架

一开始我没有急着创建前端项目，而是先在本地做了一个静态页面原型。

这一步看起来简单，但其实非常重要。因为对于不擅长前端的人来说，最容易卡住的点往往不是写代码，而是还没开始写，就一直在纠结网站到底该做成什么样。

所以我先把博客最核心的几个模块定下来，比如：

  • 首页 Hero 区
  • 文章卡片列表
  • About 页面
  • 文章详情页
  • 深色模式
  • TOC 目录
  • 搜索和分类筛选

这一步做完之后，后面的工作就不再是“凭空做一个博客”，而是：

把一个已经看得见、摸得着的页面原型，迁移成一个真正可维护的博客工程。

这比让 AI 纯靠想象自由发挥稳定得多，也更容易做出自己喜欢的效果。

第二步：把静态原型迁移成 Astro 项目

当页面原型基本满意以后，下一步就是工程化。

我最后选择的技术组合是：

  • Astro
  • Markdown 内容系统
  • GitHub
  • Vercel

为什么我选 Astro

原因很简单：博客本质上是内容站，而 Astro 天然适合这种场景。

它有几个优点特别符合我的需求：

  • 静态生成，性能好
  • 项目结构清晰，容易理解
  • 对 Markdown 支持很好
  • 很适合做博客、文档站、作品站

对于后端开发来说，Astro 还有一个很友好的点：它不会强迫你一上来就深度进入复杂前端生态。

迁移时我具体做了什么

迁移过程并不神秘，本质上就是把静态页面一步步工程化。

1. 保留原有视觉风格

我没有推翻原来的页面重做，而是尽量保留已经满意的样式，把它迁移到 Astro 项目里。

这样做的好处是，工作重点就变成“如何落地”，而不是“重新设计”。

2. 按页面职责拆分结构

我把页面拆成了更清晰的结构，例如：

  • src/layouts/BaseLayout.astro
  • src/pages/index.astro
  • src/pages/about.astro
  • src/pages/blog/[slug].astro

拆分之后，首页、详情页、公共布局就不会混在一起，后面维护起来也会轻松很多。

3. 把样式统一整理

我把通用样式放进全局样式文件里，避免每个页面都重复写一堆 CSS。后面如果要统一改配色、排版、卡片样式，就会方便很多。

4. 把文章从假数据改成 Markdown

这一步是整个博客从“演示页”变成“可长期使用网站”的关键。

如果文章内容只是写死在 JS 文件里，那项目本质上还是 demo。但当每篇文章都变成独立的 Markdown 文件之后，它才真正具备长期写作和维护的能力。

第三步：把文章系统做成适合长期维护的结构

对于个人博客来说，真正决定你能不能长期写下去的，不是首页有多漂亮，而是文章管理是不是足够顺手。

我最后采用的是最简单、也最适合个人维护的方式：

每篇文章一个 Markdown 文件。

目录结构大概是这样：

src/content/blog/
  ai-build-personal-blog.md
  mysql-indexing.md
  go-concurrency.md

每篇文章文件里都带有统一的头信息，比如：

title: 文章标题
description: 一句话摘要
pubDate: 2026-09-03
category: backend
readTime: 10 分钟
tags:
  - AI
  - 博客
draft: false

这种方式的好处很明显：

  • 写文章简单
  • 文件结构清晰
  • 很适合 Git 管理
  • 后面查找、修改、归档都方便

对我来说，这一步其实是在为未来打地基。因为我希望这个网站后面不只是有一个首页，而是可以持续沉淀内容，最后慢慢变成自己的个人知识库。

第四步：把 Git、GitHub、Vercel 串起来

本地项目跑起来以后，下一步就是把整条发布链路打通。

这一步做完之后，博客才真正从“本地项目”变成“线上网站”。

1. 先用 Git 管理项目

这一步的意义很基础，但也很重要：

  • 代码有版本记录
  • 误操作了可以回退
  • 每次改动都能追踪

2. 再上传到 GitHub

上传到 GitHub 后，代码就不只存在于本地电脑里了，而是有了远程仓库。

这样做有两个直接好处：

  • 做代码备份
  • 给部署平台提供代码来源

3. 接入 Vercel 自动部署

这是整个流程里非常关键的一环。

接入完成之后，后面更新博客基本就变成：

git add .
git commit -m "update blog"
git push

然后 Vercel 会自动完成这些事情：

  • 拉取 GitHub 最新代码
  • 安装依赖
  • 执行构建
  • 发布上线

这意味着：

以后我写博客，本质上是在更新 Git 仓库，而不是每次手动部署网站。

从长期维护角度看，这一点非常重要。因为一旦发布流程足够顺，后面持续写内容的阻力会小很多。

第五步：部署过程中，我真实踩过的坑

如果只讲成功过程，文章会显得很轻松。但真实情况其实是：AI 帮我提速了很多，可该踩的坑还是会踩。

也正因为这些坑，我对整条链路的理解反而更清楚了。

坑 1：GitHub 不能直接用账号密码 push

我第一次往 GitHub 推代码的时候，下意识输入了 GitHub 账号密码，结果直接报错。

后来才知道，现在 GitHub 的 Git 操作通常不能直接使用普通密码，而是要用 Personal Access Token。

这个问题本身不复杂，但如果没人提醒，第一次确实很容易卡住。

坑 2：本地 npm 源影响了云端部署

这是我这次遇到的一个很典型的问题。

因为我本地环境里曾经用过公司内部 npm 源，导致生成出来的 package-lock.json 带上了不适合公网环境的依赖地址。

结果就是：

  • 本地安装正常
  • 本地运行正常
  • 但到了 Vercel 上，安装依赖直接失败

这个问题让我印象很深，因为它说明了一件事：

本地能跑，不代表云端一定能跑。

后面我是通过修正 .npmrc、处理 package-lock.json、重新确认依赖来源，才把这个问题解决掉。

坑 3：Vercel 显示 Ready，不代表当前网络一定访问正常

还有一次，Vercel 明明已经显示 Ready，但访问 vercel.app 域名时一直转圈。

最后排查下来，更像是访问链路或者网络环境问题，而不是项目本身构建失败。

这也让我更坚定地想做一件事：

尽快绑定自己的域名，而不是长期依赖平台分配的演示域名。

第六步：在腾讯云购买域名，并做 DNS 解析

博客初步上线之后，我又继续往前走了一步：给它配上自己的域名。

我的域名是在腾讯云上买的，买完之后，再通过 DNS 解析把域名接到 Vercel 上。

这一步看起来像锦上添花，但实际上意义很大。

为什么自定义域名很重要

1. 更正式

相比平台自动生成的网址，自己的域名更像一个长期项目。

2. 更可控

以后即使更换部署平台，域名依然掌握在自己手里。

3. 更适合长期沉淀

如果这个博客以后真的慢慢变成个人知识库，那域名本身也是这个知识体系的一部分。

DNS 解析这一步，实际在做什么

很多人第一次接触 DNS 解析会觉得有点抽象。其实你可以简单理解成：

告诉全网，我买下来的这个域名，应该指向哪一个网站服务。

我这次实际做的事情，本质上就是两步：

  1. 在 Vercel 后台添加自己的自定义域名
  2. 在腾讯云 DNS 解析控制台里，按 Vercel 提示添加对应记录

常见会涉及的记录包括：

  • 根域名的 A 记录
  • www 子域名的 CNAME 记录

配置完成之后，等 DNS 生效，自己的域名就可以访问博客了。

这一步做完以后，我会明显感觉：这个网站终于更像一个真正属于自己的长期项目了。

这次经历给我最大的感受

以前我对“做个人博客”这件事，总会有一种很典型的拖延逻辑：

  • 等我前端再熟一点
  • 等我把设计想得更完整一点
  • 等我哪天有整块时间了再认真做

但这次真的做下来以后，我越来越觉得：

对个人博客来说，最重要的不是第一版有多完美，而是先把第一版做出来。

因为只要第一版存在了，后面所有事情都只是迭代。

而 AI 在这件事里最有价值的地方，就是帮我跨过了最难的那一步：

从“我一直想做”，走到了“我真的把它做出来了”。

AI 在这个过程中，到底帮我解决了什么

如果要总结 AI 的价值，我觉得主要有三点。

1. 降低陌生领域门槛

我不需要先系统补完整套前端知识，才敢开始做博客。

2. 缩短试错时间

很多问题如果完全靠自己查资料、试方案，当然也能解决，但会慢很多。AI 帮我把定位问题、修复问题、解释问题的时间压缩了不少。

3. 提高从 0 到 1 的完成率

很多项目不是技术太难，而是因为链路太长、细节太多，最后被拖没了。

AI 对我最大的帮助之一，就是让我真的把这件事情落地了。

接下来，这个博客不只是博客

我现在对这个网站的期待，已经不只是“有一个个人主页”。

我更希望它接下来慢慢变成一个真正属于自己的知识沉淀空间，比如承载这些内容：

  • 技术笔记
  • 踩坑记录
  • 架构思考
  • AI 辅助开发实践
  • 工作中的方法论总结
  • 个人成长复盘

也就是说，它未来更像一个长期积累的个人知识库，而不只是一个展示页面。

这也是我现在最期待的部分。因为网站搭起来只是开始，持续输出内容、持续沉淀认知，才是它真正的价值所在。

后面我还会继续分享什么

这次把个人博客从 0 到 1 搭起来，只是第一步。

后面我也会继续围绕这个博客，持续分享一些更具体、更实操的内容，比如：

  • Astro 博客的目录结构是怎么设计的
  • Markdown 文章管理怎么做更顺手
  • GitHub + Vercel 的自动发布链路怎么配更稳
  • 腾讯云域名和 DNS 解析过程中容易踩哪些坑
  • 作为后端开发，怎么借助 AI 补齐前端短板
  • 怎么把个人博客逐步沉淀成自己的知识库

如果这篇文章对你有帮助，那后面的这些内容，我也会继续整理和分享出来。

结语

从一个以后端开发为主、前端经验有限的开发者视角来看，借助 AI 从 0 到 1 搭建个人博客，是一件非常现实、也非常值得做的事情。

它并不意味着你完全不需要理解技术细节，也不意味着 AI 会替你做所有决定。

更准确地说，它意味着：

你可以用更低的启动成本，把一个原本很可能长期搁置的想法，真正变成现实。

而当博客真正上线以后，技术本身反而不再是最重要的部分。更重要的是：

你愿不愿意开始写第一篇文章，并持续把这个博客沉淀成自己的知识库。

如果你和我一样，是以后端开发为主，也一直想做个人博客，但总觉得前端门槛太高，那我的建议是：

不要再等“我前端再熟一点”的那一天了，先借助 AI，把第一版做出来。

剩下的，都是迭代问题。