AI 时代的管理后台框架，应该是什么样子？

你有没有这种感觉：管了几年后台项目，技术栈换了又换，但有些东西好像从来没变过——列表页还是那些字段，表单还是那几套逻辑，增删改查永远在重复。

这不是你一个人的问题，这是整个后台框架领域一直在试图回答的问题。

而现在，AI 和 Agent 的爆发让这个问题变得更尖锐：如果 AI 已经能读代码、改代码、理解项目结构，那管理后台框架是不是得重新设计一遍？

今天想聊聊这个话题，顺带介绍一下 Fantastic-admin 6.0 的一些思路。

后台框架的四次进化

1.0 脚手架时代：解决"从 0 到 1"

早期后台框架的核心诉求很朴素：

这个阶段的代表是 vue-element-admin，它干了一件当时看起来很超前的事——用路由驱动导航菜单。

听起来简单，但意义不小：导航菜单不再需要单独维护一份数据，路由结构和导航结构天然一致，标题、图标、权限信息可以集中管理。

为什么这一步重要？因为在后台系统里，导航本身就是产品的信息架构。导航一乱，整个后台的认知成本直接拉满。

这个设计影响了后来几乎所有的后台框架。

2.0 模板繁荣时代：繁荣但有点虚

Vue 3 发布后，vue-element-admin 停更，大量新框架涌现。

这个阶段有个很明显的问题：与其说是框架，不如说是"模板展厅"。图表、地图、编辑器、拖拽控件、可视化页面一应俱全，看着特别强大。

但实际上？

大多数团队真正需要的，是：

结果这个阶段的后台框架，大多是演示效果很强，真正落地时帮不上太多忙的样子货。

3.0 系统能力时代：开始回到本质

这个阶段终于回归本质了，出现了两条清晰的路线：

路线一：向内走，把框架本身做完整

真正影响后台项目长期体验的，往往不是最显眼的东西，而是：

拿页面保活来说，很多框架只提供一个 keepAlive: true 的开关，但真实后台的诉求远比这复杂：

真正需要的，是一套可控的保活策略，而不是一个粗糙的开关。

路线二：向外走，继续靠近业务本身

后台大量业务页面，本质上高度重复：结构重复、交互重复、列表重复、表单重复、弹窗抽屉重复。

既然重复，就不应该每次都从基础组件重新拼。所以有框架开始探索更高层的业务抽象，比如 vben 提供了更成熟的 CRUD 能力、更集成度的表格表单组件，这个方向是对的。

不过这里有个有意思的判断：高集成度的封装，本质上是减轻人类开发者的工作。但这种大文件却刚好很适合 AI——文件拆分太多，AI 频繁跨文件引入，上下文碎片化，链路过长反而容易出问题。

4.0 UI 解耦：不再绑死在某个组件库

还有一个被忽视的问题：几乎所有后台框架都和某个 UI 组件库绑死了。

这带来了几个麻烦：

后来 shadcn/ui 的出现给了我很强的启发。它最重要的不是某个组件本身，而是它在强调一件事：组件代码应该是开放的、可读的、可改的、可延展的。

shadcn/ui 官方甚至直接说自己是一种构建组件的方式，而不是传统组件库。

当侧边导航、弹窗、抽屉、消息通知这些基础组件和具体 UI 库解耦后，Fantastic-admin 才真正变成了一套独立的、不依赖任何 UI 生态的后台框架。

AI 时代，后台框架的五个新特征

到了今天，AI 和 Agent 的爆发不是在给后台框架"增加一个新卖点"，而是在逼着整个领域重新回答一个问题：

如果 AI 已经能读代码、改代码、理解项目结构，那管理后台框架应该如何被重新设计？

我总结了五个关键特征。

1. 必须让 AI 能看懂项目全貌

这就要说到 monorepo 架构了。

过去聊 monorepo，往往在说工程治理、依赖复用、多应用扩展。但今天它还有一个更现实的的价值：它天然更适合让 AI 建立完整上下文。

当应用代码、公共组件、主题、框架设置、文档、CI/CD 脚本、技能定义都放在同一个结构清晰的仓库里时，AI 更容易快速理解：

