這本書是什麼

一套跨專案共用的設計語言，加上一份可以直接抄走的參考實作。

為什麼不是「又一個元件庫」

市面上的元件庫解決的是「按鈕長什麼樣」。但在做後台系統時，真正燒時間的從來不是按鈕，而是這些：

• 使用者改了主檔的三個欄位，送出前要怎麼讓他確認自己改了什麼？
• 一筆單據「確認」之後還能不能改？誰決定解鎖？
• 改了系統參數，歷史資料要不要跟著變？
• 導覽教學卡片，剛好擋住它正在叫你點的那顆按鈕，怎麼辦？
• 報表印出來給主管簽名，狀態徽章全部變成灰色方塊，怎麼辦？

這些問題每個系統都會遇到，每次都要重想一遍，而且通常都會想錯一次才學會。 這本書把想過的結論記下來，連同「當初為什麼這樣決定」一起。

三個層次，三種相依強度

硬相依   @dooping/tokens      設計 token（色彩語意、間距、字級、動態…）
  ↑                          ← 唯一建議直接安裝的一層。它是契約。
複製走   @dooping/react       React 參考實作（registry 複製原始碼進你的專案）
  ↑                          ← 複製走之後就是你的程式碼，隨你改。
只讀     模式 Patterns        操作邏輯與取捨
                             ← 用你自己的技術棧實作，這本書只負責把坑講清楚。

相依強度刻意由上往下遞減。理由很簡單：元件一定會被改，token 幾乎不會。 把會被改的東西做成套件，只會逼所有人 fork；把不會被改的東西做成套件，才有機會真的統一。

誰該讀哪一章

角色	建議路徑
前端工程師	三種取用方式 → 元件 → 模式
設計師	基礎 → 模式 → 無障礙
PM／需求方	模式（每則都是一個「這個功能該怎麼運作」的答案）
技術負責人	治理 → ADR

它的來歷

來自一套內部後台系統的長期迭代：從第一版介面稽查（41 項發現）開始， 經過多輪真實使用者回饋、無障礙補強、跨裝置調整，最後把其中與產業無關的部分抽出來。

抽取時砍掉的東西比留下的多——這是刻意的。一個什麼都收的設計系統，等於沒有設計系統。