Plinth，以程式碼為 Source of Truth 的設計系統工具：為 AI 協作而生的設計系統（第三篇）

AI 可以在幾分鐘內生成介面，但要讓介面保持一致、方便修改，並且能長期維護，是另一回事。

去年撰寫上篇與下篇時，我嘗試以 Figma Variables 和 Figma Make 建立 AI 輔助設計流程。整個流程確實能從頭走到尾，但隨著專案進行，設計稿與程式碼逐漸產生落差。到了後期，直接在 Cursor 裡修改介面，往往比回到設計工具裡調整更快。

這段經驗改變了我對設計系統的想法。

現在，我開始探索另一種做法：把設計系統放在程式碼裡，讓規則可以透過版本控制追蹤、經過測試，也能直接提供 AI 工具使用。我正在開發開源工具 Plinth，想藉此驗證這個方向究竟能走多遠。

1. 關於前兩篇文章

我在 2025 年 11 月撰寫了前兩篇文章。這些工具在之後推出了許多更新，因此當時介紹的操作步驟、匯入流程和 Token 限制，現在可能已經不再適用。

更重要的是，我自己的做法也改變了。

前兩篇的起點都在 Figma。上篇由 Figma Variables 管理 Token，Figma Make 生成畫面，再將結果帶回 Figma 整理成元件庫。下篇則由 Figma Make 把前端程式碼推上 GitHub，Cursor 補上後端，最後部署到 Vercel。

程式碼雖然放在 GitHub 上，但設計的修改仍然從 Figma Make 開始，單向流進 repository。

現在，我開始反過來思考。我希望程式碼成為設計系統的 Source of Truth，而 Figma 則是可選擇使用的操作介面。

我會保留前兩篇文章，記錄自己當時如何看待這個問題。想了解我目前的做法，可以從這篇開始。

2. 前一套流程留下了哪些問題？

回頭看，我當時其實已經指出幾個問題，只是還沒有找到更好的解法。

• 生成很快，但流程是單向的。程式碼離開 Figma Make 之後，很難再將它帶回設計層。
• 視覺細節會產生落差。漸層、陰影和 SVG 在轉換過程中可能出現變化。
• 系統存在多個互相競爭的真實來源。Figma Variables、Make 生成的程式碼，以及 GitHub repository 都可能各自變動。
• 直接修改程式碼往往更快。專案進入後期後，在 Cursor 裡直接修改，通常更省時間，也能減少 AI 的 Token 用量。

最後這一點讓我印象很深。如果最後仍然需要在程式碼裡修改成果，那麼設計系統的核心規則是否也應該從程式碼開始管理？

3. 我想要的是：快速開始，也能細緻調整

上篇從 Relume開始。它的優勢很明確：只要輸入一段描述，就能在幾分鐘內產生網站地圖、線框稿和風格指南，並且有大型元件庫作為基礎。

我當時也提到，它能自訂的範圍不算大，不過作為起點仍然很實用。它提供的視覺風格也比較偏向常見的行銷網站。

我想要的是同樣快速的起步方式，但之後仍然可以編輯每一個顏色、圓角、字體和元件細節。

我也希望系統能支援較少見的視覺風格，以及更細緻的設計限制，例如：

• 霧面玻璃效果：在明亮和深色背景上檢查文字是否仍然清楚可讀。
• 圖表配色：從品牌主色延伸出圖表色盤，並檢查有色覺差異的使用者是否仍能區分各種顏色。
• 內外圓角的配合：分別處理容器外側與內部元素的圓角，讓容器內的元素能順著外框形狀排列。
• 字體設定：視需要為標題、內文和按鈕使用不同字體。

Relume 也正在發展 AI 輔助編輯功能，並增加讓 AI 工具讀取其元件庫的方式。我認為這個方向是合理的。我想探索類似的快速工作流程，同時讓設計規則更貼近實際使用它們的程式碼。

4. 為什麼系統仍然需要操作介面？

如果設計系統放在程式碼裡，為什麼不直接請 AI agent 修改檔案就好？

對於小幅修改，這種方式確實有效。但設計決策經常需要視覺判斷，只靠程式碼並不容易完成。

設計需要放在視覺脈絡中判斷。修改一個顏色或圓角，就可能影響不同品牌與模式下的數十個元件。要判斷結果是否合理，我需要把這些元件並列比較。只看 Token 檔案的差異，無法呈現整體效果。

設計屬性持續演進。霧面玻璃、依模式區分的陰影、貼合容器的圓角，以及動態效果，都可能帶來標準 Token 無法完整描述的設定。設計師需要能夠調整這些細節，同時保有足夠的控制權。

部分檢查交給程式更可靠。文字對比度、焦點指示、半透明表面上的文字可讀性、圖表配色，以及元件的無障礙檢查，都可以由程式更一致地執行，不必只靠設計師記住所有規則。這些檢查應該在每次變更時執行。

