用 AI 从零搭一个技术博客：完整的过程和心得

自我指涉的开场

这篇文章本身就是 AI 帮我起稿的。

你正在浏览的这个博客，从 0 到现在的样子，我和 AI 协作完成了 90% 以上的工作。整个过程花了我大约一周时间（每天 1-2 小时），产出：

• 一个上线的博客（你现在在看）
• 8 篇正式文章（加这篇 9 篇）
• 几十个自定义功能
• 完整的 X 自动发推系统

这是我对 AI 工具能力边界的一次真实测试。结果挺有启发性的。

这篇我分享完整过程，从技术选型到踩坑，面向想搭博客或者想了解 AI 工作流的人。

起点

我的需求：

• 纯静态博客（省服务器钱）
• 中英双语支持
• 代码高亮 + Mermaid 图表
• 自定义域名
• 免费部署
• 最好能一键从 Markdown 发布

一开始我对具体技术栈没有偏好，只有上面这些约束。

第 1 步：选型 — 让 AI 帮我调研

我直接把需求甩给 AI：

2026 年写一个技术博客最合适的静态站点生成器是哪个？我要考虑性能、开发体验、生态成熟度。

AI 的回答：

• Astro — 默认零 JS，性能满分，生态成熟（2026 年最主流）
• Hugo — 构建快，但 Go 模板语法反人类
• Next.js — 功能强但对静态博客过度设计
• Jekyll — 过时，不考虑

选了 Astro。

然后继续让 AI 推荐主题：

Astro 上最适合技术博客的开源主题？要有搜索、标签、RSS、SEO 优化。

AI 给了三个选项，我选了 AstroPaper（19K star，最主流）。

整个选型过程：20 分钟。对比自己调研要花 2-3 小时。

第 2 步：搭建和定制

AI 帮我做的事：

1. git clone AstroPaper 模板
2. 清理掉模板自带的示例文章
3. 修改 config.ts、constants.ts 换成我的信息
4. 定制首页（去掉模板样式，改成我想要的”你好”+项目+文章列表）
5. 定制 About 页
6. 配置 GitHub Pages + CNAME + GitHub Actions

我做的事：告诉 AI 要改什么、review 结果、commit。

踩的坑：

• 第一次部署 404 — 因为 CNAME 配了但 DNS 没配，AI 给我讲清楚了
• HTTPS 证书需要等 Let’s Encrypt 签发（几分钟到几小时），AI 提醒了
• GitHub Pages 对 <username>.github.io 和项目仓库的行为不同，AI 解释清楚了

第 3 步：加自定义功能

基础博客跑起来后，我要加一些 AstroPaper 没有的功能：

系列文章导航

“我想要文章能按系列组织，同系列的文章自动显示导航。”

AI 设计方案：

• 在 frontmatter 加 series: { name, order }
• 写一个 SeriesNav 组件，自动从所有文章里找同系列的，按 order 排序

一次就写对了。

阅读时间估算

“每篇文章显示’X 分钟阅读’。”

AI 方案：写一个 remark 插件，在 Markdown 解析阶段计算阅读时间并注入 frontmatter。

这个略微踩坑：

1. 第一版用了外部包 mdast-util-to-string，导致 lockfile 和 package.json 不一致，部署失败
2. 改成自己实现的 extractText 函数，跳过外部包

教训：不要随便加依赖，能自己实现就自己实现。

Mermaid 图表支持

“让 Markdown 里的 mermaid 代码块自动渲染成流程图。”

AI 的方案：前端动态加载 mermaid.js，选择带 data-language="mermaid" 的 <pre> 元素。

这里踩了两个坑：

1. 选择器错了：我第一次让 AI 写选择器是 code.language-mermaid，但 Shiki 实际生成的是 pre[data-language="mermaid"]。修选择器。
2. Copy 按钮污染代码：另一个脚本给 <pre> 加了 Copy 按钮，Mermaid 脚本用 pre.textContent 读代码时把”Copy”也读进去了，渲染失败。修复：让 Copy 按钮跳过 mermaid 代码块。

