・縮短「設計」與「代碼」的最後一哩路
在傳統的工作流中,設計師在 Figma 完成高保真設計稿後,需要透過繁瑣的「標註(Spec)」與「交接(Hand-off)」流程給工程師。工程師需要花費大量時間編寫結構與樣式代碼,往往導致時程延宕,或最終產出與設計稿有視覺誤差。
| 比較維度 | ❌ 傳統工作流模式 (Traditional) | 🚀 2026 AI 新一代工作流 (AI-Driven) |
|---|---|---|
| 核心工作流程 |
|
|
| 最終成效與評價 |
核心痛點
|
核心優勢
|
💡 2026 年的根本性變革:
隨著生成式 AI 的成熟,工具鏈已經發生根本性變革。本課將帶領大家認識如何利用 AI 作為橋樑,直接將 Figma 的設計意圖轉化為可運作的網頁代碼,並學會根據專案屬性選擇最合適的技術路徑。
・ 單元重點整理 (Core Lecture Points)
・2026 前端生成生態概覽 (Frontend Generation Ecosystem Overview)
AI 生成網頁工具並非要取代人類,而是根據「視覺需求」與「功能需求」進行分眾,解決不同場景的痛點。我們將現今生態分為兩大主要派別:
| 比較項目 | A. Framer(視覺派) | B. v0.dev(功能派) |
|---|---|---|
| 核心定位 | Designer-Led development | Developer-First AI assistant |
| 目標描述 | 極致視覺與動態的 No-Code/Low-Code 首選。讓設計師能直接發布網頁,無需依賴工程師重寫代碼。 | 由 Vercel 推出,旨在加速工程師構建 UI 的過程,生成的代碼需整合進開發環境。。旨在加速工程師構建 UI 的過程,生成的代碼需整合進開發環境。 |
| 核心技術特性 |
「所見即所得 (WYSIWYG)」與 AI 佈局優化:
無縫轉換:
|
專精於 Prompt 生成技術棧:
代碼質量與邏輯:
|
| 適用場景 |
|
|
・ Figma 原生技術初探
Figma 不甘僅做為設計工具,正積極向「上游(思維導圖)」與「下游(網頁發布)」延伸。
| Figma 原生 AI 技術 | 核心技術原理與定位 | 主要功能與適用範圍 | 效益優點 / 發展限制 |
|---|---|---|---|
| A. Figma Sites 網頁直通車 |
技術本質: 收購部分 No-Code 技術後推出的原生功能。允許用戶在 Figma 內設定好網頁屬性後,直接將 Frame 發布為靜態網頁(Static Site)。 |
適用範圍:
|
發展限制 (2026)
|
| B. Code Layers AI 語意化標記 |
運作原理: 突破傳統 Hand-off 僅呈現 CSS 數值的限制,利用大語言模型 (LLM) 在後台掃描並分析設計稿。 |
核心功能:
|
核心效益與優點
|
| C. Figma Make AI 佈局生成輔助 |
工具定位: 屬前置「輔助整理工具」。無法生成完整網頁,但能幫助設計師快速整理稿件,以便後續匯入 Framer 或讓 Code Layers 解析。 |
核心功能: 針對沒有使用 Auto Layout 的混亂設計稿,選取後點擊 Make AI,AI 會嘗試自動將其轉化為合理的 Auto Layout 結構。 |
核心效益
|
・實作工作坊內容 (Workshop Content)
・ 階段一:專題屬性自我分析
| 階段步驟 | 活動形式與任務 | 具體評估維度(10 分制)與案例路徑 |
|---|---|---|
|
PHASE 1 階段一: 專題屬性自我分析 |
發放表單: 「專案技術路徑分析表」 (含紙本與數位表單) 執行任務: 各組組員共同討論,針對期中提案需求,權衡三大評估項目之比重。 |
📊 三大評估維度(總分 10 分權衡):
|
|
💡 需求案例分類參考 協助組別依專案性質對號入座 |
🎨 視覺導向路徑 (Visual-Oriented Path):
線上藝廊
沈浸式品牌官網
數位產品介紹頁 (Landing Page)
設計師作品集
⚙️ 功能導向路徑 (Functional-Oriented Path):
學生選課系統後台
電商商品篩選後台
FinTech 數據儀表板
活動報名綜合管理系統
|
|
・ 階段二:技術路徑決策 (Path Decision)
| 階段步驟 | 諮詢活動形式 | 技術路徑決策邏輯與工具建議 |
|---|---|---|
|
PHASE 2 階段二: 技術路徑決策 |
1-on-1 專業諮詢: 由老師或助教與各組進行深度對談。 時間分配: 每組約 5 - 10 分鐘。
評估依據: 依據階段一填寫之「專案技術路徑分析表」分數結果進行討論。 |
🎨 偏向 Framer 路徑
視覺分 > 功能分
適用特徵:時程緊迫,追求極致視覺氣氛、流暢動畫與快速產出高保真可發布成品。
⚙️ 偏向 v0.dev + Next.js 路徑
功能分 > 視覺分
適用特徵:需要處理真實資料 (API) 與狀態邏輯,注重程式碼可維護性,未來有二次開發與擴充需求。
💡 特殊情況:雙高需求 (MVP 策略)
視覺分 ≒ 功能分 (皆高)
執行建議:討論劃定 MVP (最小可行性產品) 範疇。通常建議先從 |
・ 階段三:環境建置任務 (Environment Setup)
| 專題組別與技術路徑 | 主要工具與開發平台 | 環境建置 4 大標準步驟 (SOP) |
|---|---|---|
|
PHASE 3-A 🎨 視覺組路徑 Figma ➔ Framer |
核心工具鏈:
|
|
|
PHASE 3-B ⚙️ 功能組路徑 Figma ➔ v0.dev ➔ Next.js |
核心工具鏈:
|
|
・本週 Milestone 與授課心法整理
🎯 本週 Milestone 與授課心法整理
| 類別單元 | 核心檢核 / 溝通焦點 | 詳細執行細節與指導心法 |
|---|---|---|
|
🏆 本週 Milestone 各組完成確認書與 基礎環境檢查 |
1. 提交決策確認 |
各組完成「專題屬性自我分析」與諮詢後,明確選擇並提交主力 AI 工具鏈決策(二選一):
|
| 2. 開發環境 Check |
老師或助教逐一驗收各組基礎環境開通狀態:
|
|
|
✨ 授課心法 Instructor Notes (教師教學指引) |
2026 年的時代視角 |
講授時務必強調工具的「智慧程度」已非 2024 年早期版本可比擬:
|
| 工具無好壞,只有適不適合 |
不斷向學生強調此核心觀念,避免學生盲目追求新工具而選錯路徑:
• Framer:優點是速度極快、視覺與動畫質感優異,但遇上複雜後端邏輯與 API 易卡關。
• v0.dev:優點是產出代碼結構強且具高維護性,但若要微調出極致視覺動畫非常耗費工程。 |
|
| 工作坊 1-on-1 的諮詢關鍵 |
諮詢時務必引導學生誠實面對「專案的核心價值」:
|
・作業與交付物整理 (Homework & Deliverables)
本週作業
| 作業項目 | 適用組別 | 具體執行內容 | 應繳交付物與驗收標準 |
|---|---|---|---|
|
作業 01
專題技術路徑 分析與決策確認書 |
全組通用 |
1. 組員共同討論並填寫「專案技術路徑分析表」,完成三項指標評分(視覺、資料、時程)。 2. 參加 1-on-1 諮詢對齊需求,明確鎖定專題主力 AI 工具鏈(Framer 或 v0.dev)。 |
📄 繳交項目:
|
|
作業 02-A
Framer 環境建置 與轉譯測試驗收 |
🎨 視覺組 Figma ➔ Framer |
1. 開通並建立 Framer 團隊專案。 2. 在 Figma 安裝 Figma to Framer 官方外掛。3. 選取專題 Figma 稿件中至少一個 Section 區塊,透過外掛複製並貼入 Framer。 4. 檢查 Auto Layout 還原度與字型樣式。 |
🔗 繳交項目:
|
|
作業 02-B
Next.js 本地環境 與 v0.dev 生成測試 |
⚙️ 功能組 Figma ➔ v0 ➔ Next.js |
1. 註冊並開通 Vercel / v0.dev 帳號。 2. 本地電腦執行 pnpm dlx create-next-app 初始化專案並啟用 Tailwind CSS。3. 在 v0.dev 輸入基礎 UI Prompt (如 Login Card) 並切換至 Code 模式 檢視 JSX 代碼。 |
💻 繳交項目:
|