最近团队在全面铺开 AI Coding，工具从 Cursor 换到 Claude Code，效率确实是肉眼可见地上去了。但也带来了一个让我非常警惕的现象：“千页一面，却又处处是坑”。
AI 非常擅长生成那种“乍一看很像那么回事”的 Vue 页面。Element Plus 的组件一个个摆得整整齐齐，按钮能点，表格能渲。但只要你稍微眯起眼睛看一眼，就会发现：按钮圆角被莫名其妙覆盖了，表单项间距忽大忽小，甚至在某些角落里藏着 Tailwind 的类名。
这就像装修队找了个不懂设计的学徒工，照着效果图把砖垒起来了，但墙是歪的，水电是乱的。
作为架构师，我意识到不能再让 AI “自由发挥”了。我们需要重新定义人与 AI 的分工。经过几个迭代的磨合，我们定下了一个铁律：AI 负责生成标准化的“骨架”，人类负责“外科手术式”的细节微调。
以下是我们基于 Vue3 + Element Plus 落地这套方案的真实心得。
一、 为什么必须是“骨架 + 微调”？
在早期的尝试中，我们走过弯路。我们试图让 AI 直接生成“最终可用”的代码。结果呢？
过度设计（Over-Engineering）： 为了让页面“好看”，AI 会擅自给 el-card加阴影，给 el-button改圆角，甚至引入项目根本没有的 CSS 预处理器逻辑。
破坏一致性： 今天生成的表单 label-width是 80px，明天就是 120px。这种细微的差异在 50 个后台页面里积累起来，就是一场灾难。
不可控的风险： 最可怕的是，AI 为了修复一个样式 bug，可能会用 !important去覆盖 Element Plus 的默认样式，这在组件库升级时是巨大的隐患。
于是，我们决定收回设计权，下放搬运权。AI 就是那个高效的“搬运工”，它只负责把 Element Plus 的组件按照既定规则拼起来。而真正的“设计”——也就是对业务语义的理解和边界情况的把控，必须由人来接管。
二、 给 AI 立规矩：DESIGN.md 就是宪法
为了实现这个目标，我们在项目根目录强行植入了一份 DESIGN.md。这不仅仅是文档，这是我们给 AI 的“宪法”。
这份文件里没有任何“请保持简洁”、“要有科技感”这种虚词。全是死命令：
-
组件使用白名单： AI 只能使用 el-button、el-table、el-form等核心组件，并且必须严格按照我们定义的 Props 来用。比如，el-button的 size属性一律不许改，就用默认的。
-
布局死刑令： 严禁 AI 手写 Flex 或 Grid 布局去“优化”空间。所有的页面结构必须遵循我们定义的 page-container、page-header这种标准壳子。
-
样式封杀令： 这是最狠的一条——禁止任何形式的 <style>自定义。AI 只能使用 Element Plus 内置的 CSS Variables（如 var(–el-color-primary)）。任何试图写 scoped样式覆盖组件库的行为，都会被直接驳回。
通过这种方式，我们把 AI 的创造力锁死在了“乐高积木”的拼装上。它不能改造积木，只能按图纸拼。
三、 开发者的角色转变：从“码农”到“质检员”
当 AI 开始写骨架后，我们团队的前端同学并没有失业，反而变得更像架构守护者。
现在的工作流变成了这样：
AI 生成骨架： 输入指令：“基于 DESIGN.md，生成一个用户管理页面，包含查询表单和表格。”
AI 输出代码： 一个标准的 Vue 单文件组件出炉了。它长得中规中矩，甚至有点呆板。
人工微调（关键步骤）：
-
逻辑注入： 我去检查 Form 的校验规则是否合理，Table 的 key是否用了业务主键，权限控制是否到位。
-
业务对齐： 确认表格列的排序是否符合业务优先级，操作按钮的显隐逻辑是否处理了各种边界情况。
-
性能兜底： 看看 v-for有没有滥用，大数据列表是否需要引入虚拟滚动。
这时候你会发现，你避开了最枯燥的“搬砖”工作（写那十几个表单项，写那五六列表格），把精力全部集中在了最有价值的“风险控制”和“逻辑实现”上。
四、 实战中的代码示例
在我们的项目里，AI 生成的代码基本长这样：
<template>
<div class="page-container">
<div class="page-header">
<span class="page-title">用户管理</span>
<div class="page-actions">
<el-button type="primary">新增用户</el-button>
</div>
</div>
<el-divider />
<div class="page-body">
<el-table :data="list" border>
<el-table-column prop="id" label="ID" width="80" />
<el-table-column prop="name" label="用户名" />
<el-table-column label="状态">
<template #default="{ row }">
<el-tag :type="row.statusType">{{ row.statusText }}</el-tag>
</template>
</el-table-column>
</el-table>
</div>
</div>
</template>
这种代码看起来很“笨”，但它是可维护的。剩下的工作，就是我们去填充 list的逻辑，去对接接口，去处理那 10% 需要人类智慧的复杂交互。
五、最终版 DESIGN.md（Vue3 + Element Plus 专用）
—
version: 1.2.0
name: Admin-Console-Vue3-EP
framework: vue3
ui: element-plus
mode: ai-scaffold-human-polish
owner: frontend-arch
—
一、总体原则（AI 必须无条件遵守）
AI 只负责“拼组件”，不负责“做设计”
所有 UI 必须 100% 基于 Element Plus 默认样式
禁止任何自定义 CSS、Tailwind、UnoCSS
禁止任何形式的视觉“优化”
输出结果视为“待人工微调的骨架代码”
二、页面结构规范（AI 唯一可用模板）
<template>
<div class="page-container">
<div class="page-header">
<span class="page-title">{{ title }}</span>
<div class="page-actions">
<!– AI 仅在此处放置 el-button –>
</div>
</div>
<el-divider />
<div class="page-body">
<!– 查询 / 表格 / 表单 –>
</div>
</div>
</template>
<script setup lang="ts">
import { ref } from 'vue'
const title = '页面标题'
</script>
<style scoped>
/* ✅ 仅允许以下结构样式 */
.page-container {
padding: 16px;
background: var(–el-bg-color-page);
}
.page-header {
display: flex;
justify-content: space-between;
align-items: center;
}
.page-title {
font-size: 18px;
font-weight: 500;
color: var(–el-text-color-primary);
}
.page-actions {
display: flex;
gap: 8px;
}
</style>
三、组件使用细则（AI 只能照抄）
1️⃣ El-Button（按钮）
✅ 允许用法：
<el-button type="primary">保存</el-button>
<el-button>取消</el-button>
<el-button type="danger" link>删除</el-button>
❌ 禁止行为：
-
禁止 size属性
-
禁止自定义 style
-
禁止 circle/ round
-
一个操作区主按钮 ≤ 1
2️⃣ El-Form（表单）
✅ 强制规范：
<el-form label-width="100px">
<el-form-item label="名称">
<el-input v-model="form.name" />
</el-form-item>
</el-form>
❌ 禁止：
-
inline表单
-
自定义 label-width
-
自定义校验 UI
3️⃣ ElTable（表格）
✅ 强制规范：
<el-table :data="list" border>
<el-table-column prop="id" label="ID" width="80" />
<el-table-column label="状态">
<template #default="{ row }">
<el-tag :type="row.statusType">
{{ row.statusText }}
</el-tag>
</template>
</el-table-column>
</el-table>
❌ 禁止：
-
stripe
-
彩色文字
-
自定义表头高度
四、AI 绝对禁区（触碰即打回）
|
手写 <style>覆盖 EP |
破坏升级兼容性 |
|
Tailwind / UnoCSS |
双样式体系灾难 |
|
自定义动画 |
干扰业务稳定性 |
|
修改 border-radius |
破坏一致性 |
|
使用 Emoji 作为 UI |
非专业后台气质 |
|
修改 box-sizing |
不可控副作用 |
五、AI Prompt（固定话术，每次必带）
请基于 Vue 3 + Element Plus 生成页面骨架，严格遵守项目根目录 DESIGN.md规范。
-
只使用 Element Plus 官方组件
-
不写任何自定义 CSS
-
不引入 Tailwind / UnoCSS
-
不修改组件默认样式
-
不“优化”布局或间距
-
输出结果视为“待人工微调的骨架代码”
不要解释设计理由，只输出代码。
六、MR 人工微调 Checklist（架构师 / 高级前端用）
✅ 此 Checklist 用于 AI 生成代码 → 人工 Review → 合并主干
🔴 必须人工处理（AI 禁止碰）
-
[ ] 表单校验规则是否合理
-
[ ] 接口字段映射是否准确
-
[ ] 权限控制是否遗漏（按钮 / 路由 / 数据）
-
[ ] 表格 key是否使用业务主键
-
[ ] 是否存在非必要的响应式计算
-
[ ] 分页 / 筛选 / 排序逻辑是否完整
🟡 推荐人工优化（提升质量）
-
[ ] 表单项顺序是否符合业务优先级
-
[ ] 表格列顺序是否符合用户习惯
-
[ ] 空状态（empty）是否处理
-
[ ] loading / disabled 状态是否覆盖完整
-
[ ] 错误兜底（try / catch / message）是否完善
🟢 禁止放行的情况（直接打回）
-
[ ] 存在手写 CSS 覆盖 Element Plus
-
[ ] 引入 Tailwind / UnoCSS
-
[ ] 修改组件默认样式
-
[ ] 使用非 EP 官方组件
-
[ ] 存在“为了好看”的非功能性代码
🧠 架构师签字项（合并前确认）
-
[ ] 本次改动是否引入新的 UI 模式
-
[ ] 是否需要同步更新 DESIGN.md
-
[ ] 是否会影响已有 3 个以上页面的一致性
六、 结语
AI Coding 并不是要取代程序员，而是要淘汰那些“只会拼组件”的程序员。
在 Vue3 + Element Plus 的技术栈下，DESIGN.md + AI 骨架 + 人工微调，是目前我看到的兼顾效率与工程质量的最佳解。
我们把重复劳动交出去，把控制权拿回来。让 AI 去写那些它擅长的“标准件”，让我们专注于解决真正的业务复杂性。这才是架构师在面对 AI 浪潮时，应有的清醒与定力。
