小編精選 - 技術文章翻譯 · 04月08日

AI 時代的管理後台框架，應該是什麼樣子？

這些年我一直在做 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 個特徵：

必須能讓 AI 看懂專案全貌

這裡就繞不開 monorepo 的架構了，過去我們說 monorepo 很多時候是在說工程治理、依賴復用、多應用擴展。

但今天我越來越覺得 monorepo 還有一個非常現實、而且會越來越重要的價值：

它天然更適合讓 AI 建立完整上下文，能讓 AI 擁有完整資訊版圖。

當應用程式碼、公共元件、主題、框架設定、文件、各種 CI/CD 腳本、技能定義都放在同一個結構清晰的倉庫裡時，AI 更容易快速理解：

哪些是業務層
哪些是公共能力
哪些是設定邊界
哪些是可重用資產
哪些是專案約定，哪些只是偶然寫法

Google 在那篇著名的 monorepo 文章裡，把 monorepo 的價值概括為「common source of truth」。我不想機械照搬這句話，但在 AI 協作語境下，它確實給了我很強的啟發：

統一的程式碼真相源，也意味著統一的 Agent 理解入口。

這當然不是說用了 monorepo 架構，AI 就自動變聰明了。但至少它更容易看到全貌，減少 AI 幻覺的產生。

必須有一套 AI 能穩定讀取的專案協議

只有程式碼結構還不夠，要想讓 AI 穩定工作，還必須有一層專案級協議，也就是 AGENTS.md，或者 CLAUDE.md。

它們本質上都在解決同一件事：

AI 協作不能只靠一次次聊天，而是需要專案內建的長期說明。

這意味著一個現代專案，未來不只是有給人看的 README，也應該有給 Agent 看的 README。

應該把高頻任務產品化為 Skills（技能）

提示詞（Prompt）適合解決臨時問題，但不適合承載高頻、穩定、可重用的專案流程。

後台專案最常見的動作其實非常固定：

產生 CRUD 模組
新增表單頁
增加路由
設定國際化
修改框架設定
產生 store
客製化主題
優化／美化頁面

如果這些事情每次都靠人重新組織一段提示詞，AI 的表現一定會飄忽不定。這也讓我決定要把這些高頻動作沉澱成 Skills（技能），把目錄約定、實現策略、檔案位置、限制條件、注意事項全部前置進去。這樣做的好處非常直接：

AI 不再靠猜
產生結果更接近專案現有風格
不同 Agent 工具之間更容易復用同一套知識
專案經驗不再只存在聊天記錄裡，而會沉澱成長期資產

在我看來，這一步很重要，因為它意味著我們開始從「會用 AI」走向「把 AI 納入工程系統」。

必須把「可修改」放在「可呼叫」前面

在 AI 時代，我越來越覺得一個被黑盒包裹得太深的元件體系，長期價值其實會下降。

因為 Agent 最擅長的，不只是呼叫 API，而是：

閱讀現有程式碼
理解現有程式碼
修改現有程式碼
基於現有程式碼繼續延展

如果元件只是外部相依套件裡的抽象殼，AI 的可操作空間是受限的；但如果元件體系是開放的、分層清晰的、倉庫內可讀的，AI 的工作品質通常會高很多。

相信這也是 shadcn/ui 爆紅的原因之一。

這裡說一個暴論，目前國內比較火的 UI 庫，我一直都沒有看到官方提供 skills，在一個既沒有 skill、AI 又無法直接閱讀 UI 庫的原始碼，這在當前環境下，很有可能會被逐漸拋棄。

未來的软件系統，不只是給人維護的，也會越來越多地交給 AI 一起維護。

所以我理解的現代管理後台，不是「我有一堆元件」就夠了，而應該是：

有可讀的元件實現
有統一的元件約定
有能沉澱後台業務場景的內建元件層
有可替換的底層 UI 能力

最終服務的是「長期協作」，而不只是「快速生成」

很多人一談 AI，就會把重點放在「生成更快」上。但我做後台專案這些年越來越覺得：快，從來不是唯一問題，甚至很多時候都不是核心問題。

真正重要的是：

生成出來以後，能不能做 code review
多個頁面之間風格能不能保持一致（UI 風格、程式碼風格）
多應用、多主題、多品牌場景下會不會慢慢失控
人和 Agent 或多 Agent 混合協作時，專案是否仍然穩定

所以在我看來，AI 時代最好的後台框架，不一定是第一次生成最驚豔的那個，而應該是：

最適合持續迭代、持續擴展、持續被 AI 正確理解的那個。

最後聊一聊 Fantastic-admin 即將發布的 6.0 版本

如果把前面這幾個階段串起來看，其實就很容易理解，為什麼 Fantastic-admin 要在這個階段發布一個大版本更新。

因為對我來說，它已經不只是「一個 Vue 3 管理後台框架」，而是在嘗試回答一個更具體的問題：

如果管理後台框架要面向下一個階段，它應該提前長成什麼樣子？

一套可長期演進的工程底座

Fantastic-admin v6 採用了 pnpm monorepo 架構，倉庫裡把應用、公共套件、文件、腳本、技能清晰拆開：

fantastic-admin/
├── apps/              # 應用目錄
│   ├── core           # 應用原始碼
│   └── example        # 範例應用
├── packages/          # 公共套件目錄
├── docs/              # 文件站點
├── scripts/           # 腳本工具
├── skills/            # AI 技能
└── package.json       # 根目錄 package.json

這麼做當然也有工程治理層面的考量，但更重要的是，我希望「程式碼、文件、約定、技能」能夠在同一個倉庫裡形成閉環。對於人來說，這是更清楚的工程邊界；對於 Agent 來說，這是一張更完整的資訊地圖。