視覺判斷與自動化回饋應該一起運作。玻璃效果看起來是否自然、動畫是否讓人感到平穩，不能只靠數字決定。我希望能調整設定、即時觀察元件的變化，同時讓程式在文字開始變得難以閱讀時提醒我。

這就是操作介面的用途：把元件集中在同一個地方，將各種設定轉化為視覺控制項，並在調整的同時執行檢查。

例如，在 Plinth 的玻璃效果編輯器中，當我調整效果時，系統會同步檢查文字在明亮與深色背景上的可讀性。如果檢查未通過，Plinth 會建議一個仍能通過檢查的最低透明度。

目前動態效果還沒有專屬的控制項，這是我接下來想探索的方向之一。

檔案仍然是 Source of Truth，操作介面則是設計師以視覺方式調整這些檔案的地方。

5. 以程式碼作為設計系統的 Source of Truth

這是我目前正在嘗試建立的架構。其中有些部分已經能在 Plinth 裡運作，另一些仍停留在規劃階段。

這套流程有三種修改方式、一組共用的檢查機制，以及一個 Git repository。GitHub 負責保留版本紀錄，並在發布前執行測試。使用者可以透過元件網站瀏覽系統，AI 工具則能讀取設計指南與元件資訊。無論透過哪一種支援的方式修改，最後都應經過相同的檢查。

修改系統

設計師可以直接在 Plinth 的介面中操作，也可以用日常語言描述想要的變更。AI agent 可以透過 Plinth 提供的工具修改系統。開發者，或具備程式能力的設計師，也能直接使用 VS Code、Cursor 等編輯器修改檔案。

執行檢查

Plinth 會執行能夠自動化的檢查，包括文字對比度、顏色之間的關係、圖表配色的可辨識度，以及一項修改會影響多少元件。直接修改檔案的變更也應經過同一套檢查。

對我來說，最重要的原則是：無論由誰修改、使用哪一種工具，每一項變更都應符合相同的標準。

將所有內容集中在同一個 repository

Repository 主要保存四類資訊。

標準設計 Token。這些 Token 採用常見的三層結構：基礎色盤、依品牌與模式對應到基礎值的語意角色，以及引用語意角色的元件 Token。基礎層以 Tailwind CSS 為起點：它的色盤、圓角與陰影的尺度，以及間距單位，讓每套設計系統都從經過大量驗證的單位開始。這些數值仍然可以客製：品牌色會在 Tailwind 色盤旁長出自己完整的色階，語意角色也可以指向任何一階，顏色和圓角都能依品牌需要偏離預設。

標準 Token 無法完整描述的設計屬性。對於這些屬性，我希望只保存必要參數，再由程式計算輸出結果。以玻璃效果為例，可以保存顏色、透明度、模糊程度和邊緣光，再產生包含 fallback 的 CSS，並檢查文字可讀性。圖表顏色可以根據主色推導，再以色盤參照值保存，讓設計師仍然能調整。貼合容器的圓角可以記錄所屬容器及元素間距。不同模式可以使用不同陰影設定，而動態效果則應提供減少動態效果的替代方案。漸層目前仍是尚待解決的問題。

適合以文字表達的設計規則。品牌個性、應遵守與避免的原則，以及文字語氣，可以整理在 DESIGN.md 和 WRITING.md 等檔案中。AI 工具能讀取這些指南，發布前也可以透過 AI 審查，檢查修改是否符合規範。

以現有元件庫為基礎的元件。元件從成熟的元件庫開始，而不是從零打造。Plinth 的元件目錄建立在 shadcn/ui 和它使用的 Radix 元件上，鍵盤操作與無障礙行為一併沿用，每個元件再改寫成只讀取自己的元件 Token。持續跟進 shadcn 的更新，以及支援 Material 等其他元件庫，是我接下來想探索的方向。

測試與發布

GitHub 保存所有版本紀錄。發布前，流程會執行自動化檢查和元件測試。如果有任何檢查失敗，線上仍會維持上一個已知正常的版本。

瀏覽與使用系統

使用者可以在 Storybook 網站中，依照不同品牌和模式瀏覽 Token、元件與設計指南。AI 工具也能透過設計指南和 Storybook 的 MCP server 讀取相同資訊。

未來，設計師可以透過 MCP 將系統帶進 Figma，或直接在程式碼編輯器中使用元件建立畫面。產品 repository 也可以透過 registry 引入元件和主題設定。目前只有直接在編輯器中操作的部分已經可用，其他整合仍在規劃中。

讓回饋回到原始系統

無論是 Figma 裡的留言，還是產品中發現的錯誤，最後都應轉化為 repository 裡的修改，並經過相同的檢查流程。目標是避免另外維護一份彼此競爭、需要手動同步的設計系統。

6. Plinth 目前的狀態

Plinth 在我的電腦本機執行，並由 Claude Code 驅動。目前分成四個步驟。