Google 那篇著名的 monorepo 文章把这件事概括为 "common source of truth"——统一的代码真相源，也意味着统一的 Agent 理解入口。

当然不是说用了 monorepo AI 就自动变聪明了，但至少它更容易看到全貌，减少 AI 幻觉。

2. 必须有一套 AI 能稳定读取的项目协议

光有代码结构还不够，还需要一层项目级协议，也就是 AGENTS.md 或 CLAUDE.md。

它们的本质是：AI 协作不能只靠一次次聊天，而是需要项目内置的长期说明。

一个现代项目，未来不只是有给人看的 README，也应该有给 Agent 看的 README。

3. 把高频任务产品化为 Skills

Prompt 适合解决临时问题，但不适合承载高频、稳定、可复用的项目流程。

后台项目最常见的动作其实非常固定：生成 CRUD 模块、新增表单页、增加路由、配置国际化、修改框架设置、生成 store、定制主题……

如果这些事情每次都靠人重新组织 Prompt，AI 的表现一定会飘忽不定。

更好的做法是把这些高频动作沉淀成 Skills，把目录约定、实现策略、文件位置、限制条件、注意事项全部前置进去。

这样做的好处是：

这一步意味着从"会用 AI"走向"把 AI 纳入工程系统"。

4. 把"可修改"放在"可调用"前面

我越来越觉得，一个被黑盒包裹得太深的组件体系，长期价值其实在下降。

因为 Agent 最擅长的不只是调用 API，而是：阅读现有代码、理解现有代码、修改现有代码、基于现有代码继续延展。

如果组件只是一个外部依赖包里的抽象壳，AI 的可操作空间就受限了。但如果组件体系是开放的、分层清晰的、仓库内可读的，AI 的工作质量通常会高很多。

这也是 shadcn/ui 爆火的原因之一。

这里说一个暴论：目前国内比较火的 UI 库，很少看到官方提供 skills。既然没有 skill，AI 又无法直接阅读 UI 库源码，在当前环境下会逐渐被淘汰。

未来的软件系统，不只是给人维护的，也会越来越多地交给 AI 一起维护。

5. 服务"长期协作"，而不是"快速生成"

很多人谈 AI，就把重点放在"生成更快"上。但做后台项目这些年我越来越觉得：快，从来不是唯一问题，甚至很多时候都不是核心问题。

真正重要的是：

所以 AI 时代最好的后台框架，不一定是第一次生成最惊艳的那个，而应该是：最适合持续迭代、持续扩展、持续被 AI 正确理解的那个。

Fantastic-admin 6.0：对 AI 时代后台框架的回答

说了这么多想法，Fantastic-admin 6.0 就是这些思路的具体实现。

1. 一套可长期演进的工程底座

v6 采用了 pnpm monorepo 架构：

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

2. 把项目协议写进了仓库

仓库根目录有 AGENTS.md 文件，明确说明了项目技术栈、目录结构、开发命令、开发规范、注意事项，以及对技能使用的补充约束。

原因很简单：不希望 AI 每次都靠对话去猜这个项目是什么样子。

3. 把高频动作沉淀成 Skills

目前已有的 Skills 包括但不限于：

这些 Skill 一方面可以节省 token，另一方面是将框架作者的能力和理解，形成了一套任何人都可以直接复用的标准——相当于你"雇用"了作者本人帮你完成需求。

4. 更完善的系统设计

Fantastic-admin 一直以来的重点都不是堆砌多少示例页面，而是把后台真正核心的问题做成一套可配置化的系统：

这些能力拆开看都不算噱头，但组合在一起，构成的不是"模板展示项目"，而是一套真正的后台基础设施。

最后

Fantastic-admin 6.0 已经在 4 月中旬发布正式版，如果你对后台框架在 AI 时代应该如何演进感兴趣，不妨去了解一下。

技术选型会过时，但好的工程思路不会。

声明：本文参考了掘金社区作者 Hooray 的文章「AI 时代的管理后台框架，应该是什么样子？」，在原文基础上进行了重新创作与整理。感谢原作者的分享，推荐阅读原文获取更多细节。