先说结论
页面构建器（Elementor、Divi、WPBakery、Bricks 这一大家族）解决的是一件事：
不会写代码的人，怎么把页面做出来。
这个需求曾经非常真实、非常值钱。但 AI 来了之后，它被另一个解法覆盖了：
不会写代码的人，怎么让 AI 帮他写出页面。
这两句话看着差不多，本质差别很大。前者要求”把代码藏起来”——所以构建器必须发明一套私有格式，把页面变成一堆 JSON 和短代码，再在前端翻译成 HTML。而后者恰恰要求把一切摊开成文本——因为 AI 的工作方式就是”读文本、改文本、跑起来验证”。
于是出现了一个有点讽刺的局面：构建器越是努力地把代码藏好，它在 AI 时代就越难用。
我的判断不是”构建器会消失”，而是：它会从”默认选择”退回成”特定场景的工具”。如果你的站点要长期维护、要 SEO、要批量生产页面、还要让 AI 帮你干活，那它现在就是个负债。
下面把理由说细。
一、构建器到底”臃肿”在哪里
这不是审美问题，是有具体形态的。
1. 你看到的页面，不是”你写的页面”
在构建器里拖一个按钮，输出的 HTML 大致长这样：
<div class="elementor-element elementor-element-3f2a1b9 elementor-widget elementor-widget-button"
data-id="3f2a1b9" data-element_type="widget" data-widget_type="button.default">
<div class="elementor-widget-container">
<div class="elementor-button-wrapper">
<a class="elementor-button elementor-size-sm elementor-animation-grow"
href="#">
<span class="elementor-button-content-wrapper">
<span class="elementor-button-text">立即报名</span>
</span>
</a>
</div>
</div>
</div>
手写的话是一个标签：
<a class="btn" href="#">立即报名</a>
一层包装是”可维护性”，五六层包装就是纯负担：DOM 更深、样式选择器更长、改一个按钮要跨三四层去定位。一个中等复杂度的首页，构建器产物的 DOM 节点数轻松是手写的 3～5 倍——而这直接影响 Core Web Vitals 里的布局与渲染指标。
2. 内容是 JSON 和短代码，不是文本
这是最要命的一条，因为它决定了后面所有问题。
| 构建器 | 页面内容存在哪 |
|---|---|
| Elementor | postmeta 里的 _elementor_data（一大坨 JSON） |
| Divi / WPBakery | post_content 里的一串短代码（[et_pb_section …]、[vc_row …]） |
| Bricks、Beaver Builder 等 | 同样是 postmeta 里的私有 JSON |
| Gutenberg（块编辑器） | post_content 里的 HTML + <!-- wp:paragraph --> 块注释 |
看出来了吗？Gutenberg 的产物仍然是标准 HTML——注释是给程序读的，正文是给人（和 AI）读的。而构建器的产物是只对那个插件有意义的私有结构。你的页面内容，实际上被交给了一个商业插件托管，格式由它定义、也随它变化。
3. 断点和样式散落在每个元素里
构建器给每个元素一份自己的样式：桌面一套、平板一套、手机一套，都存在那个元素的私有数据里。
结果就是：全站想把”正文行高从 1.6 调到 1.75″，你要么逐个元素改，要么写一段 !important 去覆盖。而在”纯 CSS”的方案里，这是一行的事。
样式本该是全局的规则，被拆成了几千份私有副本。
4. 资源加载：为了一个轮播，全站背着整包
构建器插件通常带一整套组件库（轮播、图标、动画、灯箱……）。历史上它们习惯”全站加载”，所以你在”关于我们”页面打开首页，也可能捎带上轮播和图标字体的 CSS/JS。新版做了按需加载的改进，但产物结构本身仍然是重的——那几层包装、每个元素的私有样式，是机制决定的，不是版本能修好的。
二、AI 时代，为什么它从”工具”变成了”阻碍”
1. AI 改页面的方式：读文本 → 改文本 → 跑起来验证
AI 写代码也好、改主题也好，动作其实就三个：
- 读：把相关文件读进来（HTML / CSS / PHP / Markdown）
- 改：直接写出新版本
- 验证：跑一遍、打开浏览器截图、看报错
这三步有一个共同的前提：改动对象必须是”文本文件”。
2. 它读不懂构建器的数据
给 AI 看一段手写 HTML，它知道自己在看什么；给它一段 _elementor_data，它看到的是一堆 "elType":"widget"、"settings":{"title":"…"} 的嵌套对象——没有文档、没有语义约定、字段会随插件版本变。
它能猜，但每一步都在赌。而赌错的代价由你承担：改错一个字段，页面可能整块消失。
3. 没有 diff，就没有 review 和回滚
页面在构建器里 = 页面在数据库里。于是：
- Git 管不到它。你改了首页，
git log里什么都不会出现。 - 没有 diff，就没有”这次到底改了什么”的记录，也无法回滚到昨天的版本（只能指望插件的”修订版本”够用）。
- 多人协作时，谁改的都说不清。
数据库是”状态的仓库”，不是”变化的记录”。 现代开发里所有靠谱的流程，都建立在”能看到变化”这个前提上。
4. 批量生成对它来说是”不可能的任务”
我做一个落地页 → 构建器点几下，确实快。
我让 AI 生成 100 个落地页（同一套结构、不同城市/不同产品）→
- 对 AI 来说：一个模板文件 + 一份数据表，循环渲染，脚本跑完就完了。
- 对构建器来说：没有稳定可调用的文件接口，只有”人点鼠标”的界面。你只能手点 100 次，或者自己写代码去生成它的私有 JSON（等于把它的格式重新逆向一遍）。
这就是”无法自动化”的真正含义：不是功能弱，而是它把”页面”放进了一个只能靠人操作的黑盒里。
5. 一个真实的例子：藏在 postmeta 里的一段代码
我自己的站上就踩过一次：页面上有个全局公告，我想改文案——在主题文件里翻遍了都找不到。最后才发现，它被塞在主题的设置项 postmeta 里。
那个东西对我来说等于”不存在”：它不是一个文件，AI 也帮不上忙，因为你没法给它一个路径说”你去看这个”。你只能拿着数据库工具去挖。
⚠️ 那次之后我给自己定了一条规矩：功能写进代码文件，不要写进数据库配置。 代码在 Git 里、能 diff、能部署、AI 能读能改；数据库配置只存在于某台机器的某个表里，排查成本高一个数量级。
三、公平地说，构建器现在仍然适合谁
我不想把话说得太绝对——构建器不是垃圾，它只是被放错了位置。
它仍然是对的选择，当：
- 做页面的人不会写代码，也不打算让 AI 参与（设计师、运营、客户自己维护）
- 一次性页面：活动页、落地页、临时专题，做完就扔，维护成本趋近于零
- 需要靠模板库快速起步：几千套现成模板，这个生态价值是真的
- 接手别人的构建器站点，短期内不想重构
它变糟糕的场景是：
- 长期运营的内容站 / 商业站，要 SEO、要性能
- 要被 AI 接手维护、要批量产出页面
- 团队协作，需要 review 和回滚
- 页面数量会持续增长（每一个新页面都在增加”数据库里的黑盒”的总量）
四、AI 时代的选型新标准
判断标准已经变了。我把它整理成一张对照表：
| 过去的判断标准 | AI 时代的判断标准 |
|---|---|
| 拖拽好不好用、上不上手 | AI 能不能读、能不能改、能不能验证 |
| 有没有好看的模板 | 产物是不是标准文本，能不能进 Git |
| 视觉能不能”所见即所得” | 有没有 diff 和回滚 |
| 单页做得快不快 | 能不能批量生成（100 个页面是脚本还是 100 次点击） |
| 不用懂代码 | 不懂代码的人 + AI，能不能一起把事做完 |
一句话：过去问”人好不好用”，现在要问”机器好不好用”。
因为未来维护你站点的主力，很可能是一个 AI——它不点鼠标，它读文件。
五、我的做法：让页面变成”AI 能读写的文本”
我的这个博客和我做的小工具，现在都是这套方案，已经跑了很久：
flowchart LR
A["主题代码<br/>inc/*.php、functions.php、模板"] --> D["AI 直接读写"]
B["内容：Markdown 文件"] --> D
C["样式：少量全局 CSS"] --> D
D --> E["部署脚本<br/>一条命令上线"]
E --> F["打开浏览器验证"]
具体三条原则：
1. 能写进代码的，不写进数据库。
新增模块 → 写 inc/*.php；模板片段 → 写模板文件；样式 → 写 CSS。理由前面说过了：代码可版本控制、可 diff、可部署，AI 直接读写。
2. 内容用 Markdown 管，发布走脚本。
我发这篇文章的动作是：写一个 .md 文件（含 front matter），执行一条命令，脚本把它变成 HTML、推到 WordPress、再把文章 ID 写回文件。整个过程 AI 全程参与，每一句话都在 Git 里。
3. 保留”生成即验证”的能力。
代码在文件里，AI 写完就能跑、能截图、能看报错——闭环。这是构建器方案做不到的：它中间隔着一个只能靠鼠标操作的黑盒。
结果是什么？我可以对 AI 说”把这个区块的间距改小一点，顺便加一个作者信息块，然后部署，截图给我看”——它自己读写文件、跑部署、验证。换成构建器的站，这句话根本没法执行。
六、结论
页面构建器没有做错什么，它只是为上一个时代设计的：
- 上一个时代，稀缺的是”会写代码的人” → 所以要把代码藏起来
- 这个时代，稀缺的是”能把结构说清楚的人” → 所以要把结构摊开来，让 AI 能读写
所以”下岗”不是它们被谁打败了，而是它们所依赖的那个前提，被 AI 抽掉了。
如果你现在正在选型，我会给这条建议：
先问自己一句：三年后，是我自己维护这个站，还是我 + AI 一起维护？
如果是后者，请从第一天起，就让页面以文本的形态存在。
（顺带一句：本文的排版、发布、图片处理，都是”文件 + 脚本”这条路走出来的——正好是它自己的一个例子。）
本文章永久链接： AI 时代，Elementor / Divi 这类页面构建器该下岗了