很多前端开发者已经在“使用 AI”：
会问问题、会让 AI 写代码、甚至在 IDE 里和 AI 对话。

但如果这些使用方式 无法稳定地产出可运行、可验证、可回归的工程结果，
那么严格来说——其实还没有真正入门。

这篇文章想系统回答一个问题：

前端开发者“使用 AI”的能力，是有明确层级和分水岭的。

不是工具多不多，也不是模型新不新，
而是：你用 AI 的方式，决定了它在你工程体系里的角色。

把 AI 放进工程链路，用工程约束对抗幻觉，用验证与反馈逼近真实。 AI 工程化的本质，并不是让模型更聪明，
而是把 AI 放入完整的软件工程链路中。

通过 MCP 提供真实项目上下文，最大限度压缩幻觉空间；
通过 Spec 与工程规则对 AI 行为进行硬约束；
通过自动化测试与构建验证，把“是否正确”的判断交给机器；
通过多轮执行与修复循环，让 AI 像工程师一样调试问题；
最终再通过人工 Review 的反馈，不断反哺和升级工程规范。

目标不是“消灭幻觉”，而是让 AI 的行为尽可能接近真实工程世界

一、为什么“我已经在用 AI”，却感觉始终不踏实？

一个很常见的真实场景：

• AI 能写 Vue 页面，但不知道你的项目结构
• 不知道你们封装的 BaseList、request
• 不知道路由、权限、构建规则
• 更不知道怎么验证能不能跑

于是流程变成了：

问 AI → 复制代码 → 报错 → 手改 → 再问 AI

问题不在于 AI 不行，而在于：

你用的是 生成能力，而不是 工程能力。

二、前端开发者使用 AI 的能力层级（L0–L6）

🟢 L0｜纯对话型使用：把 AI 当搜索引擎

典型方式

• 浏览器里问 AI
• 复制粘贴代码

你在做什么

• AI 给建议
• 你负责所有判断

能力上限

• ❌ AI 不知道你的项目
• ❌ 代码是否能跑，全靠你

本质：AI = 搜索引擎 + 示例生成器

---

🟡 L1｜提示词工程：更会“跟 AI 说话”

你开始做的事

• 限定 Vue2 / Ant Design Vue
• 要求先给方案再写代码
• 规定输出结构

提升点

• 跑偏变少
• 可读性变好

但问题仍在

• ❌ 项目上下文全靠你描述
• ❌ 一换人 / 一换模型就不稳

这是“说清楚了”，不是“用对了”。

---

🟠 L2｜IDE 内置 AI：能看代码，但只看一点

代表场景

• Cursor / Trae 里直接对话
• AI 能看到当前文件

能做的事

• 改一个组件
• 修一个 lint 报错

能力边界

• ❌ 看不到整个 repo
• ❌ 不会主动找样例
• ❌ 不会跑构建验证

AI 还是“副驾驶”，不是工程参与者。

---

🟢🟢 L3｜IDE + MCP：AI 开始真正“干活”

这是第一个关键分水岭。

你做了什么改变

• 让 AI 能：

  • 读整个项目（白名单）
  • 搜索已有实现
  • 修改真实文件（patch）
  • 跑 npm run lint / build

AI 能力升级为

• 真正参与工程执行
• 用你们的代码当模板
• 用验证结果证明自己

但还不够

• 输出风格不稳定
• 不同需求，结果差异大

AI 会干活了，但还没有“交付标准”。

---

🔵 L4｜Spec 驱动：从“写代码”到“按合同交付”

这是真正的工程分水岭。

变化不在工具，而在工作方式

• 先写 Spec，再让 AI 实现

• Spec 里写清楚：

  • 页面路由
  • 数据契约
  • UI/交互约束
  • 验收标准

AI 的角色变化

❌ 不再“自由发挥”
✅ 按 Spec 实现
✅ 对照清单自查

这一步解决了什么

• 稳定性
• 可复现
• 可回归
• 团队可协作

---

🟣 L5｜Agent 化使用：AI 像高级工程师

AI 开始具备

• 自动拆任务
• 多步执行
• 失败自修复
• 自动验证

典型流程

