Arco Design 停擺！字節跳動 UI 庫涼了？

1. 引言：設計系統的“寒武紀大爆發”與 Arco 的陨落

在 2019 年至 2021 年間，中國前端開發領域經歷了一場前所未有的“設計系統”爆發期。伴隨著企業級 SaaS 市場的崛起和中後台業務的複雜度攀升，各大互聯網巨頭紛紛推出了自研的 UI 元件庫。這不僅是技術實力的展示，更是企業工程化標準的話語權爭奪。在這一背景下，字節跳動推出了 Arco Design，這是一套旨在挑戰 Ant Design 霸主地位的“双棧”（React & Vue）企業級設計系統。

Arco Design 在發布之初，憑藉其現代化的視覺語言、對 TypeScript 的原生支持以及極具創新性的“Design Lab”設計令牌（Design Token）管理系統，迅速吸引了大量開發者的關注。它被定位為不僅僅是一個元件庫，而是一套涵蓋設計、開發、工具鏈的完整解決方案。然而，就在其社區聲量達到頂峰後的短短兩年內，這一曾被視為“下一代標準”的項目卻陷入了令人費解的沉寂。

截至 2025 年底，GitHub 上的 Issues 堆積如山，關鍵的基礎設施服務（如 IconBox 圖標平台）頻繁宕機，官方團隊的維護活動幾乎歸零。對於數以萬計採用了 Arco Design 的企業和獨立開發者而言，這無疑是一場技術選型的災難。

本文將深入剖析 Arco Design 從輝煌到停擺的過程。我們將剝開代碼的表層，深入字節跳動的組織架構變革、內部團隊的博弈（賽馬機制）、以及中國互聯網大廠特有的“KPI 開源”文化，為您還原整件事情的全貌。

2. 溯源：Arco Design 的誕生背景與技術野心

要理解 Arco Design 為何走向衰敗，首先必須理解它誕生時的宏大野心及其背後的組織推手。Arco 並不僅僅是一個簡單的 UI 庫，它是字節跳動在高速擴張期，為了解決內部極其複雜的國際化與商業化業務需求而孵化的產物。

2.1 “務實的浪漫主義”：差異化的產品定位

Arco Design 在推出時，鮮明地提出了“務實的浪漫主義”這一設計哲學。這一口號的提出，其實是為了在市場上與阿里巴巴的 Ant Design 進行差異化競爭。

• Ant Design 的困境：作為行業標準，Ant Design 以“確定性”著稱，其風格克制、理性，甚至略顯單調。雖然極其適合金融和後台管理系統，但在需要更強品牌表達力和 C 端體驗感的場景下顯得力不從心。
• Arco 的切入點：字節跳動的產品基因（如抖音、TikTok）強調視覺衝擊力和用戶體驗的流暢性。Arco 試圖在中後台系統中注入這種基因，主張在解決業務問題（務實）的同時，允許設計師發揮更多的想像力（浪漫）。

這種定位在技術層面體現為對 主題定制（Theming） 的極致追求。Arco Design 並沒有像傳統庫那樣僅僅提供幾個 Less 變量，而是構建了一個龐大的“Design Lab”平台，允許用戶在網頁端通過可視化界面細粒度地調整成千上萬個 Design Token，並一鍵生成代碼。這種“設計即代碼”的早期嘗試，是 Arco 最核心的競爭力之一。

2.2 組織架構：GIP UED 與架構前端的聯姻

Arco Design 的官方介紹中明確指出，該系統是由 字節跳動 GIP UED 團隊 和 架構前端團隊（Infrastructure FrontEnd Team） 聯合推出的。這一血統注定了它的命運與“GIP”這個業務單元的興衰緊密綁定。

2.2.1 GIP 的含義與地位

“GIP” 通常指代 Global Internet Products（全球互聯網產品）或與之相關的國際化/商業化業務部門。在字節跳動 2019-2021 年的擴張期，這是一個充滿活力的部門，負責探索除了核心 App（抖音/TikTok）之外的各種創新業務，包括海外新聞應用（BuzzVideo）、辦公套件、以及各種嘗試性的出海產品。

• UED 的話語權：在這一時期，GIP 部門擁有龐大的設計師團隊（UED）。為了統一各條分散業務線的設計語言，UED 團隊急需一套屬於自己的設計系統，而不是直接沿用外部的 Ant Design。
• 技術基建的配合：架構前端團隊的加入，為 Arco Design 提供了工程化落地的保障。這種“設計+技術”的雙驅動模式，使得 Arco 在初期展現出了極高的完成度，不僅有 React 版本，還同步推出了 Vue 版本，甚至包括移動端元件庫。

