Supernova.io

Supernova.io 追蹤元件健康度，並讓 token 在 Figma 與程式碼之間保持同步，所以設計端做的顏色或間距變更真的會傳到程式碼庫，而不是在幾個 sprint 裡走偏。元件帶有健康、已知問題或已淘汰等狀態。你一眼就能看到元件庫的狀態。這是產品的核心：一個讓設計與程式碼對「token 究竟是什麼」達成共識的地方。

平台會連上 Figma 檔案與變數、Storybook 以及程式碼庫掃描。你可以在每個工作區連結多個檔案與連線，而且每個方案都支援擴充的 Figma collections。這種廣度很重要。大多數設計系統並不只存在於單一檔案裡。

你可以在同一個屋簷下管理多個品牌，每個都保留自己的樣貌。團隊不必為每個品牌維護各自獨立的系統，而是在同一個工作區裡切換情境，省下那種默默吃掉設計營運團隊一整週的重複治理工作。它針對的是同一個產品家族擁有多個視覺識別的組織。很少有工具能把這件事做好。

團隊撰寫並發布同時引導人員和代理的文件。每一次編輯都會留下快照，所以你能看到誰改了什麼，並還原任何版本。即時協作代表設計師、工程師和代理可以一起編輯，並有變更紀錄作為後盾。弄丟工作成果是真實的痛點。這個功能值得它佔的位置。

Supernova.io 為設計系統提供過濾式 MCP 伺服器，只給每個團隊它真正需要的知識，而不是整套系統。你可以依團隊或依介面建立連線，所以回答按鈕問題的代理不會同時拿到你整座 token 庫。Free 包含兩條連線。Pro 有十條。Enterprise 則無上限。這種過濾很重要。少了它，每個代理都會淹沒在用不到的脈絡裡。

當 token 變更時，程式碼自動化會把它匯出並開啟 pull request。變更不會躺在設計檔案裡等人手動接手。不用再靠複製貼上交接。把這套接起來的團隊，花在把設計決策手動翻成程式碼的時間更少。

Slack 裡的 Supernova 代理會從真實來源回答關於 token 與規範的問題。另一套分析則顯示團隊實際用了哪些 token 和元件、採用率在哪裡下滑。你可曾想過自己做的元件到底有沒有人在用？現在你知道了。兩者合起來，涵蓋了設計系統負責人天天被問到的兩個問題。

平台會收集團隊的回饋，並把落差變成建議的修正，而不是堆成待辦清單。這個想法聽起來很吸引人，直到你想起大多數系統之所以失敗，正因為從一開始就沒人維護。目標是一個會隨著時間變好的系統。紙上看起來不錯。這是整段說法裡最有野心的一部分，老實說，也是最該在 demo 裡用力檢驗的一環。