项目背景：为什么我想用 Vue3 还原一个企业级后台
这不是又一个 Todo App 教程。这是一个真实的 AI 模型管理后台------从 Figma 设计稿到可演示原型，一周交付，14 篇博客全程记录。
一、故事的开始：一个紧急的演示需求
那是周一早上的站会。
产品经理在 Slack 上丢过来一个 Figma 链接，附了一句：
"客户下周三想看模型管理后台的演示。后端还在写接口，你先用前端做一个能跑的原型吧。设计稿都在 Figma 里了，按那个来。"
打开设计稿，我深吸一口气------17 个 frame，涵盖三个完整的业务模块外加登录页。每个 frame 都经过了产品评审和设计走查，布局、颜色、间距、交互状态全部定稿。这意味着我不能"差不多得了"，必须做到像素级还原。
这不是一个"自己随便搭个界面"的任务。这是一个在时间压力下，严格按设计规范交付可演示原型的工程问题。
我快速估了一下工作量：
| 维度 | 规模 |
|---|---|
| Figma frame | 17 个 |
| 业务模块 | 3 个（API 注册管理 / 模型汇聚 / 模型标准发布） |
| 页面类型 | 登录页 + 列表页 + 详情页（多 Tab）+ 弹窗 + 多步骤表单 |
| 交互复杂度 | 筛选 / 搜索 / 分页 / 批量操作 / 状态机 / Tab 切换 |
| 预估工时 | 约 1 人周 |
一周时间。一个人。没有后端。设计稿已经锁死。
这就是这个系列的起点。
二、"管网模型工具"是什么
在展开技术细节之前，先交代一下这个项目的业务背景。
管网模型工具是一个 AI 模型生命周期管理平台。它的核心业务链路是：
模型汇聚 → 格式转换 → 标准发布 → API 注册 → 在线调试用大白话说：团队训练了各种 AI 模型（算法模型、几何模型、物理模型、规则模型），需要把它们统一管理起来。先汇聚到平台，转换成标准格式，然后发布成可供外部调用的 API，最后在平台上直接调试这些 API。
这个平台有三个核心业务模块：
- API 注册管理：管理已注册的后端 API------增删改查、启停用、在线调试。这是平台的"入口"，外部系统通过它调用 AI 能力。
- 模型汇聚：管理所有 AI 模型的元信息和文件------基本信息、接口参数、模型文件、命令行脚本。这是平台的"核心"，所有模型在这里被标准化。
- 模型标准发布：把内部模型封装成标准 API 供外部调用------发布审批、版本管理、状态流转。这是平台的"出口"。
Figma 设计稿中的 17 个 frame 就是按照这个业务逻辑组织的：
| 模块 | Frame 数量 | 包含页面 |
|---|---|---|
| API 管理 | 8 | 注册列表、注册弹窗（2 变体）、详情-基本信息、详情-运行调试 |
| 模型汇聚 | 6 | 模型列表、详情-接口、详情-模型文件、详情-命令行脚本、新增弹窗 |
| 模型标准发布 | 3 | 发布列表、基本信息页、发布弹窗 |
| 登录 | 1 | 登录页 |
这是一个真实的企业级后台------不是"增删改查玩具"，而是有明确业务逻辑、有状态流转、有多模块协作的生产级产品雏形。
三、为什么选择"还原 Figma"而不是"从零设计"
面对这个任务，我有两条路：
路线 A：不看 Figma，自己凭感觉搭一个后台。速度快，但最终效果和设计稿会有偏差，演示时可能被客户挑刺。
路线 B：严格按 Figma 设计稿还原。工作量大，但成品和设计稿一致，演示时零争议。
我选了路线 B。理由有三：
1. 设计稿已经过评审，避免重复造轮子
Figma 里的 17 个 frame 不是设计师随便画的------它们经过了产品评审、设计走查、甚至部分已经和客户确认过。颜色体系、间距规范、交互逻辑都已经确定。我如果从零设计，相当于重复做了一遍产品+设计的工作，而且大概率不如专业设计师做得好。
还原设计稿，本质上是站在产品和设计的肩膀上，把精力集中在工程实现上。
2. 还原设计稿是前端工程师的核心能力
在很多公司，前端工程师的日常就是：打开 Figma → 读懂设计稿 → 写出像素级一致的代码。这不是"低级重复劳动"，而是一门需要刻意练习的工程能力。你需要：
- 能读懂 Figma 的节点结构和设计 token
- 能把设计 token 翻译成 CSS 变量和组件 props
- 能处理组件状态（hover / active / disabled / loading / empty）
- 能在还原和工程可行性之间做取舍
这些能力，不是看几篇教程就能掌握的，必须在真实项目中刻意练习。
3. 还原类项目细节多，是练手的最佳题材
看起来"只是还原设计稿"，实际上涉及的技术栈非常全面：
- Figma 数据提取：用 MCP 工具解析设计稿的元数据
- 设计系统：把设计 token 工程化为 CSS 变量
- 组件封装：基于 Element Plus 二次封装通用组件
- 状态管理：Pinia 管理全局状态
- Mock 数据：mockjs 模拟真实后端响应
- 性能优化：懒加载、按需引入、构建优化
- 像素级验收：Playwright 自动化截图对比
一个项目，覆盖了 Vue 3 企业级开发的全栈技能树。
四、这个系列能让你学到什么
如果你正在看这篇文章，大概率是以下情况之一：
- 学了 Vue 3 基础，想找一个"不是 Todo App"的实战项目
- 工作中需要和设计师协作，但不知道怎么看 Figma
- 想学 Element Plus 的企业级用法（而不是"装个组件库就完事"）
- 对设计系统、组件封装、像素级还原有兴趣
这个系列就是为你准备的。具体来说，你会学到：
| 技能点 | 对应篇章 | 学完能做什么 |
|---|---|---|
| 完整企业级后台开发流程 | 01-14 全系列 | 从立项到交付的完整视角 |
| Figma + 前端协作 | 03 | 用 MCP 工具"读"设计稿而非"看"设计稿 |
| 设计系统工程化 | 04 | 定义 CSS 变量 + 覆写 Element Plus 主题 |
| 组件库二次封装 | 07 | 基于 Element Plus 封装业务通用组件 |
| 列表页工程范式 | 08 | 筛选/搜索/分页/批量操作的标准实现 |
| 复杂详情页设计 | 09 | 多 Tab + URL 同步 + 状态保持 |
| 状态机驱动开发 | 10 | 草稿→审核→发布→下线的完整流转 |
| Mock 数据策略 | 11 | mockjs + axios 拦截器让原型"活"起来 |
| 性能优化实操 | 12 | 首屏 3.2s → 0.9s 的具体手段 |
| 像素级验收 | 13 | Playwright + pixelmatch 自动化视觉对比 |
这些不是"面试八股文"式的知识点罗列，而是在一个真实项目中必然遇到的工程问题及其解决方案。
五、项目规模：真实，但不夸张
为了让读者能跟得下去，我在项目规模上做了刻意控制：
- 只做前端：不碰后端、不碰数据库、不碰部署。Mock 数据搞定一切。
- 代码量适中：约 8000 行，50 个文件。不会大到让人望而却步，也不会小到学不到东西。
- 技术栈主流：Vue 3.4+ / Vite 5+ / Element Plus 2.4+ / Pinia 2 / Vue Router 4。用的都是当前（2026 年）最主流的技术。
- 有完整源码：每篇博客的代码都在项目仓库中，可以直接跑起来看效果。
项目目录结构预览：
pipe-network-tool/
├── src/
│ ├── api/ # 接口请求层
│ ├── components/ # 通用组件（AppTable / AppDialog / AppPagination...）
│ ├── layout/ # 布局组件（MainLayout / TopBar / SideNav...）
│ ├── views/ # 页面组件（3 大业务模块）
│ ├── router/ # 路由配置（嵌套路由 + 懒加载）
│ ├── store/ # Pinia 状态管理
│ ├── styles/ # 全局样式 + CSS 变量 + Element Plus 主题覆写
│ ├── mock/ # Mock 数据 + axios 拦截器
│ ├── utils/ # 工具函数
│ └── data/ # 静态数据 / 常量
├── vite.config.js
└── package.json六、14 篇系列规划
整个系列按照"从立项到交付"的时间线组织，每篇聚焦一个核心问题：
| # | 标题 | 解决什么问题 | 难度 |
|---|---|---|---|
| 01 | 项目背景与选题（本篇） | 为什么做这个项目，能学到什么 | ⭐ |
| 02 | 技术选型 | Vue3 vs React，为什么选 Element Plus | ⭐⭐ |
| 03 | Figma 数据提取 | 用 MCP 工具"读"设计稿 | ⭐⭐ |
| 04 | 设计系统建设 | 设计 token → CSS 变量 → 主题覆写 | ⭐⭐ |
| 05 | 工程脚手架 | 5 分钟搭出标准项目结构 | ⭐ |
| 06 | 主布局设计 | 顶栏 + 侧栏的工程化拆分 | ⭐⭐ |
| 07 | 通用组件封装 | AppTable / AppDialog / AppPagination | ⭐⭐⭐ |
| 08 | API 注册管理 | 列表页范式（筛选/搜索/分页/批量操作） | ⭐⭐⭐ |
| 09 | 模型汇聚 | 多 Tab 详情页 + 多步骤表单 | ⭐⭐⭐ |
| 10 | 模型标准发布 | 状态机驱动的业务流程 | ⭐⭐⭐ |
| 11 | Mock 数据策略 | mockjs + axios 拦截器 | ⭐⭐ |
| 12 | 性能优化 | 懒加载 / 按需引入 / 构建优化 | ⭐⭐ |
| 13 | 像素级验收 | Playwright + pixelmatch 自动化对比 | ⭐⭐ |
| 14 | 项目总结 | 踩坑记录 + 可复用模式 + 经验沉淀 | ⭐ |
建议按顺序阅读，但如果你时间有限：
- 想看代码怎么写：跳到 05 → 07 → 08
- 想看设计稿怎么用：跳到 03 → 04 → 06
- 想快速了解全貌：看完本篇 + 14（总结）
七、写在第一篇的最后
前端圈有个现象：教程项目不是 Todo App 就是博客系统。它们很适合入门，但和真实的企业级开发之间有一道鸿沟------真实项目有设计稿约束、有业务逻辑、有状态流转、有模块协作、有交付压力。
这个系列想做的，就是填上这道鸿沟。
不是什么高深的技术，不是什么炫酷的架构，就是一个前端工程师拿着 Figma 设计稿，在一周内把 17 个 frame 变成可演示原型的完整过程。每一步怎么做的，为什么这么做，踩了什么坑，都会如实记录下来。
如果你准备好了，我们下一篇见：技术选型：Vue3 vs React，为什么选 Element Plus。
下一篇预告：面对企业级后台项目，Vue 3 + Element Plus 和 React + Ant Design 怎么选？从开发效率、生态成熟度、上手成本三维度详细对比。