「設計系統漂移」具體上是指什麼，跟一開始就沒做好的設計系統有什麼不同？
漂移指的是設計系統原本定義得很清楚，但隨著時間過去，實際上線的成果偷偷跟這個定義脫節，而不是系統本身從一開始就設計得不完整。這個區分很重要：一開始就有缺陷的系統，問題出在系統設計階段；漂移的系統，問題出在系統上線之後、缺乏機制去持續維持這個系統跟現實對齊。
漂移的特徵是漸進、不明顯，每個造成漂移的個別決定當下看起來都合理——一個團隊臨時做了一個例外，一個工程師憑記憶輸入了一個顏色而不是查對照表，這些單獨看都不是大事，但累積起來，久了之後系統定義的樣子跟正式上線的實際樣子之間的落差，就會變得難以忽視。
為什麼審核瓶頸會導致團隊乾脆不等審核就直接上線，這不是很不負責任嗎？
審核瓶頸的根本問題不是團隊不在乎一致性，而是流程的速度跟不上團隊需要交付的速度。當設計審查完全依賴一到兩位資深人員人工進行，這些人本來就有自己的工作要做，審查隊伍累積的速度往往比他們能清完的速度快，等待審核的時間可能拖到好幾天甚至更久。
在這種情況下，團隊面對的是一個現實的兩難：要嘛等待審核、拖延交付進度，要嘛先上線再說。多數團隊選擇後者，不是因為他們不重視一致性，而是因為業務壓力通常不允許無限期等待一個已經超載的審核流程。這也是為什麼解法通常不是「加強審核力度」，而是「讓審核不再是唯一的瓶頸」——把常見的合規檢查自動化，讓人工審核只處理真正需要人類判斷的例外狀況，而不是每一個變更都要排隊等一到兩個人過目。
文件裡「解釋為什麼」跟「只列出是什麼」，實際上會造成多大的差別？
差別在於能不能防止例外一再發生。一份只列出「按鈕該用什麼顏色」的文件，遇到一個新情境（例如一個危險操作的按鈕）時，使用者只能自己猜測該怎麼處理，猜測的結果很可能跟系統原本的設計意圖不一致；但一份解釋「危險操作按鈕之所以用不同顏色，是因為要達到某個對比度、傳達某種警示語意」的文件，使用者在遇到類似但不完全相同的新情境時，能根據這個原則自己推導出合理的做法，而不需要每次都回頭問設計系統團隊。
這個差異在邊角案例特別明顯——真正造成不一致的元件，幾乎從來不是簡單的那些，而是邊界情況：卡片標題超長怎麼辦、手機版的錯誤狀態長什麼樣子。只列出「是什麼」的文件通常沒有涵蓋到這些情境，因為邊角案例的組合幾乎無窮，不可能每一種都列出來；但解釋「為什麼」的文件，讓使用者具備舉一反三的判斷依據，能自己合理地把原則套用到文件沒有明確涵蓋的新情境上。
如果我在用 Claude Design 這類 AI 工具生成畫面，設計系統治理這件事跟我有什麼關係？
如果你是團隊裡負責維護設計系統的人，這篇談的治理原則直接適用：確保系統有明確的擁有者、確保文件解釋原則而不只是列出規則、確保無障礙標準從一開始就內建在元件裡，而不是最後才檢查。這些原則不因為改用 AI 生成工具而失效——如果團隊匯入的設計系統本身治理不良（擁有權不明、文件過時），AI 只是更快速地把這些問題複製到每一份新生成的畫面上，不會自動修正它們。
如果你是個人使用者、沒有團隊治理的需求，這篇的價值比較是在幫你判斷「什麼樣的設計系統值得信任並匯入」——一個文件完整、解釋了為什麼、涵蓋了邊角案例的設計系統，匯入之後 AI 生成的結果通常會更貼近你的實際需求；一個只有元件清單、沒有原則說明的系統，匯入之後遇到清單沒涵蓋到的情況，AI 一樣只能憑統計猜測，跟完全沒有匯入設計系統的情況差別不大。
多數設計系統不是一次性崩潰的，而是慢慢「漂移」掉的。一個團隊做了一個看似合理的例外，一個工程師把某個數值寫死沒有查對照表，一個外部合作的工程師因為不知道某個元件已經存在，自己重做了一個——每一個決定單獨看都不算大事，當下也感覺不出有什麼影響。但這些決定會累積，久了之後，設計系統裡定義的樣子跟正式上線的實際樣子之間的落差，會變得越來越難以忽視：按鈕樣式微妙地跑掉、顏色值跟品牌指南對不上、六個月前沒有的無障礙問題突然冒出來。這不是設計沒做好，是治理沒做好，而治理失敗正是設計團隊規模擴大後最常撞上的問題之一。
設計系統本身是「有什麼」——元件、Token、樣式、文件；治理則是「怎麼運作」——變更怎麼被審核跟核准、不一致的地方怎麼被抓出來修正、新加入的人怎麼學會規則、系統怎麼隨著組織成長持續跟品牌指南與無障礙要求對齊。一個做得再完整的設計系統，如果沒有治理機制，還是會隨時間漂移；治理才是讓系統長期維持有用的關鍵。
幾個最常見的破口：一是審核瓶頸——設計審查靠人工、速度慢，一兩個人變成一致性的唯一把關者，審查隊伍累積的速度比他們能清完的速度還快，團隊最後乾脆不等審核簽核就直接上線，不是不在乎，是流程慢到不切實際；二是沒有單一真相來源——品牌指南在一個地方、設計 Token 在另一個地方、無障礙標準在第三個地方、Figma 元件庫又在別處，要維持這些資訊同步需要額外的人力，而且很容易做不到；三是擁有權模糊——沒有人明確為系統的演進負責，標準就會鬆動、採用率就會下降，如果這是「每個人的責任」，最後往往變成「沒有人的責任」；四是無障礙缺口——無障礙標準常被當成最後一關才檢查的清單，而不是打從一開始就內建的要求，等到問題被抓到，修正成本已經很高；五是貢獻流程混亂——如果貢獻一個元件的審核標準含糊不清，團隊往往會被意料之外的審核強度嚇退，選擇放棄貢獻、自己在本地做一個繞過的版本，這個版本永遠不會回饋進系統，系統跟現實的落差就繼續擴大。
設計系統文件常被當成一種形式——一份在重大重構後更新一次、之後就慢慢跟現實脫節的 wiki 頁面。但真正有效的文件是治理最重要的工具之一：它出現在工作發生的地方，而不是要多點幾次連結才找得到；它解釋「為什麼」，不只是「是什麼」——說明為什麼危險操作的按鈕要用不同顏色、這個顏色選擇要符合什麼樣的對比度要求，脈絡才能防止例外一再發生；它針對邊角案例給出具體答案，例如卡片標題超過八十個字元時該怎麼處理、手機版的錯誤狀態長什麼樣子；它把無障礙標準直接內嵌在元件文件裡，而不是變成衝刺結束前才拿出來對照的另一張清單；它有版本紀錄，讓團隊不必猜測自己看的是不是最新版本。
設計跟工程之間的落差，多數其實從交接的那一刻就開始形成：設計師在 Figma 裡定義了一個元件，工程師用程式碼把它實作出來，兩個產物之間，某個數值被寫死、某個間距用了約略值、某個顏色直接輸入十六進位色碼而不是引用 Token。這些都不是故意的，只是兩套不同工具、兩套不同心智模型、加上一個沒辦法在上線前逐一核對每個細節的審查流程，自然會產生的結果。用設計 Token 當共同語言、讓 Figma 裡的命名跟程式碼裡的命名一致、把合規檢查內建在流程裡而不是放在最後，是縮小這個落差最直接的三個做法。
如果你的團隊正在感受到設計系統「好像哪裡開始不太對」，值得先確認的不是要不要重做元件庫，而是回頭檢查治理面：系統的演進有沒有明確的負責人、變更審核的流程是不是快到團隊願意真的等它跑完、文件有沒有解釋「為什麼」而不只是「是什麼」、無障礙要求是不是打從一開始就內建進元件裡。這些治理面的修正成本，遠低於等到系統漂移到大家都不信任它、必須整套重做的那一天才處理。定期稽核（不必是大規模人工審查，自動化的合規檢查會有效率得多）也值得變成固定流程的一部分，而不是等出事才臨時發動。