2.3 黃金時代的技術堆棧

在 2021 年左右，Arco Design 的技術選型是具前瞻性的，這也是它能迅速獲得 5.5k Star 的原因之一：

• 全鏈路 TypeScript：所有元件均採用 TypeScript 編寫，提供了優秀的類型推導體驗，解決了當時 Ant Design v4 在某些複雜場景下類型定義不友好的痛點。
• 雙框架並進：@arco-design/web-react 和 @arco-design/web-vue 保持了高度統一的 API 設計和視覺風格。這對於那些技術棧不統一的大型公司極具吸引力，意味著設計規範可以跨框架重用。
• 生態閉環：除了元件庫，Arco 還發布了 arco-cli（腳手架）、Arco Pro（中後台模板）、IconBox（圖標管理平台）以及 Material Market（物料市場）。這表明團隊不僅是在做一個庫，而是在構建一個類似 Salesforce Lightning 或 SAP Fiori 的企業級生態。

然而，正是這種龐大的生態鋪設，為日後的維護埋下了巨大的隱患。當背後的組織架構發生震蕩時，維持如此龐大的產品矩陣所需的資源將變得不可持續。

3. 停擺的證據：基於數據與現象的法醫式分析

儘管字節跳動從未發布過一份正式的“Arco Design 停止維護聲明”，但通過對代碼倉庫、社區反饋以及基礎設施狀態的深入分析，我們可以斷定該項目已進入實質性的“腦死亡”狀態。

3.1 代碼倉庫的“心跳停止”

對 GitHub 倉庫 arco-design/arco-design (React) 和 arco-design/arco-design-vue (Vue) 的提交記錄分析顯示，活躍度在 2023 年底至 2024 年初出現了斷崖式下跌。

3.1.1 提交頻率分析

雖然 React 版本的最新 Release 版本號為 2.66.8（截至文章撰寫時），但這更多是慣性維護。

• 核心貢獻者的離場：早期的高頻貢獻者（如 sHow8e、jadelike-wine 等）在 2024 年後的活躍度顯著降低。許多提交變成了依賴項升級（Dependabot）或極其微小的文檔修復，缺乏實質性的功能迭代。
• Vue 版本的停滯：Vue 版本的狀態更為糟糕。最近的提交多集中在構建工具遷移（如遷移到 pnpm）或很久以前的 Bug 修復。核心元件的 Feature Request 長期無人響應。

3.1.2 積重難返的 Issue 列表

Issue 面板是衡量開源項目生命力的體溫計。目前，Arco Design 倉庫中積累了超過 330 個 Open Issue。

• 嚴重的 Bug 無人修復：例如 Issue #3091 “tree-select 元件在虛擬列表狀態下搜索無法選中最後一個” 和 Issue #3089 “table 元件的 default-expand-all-rows 屬性設置不生效”。這些都是影響生產環境使用的核心元件 Bug，卻長期處於 Open 狀態。
• 社區的絕望呐喊：Issue #3090 直接以 “又一個沒人維護的 UI 庫” 為題，表達了社區用戶的憤怒與失望。更有用戶在 Discussion 中直言 “這個是不是 KPI 項目啊，現在維護更新好像都越來越少了”。這種負面情緒的蔓延，通常是項目走向終結的社會學信號。

3.2 基礎設施的崩塌：IconBox 事件

如果說代碼更新變慢還可以解釋為“功能穩定”，那麼基礎設施的故障則是項目被放棄的直接證據。

• IconBox 無法發布：Issue #3092 指出 “IconBox 無法發布包了”。IconBox 是 Arco 生態中用於管理和分發自定義圖標的 SaaS 服務。這類服務需要後端伺服器、數據庫以及運維支持。
• 含義解讀：當一個大廠開源項目的配套 SaaS 服務出現故障且無人修復時，這不僅僅是開發人員沒時間的問題，而是意味著伺服器的預算可能已經被切斷，或者負責運維該服務的團隊（GIP 相關的基建團隊）已經被解散。這是項目“斷供”的最強物理證據。

3.3 文檔站點的維護降級

Arco Design 的文檔站點雖然目前仍可訪問，但其內容更新已經明顯滯後。例如，關於 React 18/19 的並發特性支持、最新的 SSR 實踐指南等現代前端話題，在文檔中鮮有提及。與競爭對手 Ant Design 緊跟 React 官方版本發布的節奏相比，Arco 的文檔顯得停留在 2022 年的時光膠囊中。

4. 深層歸因：組織架構變革下的犧牲品