读 Spec → 拆解 → 实现 → 验证 → 修复 → 交付

你不再关心“它怎么一步步做”。

---

🔴 L6｜工程体系级使用：AI 成为系统一部分

这一层，已经不是“写页面”了。

特征

• Spec → Schema
• Schema → 自动生成页面
• AI 负责调度与校验

你在做的事情

不是写代码，而是 定义工程能力

三、更高阶：真正的工程范式升级（L7+）

🔶 L7｜Spec-as-Code（规范即代码）

• Spec 不再是文档
• 是 JSON / YAML Schema
• 不合法 → 不执行

🔷 L8｜工程治理（Guardrails）

• 禁止绕过封装
• 禁止新增依赖
• 禁止越权路由

AI 被工程规则“约束”。

🔷 L9｜Multi-Agent 协作

• Planner / Frontend / QA / Reviewer
• AI 像一个工程团队

🔴 L10｜自进化工程体系

• 人的 Review 意见
• 变成机器规则
• 下次不再犯同样错误

四、这不是工具升级，而是工程认知升级

很多人问：

“我要不要用 MCP？要不要写 Spec？要不要 Agent？”

真正的问题其实是：

你希望 AI 在你团队里，扮演什么角色？

• 写代码的助手？
• 能交付的工程师？
• 还是工程体系的一部分？

五、结语：真正的“入门”标准是什么？

真正入门 AI 前端开发的标志，不是“写得快”，
而是：
AI 是否能稳定地产出——
可运行、可验证、可回归的工程结果。

• Prompt 是技巧
• MCP 是能力
• Spec 是契约
• Guardrails 是纪律
• Agent 是组织
• 工程体系是终点

如果你发现自己：

• 已经在用 AI
• 但仍然不放心让它“直接改项目”
• 不敢让它“独立交付功能”

那不是你落后，而是你刚好站在“表面使用”和“工程化能力”的分水岭上。幻觉不是 AI 的问题，而是 AI 不在工程链路里的结果。当 AI 被约束在工程规则、上下文和验证之中，它就不再“幻想”，而是在执行。AI 的可靠性，不来自模型能力，而来自工程闭环。

AI 正在改变前端开发，但不是“替你写页面”那么简单。

在过去一年里，关于 AI 与前端的讨论，几乎都集中在一个问题上：

AI 能不能直接把前端页面写出来？

实际工程中的答案往往是：
能写，但不一定该写；能跑，但不一定能维护。

本文尝试跳出“某个工具/框架”的视角，从工程全流程出发，系统性拆解：

• AI 在前端开发中到底能做哪些事
• 哪些能力适合“直接用 AI”
• 哪些能力必须进入工程链路
• 如何在真实团队中组合使用，避免“AI 工程反模式”

一、先给结论：AI 不该只盯着“写页面”

在真实项目中，前端开发并不只是“写组件”：

• 有需求拆解
• 有规格设计
• 有工程约束
• 有测试与治理
• 有长期维护成本

AI 的价值，分布在整个链路中，而不是集中在“代码生成”这一点上。

如果只讨论“AI 写页面”，会严重低估它的工程潜力。

二、前端工程全流程拆解（AI 能介入的 9 个环节）

从工程角度，一个典型的前端中后台开发流程可以拆成 9 个阶段：

1. 需求理解与拆解
2. 规格化（Spec / Schema）
3. 模板/脚手架生成（Codegen）
4. 页面与组件实现
5. 重构与迁移
6. 调试与缺陷修复
7. 测试与质量保障
8. 代码评审与工程治理
9. 文档与知识沉淀

下面逐一分析：AI 在每一层的真实价值与风险。

三、需求理解与拆解：AI 的“第一生产力”

AI 非常擅长的事

• 将自然语言需求拆解为页面/功能点清单
• 列出字段、操作、权限、异常场景
• 辅助补齐遗漏的边界条件

工程价值

• 减少沟通成本
• 降低遗漏风险
• 提高需求进入实现阶段的质量

👉 这是“低风险、高收益”的 AI 使用场景，几乎没有副作用。

四、规格化（Spec / Schema）：AI 最理想的输出形态

相比直接写代码，AI 更适合输出结构化规格，例如：

