採用檢查表

導入前先把這幾題答完。答不出來就先不要導入——導入一半的設計系統比沒有更難收拾。

適配性檢查

• 我的產品是資料密集的後台介面（表格、表單、審核流程），不是行銷網站或內容站
• 使用者是重複操作的內部人員，不是一次性訪客
• 我需要處理「改資料 → 確認 → 留痕」這類流程
• 我的介面需要列印或匯出給人簽名／存檔
• 團隊有能力維護複製進來的元件原始碼（registry 不是託管服務）

三題以上打勾才值得導入完整的三層。只中一兩題，建議只取模式章。

技術前置

• 有 CSS 變數可用（所有現代瀏覽器都可以）
• 深色模式的鉤子是 .dark class 或 [data-theme="dark"] 屬性其中之一（兩者都內建支援）
• 如果要用 React 元件：React 18+、有 @/* 路徑別名、有 Tailwind（或願意自己補齊 utility）

決策前置（這幾題比技術更重要）

• 色彩語意誰決定？ 換品牌色只要改 token 值，但「哪個顏色代表危險」是產品決策， 不該由每個工程師各自判斷
• 「已改動未送出」的琥珀色能不能被別的東西佔用？ 建議：不能。見 ADR-0002
• 確認之後還能不能改？ 這題沒有共識就導入「硬鎖定」模式，會在上線後吵一次。 先讀 硬鎖定與明確解鎖
• 誰有權力否決一個新元件？ 沒有守門人，設計系統三個月後就會有五種按鈕。 （這一題問的是你的專案；要對上游提案時，上游的守門人與入口見 回饋與 RFC 流程）

導入後的第一週

• 把 漂移防護 的守衛測試抄進你的 CI
• 在 code review checklist 加一條：「新元件是否已通過三次法則？」
• 用無障礙檢查表掃一次現有畫面，記錄基準線

不要做的事

✅ 這樣做

先導 token，讓新舊畫面顏色一致。這是投報率最高的一步， 而且完全不影響現有功能。

🚫 不要這樣

不要一次替換所有元件。大爆炸式改版的結果通常是改到一半、 兩套並存、然後永遠並存。