第 1 篇：为什么不该再让 AI 画页面

本篇目标

说清「AI 生成 UI 为什么总出错」
给出判断标准：你的场景到底适不适合配置驱动
建立本系列的核心心智：两层分离

1. 你遇到的痛点（大概率也是这些）

让 AI（Claude Code / Cursor / 豆包等）直接生成整个页面，常见的失败模式：

样式漂移：同一个「确认按钮」，上个页面是蓝色圆角，下个页面变成灰色直角。
布局不可控：AI 每次对栅格、间距、对齐的理解都不一样，表单错位、卡片忽宽忽窄。
改了东墙倒西墙：让 AI 改一个字段，它顺手把旁边三处的类名也改了。
返工成本高：一次生成 10 个页面，9 个要手动调，省下的时间又还回去了。

根因一句话：AI 生成一个页面时，要同时决策三件事------样式、布局、逻辑。三个变量叠在一起，输出就不稳定。

2. 反过来说：AI 最擅长什么

把「要渲染什么字段」描述成结构化 JSON，AI 几乎不会出错：

json 复制代码

{
  "name": { "label": "姓名", "type": "input" },
  "birth": { "label": "出生日期", "type": "date" }
}

因为它不需要猜样式、猜布局------它只是在「列字段清单」 。

而这恰恰是你需求的本质：同一个壳，变的只有字段。

3. 核心思路：两层分离

复制代码

┌─────────────────────────────────────────────┐
│  ① 固定层（写一次，永不改）                    │
│    设计 Tokens + 布局骨架 + 组件库             │
│    → 统一样式、统一布局的唯一来源               │
├─────────────────────────────────────────────┤
│  ② 数据层（每次变，AI 只产出这个）             │
│    Schema JSON（字段名 / 类型 / 校验）         │
│    → AI 出错面从「整个页面」缩小到「一段 JSON」 │
├─────────────────────────────────────────────┤
│  ③ 渲染器（写一次）                           │
│    读 Schema → 按类型映射到组件 → 自动渲染      │
└─────────────────────────────────────────────┘

AI 不再画页面，只填清单；页面由你写死的代码生成。

4. 对比：全量生成 vs 配置驱动

维度	AI 全量生成页面	配置驱动（本系列）
样式一致性	不稳定，靠运气	固定代码，永远一致
布局	每次不同	固定骨架
改动成本	改字段可能牵连样式	改一行 JSON
AI 出错面	样式+布局+逻辑	只有 JSON
上手成本	低	需要先搭地基（约半天）
灵活性	高（想怎么画怎么画）	限定在字段体系内

5. 诚实边界：什么时候不该用

配置驱动不是银弹，以下场景请绕行：

要一次性做视觉差异化很大的营销页 / 落地页 → 每页风格不同，配置驱动是负担。
高度探索性、还没想清楚要什么 → 先用 AI 全量生成做原型，定型后再固化。
只做一两个页面，以后不再加 → 直接手写更快，不值得搭地基。

适合用配置驱动的典型信号（对号入座）：

✅ 自用工具、后台、台账类页面
✅ 样式布局固定，只有字段变
✅ 页面数量会持续增加（每加一个只加一份 schema）
✅ 想跟 AI 协作但受够了返工

6. 本篇小结

AI 生成页面出错，根因是它同时决策样式/布局/逻辑。
你的需求是「固定壳 + 可变字段」，正好适合两层分离。
下一步：搭地基------第 2 篇：搭建脚手架

验证方式

不写代码，只需确认你对上号：你的页面是否「壳固定、字段变」？

是 → 继续读系列；不是 → 这系列不适合你，省时间去做别的事。