AI帮我造博客（三）：博客架构入门——前后端分离是什么意思？
📖 本文是「AI帮我造博客」系列第三篇。上一篇：AI帮我造博客（二）：为什么不用 WordPress？一个程序员的'造轮子'理由
TL;DR（30秒速览）
| 维度 | 要点 |
|---|---|
| 主题 | 用餐厅比喻讲清楚"前后端分离" |
| 传统博客 | 老板一人全包（接单、炒菜、端菜、收钱） |
| 现代博客 | 厨房和前厅分开，各干各的 |
| API | 厨房和前厅之间的"出餐口" |
| Headless CMS | 只管存内容的"中央厨房" |
| AI 视角 | 这些概念当时全靠 AI 帮忙梳理——后面会讲怎么让 AI 当你的技术翻译 |
一句话总结：我选了前后端分离的架构，因为想要"改前端不动后端"的灵活性。
这篇文章解决什么问题
如果你曾经搜过"怎么搭博客"，大概率见过这些词：
前后端分离、Headless CMS、API……
这些是什么东西呢？
这就是这篇文章的由来：用生活中的例子讲清楚这些基础概念。
看完之后，你至少能理解：
- 什么是"前后端分离"，为什么现代博客喜欢这么做
- 什么是 API，它在中间起什么作用
- 什么是 Headless CMS
- 我的博客架构是怎样的
💡 AI 协作提示：问 AI 问题时，"用生活中的例子解释"比"解释这个概念"有效得多。这是我摸索出的第一条规律。
搞懂这些，后面讲具体技术选型时你就不会懵了。
先从一个问题开始
你有没有想过：你在浏览器里看到的网页，是怎么来的？
当你输入一个网址、按下回车，背后其实发生了很多事：
- 你的请求发到某台服务器
- 服务器处理请求，准备你要看的内容
- 内容发回到你的浏览器
- 浏览器把它画出来，你就看到了
这个过程中，"谁来准备内容"和"谁来画页面"，就是我们今天要聊的核心问题。
传统做法：一个人全包
小饭馆模式
想象一个只有老板一个人的小饭馆。
客人来了 → 老板接单 → 老板炒菜 → 老板端菜 → 老板收钱
一个人从头干到尾。简单粗暴，但：
- 老板忙不过来的时候，客人就得等
- 想换个菜单风格？老板自己改
- 老板生病了？今天歇业
传统博客系统（比如 WordPress）就是这个模式：
后端（存数据的程序）和前端（展示页面的程序）是绑在一起的。
你访问一个页面 → WordPress 去数据库拿数据 → WordPress 拼成页面 → 发给你的浏览器
整个过程由一个系统全包。简单直接，安装完就能用。
但问题也很明显：
- 你想换个好看的页面模板？只能在 WordPress 主题库里选，或者自己改它的代码
- 你想让同样的内容在手机 App 里也能看？得另外想办法
- WordPress 服务器挂了？页面也挂了，啥都看不了
现代做法：分工合作
大餐厅模式
现在换一个场景：一家分工明确的大餐厅。
厨房（后厨）：只管做菜，做好了放在出餐口
服务员（前厅）：只管把菜端给客人、跟客人沟通
收银台：只管收钱
各干各的，互不干扰。
- 厨房想换个新灶台？换，服务员不用管
- 前厅想重新装修？装，厨房照常运转
- 想加个外卖窗口？加，厨房还是同一个
这就是"前后端分离"的核心思想：
把"存内容、管数据"的后端，和"展示页面、跟用户交互"的前端，拆成两个独立的系统。
它们之间通过一个"出餐口"——技术上叫 API——来沟通。
API 是什么？
API（Application Programming Interface）这个词你可能见过很多次。直译是"应用程序接口"，听起来很唬人，其实就是：
一个系统提供给另一个系统的"点菜窗口"
举个例子：
你去肯德基，不会自己跑进厨房做汉堡。你站在柜台前，对着菜单点单，店员把做好的汉堡递给你。
这个柜台窗口，就是肯德基给你提供的"API"。
技术世界里也一样：
- 后端系统说："你想要文章列表？请求这个地址：
/api/articles" - 前端系统就去这个地址"点菜"，拿到数据，画成页面给你看
API 的好处是什么？
后端只需要定义好"菜单"（有哪些数据可以取），前端爱怎么展示随便：
- 网站可以用这个 API
- 手机 App 也可以用
- 小程序也可以用
- 甚至智能音箱都可以
一份内容，多处展示。
Headless CMS：只管存内容的"中央厨房"
CMS 是"内容管理系统"的缩写（Content Management System），就是帮你管理文章、图片等内容的软件。WordPress 就是一个 CMS。
传统 CMS 是"有头"的——它既管内容存储，也管页面怎么展示。
Headless CMS 则是"无头"的：
- 它只负责存内容、提供API
- 页面长什么样？它不管
就像一个"中央厨房"：只管把菜做好、放在窗口，至于谁来取、怎么端给客人，它不操心。
我用的 Strapi 就是一个 Headless CMS：
- 有一个后台管理界面，让我写文章、上传图片
- 但它不管我的博客页面长什么样——那是前端的事
我的博客架构
讲完概念，来看看我的实际选择。
/// 博客系统架构图：浏览器 → Nginx → Next.js/Strapi ///
各个部分是干嘛的
Strapi（后端 / Headless CMS）：
- 一个开源的内容管理系统
- 我在它的后台界面里写文章、上传图片
- 它通过 API 把内容提供给前端
Next.js（前端）：
- 一个网页开发框架
- 它负责把从 Strapi 拿到的数据画成好看的页面
- 用户看到的所有界面都是它负责的
Nginx（反向代理）：
- 可以理解为"门卫"或"接待员"
- 用户的请求先到它这儿，它再决定转给谁处理
- 还负责一些安全、加速的杂活
为什么选前后端分离？
上一篇说过：我管不住手。
用绑定在一起的系统，想改前端就得碰后端。用分离架构，明天我想把前端换成别的框架，后端 Strapi 完全不用动。
还有一个好处：一个后端可以对接多个前端。
我在 Strapi 里写好一篇文章，网站可以展示，以后做个小程序也能直接用同一份内容。甚至想同步到其他平台，也可以通过 API 自动发布。一处编辑，多处分发。这个场景有很多高阶的玩法，我以后大概率会详细讲。
灵活性，这就是我选择前后端分离的核心原因。
AI 在这里帮了什么？
落到"搭博客"这个具体场景，有两个麻烦事：
第一，选型调研很耗时间。
Headless CMS 一搜一大堆：Strapi、Contentful、Sanity、Ghost、Directus……每个都说自己好，到底选哪个？以前我得翻官方文档、找对比测评、刷社区讨论，半天下来眼睛都花了。
现在我直接问 AI：
"我要自建博客，Headless CMS 有哪些选择？请按这些维度对比：是否开源、是否免费、学习成本、社区活跃度、适合什么人群。"
三分钟，一张选型地图就出来了。再针对感兴趣的选项追问细节，效率比自己翻文档高太多。
第二，给非技术读者解释概念费脑子。
我自己懂，不代表能讲清楚。写这篇文章时，我让 AI 帮我想比喻：
"前后端分离怎么用生活场景解释？给没有技术背景的读者看。"
"厨房和前厅分开"的餐厅比喻就是这么来的。我再改改措辞，就成了你现在看到的内容。
当然，AI 给的信息不能照单全收——它可能过时，可能有偏见，选型建议也可能跟你的实际需求不匹配。但作为"先粗筛，再深挖"的起点，非常好用。
我的 AI 技术调研四条心法
用了一段时间后，我摸索出几条规律：
第一条：用生活场景提问，别问专业术语
错误姿势：
"请解释一下前后端分离架构的优缺点"
AI 会丢给你一堆技术黑话，看完更晕。
正确姿势：
"请用生活化的比喻解释给外行听"
后者得到的答案，谁都能听懂。
第二条：让 AI 做对比表格
选型时选项太多看不过来？直接让 AI 按你关心的维度列表格，三分钟出选型地图，再针对感兴趣的选项深挖。
第三条：多追问几轮
AI 第一轮答案往往笼统。学会追问：
"你说 Strapi 适合开发者，具体什么意思？对非程序员友好吗？有什么坑？"
多追问几轮，信息密度才高。
第四条：主动要求验证渠道
AI 信息可能过时，所以我会追一句：
"这些信息我应该去哪里验证？官方文档、社区论坛、还是某篇测评？"
AI 会给你具体链接，你再自己核实关键点。AI 负责粗筛，人负责定夺。
💡 一句话总结：不要把 AI 当"答案机"，要当"信息助理"。它帮你收集、整理、对比，最后的判断还是你自己做。
小结
回顾一下今天讲的几个概念：
| 概念 | 一句话版本 |
|---|---|
| 前后端分离 | 厨房和前厅分开，各干各的 |
| API | 系统之间的"出餐口"，定义好怎么要数据 |
| Headless CMS | 只管存内容和提供 API 的"中央厨房" |
理解了这些基础概念，后面讲具体技术选型时你就不会觉得是天书了。
如果你和我一样选择了前后端分离，接下来就要做具体选型了。
下一篇预告
架构确定了，接下来要选具体用什么技术。
按"先后端、后前端"的顺序，下一篇我来聊聊内容管理系统的选型——为什么是 Strapi。
航海日志
| 本次航线 | 遇到的暗礁 | 带回的货物 | 下一站 |
|---|---|---|---|
| 用大白话讲前后端分离 | 差点把 SSR/SSG/ISR 也塞进来 | 餐厅比喻模板 | 前端选型 + 渲染方式 |
📚 AI帮我造博客系列导航
上一篇：AI帮我造博客（二）：为什么不用 WordPress？一个程序员的'造轮子'理由
下一篇：AI帮我造博客（四）：后端选型——内容从哪里来？