活化設計系統

資料來源#

• How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development
• I tested Meta's "agent-ready" design system Astryx. Here's the results.

摘要#

Thariq Shihipar 的第三種 HTML 優先工作流程：維護一個 design_system.html 檔案，這份產物同時供人與機器讀取，作為應用程式視覺語言的可攜式事實來源。它不像靜態的風格指南文件，而是會實際呈現：色彩配置、字體比例、間距規則，以及核心元件（按鈕、輸入欄位、卡片）的互動範例，都會直接顯示在頁面上。每次開始新工作時，把這個檔案交給 Claude 作為脈絡，它建置出來的內容就會符合品牌風格。

這是將 HTML 作為新 Markdown 的做法，應用於設計系統遵循度這個長期難題：人可以直接檢視的產物，也是模型用來維持一致性的依據。

如何建置#

1. 擷取設計 DNA。 指示 Claude 檢視一個專案資料夾，或一次檢視多個 GitHub 儲存庫（例如行銷網站和應用程式），並請它擷取設計系統。它會分析 CSS、元件和樣式，推斷視覺語言。
2. 產生 design_system.html 產物。 Claude 將擷取出的系統呈現為單一 HTML 檔案，視覺化展示色彩配置、字體比例、間距和互動式元件範例——呈現的不是元件說明，而是元件本身。
3. 探索變體並分享。 使用 Claude Design 等工具，建置含有互動式旋鈕和滑桿的元件遊樂場（「這個按鈕加大內距會長什麼樣子？換個邊框呢？」），即時探索不同變體。

為什麼它是「活化」的#

傳統風格指南會逐漸失準：文件說一套，程式碼做另一套。從程式碼中擷取、並以真實元件形式呈現的 design_system.html 更難造假——你看到的就是元件實際呈現的樣子。而且由於它是單一可攜式檔案，可以隨處使用：交給新專案、新功能或隊友，就能成為維持輸出一致性的參考。這是一種持久的運算資源配置——產生一次，便可無限期重複作為脈絡使用——有別於用完即丟的微型應用程式。

串連工程與公司其他部門#

這項產物最大的價值在於組織層面。呈現元件的頁面讓非技術利害關係人——行銷人員、PMM、任何製作簡報或影片的人——只要前往一個頁面，就能查看所有元件的各種狀態，並取得高擬真模型，「不用打擾工程師」。Claire Vo 表示她用自己的元件視覺化頁面做的正是這件事。因此，設計系統串連的不只是人與 AI，也串連了工程與公司其他部門——這正是 HTML 作為新 Markdown 所聲稱、計畫能帶來的人類易讀性價值。

測試：符合品牌的輸出取決於涵蓋範圍，而非提示#

對核心假設的首次實作測試——把呈現完成、結構化的設計系統交給模型，是否真的能產生符合品牌的輸出？——來自 Evangeline 對 Astryx 的試用。這是 Meta 的開源「agent-ready」設計系統，搭配真實消費品牌 Salt & Straw 的實際購物流程進行測試（case-study、單一實作者、n=1、未測量）。

結果 1——產物是輸入，不是提示。 早期執行結果很普通，也不符合品牌（完全沒有購買按鈕）。作者一開始認為問題出在 Astryx；實際原因是缺少設計產物：

「通用 AI 輸出和符合品牌的輸出之間的差距，不是提示問題，而是缺少像 tokens.json、design.md 這類設計產物。AI 無法重現我沒有提供的選擇和設計。」

將品牌擷取至 DESIGN.md 和分層 token 檔案（primitives / semantic / component）之後——內容不只記錄值（珊瑚色 #F0483E、標題用 Bebas Neue／內文用 Inter、8px 基準、10/30/70 圓角、平面／無陰影的深度），也記錄背後的推理——代理程式產出了完整可用的產品介面：附地圖與等待時間的店鋪搜尋、含追蹤時間軸的訂單記錄、購物車、附真實照片和購買按鈕的口味頁面、會員忠誠度頁面，以及桌面版和手機版。「提供真實的決策和真實的圖片，它就能產出真正符合品牌特色的作品。」這直接支持了本文的主張，並使其更精確：成功之處不在於產物能呈現，而在於產物記錄了模型原本必須自行編造的決策。作者對每次失敗的診斷都是：「每次我的輸出看起來很普通，都是因為我把自己原本默認的決策寫了下來。」

結果 2——品牌呈現的邊界，恰好就是系統自訂插槽的邊界。 Astryx 只為四種元件提供深入自訂功能：按鈕、卡片、文字輸入欄位、連結。其他所有內容只能透過主題設定微調。輸出明確呈現了這條界線：有自訂插槽的地方都正確使用珊瑚色、糖果條紋和平面卡片；獎勵進度條卻呈現藍色（#0074E2），店鋪搜尋的等待時間條則是藍黃相間，因為這些元件沒有對應插槽。分段控制項也出現陰影，違反 DESIGN.md 規則 #2（「平面深度模型——絕不使用陰影」）。這次失敗不是隨機的審美偏移，而是涵蓋範圍的邊界：系統會在對應介面以外悄悄套用自有預設值。

證明這是回退行為而非誤讀的關鍵，是作者改用藍瓶咖啡重新測試；該品牌的藍色與 Astryx 的預設色接近，於是進度條看起來正確。相同程式碼路徑、相同的悄悄回退，只是這次與成功無從分辨。如果設計系統的預設值與你的品牌相似，它就會掩蓋自身的涵蓋缺口。

