之前写了一篇《AI 时代的管理后台框架，应该是什么样子？》文章，我的一些见解得到了蛮多人的认同。

如果说那篇文章是我对 AI 时代管理后台框架的全部理解，那这篇文章就是从理论到落地的一份完美答卷。

那就少废话，直接看东西。

文章内包含部分专业版特性。

AI Skills

Fantastic-admin 6.0 最核心的一点，是把后台开发里常见的高频操作沉淀成了一套可复用的 AI Skills，这是一套和 Fantastic-admin 目录结构、组件用法、路由方式、设置体系绑定的工作流，让 AI 从一开始就按框架规则工作。

更重要的是，我想解决的不是“AI 能不能写后台页面”，而是“当你在使用 Fantastic-admin 时，AI 能不能像我(作者)一样，熟悉并按照框架的规则稳定交付”。这是两个完全不同的问题，而前者是一个概率问题，后者才是真正能落地的生产力。

以下是目前提供的 Skills ：

• fa-crud-page-generator：生成完整 CRUD 模块
• fa-form-builder：生成独立表单页
• fa-framework-settings：修改框架设置
• fa-i18n-manager：管理国际化
• fa-page-optimizer：优化页面并替换为框架内建组件
• fa-route-generator：创建或修改路由
• fa-slot-creator：创建布局插槽
• fa-store-generator：生成 Store 模块
• fa-theme-customizer：定制主题配色

你可以非常直接地告诉它：

• 主题切换成蓝色，默认深色模式，不需要圆角；导航菜单改为顶部模式，风格为圆点；启用标签栏，风格选择现代，并且要在工具栏下方展示；工具栏开启收藏夹；最后开启页面水印
• 生成一个黑客帝国风格的主题，创建好后直接使用，同时默认为深色模式
• 做一个商品管理模块，支持搜索、分页、新增、编辑、删除，并使用假数据，最后配置一个可访问的一级路由
• 给xx页面增加国际化支持

通常 AI 会根据你的描述信息，自动调用相关的 skill ，当然你也可以更明确的告诉 AI 使用哪一个 skill ，就像这样：

• claude code：/fa-framework-settings 改为顶部导航栏模式
• codex：$fa-framework-settings 改为顶部导航栏模式

这里我也上传了几个视频，方便大家能直观的看到使用 skill 的方式和效果：

fa-framework-settings 演示视频 fa-theme-customizer 演示视频 fa-crud-page-generator 演示视频 fa-i18n-manager 演示视频

Monorepo

Fantastic-admin 6.0 采用了 pnpm monorepo 架构。

这么做有工程治理层面的考虑，但更重要的是，我希望“代码、文档、约定、技能”能够在同一个仓库里形成闭环。对于人来说，这是更清楚的工程边界；对于 Agent 来说，这是一张更完整的信息地图。

fantastic-admin/
├── apps/              # 应用目录
│   ├── core           # 应用源码
│   └── example        # 示例应用
├── packages/          # 公共包目录
├── docs/              # 文档站点
├── scripts/           # 脚本工具
├── skills/            # AI 技能
└── package.json       # 根目录 package.json

这样的结构对长期项目特别重要，因为它天然更适合多应用扩展、公共能力沉淀和后续维护，也更方便 AI 理解“哪些是业务代码，哪些是框架能力”。

了解更多点这里。

80+ 内建组件

Fantastic-admin 6.0 给 5.0 的内建组件做了全方位的重构，并且新增了以下组件：

• FaEmpty 空状态
• FaNumberField 数字输入框
• FaQrcode 二维码
• FaScrollingText 滚动文字
• FaCascader 级联选择器
• FaTextShiny 流光文字
• FaMention 提及

至此，Fantastic-admin 的内建组件数量也来到了 80+ ，即便你不使用 Element-plus / Ant Design Vue / NaiveUI 这些第三方 UI 组件库，仅靠框架提供的内建组件，也能构建出大部分业务页面。

并且更重要的一点是，比起第三方组件库的“可调用”，内建组件是“可修改”的，并且每个组件目录内都有完整的 markdown 使用文档。

因为在 AI 时代，一个被黑盒包裹得太深的组件体系，长期价值其实会下降。并且 AI 擅长的也不是调用 API ，而是：

• 阅读现有代码
• 理解现有代码
• 修改现有代码
• 基于现有代码继续延展

组件满足不了业务需求？随时可以让 AI 来先读再改，分分钟定制一份专属组件，这是使用第三方组件库基本不敢想的事。