• 页面配置（字段、表单、校验）
• 接口契约（OpenAPI / DTO）
• 路由与权限声明
• 表格列、搜索条件、状态枚举

{
  "title": "供应商管理",
  "columns": [
    { "prop": "name", "label": "供应商名称" },
    { "prop": "status", "label": "状态" }
  ]
}

为什么这是 AI 的“甜蜜点”？

• 结构化输出稳定
• 可校验、可 diff
• 可进入工程链路
• 可反复复用

👉 Spec 是 AI 与工程之间最重要的“接口层”。

五、模板 / 脚手架生成：AI 的放大器，而不是主角

在有 Spec 的前提下，前端可以通过：

• 页面模板
• 代码生成器
• AST 工具

确定性地生成代码骨架。

此时 AI 的角色是：

• 生成 Spec
• 而不是直接生成页面文件

工程收益

• 代码风格统一
• 可重复生成
• 易于回滚
• 新人友好

👉 模板 + 生成器负责“稳定性”，AI 负责“变化”。

六、页面与组件实现：AI 的高风险区

适合 AI 直接参与的场景

• Demo / 原型
• 内部工具
• 探索性 UI
• 一次性页面

高风险场景

• 权限逻辑
• 核心业务流程
• 复杂状态管理
• 跨模块交互

在这些场景中，让 AI 直接写代码，往往是一个工程反模式：

• 不稳定
• 难 review
• 难以长期维护

👉 这里更适合“小范围、受限”的 AI 辅助，而不是放权。

七、重构与迁移：AI 的“耐心型劳动力”

在这些场景中，AI 非常有价值：

• Vue2 → Vue3
• Router / 状态库升级
• API 调整引发的批量修改

最佳实践

• 按模块拆分
• 小步 PR
• lint / test 兜底
• AI 输出 patch（diff），而不是整文件

👉 AI 很适合做“重复但细致”的迁移工作。

八、调试与修复：报错驱动的高性价比场景

这是目前 AI 在工程中性价比最高的用途之一：

• lint 报错
• 编译失败
• 测试失败

将错误日志 + 相关文件交给 AI，限制改动范围：

• 只改指定文件
• 只做最小 diff

👉 这是“可控、可回滚、立竿见影”的 AI 用法。

九、测试、评审与工程治理：AI 的隐藏价值

测试

• 生成单测用例
• 补齐边界测试
• 生成 mock 数据

Review / 治理

• 总结 PR 风险点
• 检查风格一致性
• 提示潜在技术债

👉 AI 在“辅助判断”层面的价值，远大于“替你写代码”。

十、两种 AI 使用范式的对比

Vibe Coding（即兴编码）

• AI 直接写/改代码
• 快、爽、探索性强
• 难审计、难规模化

Spec-Driven Coding（规格驱动）

• AI 产 Spec / Patch
• 模板/生成器产代码
• lint / test / CI 兜底
• 稳定、可控、团队友好

真实工程中，探索用 vibe，交付用 spec-driven。

十一、从工程视角的能力优先级建议

优先落地（低风险）

1. 需求拆解
2. Spec 生成
3. 文档/说明
4. lint/test 修复

需要治理后落地

1. 页面生成
2. 迁移重构
3. 测试体系补齐

谨慎使用

1. 核心业务逻辑
2. 架构级重构

十二、总结：AI 在前端的“正确位置”

AI 并不是来“替代前端工程师写页面”的。
它真正擅长的是：

把变化结构化，把重复自动化，把质量交给工程链路。

如果只能记住一句话：

AI 的能力不该绕开工程，而应该被工程约束。

最后，给出一个总览图：

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

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

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

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

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

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

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

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

1. 可审计：变化在 spec，生成结果可 diff
2. 可重复：同一个 spec 反复生成结果一致
3. 可兜底：lint/test 是硬门槛
4. 可规模化：从 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 只参与变化。

这个流程长什么样？

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

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

四、什么是 Spec？

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

页面的“规格说明书”

它描述的是：

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

而不是：

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

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

一个简化的 Spec 示例

{
  "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。

然后：

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 直接写页面，让它写“变化”，其余交给工程。

---

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