别再让 AI 直接写页面了：一种更稳的中后台开发方式

本文讨论的不是 Demo 级别的 AI 编码体验，而是面向真实团队、长期维护的中后台工程实践。

AI 能写代码，但不意味着它适合直接"产出页面"。

最近一年，大模型在前端领域的讨论几乎都围绕一个问题：

"能不能让 AI 直接把页面写出来？"

在真实的中后台项目中，我的答案是：
不但不稳，而且很危险。

这篇文章想分享一种我在真实项目中实践过、可长期使用、可规模化 的方式：
不是让 AI 写页面，而是把 AI 纳入中后台前端的工程体系中。 把 AI 的不确定性关进了笼子里，用工程流程保证可控性。

模板固化规范，Spec 描述变化，大模型生成 Spec，脚本生成代码，lint/test 做兜底。 它解决了 AI 上工程最致命的四件事：

可审计：变化在 spec，生成结果可 diff
可重复：同一个 spec 反复生成结果一致
可兜底：lint/test 是硬门槛
可规模化：从 prompt 工艺变成流程

在中后台场景，尤其是 CRUD 占比高 的项目里，这几乎就是"性价比最优解"。

一、中后台页面开发的真实困境

如果你做过中后台前端，一定对下面这些场景不陌生：

页面 80% 是 CRUD
列表页结构高度一致
表单字段不断变化
大量复制粘贴
页面逻辑"看起来差不多，但永远不完全一样"

最终结果往往是：

代码冗余
风格不统一
新人上手慢
改一个字段要改好几个地方

这些问题不是某个框架的问题，而是中后台开发的结构性问题。

二、为什么"让 AI 直接写页面"在真实项目里行不通？

很多人第一反应是：

"既然页面这么重复，为什么不直接让 AI 写 Vue / React 页面？"

在真实项目中，这种方式往往会遇到几个致命问题。

1️⃣ 不稳定

同样的 prompt，每次生成结果不同
组件结构、命名风格不断漂移
难以保证团队统一规范

2️⃣ 难以 review

AI 一次生成几百行代码
reviewer 很难判断"这是不是对的"
出问题时难以定位责任

3️⃣ 无法规模化

prompt 是隐性的
经验无法沉淀
每个页面都是"重新生成一次"

4️⃣ 工程体系无法兜底

lint / test 很难提前发现语义问题
一旦出错，往往是运行期问题

结论很明确：
AI 直接写页面，更像是 demo，而不是工程方案。

三、一个更稳的思路：把"变化"和"稳定"拆开

在真实项目中，我最终选择了一种更偏工程化的做法：

Template + Spec + Generator + AI

核心思想只有一句话：

模板负责稳定性，Spec 负责变化，AI 只参与变化。

这个流程长什么样？

js 复制代码

需求描述
   ↓
页面规格（Spec）
   ↓
模板（Template）
   ↓
生成脚本（Generator）
   ↓
页面代码
   ↓
lint / test 校验

这不是为了"多一层抽象"，而是为了把 AI 的不确定性限制在可控范围内。

四、什么是 Spec？

**Spec（Specification）**可以理解为：

页面的"规格说明书"

它描述的是：

页面标题
接口地址
表格字段
查询条件
表单字段与校验规则

而不是：

生命周期怎么写
API 怎么调用
UI 组件怎么拼

这些内容，非常适合用一份结构化数据来表达。

一个简化的 Spec 示例

json 复制代码

{
  "title": "供应商管理",
  "api": {
    "list": "/api/supplier/list",
    "create": "/api/supplier/create",
    "update": "/api/supplier/update",
    "delete": "/api/supplier/delete"
  },
  "columns": [
    { "prop": "name", "label": "供应商名称" },
    { "prop": "contact", "label": "联系人" },
    { "prop": "status", "label": "状态" }
  ],
  "formSchema": [
    { "prop": "name", "label": "供应商名称", "required": true },
    { "prop": "contact", "label": "联系人" },
    {
      "prop": "status",
      "label": "状态",
      "type": "select",
      "options": ["启用", "停用"]
    }
  ]
}

这份 JSON 不依赖任何前端框架，但已经完整描述了一个中后台页面的"变化点"。

五、Template：把重复劳动固化成资产

Template 是固定不变的部分，例如：

页面整体结构
表格 / 表单 / 弹窗骨架
API 调用方式
分页逻辑
错误处理方式

它的特点是：

人工维护
版本化
可 review
很少变动

