Figma Slot 護欄設定上線：設計系統終於能管住元件被怎麼塞
Slot 變成有 contract 的接口——min / max 圖層、限定元件、預設行為，4 條護欄把設計系統治理從口頭傳統，搬進元件本體。
設計系統做久了，會發現 slot 是把雙面刃。
當初 Figma 推 slot 是為了解決 component 過度僵化的問題。一個卡片元件，header 區塊永遠固定，使用者要塞圖、塞影片、塞文字框，只能 detach。Slot 讓你把那一塊空白挖出來，任何 instance 都能進駐——元件保留結構，內容完全自由。彈性給滿了。
但設計系統維護者很快就發現副作用：「任何 instance 都能進駐」這句話太誠實。塞圖示元件的位置，有人塞了一張產品截圖；本來只該放 primary button 的容器，有人放了三個 outlined button 排排站。Slot 是個沒看門人的入口，設計慣例靠 Figma file 裡的 cover 圖示意，誰理你。
6 月 1 日上線的 Slot settings，正面回應這件事。Figma 在 slot 上加了四種護欄：最少／最多圖層數、只能放偏好元件、預設保留空 slot 在畫布上、預設讓內容自動填滿空間。從外觀上看是 4 個 checkbox 跟 2 個輸入框，但意義不只是新功能——這代表 slot 從「空白盒」變成「有 contract 的接口」。
4 個新設定，逐個拆給你看
四個設定看起來是平行的選項，實際上對應的是設計系統治理的不同維度。
Minimum / maximum layers
設定 slot 內最少跟最多能放幾層。對 toolbar、tab bar、segmented control 這類元件特別有用——以前要靠註解寫「最多 5 個」，現在直接寫進元件本體，超過 5 個就跳警告。
對 design system maintainer 來說，這是把「使用規範」從 documentation 移到 source of truth 的第一步。以前 documentation 跟元件是兩個檔案，現在規範直接住在元件裡。
Only allow preferred instances
這個是最強的一條。先設一組「偏好元件」（preferred instances），這個 slot 之後只能塞這幾個元件，其他都會被標成 non-preferred。
對 icon system 這種大量 variant 的庫超關鍵。以前一個 icon slot，你做了 200 個圖示，沒人擋使用者把 product screenshot 塞進去當圖示。現在你可以限定這個 slot「只接受 / Icon / 開頭的 component」，整個 design system 的視覺一致性立刻有底。
Display an empty slot by default
預設讓 slot 以「空狀態」出現在畫布。聽起來很小的調整，但這影響的是元件被「發現」的速度。
以前 slot 預設可能藏住，使用者拖了元件下來不知道哪裡能放東西。預設顯示空 slot，等於畫布上會浮現一個明顯的「請放東西這裡」的視覺提示——這對新進來的設計師、跨團隊複用設計系統的人，learning curve 直接砍一半。
Set fill as default
讓 slot 內容預設自動填滿可用空間。這條跟 Auto Layout 的 fill container 行為一致——設計師不用每次拖新內容進來都手動調 resizing，元件自己會撐開。
為什麼這次升級用「contract」這個詞看比較準
軟體工程有個概念叫 type contract。一個函式宣告它接受什麼型別、回傳什麼型別，呼叫端拿到 type error 就知道自己塞錯東西，編譯時就擋下來，不會等執行時才炸。
新版 slot 走的就是這條路。以前的 slot 是 any——什麼都能塞，runtime（也就是 Figma file 開來實際用的時候）才靠人肉檢查。現在的 slot 變成有 type signature 的接口：
slot Drawer {
layers: minimum 2, maximum 10
accept: only PreferredInstance[]
display: emptyStateVisible
resize: fillContainer
}
寫成這樣不誇張——這就是 Figma 在 slot 屬性面板上要你填的欄位，只是 GUI 化了。
對純做設計的人，這個比喻可能太工程師。換個角度：你進銀行辦事，櫃台會貼「請準備身分證＋第二證件」，這就是 contract。以前 Figma 元件像沒貼公告的櫃台，設計師上門才知道規矩；現在 contract 直接寫在元件上，違反了 Figma 替你跳警告。
很多設計系統的 maintenance 時間，花在事後 review 別人怎麼用元件、發現用錯了去溝通、補文件、培訓。Slot contract 把這些往前推到設計階段。寫對的成本一樣，寫錯的成本變高——這就是 systematic 與 ad-hoc 的差別。
Design system 的下一階段：從 lint 走向 type
把這次升級放回 Figma 過去三年的脈絡，會看到一條一致的線。
Variables 把設計值從散落各處的數字，收進有名字、有作用域的中央倉庫——那是把「樣式」做成 single source of truth。Auto Layout 把 spacing、padding、resizing 的邏輯從「肉眼對齊」變成「規則計算」——那是把「排版」做成可預測的系統。現在 Slot contract 補上最後一塊：把「組合規則」從口頭傳統，變成元件本體強制執行的條款。
軟體那邊有個對應演進。最早 JavaScript 全 dynamic、想塞什麼塞什麼，誰知道 runtime 會出什麼錯。後來大家慢慢 adopt TypeScript，把契約寫到 type signature 裡，編譯就擋掉一堆事。再後來 lint 工具補位，連 style 都規範起來——程式碼長相從個人喜好變成團隊共識。
Figma 這條路走的順序差不多。早期 design tool 是個畫圖板，誰愛怎麼擺怎麼擺，設計系統靠 PDF spec 維持。Component library 之後有了「複用」，但複用的方式不受控。Slot 加 contract 之後，等於設計系統第一次有「編譯期檢查」——錯誤在設計階段就擋下來，不用拖到 review、不用拖到工程實作才發現對不上。
對設計師個人，這代表 2026 之後做 design system maintainer 的人，工作內容會從「教育＋糾錯」轉成「設計治理規則」。這跟工程的 senior 跟 staff 級距演進很像——junior 寫 code、senior 寫 framework、staff 寫 system constraint。設計這邊終於有了 constraint 可以寫。
接下來一週可以做的事
如果你在維護一套 5 個產品團隊以上用的 design system，這條 release 是這個月最值得花一下午的調整。
第一步是挑 3 個最容易出錯的元件，把護欄補進去。最容易出錯的判斷標準很簡單——你最常在 Slack 收到「這個 component 我可以這樣用嗎？」的那幾個，就是它們。把 minimum / maximum 跟 preferred instances 補上，你下個 sprint 大概可以省下兩三輪溝通。
第二步是趁機檢視 documentation 跟 component 的同步狀況。Slot description 欄位可以寫敘述——把舊文件裡仍正確的部分搬過來，過期的直接刪。一年來累積的 design system 文件腐敗債，這個機會清一輪。
第三步比較長線：盤點哪些舊元件可以重構成「slot + contract」的形式。以前因為 slot 沒護欄，你可能用 component variants 硬撐——同樣概念做 30 個 variant 排列組合來「限定」使用方式。現在可以拆成一個 base component + 受 contract 約束的 slot，maintainability 直接提升。
護欄上線了，邊界第一次清楚。剩下的就是設計系統 maintainer 怎麼運用——可以當作止損工具（補上最常出錯的元件），也可以當作重新設計治理結構的契機。看你想花多少時間。