夜雨聆风之前写了一篇《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 的方式和效果：
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专有功能)后，进入某些页面要保活，进入某些页面又必须释放保活
框架提供了一套精细化的保活策略配置，满足复杂业务场景。
标签页合并
提供了两种合并模式：
根据 routeName合并，比如反复从列表页多次打开详情页，始终保持一个详情页（标签页）
根据 activeMenu合并，比如一个模块内，列表、详情、编辑页（或者更多相关页面），始终保持只有一个标签页
标签页行为和路由行为保持一致
后台框架通常会提供一些标签页的 API ，比如打开、关闭等，但在 Fantastic-admin 里，提供了进一步的加强。
后退自动关闭标签页，调用 router.go(delta)时会关闭当前标签页，通常在详情页返回列表页时会用到替换当前标签页，调用 router.replace(to)时会直接更新当前标签页，而不是新打开一个关闭标签页，扩展了一个路由的 API ，调用 router.close(to)时会关闭当前标签页，并新打开一个目标路由的标签页
这3个行为和路由的行为预期保持了一致，优势就是开发者通常不再需要关注标签页的 API 了，正常处理路由跳转时，标签栏会自动做处理。
为什么说是 AI 时代的版本答案？
相信看到这里，答案已经不言而喻了。
围绕着 monorepo 搭建的工程底座，让“代码、文档、约定、技能”能够在同一个仓库里形成闭环，从而实现长期演进。
结合 AGENTS.md 和 Skills ，让 AI 每次执行任务不再是重新了解，而是有明确的指导方针。
最后搭配上 Fantastic-admin 出色的系统设计，兼顾“人类开发者的效率”和“AI 协作的稳定性”。
如果你需要一个要长期维护、持续扩展、并且希望真正把 AI 引入开发流程的项目，那么 Fantastic-admin 6.0 全新版本值得你看看。
Fantastic-admin 官网
https://fantastic-admin.hurui.me/
