用 AI 做后台管理系统：最适合练手的场景

接手过后台项目的人都有这个经历：产品经理甩过来一张 Figma，里面是用户列表、订单表格、折线图、侧边导航——感觉信息量很大，但真的坐下来写，你会发现其中至少七成是重复模式：一张表、一个表单、一个图表、一套权限控制。

这就是为什么后台 Dashboard 是 AI 编程练手最好的地方。

---

为什么后台最适合用 AI 练手

别的场景——算法优化、实时通信、底层 SDK——AI 给的方案往往需要你深度审查才能用，你得有足够的背景知识判断它对不对。但后台不一样：

模式固定，结果可验证。

后台的核心是增删改查（CRUD）。一张用户表需要：列表页、详情页、新建表单、编辑表单、删除确认。这五个页面的结构几乎一模一样，换个数据模型就换了一套。AI 最擅长的就是这种有清晰模板的重复工作——你给它数据模型，它能把整套页面生成出来，而你要做的是审查逻辑对不对、UI 是否符合设计稿。

有大量成熟组件可用。

表格、表单、图表、权限——每一个在主流组件库里都有开箱即用的方案。AI 知道这些组件的用法，你不需要教它，只需要说清楚你要什么效果。

错了马上能看出来。

后台的交互反馈直接：按删除按钮数据没减少，提交表单报 400，图表没渲染——这些问题你肉眼就能发现，不需要写复杂的测试来验。这让"让 AI 改 → 看效果 → 再给反馈"的循环跑得非常快。

---

技术选型：先选模板，不要从零搭骨架

很多人第一次做后台，想着"我用 React + Vite，自己搭路由、搭布局、搭主题"。结果两天过去了，还在调侧边栏的折叠动画，连一个业务页面都没写。

结论：用成熟的 admin 模板或 UI 组件库，让 AI 填业务，不要让 AI 替你造轮子。

几个方向，以你熟悉的技术栈为主（具体版本以官方文档为准）：

React 技术栈

• Ant Design Pro：完整的 admin 骨架，内置权限、菜单、请求封装，拿来就能用。适合不想花太多时间在工程配置上的场景。
• Arco Design Pro（字节系）：和 Ant Design Pro 思路类似，组件风格不同，看喜好选。

Vue 技术栈

• Element Plus + vue-element-admin（或同类模板）：社区积累深厚，问题基本都能搜到。
• Naive UI Admin / Arco Design Vue：相对年轻，组件设计更现代，适合新项目。

不想折腾框架配置

• 直接让 v0.dev 帮你生成初始界面：把你的数据模型和页面描述喂给它，先出 UI 草稿，再拉进项目里调。

选定技术栈之后，把模板跑起来是第一步，后续所有 AI 操作都在这个已经跑通的骨架上进行。

---

一步步搭：数据模型→CRUD→接数据→图表→权限

下面以一个"订单管理后台"为例，演示每一步怎么给 AI 提需求。工具用 Cursor 或 Claude Code 都行，提法相同。

第一步：定数据模型

先把你的业务实体说清楚。不要直接让 AI "帮我做个订单管理系统"——太宽泛，它猜一半，你改另一半。

提需求示例：

我要做订单管理的后台，数据模型如下：

Order {
  id: string
  orderNo: string        // 订单号，展示用
  userId: string
  userName: string       // 冗余用户名，避免联表
  status: 'pending' | 'paid' | 'shipped' | 'done' | 'cancelled'
  totalAmount: number    // 单位分
  createdAt: timestamp
  items: OrderItem[]
}

OrderItem {
  productId: string
  productName: string
  qty: number
  price: number
}

先帮我把这两个类型的 TypeScript interface 写出来，放在 src/types/order.ts，
同时生成一份 mock 数据（10 条 Order，每条 1-3 个 OrderItem），放在 src/mock/orders.ts。
暂时不接真实接口，用 mock 先把 UI 跑起来。

这一步的产出是：明确的类型定义 + 可用的假数据。后续所有页面都基于这份数据结构生成，不会出现字段对不上的情况。

