这些年我一直在做 Fantastic-admin 这套管理后台框架。也一直在关注这个圈子的发展，虽然"技术栈在升级"、"UI 风格也在变化"，但管理后台框架核心一直在不断解决同一个问题：
如何把那些反复出现、又特别容易失控的工程问题，提前收敛成一套系统能力。
早期，这个问题的答案是"给我一个能跑起来的脚手架"；后来变成"帮我把常见页面骨架搭好"；再后来，变成"不要让我被框架反过来绑架"；而到了今天，在 AI 和 Agent 已经真的进入开发现场之后，我觉得问题已经变成了：
一个管理后台框架，能不能同时服务开发者和 Agent ？
这也是我写这篇文章的原因。在我看来，AI 当下的管理后台，已经不能只是一个后台模板，它必须是一套面向长期协作的工程系统。
再聊之前，不妨先回顾下管理后台框架的发展史。这里以 Vue 生态下的管理后台为主。
第一阶段：脚手架时代，解决了"从 0 到 1"
这个阶段最核心的诉求非常朴素：
- 不要让我从空目录开始搭项目
- 不要让我自己接 Vue、路由、状态管理、权限、登录、Mock、构建配置，哪怕其中有些我不用，但也最好有
在这个阶段，vue-element-admin 是绕不过去的一款产品，它除了解决了开发者的基本诉求外，还提供了一套非常前卫的设计：用路由驱动导航菜单。
今天看这件事很自然，但在当时，这其实是很关键的一步：
- 导航菜单不再需要额外维护一份数据
- 路由结构和导航菜单结构天然一致
- 标题、图标、权限这类信息可以集中管理
为什么这一步重要？因为后台和普通内容网站不一样，导航本身就是产品的信息架构。导航一乱，整个后台的认知成本就会上去。
所以在我看来，第一个阶段最重要的历史贡献就是这个路由即导航的设计，影响了几乎所有后来诞生的后台框架。
第二阶段：模板繁荣时代，开始出现"虚假的强大"
随着 Vue 3 发布，以及 vue-element-admin 作者的停更，大量新的管理后台框架开始出现。
这一阶段有一个非常明显的现象：与其说是框架，更像是"模板展厅"。因为你会看到：
- 第三方插件集成示例越来越多
- 图表、地图、编辑器、拖拽控件、可视化页面一应俱全
很容易让人觉得"这个框架很强"，但真的是这样么？
我们不可能在一个项目中把这些所有插件都用上，即便会用到其中几个，提供的这些示例页面也未必能满足实际的需求。而绝大多数真实业务团队，日常最高频的需求反而是：
- 列表页怎么高效搭建
- 搜索区、分页区、操作区怎么统一
- 新增、编辑、详情页怎么组织
- 菜单、路由、权限、缓存怎么协同
也就是说，这个阶段很多后台框架在解决的是"看起来像个成熟后台"的问题，而不是"怎样真正高效地服务开发者"的问题。
这是我做 Fantastic-admin 时非常警惕的一件事：
不要把框架做成一个演示效果很强、真正落地时却帮不上太多忙的样子货。
第三阶段：后台框架开始回到"系统能力"本身
如果说第二阶段有不少东西是在做"展示能力"，那么从第三阶段开始，我觉得后台框架终于慢慢回到了更本质的问题上：
它到底能不能成为一套真正服务业务的系统。
在我看来，这一阶段出现了两条很清晰的路线。
一条路线是向内走：把框架本身做得更完整
这条路线的核心是尽量扩充框架自身的系统能力，也是我开发 Fantastic-admin 时侧重的一条路。因为我发现，真正影响一个后台项目长期体验的，往往不是那些最显眼的东西，而是：
- 导航布局够不够灵活
- 页面布局能不能适配不同产品形态
- 路由元信息够不够细
- 标签栏、工具栏、偏好设置是不是成体系
- 页面保活是不是只停留在"开/关"两档
- 有没有合理的扩展位，而不是逼着开发者去改框架源码
- 等等
这些能力平时开发使用未必会注意到，但它们决定了一个项目在需求扩张的时候，能否让开发者放心，不用担心框架没有提供这个能力的问题。
比如页面保活这件事，我一直觉得很多框架做得太粗了，通常都只是提供一个 keepAlive: true 的开关，虽然能解决一部分问题，但真实后台项目的诉求往往更复杂：
- 从列表进详情，希望列表保活
- 从列表跳其他模块，希望列表不保活
- 标签页合并(Fantastic-admin专有功能)后，有些页面要保活，有些页面返回时必须释放保活
基于这些场景，我更想做的是一套可控的保活策略，而不是一个粗糙的开关，因为这才是业务开发者真正会长期依赖的能力。
另一条路线是向外走：继续靠近业务开发本身
另一条路线也很重要，因为一个事实是：后台大量业务页面，本质上高度重复。
- 结构重复
- 交互重复
- 列表重复
- 表单重复
- 弹窗抽屉重复
总的来说就是大量 CRUD 模块高度重复，既然重复，那就不应该每次都从基础组件重新拼。
所以有框架开始探索更高层的业务抽象，比如 vben 就提供了更成熟的 CRUD 能力、更高集成度的表格表单组件，这些方向我都认为目前还是对的。
岔开聊一句，为什么说目前还是对的，因为高集成度的封装和抽象，本质上是减轻人类开发者的工作，假设我们面对一个5000-6000行的代码文件，想要理解它是很痛苦的，所以工程化、组件化的理念才如此重要。但这种大文件却刚好很契合 AI ，毕竟如果文件拆分太多，AI 频繁需要跨文件引入，上下文变得碎片化，必然会出现链路过长，信息丢失的情况，反而不适合 AI 优先的开发模式。
但不管怎么说，从这一步开始，后台框架的竞争终于不再停留在"模板多不多"，而是进入了更实在的层面：
谁能真正把业务开发里的重复劳动继续向上抽象。
补充一点：框架开始和 UI 组件库解耦
第三阶段继续往前走，我自己又越来越强烈地感受到另一个问题：
几乎所有后台框架和某个 UI 组件库绑定死了。
这会直接带来几个问题：
- 开发者认同你的工程设计，但不认同你的 UI 风格
- 框架代码和某个 UI 库深度绑定，更换 UI 库成本巨大
- 一旦 UI 组件库停止维护或维护不积极时，整套系统都会受到牵连
发现这个问题后，我就知道不能把 Fantastic-admin 绑死在某个 UI 库上。
而 shadcn/ui 以及后来社区出现的 shadcn-vue ，对我来说是一个非常关键的信号。
它带来的最重要启发，不是某个按钮或者弹窗组件本身，而是它在强调一件事：
- 组件代码应该是开放的
- 组件应该是可读、可改、可延展的
- 设计系统应该掌握在项目自己手里
- 组件不是黑盒消费品，而是工程资产
shadcn/ui 官方甚至直接强调自己 不是传统组件库，而是一种构建组件的方式。
当侧边导航、弹窗、抽屉、消息通知等等这些基础组件和 UI 组件库解耦后，Fantastic-admin 彻底变成了一套独立的，不再是某个 UI 组件库生态下的管理后台框架。
第四阶段：Agent 爆发之后，后台框架应该被重新定义
到了今天，AI 和 Agent 的爆发，不是在给后台框架"增加一个新卖点"，而是在逼着整个领域重新回答一个问题：
如果 AI 已经能读代码、改代码、理解目录、执行任务，那么管理后台框架应该如何被重新设计？
我自己简单分析了一下，在 AI 时代，一个管理后台框架至少应该具备下面 5 个特征：
1. 必须能让 AI 看懂项目全貌
这里就绕不开 monorepo 的架构了，过去我们说 monorepo 很多时候是在说工程治理、依赖复用、多应用扩展。
但今天我越来越觉得 monorepo 还有一个非常现实、而且会越来越重要的价值：
它天然更适合让 AI 建立完整上下文，能让 AI 拥有完整信息版图。
当应用代码、公共组件、主题、框架设置、文档、各种CI/CD脚本、技能定义都放在同一个结构清晰的仓库里时，AI 更容易快速理解：
- 哪些是业务层
- 哪些是公共能力
- 哪些是配置边界
- 哪些是复用资产
- 哪些是项目约定，哪些只是偶然写法
Google 在那篇著名的 monorepo 文章里，把 monorepo 的价值概括为"common source of truth"。
我不想机械照搬这句话，但在 AI 协作语境下，它确实给了我很强的启发：
统一的代码真相源，也意味着统一的 Agent 理解入口。
这当然不是说用了 monorepo 架构，AI 就自动变聪明了。但至少它更容易看到全貌，减少 AI 幻觉的产生。
2. 必须有一套 AI 能稳定读取的项目协议
只有代码结构还不够，要想让 AI 想稳定工作，还必须有一层项目级协议 ，也就是 AGENTS.md ，或者 CLAUDE.md 。
它们本质上都在解决同一件事：
AI 协作不能只靠一次次聊天，而是需要项目内置的长期说明。
这意味着一个现代项目，未来不只是有给人看的 README，也应该有给 Agent 看的 README。
3. 应该把高频任务产品化为 Skills
Prompt 适合解决临时问题，但不适合承载高频、稳定、可复用的项目流程。
后台项目最常见的动作其实非常固定：
- 生成 CRUD 模块
- 新增表单页
- 增加路由
- 配置国际化
- 修改框架设置
- 生成 store
- 定制主题
- 优化/美化页面
如果这些事情每次都靠人重新组织一段 Prompt，AI 的表现一定会飘忽不定。这也让我决定要把这些高频动作沉淀成 Skills，把目录约定、实现策略、文件位置、限制条件、注意事项全部前置进去。这样做的好处非常直接：
- AI 不再靠猜
- 生成结果更接近项目现有风格
- 不同 Agent 工具之间更容易复用同一套知识
- 项目经验不再只存在聊天记录里，而会沉淀成长期资产
在我看来，这一步很重要，因为它意味着我们开始从"会用 AI"走向"把 AI 纳入工程系统"。
4. 必须把"可修改"放在"可调用"前面
在 AI 时代，我越来越觉得一个被黑盒包裹得太深的组件体系，长期价值其实会下降。
因为 Agent 最擅长的，不只是调用 API，而是：
- 阅读现有代码
- 理解现有代码
- 修改现有代码
- 基于现有代码继续延展
如果组件只是一个外部依赖包里的抽象壳，AI 的可操作空间是受限的；但如果组件体系是开放的、分层清晰的、仓库内可读的，AI 的工作质量通常会高很多。
相信这也是 shadcn/ui 爆火的原因之一。
这里说一个暴论，目前国内比较火的 UI 库，我一直都没有看到官方有提供 skills ，在一个既没有 skill ，AI 又无法直接阅读 UI 库的源码，这在当前环境下，很有可能会被逐渐弃用。
未来的软件系统，不只是给人维护的，也会越来越多地交给 AI 一起维护。
所以我理解的现代管理后台，不是"我有一堆组件"就够了，而应该是：
- 有可读的组件实现
- 有统一的组件约定
- 有能沉淀后台业务场景的内建组件层
- 有可替换的底层 UI 能力
5. 最终服务的是"长期协作"，而不只是"快速生成"
很多人一谈 AI，就会把重点放在"生成更快"上。但我做后台项目这些年越来越觉得：快，从来不是唯一问题，甚至很多时候都不是核心问题。
真正重要的是：
- 生成出来以后，能不能做 code review
- 多个页面之间风格能不能保持一致（UI风格、代码风格）
- 多应用、多主题、多品牌场景下会不会慢慢失控
- 人和 Agent 或多 Agents 混合协作时，项目是否仍然稳定
所以在我看来，AI 时代最好的后台框架，不一定是第一次生成最惊艳的那个，而应该是：
最适合持续迭代、持续扩展、持续被 AI 正确理解的那个。
最后聊一聊 Fantastic-admin 即将发布的 6.0 版本
如果把前面这几个阶段串起来看，其实就很容易理解，为什么 Fantastic-admin 要在这个阶段发布一个大版本更新。
因为对我来说，它已经不只是"一个 Vue 3 管理后台框架"，而是在尝试回答一个更具体的问题：
如果管理后台框架要面向下一个阶段，它应该提前长成什么样子？
1. 一套可长期演进的工程底座
Fantastic-admin v6 采用了 pnpm monorepo 架构，仓库里把应用、公共包、文档、脚本、技能清晰拆开：
bash
fantastic-admin/
├── apps/ # 应用目录
│ ├── core # 应用源码
│ └── example # 示例应用
├── packages/ # 公共包目录
├── docs/ # 文档站点
├── scripts/ # 脚本工具
├── skills/ # AI 技能
└── package.json # 根目录 package.json这么做当然也有工程治理层面的考虑，但更重要的是，我希望"代码、文档、约定、技能"能够在同一个仓库里形成闭环。对于人来说，这是更清楚的工程边界；对于 Agent 来说，这是一张更完整的信息地图。
2. 把项目协议写进了仓库
仓库根目录有 AGENTS.md 文件，里面明确说明了：
- 项目技术栈
- 目录结构
- 开发命令
- 开发规范
- 注意事项
- 对技能使用的补充约束
这么做的原因很简单：我不希望 AI 每次都靠对话去猜这个项目是什么样子。
3. 把高频动作沉淀成了一套 Skills
目前已经有的 Skills ，包括但不限于：
- CRUD 模块生成
- 表单页生成
- 路由生成
- 国际化管理
- 框架设置管理
- 页面优化
- 预留插槽创建
- Store 生成
- 主题定制
Skill 一方面是可以节省 token ，另一方面是将我的能力和我对框架的理解，形成了一套任何人都可以直接复用的标准，这是一份给 AI 的指导方针，让 AI 不再是猜测你的需求，或者可以说相当于你"雇用"了作者本人帮你完成需求😁。
4. 一套更加完善的系统设计
Fantastic-admin 一直以来的重点，都不是去堆砌多少示例页面，而是把后台真正核心的问题做成一套可配置化的系统：
这些能力拆开看都不算噱头，但组合在一起，我认为它们构成的不是一个"模板展示项目"，而是一套真正的后台基础设施。
至此，Fantastic-admin 即将发布的 6.0 全新版本就是我对 AI 时代管理后台框架的全部理解。
如果你对 Fantastic-admin 开始感兴趣了，现在已经发布了 6.0 beta 版，欢迎来尝试体验，我将在4月中旬左右发布正式版本。