这种细节 AI 自己想不到，只有真实跑起来才能发现。要真实测试，不要只看静态检查通过就信了。

浮动目录、相关文章、评论系统、404 页、搜索快捷键、OG 图定制、分类体系

…

全部是”描述需求 → AI 写代码 → 我 review → 调整”。

第 4 步：内容

基础设施搭好后，开始写内容。

我已经有一个 meme-trade-wiki 知识库（也是 AI 协作写的）。让 AI 基于 wiki 的内容，改写成博客风格的文章：

• Wiki 是”科普教材”式
• 博客是”个人叙事 + 内部视角”式

改写时让 AI 保留数据和观点，但改变叙事口吻 — 加入”我两年前看到…”、“从平台方视角…”这种第一人称语境。

一天时间写了 6 篇正式文章。如果纯人工写，我至少要一周。

第 5 步：X Thread 传播

又写了一个独立的子项目：X 自动发推工具。

让 AI 帮我：

• 写 Python 脚本（tweepy + 自建 parser）
• 设计 Markdown Thread 格式
• 做定时发布（GitHub Actions）
• 处理速率限制和重试

两三小时搞定一个完整的发推系统。

整体数据

对比估算：纯手工做这件事，至少 60-80 小时。AI 把效率提升了 3-5 倍。

踩坑总结

坑 1：AI 的”自信的错误”

AI 给出的代码有时会用不存在的 API。比如它让我用 astro.content.syncFrontmatter()（这个 API 在 Astro 里不存在）。

对策：实际跑一下。本地 build / 部署失败时仔细看报错。

坑 2：版本相关的错误

AI 的训练数据截止到某个时间点，某些库的最新 API 它可能不知道。

对策：告诉 AI “我用的是 Astro 5.x”、“当前 tailwindcss v4”，让它以最新版本为准。

坑 3：边缘情况处理不全

AI 的代码往往是”正常路径完美，失败路径粗糙”。

对策：主动问”这段代码在 X 情况下会怎样？“，让 AI 补上错误处理。

坑 4：以为自己在 review 其实只是在点头

看 AI 写的代码容易陷入”看起来合理就通过”的陷阱。

对策：关键逻辑自己敲一遍或重写；非关键逻辑至少跑起来验证一遍。

工作流建议

给想用同样方式的人：

1. 从明确的需求开始

不要：“帮我做个博客” 要：“做一个静态博客，技术栈 Astro，托管 GitHub Pages，自定义域名 X，需要支持 Y Z 功能”

明确的需求是有效对话的前提。

2. 小步迭代

一次不要让 AI 做太大的改动。每次修改一个文件/一个功能，验证 OK 再下一步。

3. 有个版本管理思维

每次可用的状态就 commit。出问题能回滚到上一个 known good 状态。

4. 和 AI 讨论”为什么”

不只要代码，还要让 AI 解释为什么这样写。这既能帮你发现它的潜在问题，又能帮你学到新知识。

5. 最后由你决定

AI 是顾问，不是决策者。所有重要选择（选 A 还是 B 方案、做还是不做某个功能）都是你自己决定的。

结论

用 AI 搭博客不是偷懒，是新的工作方式。

传统方式：程序员写 100% 的代码，花 100% 的时间。 AI 协作：程序员审阅 100% 的代码，花 30% 的时间。

价值的体现变了：从”能不能写出来”变成”能不能做出正确的决策”。

这对初级开发者可能是坏消息（他们的活被 AI 替代了）。对资深开发者是好消息（他们的判断力被放大了）。

而对”想做自己项目但不是全职开发者”的人来说，AI 是真正的开放时代 — 你不用先学会所有技术，就能做出你想要的东西。

接下来

这个博客现在跑着了，但远没有完成。还要：

• 写更多文章（这是最重要的）
• 持续优化（读者反馈驱动）
• 可能加上访问统计
• 可能加上邮件订阅

每一步都会继续用 AI 协作。

如果你想看这个博客的源代码：https://github.com/survivorff/blog

如果这篇对你有帮助，订阅 RSS 或 关注 X 看更多 AI + 工程的实战内容。