從一份不完整的 Figma 開始

為什麼設計到程式實作總是出現斷層？

為什麼會說這一份 Figma 不大完整呢？

過去開發時，設計外包就不提供 dev mode，以前端的角度來說這非常奇怪，但沒有參與到一開始的流程，後續忙於開發也不想去干預別人談好的合作。

結案時拿到整份 Figma 才發現有缺失。實作時這些設計問題會透過我腦補去修復掉，但後續若要做任何自動化——design token、AI 生成、跨平台 export——這份設計就會立刻爆炸。因此想要藉由這一個半月的交接期來好好處理並熟悉整個流程。

---

在前端工程師眼裡，這份 Figma 是什麼樣子

以「人」進行前端實作的角度來說，這份 Figma 其實沒有什麼太大的問題：

有問題的地方	堪用之處（需要通靈的地方）
命名亂	用視覺判斷這個按鈕跟那個按鈕是不是同一個東西
沒有 auto layout	會用眼睛量 16px 還是 24px
已結案找不到設計師	視覺稿本身沒有太大問題

視覺稿沒問題，但 AI 看不到設計意圖。只要把「人」換成「機器」，每一條剛剛能通靈的東西都會爆炸：

• 命名亂 → token 推導推不出穩定的命名空間
• 沒有 auto layout → 抓不到 spacing 的設計意圖，只能看到一堆 hardcoded 的 x/y
• 同一個顏色在不同地方寫成不同 hex → AI 生 UI 時會選哪一個？

但最大的問題是找不到設計師，如果後續也沒有具設計概念的前端……

---

為什麼這個系列存在

即將離開現在這家公司。在那之前想做兩件事：

1. 「邊做邊研究」的過程筆記 — 把 Figma 變成 design token、再讓 AI agent 用文字描述生 UI／寫 code 這整條 pipeline 走過一遍，誠實記下卡關和繞路
2. 取代傳統交接文件的助理 — 透過 token + agent，未來接手人用對話就能生出符合設計系統的 UI 與程式碼

第二件事是這個系列真正的目的。不想留一份 200 頁、半年後就過時、沒人會打開的 wiki，我想留一個可以對話的東西。

一個關鍵的早期決策：不從「先把 Figma 弄乾淨」開始

直覺上會想先把 Figma 整理好再萃取 token，但沒有這樣進行：

1. 在不到一個月的時間壓力下，Figma cleanup 會吃掉所有時間
2. Figma 不應該是 design system 的 source of truth，code 才是
3. 即使整理好了，沒有同樣紀律的接手人三個月後又會弄亂——那這份「乾淨的 Figma」的半衰期就是三個月

正確方向反過來：

1. 以 tokens.json 為 source of truth
2. 把現在的髒 Figma 當「考古資料」抽出原始素材
3. 透過agent協助生成vue基底的組件庫

---

這個系列接下來要做什麼

第 2 篇開始就是怎麼把這團混亂變成資料——Figma MCP 為什麼失敗、最後怎麼用 REST API 接通、第一次撈到的 raw data 長什麼樣。