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

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

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

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

截至 2025 年末，GitHub 上的 Issue 堆積如山，關鍵的基礎設施服務（如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：通用信息平臺 (General Information Platform)

GIP 全稱為 General Information Platform（通用信息平臺）。這是字節跳動早期的核心業務支柱，主要包含以下以“圖文與中長視頻”為核心的信息分發產品：

• 今日頭條：字節跳動的起家之作，智能推薦資訊平臺。
• 西瓜視頻：中長視頻平臺。
• 番茄小說：免費網文閱讀平臺。

2.2.2 業務對技術的反哺與制約

GIP 的業務特點是高信息密度。今日頭條的內容審核后臺、廣告投放系統（早期巨量引擎）、創作者管理平臺（頭條號后臺）都需要處理海量的文本數據和復雜的表格操作。因此，Arco Design 從誕生起就帶有濃重的“B 端中后臺”基因，強調緊湊、理性和高效率，這正是為了服務于 GIP 龐大的內部系統需求。

在 2019-2020 年，GIP 仍是公司的絕對核心與營收主力。Arco Design 的推出，實際上是字節跳動“長子”（頭條系）試圖確立公司內部技術標準的一次有力嘗試。

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 戰略重心的轉移：從“頭條”到“抖音”

2021 年底至 2024 年，字節跳動進行了多次大規模的組織架構調整。其中最關鍵的變化是戰略重心從圖文資訊（今日頭條）全面轉向短視頻與直播（抖音/TikTok）以及后來的 AI 大模型。

• GIP 的邊緣化：隨著移動互聯網進入存量時代，今日頭條和西瓜視頻的用戶增長見頂，戰略地位從“增長引擎”退化為“現金牛”甚至“存量維持”業務。
• 資源的抽離：GIP UED 和相關前端團隊面臨縮編或重組。維護 Arco Design 這樣一套龐大的開源系統需要持續的人力投入。當母體部門本身都在進行“去肥增瘦”時，一個無法直接帶來商業增量的開源 KPI 項目，自然成為了裁員的首選目標。

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 在架構上更為先進，采用了 Foundation/Adapter 模式，實現了邏輯與渲染分離，能以更低的成本適配不同框架。同時，Semi 深度集成了 D2C（Design-to-Code）工具鏈，更符合公司對 AI 和人效的追求。

4.2.2 為什么 Arco 輸了？

在資源整合期，公司高層顯然不需要維護兩套功能高度重疊的企業級 UI 庫。

• 業務綁定：Semi Design 宣稱服務了內部 10 萬+ 用戶和近千個平臺產品，深度嵌入在抖音的內容生產與運營流中。
• 結局：隨著 GIP 業務權重的下降和團隊的調整，Arco Design 失去了維護的資源，而 Semi Design 成為了事實上的內部標準。

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 并沒有復活的跡象，社區也沒有出現強有力的接棒者。這套組件庫正在數字化浪潮的沙灘上，慢慢風化成一座無人問津的豐碑。