• Describe：我用一句話描述產品，Claude 會提出後續設定建議，並簡短說明每項建議的理由。我可以直接確認或修改，不必從空白表單開始。也可以貼上一個喜歡的網站的網址，Plinth 會讀取它的顏色、圓角和字型作為起點。
• Style：以視覺化方式呈現預計使用的 Token，包括基礎值、品牌色、共用設定，以及使用這些 Token 的元件。選取某個 Token 後，系統會標示它的關聯，並顯示受到影響的元件。
• Components：所有元件集中在同一個頁面。我可以選取元件的某個部分進行修改。如果顏色被多個元件共用，Plinth 會先計算影響範圍，再詢問我要只修改目前選取的元件，還是同步修改所有使用該顏色的元件。
• Publish：將系統推送到 GitHub，執行檢查與測試，通過後再更新元件網站。

←

→

Describe：這套設計系統的答案。每一題 Claude 都附理由建議，外觀則從一個網站讀來。

整個開發過程有兩個原則始終沒有改變。

AI 負責草擬，由人確認。名稱、版本備註和建議答案會先填入欄位。使用者可以確認或修改，不必每次都從空白欄位開始。

程式能計算的，就交給程式計算。文字對比度、色階、圖表配色，以及修改會影響的範圍，都應透過計算得出，而不是靠猜測。AI 協助理解我的需求，程式則負責可以量化的部分。

發布後，元件網站、供 AI 工具讀取的設計指南，以及所有版本紀錄，都可以透過 GitHub 取得。元件網站打開就是一個範例畫面：只用這套系統的元件組成的小型儀表板，整體風格一眼就能判斷。

7. 為什麼我傾向以程式碼為核心

這是我目前的看法，仍然需要透過實作繼續驗證。

我觀察到設計工作正逐漸靠近 Design Engineering。設計師的產出愈來愈可能同時包含元件程式碼、設計 Token 和介面畫面。

當程式碼本身就是交付成果的一部分，把設計系統的 Source of Truth 放在程式碼裡，就有幾個實際優點：

• 完整的版本紀錄：每次修改都可以被檢視，也能還原到先前的版本。
• 可重複執行的檢查：發布前可以自動檢查對比度、失效的參照，以及寫死在程式碼中的數值。
• AI 工具能讀取的格式：使用 DTCG 格式的 Token，並將設計規範整理在 DESIGN.md，Claude Code 或 Cursor 就能依照明確的規則工作，不必從截圖猜測設計意圖。

不過，程式碼目前還無法完美描述所有設計屬性。現有 Token 格式只能部分涵蓋陰影、漸層和動態效果。我正在透過 Plinth 探索如何補足這些缺口，同時避免讓系統變得更難維護。

8. 那 Figma 呢？

這是一個仍待驗證的假設，而不是定論。

我認為 Figma 仍然很適合讓人們一起工作，例如並列檢視不同方案、留下意見、比較設計方向，以及與不熟悉設計工作的人討論。程式碼並不適合取代這些活動。

但對於設計系統底層的規則與數值，我傾向將它們保留在程式碼中，再把呈現結果帶進 Figma。在這樣的架構裡，Figma 是檢視原始系統的介面，而不是另一個也必須同步維護設計規則的地方。

Figma 正在發展讓 AI 工具讀取設計檔案的方式，設計系統周邊的工具也會持續改變。我還不知道一年後 Figma 最終會扮演什麼角色。這只是我目前正在探索的方向。

9. 目前的限制

Plinth 還在早期 Alpha 階段，目前有幾項重要限制：

• 目前只在 Windows 11 上測試過，實際使用者也很少。
• 需要搭配 Claude Code。建立一套設計系統目前約花費 0.35 美元，透過聊天進行的每次修改約為 0.30 美元。
• 部分較少見的視覺效果仍受到限制。例如，我目前還無法在網頁上實現自己想要的、類似 iOS 玻璃效果邊緣折射的呈現方式。
• 產品整合流程尚未完成。下一個重要步驟，是讓產品 repository 能夠直接使用已建立的設計系統。

這些限制也是實驗的一部分。在把這套架構視為完整解法之前，我想先了解它在實際使用時，哪些部分真正有幫助。

10. 接下來的方向

接下來，我打算：

• 透過 shadcn registry，讓產品 repository 能直接使用元件與主題設定。
• 持續跟進 shadcn 的更新，並探索支援其他元件庫的可能性。
• 擴充對較少見視覺風格的支援。

一年前，我關注的是如何讓 AI 理解設計。現在，我更想探索如何將設計規則集中管理，並讓這些規則能夠被自動檢查。

Plinth 是我嘗試把這個想法付諸實作的方式。整套做法仍在演進，但目標很明確：建立一套設計師能以視覺方式調整、程式碼能持續驗證，而且 AI 工具不必每次都從截圖推測規則的設計系統。