元件庫的「可重用」承諾，具體上是建立在什麼假設之上，這個假設什麼時候會失效？
可重用的承諾建立在「這個元件未來會被使用的情境，跟它最初被設計出來時的情境足夠相似」這個假設之上。這個假設在產品初期通常成立，因為功能還沒擴張太多，元件面對的情境變化不大；但隨著產品成長、功能增加，這個假設會慢慢失效——一個原本只需要處理最簡單情境的元件，會被要求適應越來越多的新變化。
這個假設失效的臨界點，通常不是某個明確的時間點，而是一個漸進的過程：一開始加一兩個新的 prop 感覺不出問題，但當一個元件累積到十幾二十個 prop、彼此之間的組合關係變得難以追蹤，這個元件事實上已經從「一個簡單可重用的積木」變成了「一組複雜的參數系統」，維護成本已經悄悄超過了它原本承諾要節省的成本。
「三成元件從未被使用」聽起來很浪費，是不是代表元件庫本身設計得不好？
不完全是，這個數字背後至少有兩種完全不同的成因，需要分開判斷。第一種是健康的閒置：一部分元件確實是為了某個特定情境設計的，這個情境後來沒有真的持續存在或普及開來，元件自然就沒有被使用——這種情況下閒置反而是好事，代表當初做出「不需要為每個假設情境都建元件」的判斷是對的，硬要把這些元件用起來才是真正的浪費。
第二種是溝通失敗導致的閒置：元件確實存在、確實能解決某個團隊遇到的問題，但那個團隊不知道它存在，或者知道但覺得客製化一個本地版本比研究怎麼用這個元件更快。這種閒置才是真正該被關注的問題，而解法通常不是砍掉這些元件，而是改善元件的可發現性——例如在文件裡更清楚地標註「這個元件適用於哪些情境」，或是在團隊詢問類似需求時，有一個順暢的管道讓大家想到去查元件庫，而不是直接動手寫。
既然擴充共用元件的審核成本高，是不是應該乾脆放寬審核，讓每個團隊自由修改共用元件就好？
這個做法會製造出跟現在完全相反、但一樣嚴重的問題。如果每個團隊都能自由修改共用元件，一個團隊為了自己的需求調整了元件的行為，很可能在不知情的狀況下，破壞了另一個團隊原本依賴的用法——這正是共用元件需要審核機制存在的原因，審核不是多餘的官僚程序，而是確保修改不會波及其他使用者的必要步驟。完全放寬審核，只是把「元件庫跟現實脫節」的問題，換成「元件庫本身變得不穩定、無法預測」的問題，並沒有真正解決根本的落差。
比較務實的做法，是把審核流程本身變快、變輕量，而不是取消審核。例如針對「新增一個不影響既有用法的可選 prop」跟「修改一個可能影響既有用法的核心行為」，設計不同嚴謹程度的審核路徑；前者可以走比較快速的流程，後者才需要完整的跨團隊確認。這樣一來，大部分日常遇到的擴充需求可以很快被處理，只有真正高風險的變更才需要付出對應的審核成本，兩者不再被綁在同一套流程裡。
如果我用 AI 設計工具生成畫面，元件庫膨脹這個問題會不會反而更嚴重，因為 AI 生成的速度更快？
有可能更嚴重，也有可能改善，關鍵在於 AI 生成時有沒有被要求對照既有元件庫。如果 AI 生成一個新畫面時，完全沒有匯入既有元件庫作為參考，它每次都是憑統計猜測去生成一個「看起來像按鈕」的東西，這相當於團隊裡又多了一個「不查元件庫、直接自己做一個」的成員，而且產出速度比人類工程師快得多，膨脹的速度只會更快。
但反過來，如果生成流程裡明確匯入了既有元件庫，並要求 AI 優先使用已有的元件、只在真正找不到合適選項時才建議新增，AI 反而可以扮演一個不會偷懶的稽核者角色——它可以被要求在每次生成前，先檢查這次的需求是不是可以用現有的某個元件配上既有的 prop 組合來滿足，而不是每次都預設要生成全新的東西。這代表元件庫膨脹是不是會因為導入 AI 工具而惡化，取決於團隊有沒有把「優先查找既有元件」這個原則，明確寫進 AI 的生成流程裡，而不是自動發生的結果。
一位工程師在自己團隊的元件庫稽核裡，發現了一組值得所有依賴元件庫的團隊警惕的數字：一個原本設計來「可重用」的按鈕元件，在十八個月的時間裡，衍生出二十三種不同的 prop 組合，分散在四十七處不同的實作裡；打包工具分析顯示，團隊匯入了整個元件庫，實際使用到的元件卻只有其中的一到兩成；元件的整體採用率在第一年後就停滯在六成七左右，團隊持續為新出現的「邊角案例」建立客製化的實作，而不是延用既有元件。這組數字揭露的問題，不是這個團隊特別隨便，而是「可重用元件」這個概念本身，包含一個容易被忽略的隱藏假設。
元件庫的核心承諾是「做一次，到處用」，這個承諾成立的前提是，這個元件未來會被使用的情境，跟它第一次被設計出來時所預設的情境足夠相似。但現實裡，產品功能不斷擴張，新的使用情境不斷出現，一個原本只需要處理「文字加圖示」的按鈕，慢慢會被要求要能處理「載入中狀態」「圖示放右邊」「危險操作用的紅色版本」「行動裝置上要更大的點擊區域」——每一個新需求單獨看都合理，但如果元件的核心設計沒有預留足夠的彈性去容納這些變化，結果就是每個新需求都變成一個新的 prop，日積月累，一個原本簡單的元件就變成了一組難以理解的參數組合。
元件採用率停滯的關鍵原因，往往不是團隊不知道元件庫存在，而是擴充一個現有元件所需要的溝通與審核成本，有時候比直接寫一個新的差不多。如果修改一個共用元件需要跑完整的審核流程、需要跟其他使用這個元件的團隊協調確認不會破壞既有用法，而寫一個本地版本只需要自己團隊點頭，理性的選擇往往是後者——即使這個選擇會讓元件庫跟實際程式碼庫的落差越來越大。這個現象也解釋了為什麼「三成元件從未被使用」這個統計數字不完全是壞消息：這些元件裡，有一部分確實是過度設計、解決了根本不會持續存在的問題，長期閒置反而是正確的訊號；但另一部分，可能只是團隊不知道它存在，或者知道但覺得客製化更省事。
把這個現象簡化成「元件庫管理得不好」，容易讓人以為解法是更嚴格地限制新增元件、要求每個新元件都經過更審慎的審核。但真正的根源，是多數元件庫缺乏一個持續回饋的機制，讓「工程師在真實情境裡遇到元件不夠用」這件事，能有效地回饋到元件庫本身的演進上，而不是變成一個永遠不會被看見的本地繞過版本。沒有這個回饋迴路，元件庫的演進速度會遠遠落後於產品真實需求的演進速度，兩者的落差就是二十三種變體、六十七趴停滯採用率背後的真正成因。
如果你的團隊正在使用或考慮建立一套元件庫，值得先問的問題不是「要放多少元件進去」，而是「當工程師發現元件不夠用時，回報跟擴充這個元件的流程有多順暢」。如果答案是「要走完整審核流程，可能要等好幾週」，就算元件庫本身設計得再完善，長期而言也很可能走向跟前面案例一樣的命運。定期稽核元件的實際使用情況（哪些元件真的被引用、哪些從未被使用、哪些正在被大量客製化繞過）值得變成固定的例行工作，而不是等到元件庫已經膨脹到難以維護才臨時處理——這個稽核成本，遠低於事後才發現整套元件庫已經跟實際程式碼脫節的代價。