導入三階段

不要一次全上。每個階段都要能單獨停下來而不留爛攤子。

流程圖載入中…

（這一頁是既有系統的漸進路；全新專案不必遷就既有畫面， 直接從頁面章選頁型起手。）

階段一：只導 token（1–2 天）

npm install @dooping/tokens

tailwind.config.js

presets: [require("@dooping/tokens/tailwind-preset")]

做什麼：把硬編色換成語意 token。

- className="bg-red-50 border-red-200 text-red-700"
+ className="bg-danger/10 border-danger/30 text-danger"

收益：新舊畫面顏色一致、深色模式一次到位、換品牌色變成改一個檔案。 風險：幾乎為零，不影響任何功能。

停在這裡也完全合理。 這是投報率最高的一步。

階段二：新畫面用元件（持續）

規則：新做的畫面用工具箱的元件，舊畫面不動。

npx shadcn@latest add https://kielchang.github.io/dooping-design-book/r/data-table.json

✅ 這樣做

從資料表開始。它是後台系統重複最多、收益最明顯的一塊。

🚫 不要這樣

不要為了統一而重寫還能用的舊畫面。大爆炸式改版的結果通常是改到一半、 兩套並存、然後永遠並存。

收益：新畫面行為一致，開發速度變快。 風險：兩套介面並存一段時間。可接受——顏色已經在階段一統一了，使用者感覺不到割裂。

階段三：導入模式（按需）

模式不是一次導入的，是遇到問題時去查：

遇到	讀
「使用者常改壞主檔」	唯讀逐欄編輯
「確認之後還能改，出過事」	硬鎖定
「不知道誰改了什麼」	稽核與回復
「改參數把歷史報表弄壞了」	生效日版本化
「新人不會用」	引導式導覽
「印出來很醜」	列印與匯出
「手冊的截圖過期了」	零截圖文件示意

收益：這些模式每一個都是別人踩過坑換來的。 風險：有些模式（硬鎖定、生效日版本化）會改變業務流程，導入前要先取得共識。

三個階段之外：建立守門機制

不管走到哪一階段，都要有人負責看門。 沒有守門人的設計系統，三個月後會有五種按鈕。見 RFC 流程。

導入完成之後才開始的那些問題——「我這個元件到底算不算遵循？」「我想改上游該怎麼辦？」 ——見符合性台帳；「怎麼知道上游出新版了？要不要跟？怎麼跟？」 ——見跟上新版。 這一頁講的是導入的那幾天，那兩頁講的是之後的每一個月。