在大型企業中，內部工具（Internal Tools）的開發往往處於一種混亂狀態：各團隊為了快速交付，會自行開發重複的 UI 組件，導致視覺不統一且維護成本極高。Meta 的 XDS (Cross-Design System) 便是為了解決這個問題而生。
這篇文章將以工程實務的視角，分享 XDS 如何從幾個工程師的「草根行動」演變成支援超過 10,000 個內部頁面、被 95% 產品團隊採用的統一 UI 平台。
從草根行動到快速啟動
許多設計系統（Design System）失敗的原因在於過度追求完美，在設計階段耗時太久而遲遲沒有產出。XDS 的成功在於採取「價值先行」的策略。
首先，團隊並不試圖一次定義所有規範，而是優先解決「痛點」。例如，他們將一個被數百個工具使用、但複雜且難用的篩選組件 PowerSearch 遷移到 XDS 並改善其可用性。當開發者發現使用 XDS 能直接解決棘手問題且不需要自己維護時，採納率會迅速提升。
其次，透過在具有代表性的複雜工具（如 Butterfly 工作流工具）上進行 Pilot（試行），向公司證明該系統能處理真實且複雜的業務場景，而非僅僅是幾個簡單的按鈕。
解決大規模擴展的挑戰
當系統規模擴大到全公司使用時，維護團隊會面臨三個核心挑戰：需求爆炸、更新風險以及 API 演進。
建立社群貢獻模型
為了避免核心維護團隊成為開發瓶頸，XDS 建立了社群貢獻機制。這不僅是為了增加人力，更是為了建立雙向的資訊對接：核心團隊能了解產品端的需求，而產品端則能參與系統演進。
為了管理海量貢獻，團隊引入了自動化工具，例如使用結構化表單規範需求、利用自動化代理（Agent）彙整貢獻紀錄，並編寫自定義的 ESLint 規則。將 API 規範直接寫入 Lint 規則中，能讓貢獻者在編碼時就收到即時提醒，大幅降低審核成本。
安全地執行大規模更新
在 Meta 的 Monorepo（單一程式碼倉庫）環境中，所有工具都運行在同一版本。這意味著任何一個組件的修改都可能影響上萬個頁面。
為了降低風險，團隊採取了三層防護： 第一層是自動化測試，包含截圖測試（Screenshot Tests）和無障礙規範測試。 第二層是 Gatekeeper（類似 A/B Testing 的功能開關），允許逐步推送更新或在出錯時快速關閉功能。 第三層是經驗判斷，例如意識到即使是簡單的 CSS 變數增加，在極端情況下也可能導致瀏覽器記憶體溢位而崩潰。
利用 Codemod 處理 API 遷移
當需要進行破壞性變更（Breaking Changes）時，手動修改上萬處調用是不可能的。這時就需要用到 Codemod（程式碼自動遷移工具）。
Codemod 是透過分析 JS AST (Abstract Syntax Tree，JavaScript 抽象語法樹) 來將舊代碼轉換為新代碼的腳本。例如，當 XDS 發現開發者誤用標題組件來強調文字，導致頁面導覽結構混亂時，他們編寫了 Codemod 腳本，自動將不符合語義的標題轉換為普通文字，並將真正的標題遷移至新組件。
目前，AI Codemod 也在被嘗試應用。相比傳統 AST 靜態分析，LLM（大語言模型）能理解跨檔案的上下文意圖，處理更複雜的遷移，但因其非決定性（Non-deterministic），仍需嚴格的人工審核。
從 UI 庫演進為全棧平台
當 UI 組件的採納率達到飽和後，系統容易陷入停滯。XDS 團隊透過重新詢問社群發現，開發者的痛點已從「UI 長什麼樣」轉移到「如何快速連接後端」與「如何監控性能」。
因此，XDS 的定位從單純的 UI 庫擴展為內部工具平台。他們開始提供： 端到端（End-to-End）的頁面模板，將 UI 組件、路由（Routing）與後端系統預先整合。 統一的工具管理與可觀測性（Observability）系統，讓開發者能輕鬆除錯。 AI 生成工具的基礎設施，透過提供標準化的模板，讓 AI 能更精準地生成符合 Meta 規範的內部工具。
實務總結與建議
對於想要在公司內推動基礎設施或設計系統的工程師，可以參考以下路徑： 不要追求完美，先解決最困難且高價值的問題，讓價值可見。 建立貢獻機制，將用戶轉化為貢獻者，並用自動化工具（如 Lint）降低管理成本。 投資於 Codemod 技術，這是管理大規模單一版本程式碼庫的唯一高效手段。 持續觀察用戶在整個開發流程中的痛點，將系統從單點工具（如 UI 庫）演進為全鏈路平台。
來源：infoq.com (Building and Scaling UI Systems for Internal Tools at Meta)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。