AI 時代如何更高效開發(fā)前端組件？21st.dev 給了一種答案
給大家推薦一個好東西：21st.dev ，大致上你可以將它理解為一個非常前衛(wèi)的組件托管市場，特別之處在于：
- 它參考
shadcn/ui的設(shè)計理念提供了一種原子化的，Code Out 形式的依賴安裝、管理模式； - 并且更具有啟發(fā)性的，它為每一個組件都提供了一套用于生成組件代碼的 Prompt，用戶可以借此在特定項目上下文中生成適配度更高的組件效果。
借助 21st.dev 與 cursor，我做了這樣一個 demo：
這一切都是在 5min 內(nèi)，不寫一行代碼的情況下實現(xiàn)的！更值得稱謂的是，21st.dev 的功能設(shè)計真正做到了 AI 友好，能夠很好地應(yīng)用在各類 AI 工具中(cursor、v0.dev、bolt.new、cline 等等)，并且這套設(shè)計邏輯還非常適合復(fù)用到各種 TO-D 場景中，
21st.dev 是什么
21st.dev 是一個開源的 React UI 組件市場，專門為設(shè)計工程師和前端開發(fā)者提供高質(zhì)量的 UI 組件。它的靈感來自于 shadcn/ui，旨在幫助開發(fā)者快速構(gòu)建精美的用戶界面，尤其適用于 AI 產(chǎn)品的開發(fā)。21st.dev 目前已經(jīng)托管了海量開源組件，類型涵蓋各種極具設(shè)計感(由官方審核)頭像、dialog、按鈕、日歷，甚至完整 Page，應(yīng)有盡有，并且這些組件都經(jīng)過 21st.dev 官方審核，質(zhì)量上還是比較有保證的。
與 npm 等傳統(tǒng)市場的主要差異點：
- 21st.dev 偏向于一次性交付，安裝后會把代碼 clone 到本地，之后就算是跟市場本身脫鉤了，這種方式缺點是無法持續(xù)跟進(jìn)組件本身的迭代；但好處則是這會大大減少版本概念帶來的復(fù)雜性(《NPM 依賴管理的復(fù)雜性》)，并且，代碼被復(fù)制下來后，可按項目的具體上下文做任意調(diào)整，比較適合一些復(fù)雜度不是很高的代碼復(fù)用場景；
- 21st.dev 提供了一些 AI 友好的交互，一是為每一個共享組件都設(shè)置了用于生成組件代碼的 Prompt，用戶可直接復(fù)制粘貼到 LLM 工具中(推薦用 Cursor)，即可生成對應(yīng)組件代碼；其次，它還提供了 MCP 實現(xiàn)，用戶可將之接入到各類支持 MCP 協(xié)議的工具中；
相對而言，21st.dev 的模式更匹配 AI 時代的用戶習(xí)慣：Codeout、可定制、AI 可理解，因此它在海外也就迅速走紅，Producthub 評分非常高。
怎么用
使用之前，建議先進(jìn)入市場內(nèi)(https://21st.dev/)看看有那些可用組件，整體質(zhì)量很不錯。
21st.dev 本質(zhì)上是一個組件市場，提供了多種組件消費方式：
- 使用
dlx工具：進(jìn)入 21st.dev ，選定組件，進(jìn)入組件詳情頁后，直接復(fù)制右上角的install component命令，之后在項目目錄中執(zhí)行，即可生成對應(yīng)代碼； - 使用 Prompt：同樣的，進(jìn)入組件詳情頁后，點擊
copy prompt按鈕，之后使用 cursor、cline 等工具，即可生成組件代碼： - 使用 21st.dev MCP 服務(wù)：參考：https://github.com/21st-dev/magic-mcp 文檔，配置 MCP 服務(wù)接口，之后在 prompt 中使用
/ui指令明確要求調(diào)用 21st.dev 生成組件(具體用法，下面有詳細(xì)介紹)；
這里強(qiáng)烈推薦使用第三種：MCP 服務(wù)，這種方式相當(dāng)于將 21st.dev 的組件知識外掛到 cursor 等 IDE，之后這類 IDE 可根據(jù)實際場景中的上下文，自行規(guī)劃實現(xiàn)路徑，以及自行判定如何基于 21st.dev 提供的組件設(shè)計知識(注意，這里是設(shè)計知識，而不是代碼本身)實現(xiàn)用戶需求。
如果你還不了解 MCP，可閱讀科普文檔：使用 MCP 擴(kuò)展 Cursor 能力: https://ecn5ehmm9iou.feishu.cn/wiki/EyrOwRg5Cit5e8kKKjpcRe4cnuh
亮點：一鍵復(fù)制組件 Prompt
最讓人驚喜的是，組件詳情頁提供了 Copy Prompt 按鈕：
點擊即可復(fù)制用于實現(xiàn)該組件的 Prompt，用戶可將之粘貼到 Curosr 等工具中由 LLM 協(xié)助生成該組件的代碼，例如用于實現(xiàn) AI Chat 對話框的組件：
過去，我們在開源市場見到一些驚艷的組件，至少需要經(jīng)過學(xué)習(xí)、demo、編碼、調(diào)試之后才能復(fù)用起來，但 21st.dev 提供的 prompt，真的就能實現(xiàn)一鍵復(fù)刻，即使你完全不讀組件代碼也不妨礙你的使用和微調(diào)，效率高出許多。
亮點：MCP 服務(wù)
其次，21st.dev 官方還提供了一套 MCP 服務(wù) (https://github.com/21st-dev/magic-mcp)，可直接配置到各類支持 MCP 的工具中使用：
以 Cursor 為例：
- 注冊 21st.dev 服務(wù)，拿到 api key
- 在 cursor 中配置 MCP 服務(wù)：
注意幾個點：
Type 設(shè)置為 `command`Command 中需要輸入如下命令：npx -y @smithery/cli@latest run @21st-dev/magic-mcp --config "{"TWENTY_FIRST_API_KEY":"your-api-key"}"- 配置完成，并且確認(rèn) MCP 服務(wù)狀態(tài)正常可用后，使用
/ui開頭的 prompt 生成組件，例如：
對應(yīng)實現(xiàn)效果：
雖然顏色有點丑，但真的能在幾分鐘能完成初版內(nèi)容，交互流程比 v0.dev、bolt.new 等工具都流暢許多，并且所有代碼都嚴(yán)格按照我倉庫設(shè)置的 .cursorrules 規(guī)則生成，幾乎沒有調(diào)整成本。
一些啟發(fā)
私有組件庫的復(fù)用思路
試用下來，我覺得 21st.dev 的爆火并非偶然，它實在太適合 AI 時代了，過往都是基于 package 粒度做組件共享，消費者需要閱讀理解組件文檔后，再嵌入到業(yè)務(wù)系統(tǒng)中使用，這會引發(fā)幾個問題：
- 學(xué)習(xí)成本比較高，開發(fā)者需要花時間精力理解這些組件，分析組件質(zhì)量(通過單測、源碼等)；
- 組件代碼與版本號綁定，一旦發(fā)布，消費者幾乎沒法修改，作者給了你啥，基本就得吃啥；
- Package 與子 package 之間的相互依賴關(guān)系非常復(fù)雜，非常容易出現(xiàn)版本管理問題；
而 21st.dev 這種源碼共享方式，配合 AI 自動理解、生成、修改代碼的能力，則很好解決了上述這些傳統(tǒng)組件復(fù)用手段的學(xué)習(xí)成本、版本化與靈活性等方面的問題，不僅僅大幅降低代碼復(fù)用成本，還能針對具體場景(技術(shù)棧、需求等)自動做好調(diào)整適配，某種程度上這已經(jīng)是一種新的范式：不是代碼復(fù)用，而是設(shè)計邏輯復(fù)用了。
沿著這個解題思路，假設(shè)將 21st.dev 部署到私域，托管私有組件庫，那么我們只需集中精力維護(hù)好核心組件的質(zhì)量、性能、文檔工程，之后借助 21st.dev + cursor 就可以輕易完成私域場景中的業(yè)務(wù)組件復(fù)用、復(fù)刻、組裝、功能開發(fā)等方面的任務(wù)，提升開發(fā)效率，這是一個非常值得探索的方向。
Prompt 優(yōu)于代碼
如果 21st.dev 只是提供了傳統(tǒng)的組件托管、分發(fā)能力的話，那這只會是另一個俗套的 npm。但它創(chuàng)新地為每一個組件都提供了一套有針對性的 prompt，并且進(jìn)一步提供了集成 MCP 服務(wù)，這性質(zhì)可就變了。配合 AI 工具后，具體組件的代碼(僵化，無法調(diào)整的知識)已經(jīng)不是很重要，取而代之的是指導(dǎo) AI 實現(xiàn)同類效果的思路(靈活，可調(diào)整的知識)，AI 可以根據(jù)實現(xiàn)思路與具體上下文約束，更靈活調(diào)整出更適配的具體代碼，算是從魚到漁的轉(zhuǎn)變了。
沿著這個思路，假設(shè)你正在開發(fā)一些 TO-D 類的產(chǎn)品，其實也可以考慮為每一個具體接口提供定制的 Prompt、功能描述以及集成 MCP 服務(wù)，提供一套轉(zhuǎn)為 AI 優(yōu)化的知識面板，那么原本面向人類智能的交互，也就能夠轉(zhuǎn)換成面向 AI 的交互，對人類而言學(xué)習(xí)成本、使用成本都會急劇降低，也就更容易推廣。
因此，非常建議做 TO-D 工具的同學(xué)都往 AI 友好這個方向思考，包括但不限于：開源產(chǎn)品、Open API 類平臺、私有組件庫、私有代碼庫等。
基于 antd 的實踐
這只是一個實例，但這種模式其實可以被復(fù)用到各種基于 md 的信息場景，例如私有組件庫，代碼我已經(jīng)整理好了：https://github.com/Tecvan-fe/vercel-ai-demo/blob/main/packages/mdc-mcp/package.json
基于上述啟發(fā)，有沒有可能在 antd 基礎(chǔ)上配合 Cursor 與 MCP 協(xié)議實現(xiàn)代碼自動生成效果呢？答案是必然的，并且成本并不高，需要做幾件事情：
- 為基礎(chǔ)組件梳理完善的使用文檔，并且最好是基于 MDX 格式的，方便LLM 理解；
- 開發(fā) MCP 服務(wù)，讓 LLM 有機(jī)會理解 antd 所提供的能力細(xì)節(jié)，雖然我們也能通過 docs 等方式實現(xiàn)這一點，但出于擴(kuò)展性與可維護(hù)性考慮，這里采用 MCP 方式；
- 可用的組件列表
- 每一個組件的使用方法
- 在 Cursor(其他工具同理) 中配置 MCP 服務(wù)；
- 寫好
.cursorrules，讓 Cursor 知道我們的編碼規(guī)范，按正確的規(guī)則生成代碼；
這些動作，本質(zhì)上就是把正確的、充足的信息，喂給 LLM ，讓它理解私域知識，滿足特定上下文下的開發(fā)需求(感謝 MCP)。基于這套 MCP ，我試著做了一個簡單頁面：
- 原始頁面效果：
- 初次實現(xiàn)效果：
- 初次生成代碼：
從結(jié)果來說，還原度還是比較高的，并且也正確用了各種 antd 的各類組件。雖然各種樣式細(xì)節(jié)對不上，但我們可以繼續(xù)要求 LLM 持續(xù)優(yōu)化代碼，不斷逼近最終要求；其次，初次生成的代碼結(jié)構(gòu)雖然比較粗糙，但也同樣可以要求 LLM 持續(xù)優(yōu)化直至符合技術(shù)規(guī)范。
重點在于，這是一個可持續(xù)迭代優(yōu)化的過程，雖然結(jié)果上只能無限逼近理想狀態(tài)，但也比純粹靠人力從零開始開發(fā)、調(diào)優(yōu)，要高效的多。并且，假如未來我們進(jìn)一步整理出更多可復(fù)用的基礎(chǔ)業(yè)務(wù)組件，AI 的組件生成能力還可以進(jìn)一步擴(kuò)展，業(yè)務(wù)功能的開發(fā)成本還可以進(jìn)一步降低。
接下來演示具體使用方法，以 Cursor 為例：
- 配置 MCP 服務(wù)，類型是 Command，命令是
npx @tecvan-fe/mdc-mcp@alpha start，例如： - 在 Composer 中輸入關(guān)鍵詞
/ui以及，你需要實現(xiàn)的效果，建議截圖貼進(jìn)去，例如： - 后續(xù)針對樣式效果和代碼結(jié)構(gòu)繼續(xù)提出優(yōu)化需求，例如：
不過，真實開發(fā)場景是很復(fù)雜的，這套邏輯還只能生成靜態(tài)代碼，后續(xù)還是需要繼續(xù)開發(fā)數(shù)據(jù)交互、用戶交互、調(diào)試、測試、上線、監(jiān)控等方面的工作后續(xù)我會繼續(xù)輸出如何借助 Cursor 高效編碼的更多內(nèi)容。
問題
說完優(yōu)點，不能免俗的還是得聊聊 21st.dev 的問題，我目前看到的：
- 底層基于 shadcn 實現(xiàn)，暫時無法脫離 react 技術(shù)棧，且從組件代碼來看，還深度綁定了 nextjs，有點捆綁銷售的意思；好消息是，它為每一個組件都生成了 prompt，可以很方便復(fù)制到項目中，之后借助 cursor 等工具做深度優(yōu)化；
- 不支持私有化托管，因此雖然能快速做出各種小產(chǎn)品的原型，但對大型項目并不友好；
- 21st.dev 目前僅提供純前端類型的組件，并沒有很好串聯(lián)起前后端整套機(jī)制；
不過，即使如此，Cursor + 21st.dev 組合依然比傳統(tǒng)開發(fā)方式要高效太多了，非常建議大家深入學(xué)習(xí)。
