共享 UI 元件庫曾是大型工程團隊的標準答案。InfoQ 上 Daniel Curtis 的文章《From Reusable to Regeneratable》重新檢視這個假設，提出在生成式 AI 讓程式碼產出成本大幅下降之後，值得保留的不再是整套共享元件，而是設計系統、規則與測試。文章以 Griffiths Waite 多年在大型企業建置 React 元件庫的經驗為基礎，說明為什麼「可重複使用」的經濟邏輯正在被「可再生成」取代。
背景：元件庫原本承諾什麼 過去十年，公司內部元件庫被視為必備基礎建設。按鈕、彈窗、資料表格、表單控制項放進同一個版本化套件，各團隊就能共用成品、維持一致體驗、傳承無障礙與鍵盤操作等專業知識，也讓品牌改版能從單一來源一次擴散。作者指出，這四個承諾其實只有兩個需要散佈程式碼。一致性與單一事實來源主要靠設計系統和設計權杖；設計權杖是顏色、字型、間距等共享值，元件只是引用這些值。真正需要維護元件程式碼的，是重複使用與封裝好的專業知識，而這正是 AI 現在能協助的部分。
維護成本才是真實帳單 元件庫的初次建置耗時，但長期維護更貴。daisyUI 的維護團隊提醒，每一行程式碼都要維護、測試、修正、更新，因此「避免倉促抽象化」這類原則值得重視。Hacker News 討論串中也有工程師分享，內部 UI 元件庫比一般 CRUD 應用複雜得多，需要資深且穩定的人員長期投入。一旦多個產品團隊採用，所有權會變得模糊，維護者被拉去處理交付工作，消費端需求互相衝突，最後元件累積出比實際需要更多的變體。版本管理、依賴升級、跨團隊溝通都變成持續付出的成本。Griffiths Waite 在多團隊大型環境也有相同經驗，共享程式庫若沒有明確且持續的擁有者，幾個發行週期後就會開始失序。
從重複使用到再生成 生成式 AI 改變了成本結構。Tailwind CSS 因為大量出現在訓練資料中，開發者需要元件時往往直接請 AI 產生程式碼，而不是查文件。Marco Kotrotsos 的文章甚至以《元件庫之死》為題，描述這種現象。Denis Uraev 則把轉變形容為從 reusable 到 regeneratable：保留規格，需要時再生成實作，並用測試驗證。2026 年一份關於 AI 編碼的元件化開發技術報告，也描述讓 AI 檢查、修改、測試、除錯與重新生成程式碼片段的工具。當團隊能從共享設計系統和明確指令快速產生所需元件，集中式套件的版本、發布與升級成本就變得很難合理化。一致性仍然存在，因為它由設計系統承載。
中央化規則，分散生成元件 這個路線不是減少紀律，而是把紀律從程式碼移到規則。設計系統與權杖仍是單一事實來源，可用 Style Dictionary 這類工具轉成 CSS、iOS、Android 的值。機器可讀的指引也越來越重要，例如把 token 使用規則與無障礙要求放進版本化目錄，再讓 AI 在寫程式前讀取。Griffiths Waite 還建置了工程原則庫，涵蓋元件簡潔度、開發體驗與無障礙，作為 AI 的第一個參考來源。實際生成時，他們使用 Figma 的 Model Context Protocol（MCP）伺服器，讓 AI 直接取得 Figma 設計稿資訊，並搭配自訂技能確保產出符合標準。最後一步是驗證：Chromatic、Percy、Playwright 等視覺回歸工具可與基準畫面比對，找出色差或間距漂移；也能透過截圖比對設計稿，檢查無障礙結構，並用計算後樣式確認顏色、間距、字型都解析到權杖。
改版控制向上移動 共享元件庫的改版控制住在發布的程式碼，語意化版本號告訴下游會壞多少東西。再生成模式下，程式碼可拋棄，版本化對象變成規則本身。工程技能、無障礙原則、元件規則、設計系統與 Figma 設計稿都要各自管理並對齊版本。版本更新時，團隊可以只重新生成受影響的元件並跑測試，不必全面重來。若專案想在自家儲存庫保留實際建置出來的元件，也仍然可行。
同質化風險讓設計系統更重要 模型學習的是公開網路上的統計中心，因此「現代、乾淨的登陸頁」這類模糊指令很容易產出平均化設計。Curio 的文章、Claude Design 產出相似簡報的案例，以及 Lovable、v0、Base44 等工具造成的「同質化海洋」，都顯示這個問題。2026 年 Tilburg 大學研究發現，AI 使用會帶來微小但顯著的同質化效應，且在語意受限的任務中更明顯。這正是強烈且有觀點的設計系統能發揮作用的地方：先定義真實的字級、色彩、間距、動態規則，再讓模型生成，才能把輸出從平均值拉開。McKinsey 的設計價值研究追蹤三百家上市公司五年，設計指數前四分之一的企業在營收成長與股東總報酬上明顯領先。不過熟悉不一定是壞事，Jakob 法則提醒，使用者大部分時間停留在其他網站，常見版面能降低認知負擔。品牌差異可以視情況取捨，但體驗品質不能。
共享程式碼仍適用的地方 無障礙是最有力的保留理由。Telerik 指出 AI 程式碼生成工具並不擅長無障礙，AI 產生的 UI 常常預設不可存取；比較好的做法是把無障礙編碼進元件 API 合約，而不是依賴每次指令都正確。鍵盤操作、焦點管理、ARIA 語意正是容易被粗心再生產丟掉的專業知識。知名的元件庫也能提供大量一致範例，讓 AI 有參考基準。2026 年一篇關於生成式 AI 時代軟體重用的論文警告，盲目信任生成程式碼與貨物崇拜式開發相去不遠，未經驗證的資產可能帶來嚴重品質問題。因此驗證不是可選項。可以將共享程式碼切成三類：高用量低風險的版面、按鈕、卡片、簡單表單交給再生產；資料表格、下拉選單、日期選擇器等真正困難的元件保留人工審查；設計系統、權杖、指引與測試套件則永遠中央化。
結論上，要不要建共享元件庫，應該先回答一個問題：設計系統加上測試，能不能更便宜地達成重複使用、一致性、專業知識與單一事實來源這四件事？對許多沒有專責平台團隊的組織來說，更精簡的路徑是留下一個權威設計系統、機器可讀規則、各專案自行再生產，以及嚴格驗證，只把真正困難的元件留在共享程式碼中。設計系統不會消失，反而更重要；縮小的只是共享元件庫本身。本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。