你可以用 Vue、React、Svelte，模板思想本身与框架无关。

六、Generator：让生成变成确定性行为

Generator 的职责非常单一：

把 Spec 填进 Template，生成代码文件

这一点非常重要：

Generator 是脚本
输出是确定的
不涉及 AI 决策

换句话说：

Generator 不是"智能的"，但它是可靠的。

七、AI 在这里扮演什么角色？

在这套体系中，AI 的职责被严格限制在两点：

✅ 1. 从自然语言生成 Spec

AI 非常擅长：

理解业务描述
生成结构化 JSON
补全字段信息

✅ 2. 按 lint / 报错做最小修复

只修具体文件
只做最小 diff
不重写整体结构

❌ AI 不该做的事

直接写页面代码
修改模板
改动基础设施
引入新依赖

这样做的结果是：
AI 的能力被"工程流程"约束，而不是反过来。

✅ 正确姿势

让 Codex 做两件事：

1️⃣ 根据自然语言 生成 Spec JSON

2️⃣ 根据 lint / 报错 做最小 patch 修复

示例指令（在 Codex CLI / IDE 中）：

在 specs/ 下生成 supplier.json，字段为供应商名称、联系人、电话、状态（启用/停用），接口路径为 /api/supplier/*，输出必须是严格 JSON。

然后：

bash 复制代码

yarn gen:page specs/supplier.json
yarn lint

如果 lint 报错，再让 Codex 修：

根据 lint 报错，只修改 src/views/supplier/List.vue，用最小改动修到通过。

八、为什么这种方式更适合真实团队？

从工程角度看，这种方式有几个明显优势：

可控：模板稳定，变化集中在 Spec
可 review：Spec 是结构化数据
可回滚：git diff 非常清晰
可规模化：不是 prompt 驱动，而是流程驱动
可迁移：换框架只需换模板

这也是为什么它比"直接让 AI 写页面"更稳。

九、这套思路不只适用于中后台

这种模式可以自然扩展到：

表单页 / 详情页
权限路由生成
页面迁移（如 Vue2 → Vue3）
低代码 / 页面工厂
前端工程自动化

核心不在工具，而在拆分变化与稳定的边界。

十、模板化不是终点：一条更现实的"最佳进化路线"

需要说明的是，Template + Spec + Generator 并不是终极方案 ，而是一个非常合适的工程起点 。并不是所有团队都需要走到配置驱动或 AST 修改阶段，对很多团队来说，Template + Spec 本身已经是最优解。

在真实项目中，我更推荐把它看作一条"可进化的路线"，而不是一锤定音的设计。

第一步：Template + Spec（现在的方案）

适用场景：

CRUD 页面占比高
新页面数量多
团队希望尽快统一规范

价值：

快速落地
风险可控
非常适合引入 AI 的第一步

第二步：抽象稳定能力，弱化模板复杂度

当发现模板里开始出现大量条件分支时，一个更稳的做法是：

把模板中的稳定逻辑抽成基础组件（如 BaseCrudPage）

此时：

模板变薄
spec 只描述"页面配置"
页面本身不再频繁生成新文件

这一步，已经非常接近配置驱动页面渲染。

第三步：从"生成代码"走向"配置即页面"

在 CRUD 占比极高的系统中，最终形态往往是：

页面 = 配置（Spec） + 渲染器

此时：

新页面不再生成 .vue 文件
只新增 spec + 路由配置
AI 直接生成 spec，收益最大

这本质上就是低代码/页面工厂的雏形。

第四步：存量项目引入结构化修改（AST / Patch）

对于已有大量页面的系统，更稳妥的方式是：

用 spec 描述"变更意图"
用工具对代码做结构化修改（如只改 columns、formSchema）
AI 只产出 patch，而不是重写页面

这一步非常适合：

老项目
安全要求高的团队
渐进式演进

一句话总结这条路线

模板化是把 AI 引入工程体系的第一步，
配置驱动和结构化修改，才是中后台工程的长期形态。

十一、总结

大模型的价值，不在于"替代工程师写页面"，

而在于：

把重复劳动结构化，并嵌入到工程体系中。

在中后台前端开发中，
最稳的方式永远不是"让 AI 自由发挥"，
而是让它在清晰的边界内工作。

如果只能记住一句话：不要让 AI 直接写页面，让它写"变化"，其余交给工程。

如果你觉得这篇文章对你有启发，欢迎点赞或收藏 👍