说明：Fantastic-admin 内建组件的定位并不是代替第三方组件库，而是提供了一些更贴合业务场景、美化视觉交互、风格尽量和框架保持一致的组件，通常是作为第三方组件库的补充。

了解更多点这里。

19 个预留插槽

Fantastic-admin 6.0 增加了布局顶部和底部插槽，支持的插槽数量也来到了 19 个。

你问什么是预留插槽？就是允许开发者在一定限度内满足客制化的需求，并且无需修改框架核心部分源码，这也是大部分后台框架没有提供的能力。

而通过这个能力，可以在框架各个区域扩展属于自己产品的内容，比如：

• 网站顶部的横幅公告

• 标题右侧的切换组织功能

• 网站底部支持伸缩的站点地图

了解更多点这里。

锁屏

了解更多点这里。

多账号管理

了解更多点这里。

路由级的页面布局配置

除了全局设置页面布局，现在可以针对每个路由单独设置页面布局。

了解更多点这里。

区域权限控制

在做国际化业务场景时，可以对某个路由做区域访问限制。例如某个模块，只允许中文用户访问，其他语言则无法访问。

了解更多点这里。

RTL 模式跟随语言设置

在 v5.x 里，RTL 模式是一个配置项，可以开启或关闭，但这其实并不合理，因为可能会出现明明是中文界面，却误开启了 RTL 。

现在将 RTL 这个开关移除并收纳进了语言信息中，也就是当用户切换语言的时候，如果该语言是需要 RTL 的，框架会自动开启。

了解更多点这里。

偏好设置支持更细粒度的自定义

几乎所有同类的后台框架都没有提供偏好设置这个能力，而是固定将几个配置项做了本地存储，例如主题、导航栏模式。

而我在 v5.x 里就已经提供了一份偏好设置的方案，只不过当时的方案并不完美，需要通过注释或取消注释代码的方式，才能将部分框架能力开放给用户自定义，并且也不支持更细粒度的自定义。

但在 6.0 里一切都解决了，除应用配置外，框架其余 40+ 个配置项（涵盖主题、导航菜单、顶栏、标签栏、工具栏、页面），均可以轻松开启偏好设置，开启的配置项则用户可以根据使用习惯自行调整。

了解更多点这里。

还有吗？

没有了，6.0 的新特性大概就是以上这些。

但考虑到大部分人可能是第一次了解到 Fantastic-admin ，我再介绍几个 6.0 版本之前就有提供，并且也是广受好评的特性。

7 款导航菜单模式

自由选择 UI 组件库

框架提供了 Ant Design Vue / Antdv Next / Arco Design Vue / Naive UI / Tdesign / Vexip UI 6 款组件库的预设模版，开箱即用，免去你自己集成。

当然你也可以自行集成其他的 UI 组件库，比如公司内部的，框架提供了统一的接入入口，方便快速更换。

了解更多点这里。

可控的保活策略

页面保活这件事，很多框架都做得太粗糙了，通常只提供一个 keepAlive: true 的开关，虽然能解决一部分问题，但真实后台项目的诉求往往更复杂：

• 从列表进详情，希望列表保活
• 从列表跳其他模块，希望列表不保活
• 标签页合并(Fantastic-admin专有功能)后，进入某些页面要保活，进入某些页面又必须释放保活

框架提供了一套精细化的保活策略配置，满足复杂业务场景。

了解更多点这里。

标签页合并

提供了两种合并模式：

1. 根据 routeName 合并，比如反复从列表页多次打开详情页，始终保持一个详情页（标签页）

2. 根据 activeMenu 合并，比如一个模块内，列表、详情、编辑页（或者更多相关页面），始终保持只有一个标签页

标签页行为和路由行为保持一致

后台框架通常会提供一些标签页的 API ，比如打开、关闭等，但在 Fantastic-admin 里，提供了进一步的加强。

• 后退自动关闭标签页，调用 router.go(delta) 时会关闭当前标签页，通常在详情页返回列表页时会用到
• 替换当前标签页，调用 router.replace(to) 时会直接更新当前标签页，而不是新打开一个
• 关闭标签页，扩展了一个路由的 API ，调用 router.close(to) 时会关闭当前标签页，并新打开一个目标路由的标签页

这3个行为和路由的行为预期保持了一致，优势就是开发者通常不再需要关注标签页的 API 了，正常处理路由跳转时，标签栏会自动做处理。

了解更多点这里。

所以，为什么说 Fantastic-admin 是 AI 时代的版本答案？

相信看到这里，答案已经不言而喻了。

围绕着 monorepo 搭建的工程底座，让“代码、文档、约定、技能”能够在同一个仓库里形成闭环，从而实现长期演进。