---

第二步：生成 CRUD 页面

有了数据模型，让 AI 生成完整的 CRUD：

提需求示例：

基于 src/types/order.ts 的 Order 类型，帮我生成订单列表页。

要求：
1. 用 Ant Design 的 Table 组件
2. 列：订单号、用户名、状态（Tag 展示不同颜色）、金额（分转元，保留两位小数）、创建时间、操作列（查看/取消）
3. 支持按状态筛选（顶部 Select 下拉）
4. 分页，pageSize 默认 20
5. 数据先用 src/mock/orders.ts 里的 mock 数据

文件放 src/pages/orders/List.tsx，路由已配好，直接写页面组件就行。

注意几个好习惯：

• 说清楚用哪个组件库（不然 AI 可能随机选一个）
• 说清楚数据来源（mock 还是接口）
• 说清楚文件放哪里（不然它可能新建一层奇怪的目录结构）

生成完之后，看一遍代码，确认列定义和你的字段名对上了，再跑起来看效果。

---

第三步：接真实数据

Mock 跑通之后，换成真实接口：

提需求示例：

把 src/pages/orders/List.tsx 的数据来源从 mock 改成调后端接口。

接口信息：
GET /api/orders
参数：page(number), pageSize(number), status(string, 可选)
返回：{ data: Order[], total: number, page: number }

用项目里已有的 request 工具（src/utils/request.ts），
不要引入新的 HTTP 库。

把接口文档直接粘进去，AI 能准确生成请求代码和参数绑定。不要只说"帮我接一下接口"——它不知道接口长什么样，猜出来的参数名大概率对不上。

---

第四步：加图表

大多数后台首页都有数据概览，折线图、柱状图、数字卡片三件套：

提需求示例：

帮我做后台首页的数据概览区域（src/pages/dashboard/Overview.tsx）。

要求：
1. 顶部 4 个数字卡片：今日订单数、今日销售额（元）、待发货订单数、本月新用户数
2. 下方左侧：近 7 天订单量折线图（用 Ant Design Charts 或 ECharts，用项目里已有的那个）
3. 下方右侧：订单状态分布饼图

数据先硬编码假数据，我后面自己换接口。图表区域高度 300px，响应式布局，移动端单列。

坑预警：图表库的选型和项目保持一致，别让 AI 随便引入新的依赖。如果项目已经有 ECharts，就说"用项目里已有的 ECharts"；没有的话，选一个自己熟悉的，告诉 AI 你选了哪个，让它按那个写。

---

第五步：加权限控制

权限是后台最容易做过头的地方，后面会细说。先把最常用的场景跑通：

提需求示例：

帮我给路由加基础的权限控制。

权限模型：
- 每个用户有一个 role：'admin' | 'operator' | 'viewer'
- admin：所有页面可访问
- operator：可访问订单管理和客户管理，不能访问用户管理和系统设置
- viewer：只读，不显示操作列里的"取消"和"编辑"按钮

实现要求：
1. 在 src/router/index.tsx 里，给需要权限的路由加 meta.roles 字段
2. 做一个路由守卫，没权限的路由重定向到 /403 页面
3. 做一个 usePermission hook，暴露 canEdit / canDelete 两个布尔值，供页面组件判断按钮是否显示
4. 当前用户角色先从 localStorage 读，key 是 'user_role'，我自己会做登录写入那块

不需要做角色管理的 CRUD，只需要上面这些。

这个示例的关键是把边界说清楚："不需要做角色管理的 CRUD"——不然 AI 很可能给你一套完整的 RBAC 系统，你要的只是基础控制，结果拿到一堆你暂时用不上的代码。

---

别从零手搓后台骨架

有个真实场景：一个独立开发者想做一个内容管理后台，从零开始用 React Router 搭路由、做菜单收起展开、做主题切换、做面包屑……两周过去，基础骨架刚好用，还有一堆 bug 等着修，业务页面一行没写。

用成熟模板的逻辑：骨架已经有人验证过了，你的时间应该花在业务逻辑上，而不是重新证明侧边栏可以折叠。