「這套系統能展示品牌，卻無法完整吸收品牌。任何 Astryx 沒有自訂插槽的內容，品牌識別就會留在系統之外，或是被呈現成錯誤的顏色。」

結果 3——自訂模式比 token 格式更重要。 將相同品牌和畫面改用 shadcn/ui 執行，進度條便會呈現珊瑚色。差異在於元件的所有權，不在產物品質：shadcn 會把元件複製進你的專案（由使用者擁有的檔案，可像一般程式碼一樣編輯）；Astryx 則將元件留在系統中，透過主題層設定樣式，結果是「分層 token 被攤平成一層」，而且沒有變通方式——「在我使用的流程中，進度條顏色錯了，我無法透過主題設定修正。」取捨很平常：品牌成長時，shadcn 的使用者要維護每個元件；Astryx 的使用者維護的元件較少，但必須接受系統限制。「Agent-ready」這個標籤描述的是代理程式能否讀懂；它完全沒說系統能否吸收品牌。

這為本文補上了什麼。 能呈現內容的 design_system.html 提升了易讀性，但易讀性不等於涵蓋範圍。這裡涉及兩項不同特性，而本文原先主張的只有第一項：

1. 記錄決策——產物是否明確表達了這項選擇？（Astryx 測試：有，而且有效。）
2. 套用插槽——產品所需的每種元件，是否都有地方能套用這項決策？（Astryx 測試：涵蓋 4 種元件，其他所有內容都會退回預設值。）

以擷取為基礎的產物，例如 design_system.html，比外部引入的系統更能滿足（2），正因為它是從你已經擁有的元件衍生而來；但缺口仍會以另一種方式出現：產物只記錄擷取器找到的內容，而產品後續需要、但產物未曾涵蓋的項目，模型就會採用自己的先驗，而不是你的。本文開放問題所提到的維護責任，因此不只是維持同步，也要維持完整。

相關連結#

• 依選擇設計——將相同做法產品化：上傳品牌檔案、標誌、簡報和字體規格至 Claude Design，讓它產生所有後續產物的設計系統——這是直接對應模型預設美感的官方解法。上文的 Astryx 測試為此解法劃出邊界：只有在存在自訂插槽的地方，脈絡才能克服預設美感；其他地方都無法
• 為什麼 AI 在設計上落後——原因 4（設計與程式碼之間的抽象層）正是設計系統的問題：元件之間的語意，而不是元件的像素
• Agent-Native Infrastructure——design_system.html 是設計層的代理程式原生基礎設施
• Systems Thinking Over Specialization——企業規模的實踐：Netflix 的設計組織轉而招聘懂設計系統的人，將「卓越設計的樣貌」編碼為範本，讓非設計師也能一致地交付成果，不必「做出拼湊怪物」
• Thariq Shihipar——design_system.html 工作流程的創始者
• Claude Code——從程式碼庫擷取設計 DNA 並呈現 design_system.html；Claude Design 提供元件遊樂場功能
• HTML 作為新 Markdown——母題；設計系統是將 HTML 優先的做法應用於設計
• 運算資源配置器——一種持久的運算資源配置（產生一次，重複作為脈絡使用）
• 用完即丟的微型應用程式——相對的用完即丟做法；設計系統則是保留使用的做法
• Claire Vo——為非技術利害關係人採用平行的元件視覺化實踐
• Engineer PM Convergence——讓非工程師自行取得高擬真素材的產物，正是組織內角色逐漸模糊的工具面向
• HTML 產物生命週期：計畫歷史的所在，以及一次性產物何時變得持久——將本文稱為持久產物的範例：產物因反覆使用、同步壓力和受眾而取得保留資格，並承擔本文開放問題列舉的維護責任

開放問題#

• 隨著程式碼庫演進，design_system.html 如何維持同步——定期重新擷取，還是接入 CI？而真正的瓶頸會不會是完整性（產品所需的每種元件都有插槽嗎？），而不是新鮮度？Astryx 測試顯示，未涵蓋的元件會悄悄失敗，僅檢查內容是否過時並無法察覺。
• 可呈現且模型可讀的設計系統，相較於純 CSS/token 檔案，是否能顯著改善符合品牌的輸出，還是其價值主要在於人類易讀性？#oq/source 部分解答：我測試了 Meta 的「agent-ready」設計系統 Astryx，以下是結果。 顯示結構化產物（DESIGN.md 加上分層 token）能讓輸出從一般風格轉為符合品牌，因此有產物顯然勝過沒有產物——但它沒有拆解本題真正詢問的變因，因為使用的產物是純檔案，而不是呈現頁面。呈現頁面與純檔案之間的差異仍未測試。
• 專案規模到什麼程度時，維護產物的成本會超過它帶來的一致性價值？

資料來源#

• How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development
• I tested Meta's "agent-ready" design system Astryx. Here's the results. — Evangeline，Substack，2026 年 7 月（case-study、n=1）：以 Salt & Straw 測試 Meta 的 Astryx；結構化產物能產生符合品牌的輸出，但僅限於具有實際自訂插槽的四種元件；另以 shadcn/ui 對照，確認元件所有權是差異所在