结合 AGENTS.md 和 Skills ，让 AI 每次执行任务不再是重新了解，而是有明确的指导方针。

最后搭配上 Fantastic-admin 出色的系统设计，兼顾“人类开发者的效率”和“AI 协作的稳定性”。

如果你需要一个要长期维护、持续扩展、并且希望真正把 AI 引入开发流程的项目，那么 Fantastic-admin 6.0 全新版本值得你看看。

背景

逛 X 和 Github 的时候，经常会刷到一些很有意思的前端插件或组件，但它们大部分都是用 React 写的，毕竟 React 在全球的市占率还是远远高于 Vue 的。

但看到了就会一直心痒痒，总会想着如果能在我的 Vue 项目里也用上就好了。

换在以前，简单的我还能照着 React 源码实现手撸一份 Vue 的，但越来越多小而美的组件，背后的代码量不一定就很少。而且它也有可能是某个组件合集内的其中一个，并不是一个独立组件，这就会牵扯到 shared utils、样式入口、导出结构等等情况。大大增加了我这个只会一点 React 三脚猫功夫的 Vue 开发者。

于是，我决定写一个 skill ，让它能帮我将这些 React 组件，直接 1:1 复刻成 Vue 的。

为什么要用它？

直接让 AI 开干不行么？一定要用这个 skill 么？当然可以，如果是一个代码量很少的 React 组件，你完全可以直接将整个代码丢给 AI ，让 AI 直接写。

但下面这些场景，我更建议你使用这个 skill ：

1. 已经有明确的“参考实现”

这是最典型的情况，比如我在 GitHub 上看到了一个不错的组件，或者已经锁定了某个包、某个子目录，甚至只是某个 demo 页面。则可以直接将链接地址发给这个 skill ，接下来就是等待并验收。

我并不是从零想交互，而是已经有一个清晰的参考物，希望 Vue 版本尽量接近它的行为和体验。

2. 有些组件简约但不简单

很多组件表面上看起来不复杂，但想要复刻，背后的逻辑却是一层套一层：焦点管理、键盘交互、受控与非受控状态、浮层定位、portal、隐藏输入、事件抛出方式、组合式 API 的组织方式。这些东西很多只靠鼠标点点前端的UI界面是不一定能看出来的。

但如果使用这个 skill，它会把 README、示例、测试、源码、包导出这些材料一起当作“行为说明书”来看，完整复刻每一处逻辑，确保高还原度。

3. 迁移的是一个“小包”

还有一个场景就是把某个 React 小型前端库迁到 Vue，这时候就不只是重新实现几个 .tsx 文件了。比如一个带 Root、Trigger、Content、Item 这种结构的 headless 组件族，或者一个带若干 helper、样式入口和包级导出的轻量插件。

这种场景下，真正难的不是把组件渲染出来，而是保留它原来的使用方式和工程组织。

4. 不确定能不能实现一份 Vue 的版本

有些 React 组件它本身也就是个包装层，核心实现可能是引入了某个三方依赖，这时候我不确定三方依赖是否支持 Vue ，如果不支持，Vue 生态又是否有同类型的平替。再或者有些依赖本身就没必要保留，局部重写反而能让代码更轻量。

这时候这个 skill 就不是简单进行复刻了，它会先收集完整的信息，分析复刻难度，最后采用最合适的方案进行。

如何使用它？

安装：

npx skills add hooray/skills --skill='replica-to-vue' -g

然后在 Agent 里把链接丢给它就行，就像这样：

/replica-to-vue https://github.com/owner/repo 将这个仓库，实现一份适用于当前项目的 Vue 组件

实战案例

案例一：sileo

这是一个前阵子在 X 上算是比较火的 Toast 通知组件，这是它原本的样子：

而这是通过 skill 复刻后的样子：

案例二：Dice UI 里的 Mention 组件

这是一个在大组件库中的一个"提及"功能小组件，功能看起来不复杂，但因为并不是独立组件，涉及到一些组件库内部共享的包依赖，所以要单独复刻其中这一个组件，场景会更复杂。

这是它原本的样子：

而这是通过 skill 复刻后的样子：

甚至通过几轮简单沟通，还实现了自定义插槽，比原本组件功能更强大。

最后

写这个 skill 不仅仅是为了追求语法层面的转换效率，而是考虑在面对一个已经存在的优秀参考实现时，能更稳地把它带进 Vue 3 的世界里。

什么该保留，什么该替换，什么时候该承认边界，这些判断本身，才是这个 skill 真正重要的部分。