Arco Design 的陨落，本質上不是技術失敗，而是組織架構變革的犧牲品。要理解這一點，我們需要將視線從 GitHub 移向字節跳動的辦公大樓，審視這家巨頭在過去三年中發生的劇烈動蕩。

4.1 “去肥增瘦”戰略與 GIP 的解體

2022 年至 2024 年，字節跳動 CEO 梁汝波多次強調“去肥增瘦”戰略，旨在削減低效業務，聚焦核心增長點。這一戰略直接衝擊了 Arco Design 的母體——GIP 部門。

4.1.1 戰略投資部的解散與業務收縮

2022 年初，字節跳動解散了戰略投資部，並將原有的投資業務線員工分流。這一動作標誌著公司從無邊界擴張轉向防禦性收縮。緊接著，教育（大力教育）、遊戲（朝夕光年）以及各類邊緣化的國際化嘗試業務（GIP 的核心腹地）遭遇了毀滅性的裁員。

4.1.2 GIP 團隊的消失

在多輪裁員中，GIP 及其相關的商業化技術團隊是重災區。

• 人員流失：Arco Design 的核心維護者作為 GIP UED 和架構前端的一員，極有可能在這些輪次的“組織優化”中離職，或者被轉崗到核心業務（如抖音電商、AI 模型 Doubao）以保住職位。
• 業務目標轉移：留下來的人員也面臨著 KPI 的重置。當業務線都在為生存而戰，或者全力以赴投入 AI 軍備競賽時，維護一個無法直接帶來營收的開源 UI 庫，顯然不再是績效考核中的加分項，甚至是負擔。

4.2 內部賽馬機制：Arco Design vs. Semi Design

字節跳動素以“APP 工廠”和“內部賽馬”文化著稱。這種文化不僅存在於 C 端產品中，也滲透到了技術基建領域。Arco Design 的停擺，很大程度上是因為它在與內部競爭對手 Semi Design 的博弈中敗下陣來。

4.2.1 Semi Design 的崛起

Semi Design 是由 抖音前端團隊 與 MED 產品設計團隊 聯合推出的設計系統。

• 出身顯赫：與 GIP 這個邊緣化的“探索型”部門不同，Semi Design 背靠的是字節跳動的“現金牛”——抖音。抖音前端團隊擁有極其充裕的資源和穩固的業務地位。
• 業務渗透率：Semi Design 官方宣稱支持了公司內部“近千個平台產品”，服務 10 萬+ 用戶。它深度嵌入在抖音的內容生產、審核、運營後台中。這些業務是字節跳動的命脈，因此 Semi Design 被視為“核心資產”。

4.2.2 為什麼 Arco 輸了？

在資源收縮期，公司高層顯然不需要維護兩套功能高度重疊的企業級 UI 庫。選擇保留哪一個，不僅看技術優劣，更看業務綁定深度。

• 技術路線之爭：Semi Design 在 D2C（Design-to-Code）領域走得更遠，提供了強大的 Figma 插件，能直接將設計稿轉為 React 代碼。這種極其強調效率的工具鏈，更符合字節跳動“奮力出奇蹟”的工程文化。
• 歸屬權：Arco 屬於 GIP，GIP 被裁撤或縮編；Semi 屬於抖音，抖音如日中天。這幾乎是一場沒有懸念的戰役。當 GIP 團隊分崩離析，Arco 自然就成了沒人認領的“孤兒”。

4.3 中國大廠的“KPI 開源”陷阱

Arco Design 的命運也折射出中國互聯網大廠普遍存在的“KPI 開源”現象。

• 晉升階梯：在阿里的 P7/P8 或字節的 2-2/3-1 晉升答辯中，主導一個“行業領先”的開源項目是極具說服力的業績。因此，很多工程師或團隊 Leader 會發起此類項目，投入巨大資源進行推廣（刷 Star、做精美官網）。
• 晉升後的遺棄：一旦發起人成功晉升、轉崗或離職，該項目的“剩餘價值”就被榨幹了。接手的新人往往不願意維護“前人的功勞簿”，更願意另起爐灶做一個新的項目來證明自己。
• Arco 的軌跡：Arco 的高調發布（2021年）恰逢互聯網泡沫頂峰。隨著 2022-2024 年行業進入寒冬，晉升通道收窄，維護開源項目的 ROI（投入產出比）變得極低，導致項目被遺棄。

5. 社區自救的幻象：為何沒有強有力的 Fork？

面對官方的停擺，用戶自然會問：既然代碼是開源的（MIT 協議），為什麼沒有人成立 Fork 繼續維護？調查顯示，雖然存在一些零星的 Fork，但並未形成氣候。

