Claude Design 最關鍵的技術細節：讀 codebase 建設計系統
Claude Design 最被低估的功能是它在 onboarding 時會讀取團隊的 codebase 與 design files，自動建出包含顏色、字型、元件的 design system，之後每個專案都自動套用。對開發者來說，這是 AI agent 從「會寫 code」進化到「理解 design tokens 與系統」的一大步。本文拆解這個機制對 AI agent 與設計工程的意義。
Anthropic Labs 於 4 月 17 日推出 Claude Design，多數媒體報導集中在「對 Figma 的衝擊」。但從開發者和設計工程師的角度，這個產品最有看頭的是一個被低估的功能：onboarding 階段的 codebase-aware design system 建立機制。
簡單說，Claude Design 會讀你的 codebase 與 design files，自動提取出顏色、字型、元件定義，組成一套專屬於你團隊的 design system，之後所有在 Claude Design 產出的作品都會自動套用。這個機制代表 AI agent 從「會寫 code」進化到「理解系統」，是一個值得認真看的里程碑。
傳統 design system 建構有多痛
任何做過 design system 的人都知道這件事多痛：
- 人工整理 token：設計師要開會定義 primary color 是 #2563EB 還是 #1D4ED8，工程師要把這個值寫進 CSS、Tailwind config、iOS asset catalog、Android color resource 四個地方
- 跨 repo 同步：行銷官網、App、管理後台各自用不同技術棧，token 同步靠人肉
- Drift 問題：半年後你會發現設計稿上寫 #2563EB，生產環境實際跑 #2064E8，沒有人知道什麼時候被誰改的
- 文件落後：Storybook 寫的和實際 component 做的可能已經對不起來
大公司會花整個 Design System Team 處理這些問題，小公司只能放給它爛。
Claude Design 怎麼做
根據官方公告，Claude Design 的 onboarding 流程大致是：
- 連接 codebase：使用者授權 Claude 讀取 repo
- 解析 design files：掃 Figma、Sketch 或其他設計檔案
- 提取 token：從程式碼（Tailwind config、CSS variables、component library）與設計檔中抽出顏色、字型、間距、圓角、陰影等基礎 token
- 建構 component 識別：辨認常用的 button、card、input 等 component 特徵
- 生成可用 design system：整理成一套 Claude Design 內部可用的系統
- 持續更新：團隊修改後 Claude 可以重新同步
這個流程裡最關鍵的是第 3 步和第 4 步。過去 AI 只會做「視覺辨識」或「語法分析」，現在 Claude 需要跨模態：從 CSS 變數名看出「這是 primary color」，從 Figma component 看出「這跟 codebase 裡的 Button.tsx 是同一個東西」。這是 Opus 4.7 高解析度視覺能力加上長上下文推理的組合拳。
對 AI agent 的意義
這個功能真正重要的地方，不是「做出了好看的設計系統」，而是展示出 AI agent 的能力邊界又往前推了一格。
過去的 AI agent 分成幾種：會寫程式的（GitHub Copilot）、會處理語義的（文字生成）、會理解圖片的（視覺模型）。Claude Design 第一次把這三件事綁在一起做一個具體任務：讀程式碼、看設計稿、理解設計師意圖、生成符合系統規範的新作品。
換句話說，這不是「code + image + text」的簡單加總，而是「system thinking」的 AI 化。Claude 必須理解「為什麼這個 color 叫 primary、那個叫 accent」才能把新作品的顏色用對。這種系統性理解，是 AI agent 從「執行工具」進化到「協作夥伴」的必要能力。
給開發者與設計工程師的啟示
這個轉變有幾個直接的實務意義：
- 你的 token 命名會直接影響 AI 產出品質：如果你的 CSS 變數叫
--color-1、--color-2，Claude 沒辦法推測語意；如果叫--color-primary、--color-on-surface，就有脈絡可以用 - Design file 的結構也很重要：Figma 裡有用 variable 和 component 的團隊，Claude 能提取的資訊比純圖層多得多
- 文件品質會變成 AI 成果的天花板：Component README、Storybook story、TypeScript 型別註解，這些過去對人類有價值的文件，現在對 AI 也一樣有價值
- 「為 AI 可讀」會變成新的工程品質指標：就像過去「為測試可寫」成為好程式碼的一個標準
這不是要你為了 AI 重寫專案，而是「好的工程實踐本來就對 AI 友善」這件事被放大了。
可能的風險與限制
這個機制也有值得警惕的地方：
- Drift 風險：Claude 讀了一次 codebase 後，如果 token 後來被改，AI 用的還是舊的。需要搞清楚同步機制
- 私有 codebase 資安：把整個 repo 給 Claude 讀，涉及機密邏輯和未發表功能的洩漏風險。官方有說明資料處理政策，但企業部署前要仔細看
- Monorepo 複雜度：大型 monorepo 內可能有多套風格不同的 design system，Claude 要選哪一套？目前不清楚
- 品質依賴來源：如果你的 codebase 裡 token 命名本來就亂，Claude 建出的系統只會一樣亂
換句話說，Claude Design 的 design system 功能效果好壞，很大程度取決於你自己的工程品質。
結語
Claude Design 的 codebase-aware 機制可能是這次發布最被低估的部分。它不只是一個功能，而是 AI agent 進化路線上的一個明確信號：下一代工具不只會執行任務，會理解你的系統。對開發者和設計工程師來說，這件事的意義比「多一個 AI 畫圖工具」大得多。
