如果你能取得 HTML 和 CSS 原始碼，例如你自己的正式產品程式碼、開源 UI 函式庫、前端原型，或是靜態輸出，就可以直接把它轉成可編輯的 Figma 檔案。這是以開發者為主、以原始碼為起點的 Website-to-Figma 工作流程近親。
為什麼要用原始碼，而不是網址？有三個理由：最高保真度（computed styles 直接來自 CSS，不是從像素猜測）、可處理難以擷取的頁面（建置時生成、需要登入、開發環境），以及很適合工程導向的 code-design 來回流程。
相關 Codia 產品：Codia HTML to Figma。
什麼時候適合用 HTML-to-Figma
當符合以下情況時，這個流程最適合：
- 頁面還在開發環境裡，尚未部署。
- 你手上有靜態 HTML/CSS 輸出，但沒有設計來源。
- 你在使用以程式碼撰寫的開源設計系統或元件庫。
- 由工程團隊掌控頁面，需要從正式 CSS 逆向生成 Figma 來源。
- 你要把元件庫重新整理回 Figma，以便與設計對齊。
- 設計系統團隊想檢視正式 CSS 與設計 tokens 的差異。
如果頁面能用 URL 存取，通常 Website-to-Figma 會更簡單。HTML-to-Figma 是針對你手上已有原始碼的情境。
HTML 轉 Figma、Website 轉 Figma、Screenshot 轉 Figma 的差異
| 輸入 | 流程 | 最適合 |
|---|---|---|
| 原始 HTML/CSS 原始碼 | HTML to Figma | 開發者主導轉換、最高保真度、未發布頁面。 |
| 可存取的網址 | Website to Figma | 可連線頁面，包含競品與正式環境。 |
| PNG/JPG | Screenshot to Figma | 只有圖片時。 |
這三種流程最後都會回到同一個目的地：可編輯的 Figma 檔案。差別只在於你輸入的是什麼。
工作流程
- 準備來源。 確保 HTML 在單獨環境中能正常渲染，不要有缺少的 CSS、損壞的字型，或必須啟動建置伺服器才能運作的依賴。
- 進行轉換。 Codia AI 會解析標記、套用 computed CSS 樣式、解析圖片與字型，並將視覺重建成 Figma 圖層。
- 在 Figma 開啟結果。 每次轉換會產出一個 frame，裡面有結構化圖層、文字樣式與圖片填色。
- 檢查——見下方清理建議。
- 將重複元件 componentize，讓 Figma 檔案反映與原始碼相同的結構。
轉換後通常能保留什麼
通常很完整
- 語意化 HTML 結構 —
<section>、<article>、<header>、<footer>與巢狀版面會轉成群組化的 Figma frames。 - 文字內容與字體樣式 — 真實文字圖層，
font-family、font-size、font-weight、line-height都會保留。 - 色彩值 — 純色背景與文字顏色會直接轉成 Figma fills。
- Flexbox 與 Grid 版面 — 在類比合理的地方會轉成 Figma Auto Layout。
- 邊框、圓角、陰影 — 會套用成 Figma effects。
- 圖片 — 會以圖片填色的方式，引用原始資源網址。
需要檢查
- CSS-only 複雜效果 —
backdrop-filter、複雜mask-image、多段漸層混合。會盡量近似成 Figma 對應效果。 - 偽元素 —
::before/::after內容會被捕捉為獨立 frame；偽類狀態（:hover）需要分別擷取每個狀態。 - 自訂字型代管 — 透過自訂 CDN 載入的字型，可能需要手動對應到本機 Figma 字型。
- CSS 變數與 design tokens — 會以原始值保留；要回對到你的 Figma design system 仍需人工處理。
- JS 驅動版面 — 任何由 JavaScript 定位或尺寸決定的內容，都必須先跑完，讓頁面在擷取前處於最終狀態。
- 網頁動畫 — Figma 不原生表示 CSS keyframes 或 transitions。請轉換靜態停駐狀態。
以角色來看使用情境
接手 codebase 的設計師
你剛加入一家公司。已經有正式前端，但沒有 Figma。HTML-to-Figma 可以讓你先有設計起點，而不是手工重做每個畫面。
設計系統團隊
對照正式 CSS 與 Figma 元件庫的實際差異。把 codebase 裡有代表性的元件轉成 Figma，並和設計端版本並排比較，差異就會一目了然。
文件化元件的工程團隊
如果元件庫在程式碼裡，但設計團隊需要 Figma 文件，HTML-to-Figma 就是橋樑。把每個元件的 Storybook 或 demo 轉成 Figma frame。
代理商與自由接案者
客戶交給你的是靜態 HTML mockup（常見於前一個供應商留下的檔案）。HTML-to-Figma 比手工重建快得多，也能提供可編輯的重設基礎。
需要怎麼清理
轉換完成後，優先處理：
- 文字樣式 — 把內聯樣式換成 Figma 字體 tokens。
- 色彩 tokens — 將還原出的 hex 值對應到你的設計系統色彩樣式。
- 圖示 — 將點陣圖示替換成你素材庫中的 SVG 元件。
- Auto Layout — 驗證回應式區塊是否正確轉成 Auto Layout，必要時重建。
- 元件結構 — 把重複樣式（卡片、按鈕、列表項目）轉成 Figma 元件。
- 命名 — 程式碼裡的 class 名稱通常不適合設計命名，請重新命名以利閱讀。
- 第三方小工具 — 把分析、聊天與同意視窗的覆蓋層從設計畫布移除。
常見陷阱
來源本身就壞掉。 如果 HTML 在瀏覽器裡都無法正常渲染，轉換自然不可能憑空修好。先確認來源可以乾淨顯示。
缺少 CSS 或字型。 邏輯相同——如果外部 CSS 或字型載入失敗，轉換只會抓到 fallback。轉換前請把所有依賴包好。
忘了 JS 生成的內容。 如果重要版面或內容是在頁面載入後由 JavaScript 生成，請先讓 JS 跑完、頁面完全 hydrate，再開始擷取。
期待 CSS 動畫能直接搬過去。 Figma 是靜態的。先轉靜止狀態，若需要互動變體，再在 Figma 中另外設計。
把它當成程式碼品質檢查。 HTML-to-Figma 不會幫你重構程式碼，它只會把現有內容轉出來。程式碼品質該在 code review 裡處理，而不是在 Figma 裡。
搭配 Figma-to-Code
一個對工程團隊很實用的來回流程是：HTML → Figma（這個流程）→ 在 Figma 裡清理 → Figma to Code → 生成更乾淨、可重構的前端。當你想把正式環境裡不一致的 CSS 收斂回符合設計系統的實作時，這條路特別有用。
API 存取
如果要大量轉換整個元件庫或設計系統，Visual Struct API 可以接受 HTML 輸入，並回傳結構化 JSON，供下游工具轉成 Figma 或接進 design-ops 流程。
FAQ
我真的可以把原始 HTML/CSS 轉成可編輯的 Figma 嗎？
可以。轉換會解析 HTML、套用 computed CSS，並把視覺重建成 Figma 圖層——文字是真文字、顏色是真 fills、版面在類比合理時會是真 Auto Layout。
這和截圖頁面有什麼不同？
截圖會失去 computed CSS 的上下文——字型、精確色彩、版面判斷都得從像素重新估算。HTML-to-Figma 是從原始值出發，因此保真度更高、檢查成本也更低。
這能搭配 React 或 Vue 這類框架嗎？
轉換的是渲染後的 HTML，不是框架原始碼。請先把元件渲染成 HTML/CSS（Storybook、靜態輸出、瀏覽器 DevTools 的 "Copy outerHTML"），再餵給它。
Tailwind CSS class 可以嗎？
可以。Tailwind 在執行時會編譯成標準 CSS，因此轉換看到的是一般 CSS 規則。還原出的 Figma 樣式會對應到視覺結果，而不是 class 名稱。
design tokens 會被保留嗎？
CSS custom properties（例如 --brand-primary）會以原始值保留。要對回 Figma design-system tokens 仍需手動整理，不過報告會列出每個不同的 token 值，方便系統化對應。
一定要是完整網站，還是可以只處理單一元件？
兩者都可以。可以餵整頁，也可以只餵一段元件片段。越小、越聚焦的輸入通常會得到更乾淨的結果。
API 可以處理整個元件庫嗎？
可以——請參考 Visual Struct API 的批次端點。