用 Cursor 或 Claude Code 的正确姿势是：

1. 把模板跑通（10 分钟内）
2. 把项目结构喂给 AI（让它 ls 一遍目录，或者你贴一段 tree 给它）
3. 在这个上下文里逐步添加业务页面

AI 在"已有骨架基础上加功能"的场景里表现明显好于"从零搭整个项目"——因为它能看到项目已有的约定（请求工具、路由配置方式、组件引用风格），新生成的代码会自然地遵循这些约定，不会出现一半代码用 axios 一半用 fetch 的情况。

---

故障排查表

症状	大概率原因	处理方式
表格数据渲染出来 key 报 warning	Table 的 rowKey 没设，或设了 'id' 但数据里字段名不是 id	检查数据结构，把 rowKey 改成实际的唯一字段名
图表容器高度为 0，图表不显示	父容器没设高度，或组件在 Tabs 里被隐藏时初始化	给容器加明确高度；Tabs 切换后手动触发 resize
路由守卫跳转死循环	未登录状态重定向到 /login，但 /login 本身也触发了守卫	守卫里把登录页、403 页白名单排除在外
表单提交后数据没刷新	提交成功后没触发列表页的重新请求	提交成功回调里调用列表页的 refetch，或用全局状态触发
权限 hook 在某些组件里总是返回 false	localStorage 读取时用户还没完成初始化，拿到 undefined	登录流程里确保写 localStorage 早于权限 hook 的首次读取

---

常见问题

Q：后台首页的图表每次都要问 AI 怎么用某个库，太烦了。

把图表组件的封装方式固化一次。让 AI 帮你封装一个 LineChart 和 PieChart 包装组件，把复杂的初始化藏在里面，对外只暴露 data 和 config 两个 props。之后做新图表，复制这个模板改数据就行，不用每次重新搞配置。

Q：权限做到一半，角色越来越多，越来越乱，怎么办？

大多数后台不需要真正的 RBAC（基于角色的访问控制）——需要的是 2-3 个角色 + 几十个功能点的映射表。把这张映射表写成一个 config 文件，每次加新角色或新功能点，只改这一个文件，不要把权限判断散落在每个组件里。这个配置文件，AI 帮你维护非常方便。

Q：大表格翻页很卡，是哪里的问题？

先确认是前端问题还是接口慢。打开 Network 面板，看请求响应时间——如果接口 200ms 内返回，问题在前端渲染。常见原因：把操作列的按钮写成每行都 useState 管理弹窗状态、表格行数据里带了大对象（比如每条订单附带了完整的商品列表）。把弹窗状态提升到表格组件层级，表格里只存 ID，点击时再按需加载详情。

Q：能直接让 AI 生成整套后台然后我直接用吗？

可以先让它生成骨架，但实际项目里不建议完全不审查直接用。AI 生成的代码里最容易出问题的地方是：字段名和你的接口不对应、权限判断逻辑有漏洞、边界情况（空数据、网络超时）没处理。每个模块生成完，花 5 分钟过一遍这三点，后面的维护成本会低很多。

---

小结：后台是 AI 编程的最佳练手场

后台 Dashboard 的特点——模式固定、组件成熟、反馈直接——使它天然适合 AI 编程的工作节奏：你描述需求，AI 生成代码，你看效果，你给反馈，循环快速推进。

给 AI 的需求越具体（数据模型、字段名、用哪个组件、数据来源是什么），生成的代码质量越高，来回改的轮次越少。

上一节 用 AI 从零做 SaaS 实战 覆盖了完整产品的构建节奏，后台通常是 SaaS 产品的 admin 端，两者结合着看更完整。下一节 用 AI 做落地页营销站 换一个场景——前台展示型页面，提需求的方式和后台有明显不同。

不想只做后台练手，想系统看 MVP 阶段哪些地方容易翻车，可以看 MVP 阶段最容易范错的 8 个地方，提前避坑。

回到 AI 编程教程全景 看你在整体路线里走到哪了。

---

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。