5.1 Fork 的現狀調查

通過對 GitHub 和 Gitee 的檢索，我們發現了一些 Fork 版本，但並未找到具備生產力的社區繼任者。

• vrx-arco：這是一個名為 vrx-arco/arco-design-pro 的倉庫，聲稱是 "aro-design-vue 的部分功能擴展"。然而，這更像是一個補丁集，而不是一個完整的 Fork。它主要解決特定開發者的個人需求，缺乏長期維護的路線圖。
• imoty_studio/arco-design-designer：這是一個基於 Arco 的表單設計器，並非元件庫本身的 Fork。
• 被動 Fork：GitHub 顯示 Arco Design 有 713 個 Fork。經抽樣檢查，絕大多數是開發者為了閱讀源代碼或修復單一 Bug 而進行的“快照式 Fork”，並沒有持續的代碼提交。

5.2 為什麼難以 Fork？

維護一個像 Arco Design 這樣的大型元件庫，其門檻遠超普通開發者的想像。

1. Monorepo 構建複雜度：Arco 採用了 Lerna + pnpm 的 Monorepo 架構，包含 React 庫、Vue 庫、CLI 工具、圖標庫等多個 Package。其構建腳本極其複雜，往往依賴於字節內部的某些環境配置或私有源。外部開發者即使拉下來代碼，要跑通完整的 Build、Test、Doc 生成流程都非常困難。
2. 生態維護成本：Arco 的核心優勢在於 Design Lab 和 IconBox 等配套 SaaS 服務。Fork 代碼容易，但 Fork 整個後端服務是不可能的。失去了 Design Lab 的 Arco，就像失去了靈魂的空殼，吸引力大減。
3. 技術棧鎖定：Arco 的一些底層實現可能為了適配字節內部的微前端框架或構建工具（如 Modern.js）做了特定優化，這增加了通用化的難度。

因此，社區更傾向於遷移，而不是接盤。

6. 用戶生存指南：現狀評估與遷移策略

對於目前仍在使用 Arco Design 的團隊，局勢十分嚴峻。隨著 React 19 的臨近和 Vue 3 生態的演進，Arco 將面臨越來越多的兼容性問題。

6.1 風險評估表

6.2 遷移路徑推薦

方案 A：遷移至 Semi Design（推薦指數：⭐⭐⭐⭐）

如果你是因為喜歡字節系的設計風格而選擇 Arco，那麼 Semi Design 是最自然的替代者。

• 優勢：同為字節出品，設計語言的命名規範和邏輯有相似之處。Semi 目前維護活躍，背靠抖音，擁有強大的 D2C 工具鏈。
• 劣勢：API 並非 100% 兼容，仍需重構大量代碼。且 Semi 主要是 React 優先，Vue 生態支持相對較弱（主要靠社區適配）。

方案 B：遷移至 Ant Design v5/v6（推薦指數：⭐⭐⭐⭐⭐）

如果你追求極致的穩定和長期的維護保障，Ant Design 是不二之選。

• 優勢：行業標準，龐大的社區，Ant Group 背書。v5 版本引入了 CSS-in-JS，在定制能力上已經大幅追趕 Arco 的 Design Lab。
• 劣勢：設計風格偏保守，需要設計師重新調整 UI 規範。

方案 C：本地魔改（推薦指數：⭐）

如果項目龐大無法遷移，唯一的出路是將 @arco-design/web-react 源碼下載到本地 packages 目錄，作為私有元件庫維護。

• 策略：放棄官方更新，僅修復阻塞性 Bug。這需要團隊內有資深的前端架構師能夠理解 Arco 的源代碼。

7. 結語與啟示

Arco Design 的故事是現代軟體工程史上的一個典型悲劇。它證明了在企業級開源領域，康威定律（Conway's Law） 依然是鐵律——軟體的架構和命運取決於開發它的組織架構。

當 GIP 部門意氣風發時，Arco 是那顆最耀眼的星，承載著“務實浪漫主義”的理想；當組織收縮、業務調整時，它便成了由於缺乏商業造血能力而被迅速遺棄的資產。對於技術決策者而言，Arco Design 的教訓是慘痛的：在進行技術選型時，不能僅看 README 上的 Star 數或官網的精美程度，更要審視項目背後的組織生命力和維護動機。

目前來看，Arco Design 並沒有復活的跡象，社區也沒有出現強有力的接棒者。這套元件庫正在數字化浪潮的沙灘上，慢慢風化成一座無人問津的豐碑。

原文出處：https://juejin.cn/post/7582879379441745963