難度
中階
所需時間
60–120 分鐘
你需要準備
Gemini Canvas · Figma Design · html.to.design（可選） · Figma Make（可選） · 桌面瀏覽器
開始之前
- 可登入 Gemini Apps，並能在提示列選擇 Canvas；實際功能和使用限額以帳戶畫面為準
- 有 Figma 檔案的編輯權限；若使用 Figma Make 或 Copy design，先核對目前 plan、seat 和管理員 AI 設定
- 只使用自己擁有、獲授權或可合法重用的參考圖、字型、相片、圖示和品牌素材
- 先以虛構資料製作原型，不上載客戶資料、未公開產品畫面、密碼、token 或公司機密
- 能閱讀基本 HTML／CSS／React 結構；不需要由零編寫前端，但要能辨認外部依賴和明顯錯誤
想把 AI 生成的畫面真正帶入產品設計，關鍵不是「生成一張像設計稿的圖」，而是建立一條可反覆驗證的流程：輸入合法而清楚的規格 → 產生可運行原型 → 檢查互動和響應式 → 轉成可編輯設計圖層 → 重建元件與設計系統 → 交付驗收。
這段示範包含三個 Gemini Canvas 起點：參考圖、低保真互動 Demo、純文字 brief；最後亦展示 Figma Make。本文會完整重建這些步驟，同時按目前 Google、Figma 和 html.to.design 官方文件修正兩個容易誤會的地方：HTML 轉 Figma 不應被視為保證像素級 1:1，而 Figma Make 的 Copy design 也只是可編輯的靜態狀態快照，不會把互動和設計系統一起帶過去。
先做資料清理：參考圖、流程截圖和 PRD 可能含客戶名稱、個人資料、內部網址、API key 或尚未公開功能。本文只用虛構內容。處理真實項目前，先確認素材權利、公司 AI 政策、Gemini Keep Activity／Temporary chat、Figma AI 和 content training 設定。
一、先選路線：你手上有甚麼輸入？
| 起點 | 最適合 | 主要缺口 | 建議輸出 |
|---|---|---|---|
| 高質素參考圖 | 重建版面、探索相近視覺方向 | 沒有互動、資料和響應式規則 | Canvas 可運行預覽 → HTML → Figma 圖層 |
| 低保真互動 Demo | 已有流程，想快速提升視覺質感 | 截圖不能表達全部行為和狀態 | 一張狀態圖 + 流程表 + 視覺 tokens → 原型 |
| 文字 brief／PRD | 由零探索資訊架構和功能 | 容易含糊，AI 會自行補假設 | 結構化規格 → 分頁／分狀態生成 |
| Figma 檔案與團隊設計系統 | 希望留在 Figma 內建立功能原型 | 受 seat、plan、credits 和 AI 設定影響 | Figma Make → Copy design → Design 整理 |
三條路線不是互相排斥。成熟做法通常先用文字定義目標和狀態，再以一至兩張參考圖約束視覺；若已有設計系統，則把 components、tokens 和 guidelines 放在生成之前，而不是等結果出現後才要求 AI「變得一致」。
二、方法一：參考圖 → Gemini Canvas → 可運行 UI
步驟 1：整理一張可用的參考圖
- 確認你有權使用圖中的版面、相片、圖示、字型和品牌元素。
- 刪除姓名、電郵、電話、帳戶餘額、內部網址和識別碼；用虛構資料替換。
- 記錄截圖原始 viewport，例如 390 × 844；不要只寫「手機版」。
- 標示這是「盡量重建版面」還是「只參考風格」。兩者的驗收準則完全不同。
- 若畫面很長或很複雜，拆成 header、內容、導覽等區域逐一處理。Figma 官方對 Make attachments 的建議同樣是由較小、較少內容的畫面開始。
步驟 2：開 Canvas，連參考圖和規格一起提交
目前 Gemini 官方流程是在 gemini.google.com 的輸入列加入 Canvas；亦可一併上載圖片。界面文字、模型和按鈕位置會更新，不必追求與影片完全相同。
可從以下提示詞開始，再按實際產品修改：
請在 Canvas 建立一個可運行的手機 UI 原型。
目標：重建附件的資訊架構和版面比例；相片和品牌只作位置參考，不要複製商標。
Viewport：390 × 844 px，並在 360／390／430 px 寬度保持可用。
技術：輸出自包含的 HTML、語意化 CSS 和必要 JavaScript；避免不明 CDN。
版面：頂部日期、月曆、今日任務、時間軸、底部導覽。
互動：切換日期、完成任務、加入任務、底部導覽 active state。
狀態：default、empty、loading、error、success、disabled。
無障礙：鍵盤可操作、可見 focus、按鈕有 accessible name、文字對比清楚。
資料：只使用虛構名稱和內容。
先列出你從參考圖推斷的規格和仍需假設的項目；我確認後才產生程式碼。最後一句很重要：先讓模型分開「畫面可觀察事實」與「它自行補出的假設」。例如參考圖看見底部五個圖示，不代表它知道每個 tab 的內容，也不代表中央按鈕一定是新增行程。
步驟 3：先讀 Code，再看 Preview
Gemini 官方 Canvas 文件列明，可在右上角開 Code 直接編輯、用 Preview 查看 app，並開 console 找錯誤和 logs。第一輪檢查以下項目：
- 是否把整個介面塞成一張背景圖，還是真正有文字、按鈕、列表和容器？
- 是否偷偷使用不可控的 CDN、外部相片、追蹤 script 或未核對授權的 icon package？
- 同一內容是否在 HTML 和 JavaScript 重複硬編碼？
- 按鈕是否真能操作，還是只畫出游標和 hover 效果？
- 在 360、390、430、768 和 1440 px 是否溢出、遮擋或失去導覽？
- console 是否有 missing asset、runtime error 或無限 re-render？
步驟 4：用驗收差異迭代，不用「再像一點」
每次只處理一組差異，並給可量度條件。例如：
只修改月曆區域，不改動任務列表：
1. 卡片寬度 342 px，左右 padding 24 px。
2. 日期格使用 7 欄等寬 grid；每格最小點按區 44 × 44 px。
3. selected、today、has-event、disabled 四個狀態要可辨識。
4. 390 px 以下不准出現水平捲動。
5. 用鍵盤 Tab 可到前後月份和每個日期，focus ring 不可被裁切。
完成後列出修改檔案、狀態和測試結果。這比「完全 1:1」更可驗收。像素差異可以量度，但文字換行、字型 fallback、瀏覽器渲染和動態內容本來就會改變；產品設計要確認的是規則是否穩定，而不是只對齊單一截圖。
三、把 Canvas 輸出保存成可檢查 HTML
影片把 Canvas Code 全選、貼到 Sublime Text，再以 .html 儲存。這可以快速建立本機測試檔，但請先判斷輸出類型：如果 Canvas 產生 React、模組化檔案或 build tool 專案，把單一 code panel 存成 HTML 未必能運行；不要為了方便而刪除 imports 或把所有內容硬塞到一個檔案。
儲存前檢查
- 完整性：有沒有
<html>、<head>、viewport meta、CSS 和必要 script？ - 資源：相片、字型、SVG 和 CSS 是 data URL、本機相對路徑，還是需要登入的外部網址？
- 安全：搜尋
fetch(、script src、token、analytics 和未核對網域。 - 可重現：保存生成日期、使用模型、原始 prompt、參考圖版本和修改紀錄。
- 本機測試：以瀏覽器直接開檔，檢查 console；需要 module／fetch 時用受控的 local dev server，不要關閉瀏覽器安全設定。
四、HTML → Figma 可編輯圖層
影片使用 html.to.design。供應商官方文件目前提供幾條入口：在 Editor／Code tab 直接貼 HTML 與 CSS、在 File tab 上載 .html／.htm／.zip，或以 URL／browser capture 匯入頁面。File 文件亦明確提醒，HTML 引用的外部圖片、CSS 或 JavaScript 若不存在或不可公開存取，可能無法完整匯入。
建議匯入次序
- 在新 Figma 草稿檔建立獨立 page，例如
AI import — raw。 - 只從官方 Figma Community／供應商網站安裝 plugin，核對名稱、開發者、權限和目前收費。
- 若是自包含 HTML，優先試 Code／File；若有複雜外部資源，在你有權限的情況下考慮官方 capture 方法。
- 選明確 viewport，先匯入一個手機尺寸，不要同時產生大量未驗收 breakpoint。
- 匯入後立即 duplicate 一份 raw snapshot；在另一份做清理，方便比較。
不要把「可編輯」等同「可交付」
| 匯入結果 | 仍要做的設計工作 |
|---|---|
| 每段文字可選 | 建立 title／body／caption styles，處理繁中 fallback 和 line-height |
| 容器是 frame | 改成合理 Auto layout、padding、gap、hug／fill 規則 |
| 按鈕外觀完整 | 建立 default／hover／focus／pressed／disabled／loading variants |
| 顏色看似一致 | 建立 semantic variables，例如 surface、text、border、accent、danger |
| 圖示可見 | 核對 license、vector bounds、stroke、accessible label 和一致尺寸 |
| 手機 frame 正確 | 定義 desktop／tablet／mobile breakpoint 和內容重排規則 |
| 一張畫面相似 | 補齊 empty、error、success、long content、permissions 和 edge cases |
五、方法二：低保真互動 Demo → 視覺化原型
低保真 Demo 比單張參考圖多了一層流程資訊，但上載到 Canvas 的仍通常只是一張或數張截圖。AI 看不到你沒有提供的點擊路徑、條件分支和資料更新，因此要把 Demo 分解成「狀態清單 + 轉移規則」。
先製作流程表
| 目前狀態 | 使用者動作 | 下一狀態 | 要保留的資料 |
|---|---|---|---|
| 首頁 | 選擇「山區」 | 已篩選首頁 | category=mountain |
| 首頁 | 按收藏 | 卡片已收藏 | item id、登入狀態 |
| 卡片列表 | 開啟目的地 | 詳情頁 | 來源列表位置、選中 id |
| 詳情頁 | 網絡失敗 | 錯誤狀態 | 重試 action、已載入摘要 |
| 任何頁 | 切換 tab | 對應主頁 | 各 tab 捲動位置 |
把主觀風格字轉成 tokens
「年輕、活力、國際化」太寬泛。改為可驗收規格：主色、輔色、中性色、圓角、陰影、字體層級、圖片比例、icon style、motion duration，以及不想出現的元素。品牌團隊最好直接提供 approved tokens。
視覺方向：清爽旅遊工具，不使用玻璃擬態和高飽和漸層。
顏色：primary #6D28D9；accent #F97393；surface #FFFFFF；text #111827。
圓角：卡片 16 px、按鈕 12 px；shadow 只用一級。
字體：繁中以系統無襯線；標題 28/36，內文 16/24，caption 13/18。
圖片：卡片 16:10，保持 cover crop；必須有 loading skeleton 和失敗 fallback。
導覽：五個 tab，active 不可只靠顏色；中央 action 要有文字 accessible name。
互動：200 ms ease-out；尊重 prefers-reduced-motion。
輸出：先做 390 px 首頁 default／loading／empty／error 四個畫面。這條路最適合前期設計探索和與產品團隊溝通，不適合把第一輪輸出直接當成 final UI。先評估資訊層級和操作流，再決定是否值得把某個方向整理成完整設計系統。
六、方法三：文字 brief → 完整 UI 原型
純文字的優點是沒有舊介面限制，缺點是模型會填補所有未寫清楚的空白。影片使用「頂部區域、內容區域、底部 tab、視覺風格」四段模板；以下把它擴展成可交付版本。
產品：香港週末活動探索 App
目標：讓使用者在 3 分鐘內找到、比較並收藏活動。
主要使用者：18–45 歲手機使用者；繁體中文為預設，可切英文。
平台：mobile-first web app；基準 390 × 844 px；支援 360–1440 px。
一、資訊架構
1. 探索：搜尋、日期、地區、類別、活動列表
2. 收藏：已收藏活動、移除、空白狀態
3. 行程：按日期編排、衝突提示
4. 訊息：系統通知和已讀狀態
5. 帳戶：語言、通知、私隱和登出
二、首頁內容
頂部：搜尋、目前地區、篩選器
卡片：圖片、標題、日期、地點、價格、標籤、收藏
排序：相關度／日期／距離／價格
分頁：載入更多；保留返回後的捲動位置
三、互動與狀態
每個主要區域提供 default、loading、empty、error、success、disabled。
搜尋要有無結果和清除；篩選要顯示已套用數目；登入前收藏要有清楚提示。
四、視覺 tokens
列出 semantic colors、8 px spacing scale、type scale、radius、shadow、icon style。
active、error、warning、success 不可只靠顏色表達。
五、內容與資料
只用虛構活動。長標題、缺圖、免費、售罄、跨日和中英混排都要測試。
六、無障礙與效能
語意標題、label、44 × 44 px 點按區、鍵盤、focus、對比、reduced motion。
圖片有尺寸和 lazy loading；避免 layout shift。
輸出次序：
先回覆頁面地圖、資料 schema、假設和問題；我確認後才逐頁生成。
每次只生成一個頁面及其狀態，並附驗收清單。七、Figma Make：更直接的 Figma 原生路線
影片後段亦展示 Figma Make。根據 Figma 目前官方文件，Make 可以從 prompt、Figma designs、images、text files 和其他 context 生成 functional prototype／web app；圖片可作 style reference 或 embedded asset。官方建議要明確說明是精準重建還是只取風格、先做 layout 再加功能、逐步迭代，複雜畫面要一至兩張逐批加入。
目前的建議步驟
- 在 Figma file browser 建立 Make file；若沒有入口，核對 plan、seat、管理員 AI toggle 和目前 rollout。
- 加入一個清楚 brief；有設計系統時加入相關 library／guidelines，不要一次把整個產品倒進 context。
- 只要求第一個核心畫面和 default state；完成後再加 interaction。
- 使用 Point and edit／prompt 指向具體區域修正；不要每次重新生成全頁。
- 在 Preview 到達要交付的狀態，例如某個 tab、modal 或 expanded menu。
- 按目前官方說明使用 Copy design，等待轉換完成，再到 Figma Design 貼上。
- 每個關鍵狀態分別複製；貼上後建立 components、variants、variables 和 prototype connections。
八、Gemini + HTML 匯入，還是 Figma Make？
| 比較 | Gemini Canvas → HTML → Figma | Figma Make → Copy design |
|---|---|---|
| 最適合 | 想用 Gemini 迭代、查看 HTML／React、跨設計與開發探索 | 團隊已在 Figma，想由 prototype 狀態直接得到圖層 |
| 中間格式 | HTML／CSS／JavaScript 或 React code | Make functional prototype／web app |
| 進入 Design | 第三方 HTML import／capture | 官方 Copy design |
| 圖層結果 | 視工具、HTML 和資源而異 | 目前預覽狀態的可編輯圖層 |
| 互動是否保留 | 一般不會自動變成 Figma prototype | 官方明確說明不保留 |
| 設計系統 | 要人工映射 components／tokens | 官方明確說明不會自動綁定 |
| 主要風險 | 外部資源失效、轉換差異、plugin 權限 | plan／credits、長 context 漂移、快照誤當最終稿 |
選工具時不要只比較「第一張圖誰較漂亮」。請用同一份 brief、同一組狀態和同一驗收表，記錄達標前需要多少 prompt、多少人工修正、圖層清理時間、可重現性和團隊權限成本。
九、發布前的四層驗收
1. 資訊與內容
- 每頁只有一個清楚主要任務；標題、CTA 和內容層級一致。
- 長繁中、英文、數字、價格、日期、空值和缺圖不會破版。
- 示例內容明確標示為 dummy data，不包含虛構的真實品牌背書。
- 搜尋、篩選和排序的定義一致，返回頁面後保留必要狀態。
2. 視覺與響應式
- 在 360、390、430、768、1024、1440 px 實測，不只拖動 Figma frame。
- 文字使用 tokens，不出現大量 13、14、15、16 px 任意值。
- 卡片、button、input、nav 有統一 spacing、radius 和 state。
- 圖片有固定比例、裁切規則、placeholder、失敗 fallback 和來源／license。
- 內容重排規則清楚；不是把手機 UI 無限放大到 desktop。
3. 互動與無障礙
- 每個 action 有 default、hover、focus、pressed、disabled、loading、error、success。
- 鍵盤可完成主要流程，focus 順序合理，modal 能關閉並把焦點送回觸發點。
- icon-only button 有 accessible name；圖片有適當 alt 或標記為 decorative。
- 文字和控制項對比足夠；active／error 不只靠顏色。
- touch target 建議至少 44 × 44 px；動態效果尊重 reduced-motion。
4. 工程、安全與交付
- 生成 code 經 lint、typecheck、依賴、license、XSS、secret 和 network request 審查。
- 不把 API key 寫在前端，不用公開 link 儲存私人或跨使用者資料。
- Canvas 官方安全文件提醒，分享 app 的 public link 和 multi-user data 要特別小心；測試 app 不處理密碼或付款資料。
- 交付包括：Figma source、raw import snapshot、清理後元件、tokens、狀態矩陣、內容 schema、prompt 版本、測試結果和已知限制。
十、常見失敗與修正
| 症狀 | 常見原因 | 修正 |
|---|---|---|
| Canvas 很像參考圖，但按鈕沒有作用 | 只描述外觀，沒有狀態轉移 | 提供 flow table、action、next state 和持久化規則 |
| 手機好看，desktop 大量空白 | 只給單一 viewport | 寫明 breakpoint 和重排，不只要求「responsive」 |
| HTML 匯入後圖片消失 | 相對路徑、登入、CORS 或 hotlink | 先在乾淨瀏覽器驗證資源；按授權本地化或用官方 capture |
| Figma 圖層很多但難以修改 | 絕對定位、無 Auto layout、命名混亂 | 保留 raw import；重建主要 components 和 semantic variables |
| 第二輪生成令其他區域走樣 | 指令範圍過大、context 累積 | 鎖定區域、列出不得修改項目；Figma Make 可按官方流程清理 context |
| Copy design 後不能點擊 | 把靜態 snapshot 誤當 prototype | 逐狀態複製並在 Design 重建 prototype connections |
| 生成圖很漂亮但不能開發 | 欠缺 data schema、edge cases 和 acceptance criteria | 先補狀態矩陣和真實內容，再交工程估算 |
十一、一個可重複使用的團隊工作流
- Brief review：產品、設計、工程先確認目標、資料、狀態和禁止事項。
- Input sanitisation：移除私隱和機密，核對素材權利。
- Prototype pass：用 Canvas 或 Make 每次生成一頁、一個狀態。
- Functional QA：瀏覽器實測 flow、viewport、console 和 network。
- Design extraction：HTML import 或 Copy design，保留 raw snapshot。
- System pass：建立 tokens、components、variants、Auto layout 和 naming。
- Accessibility pass：鍵盤、focus、對比、labels、reduced motion 和長內容。
- Engineering review：決定哪些 code 可參考、哪些必須重寫；記錄依賴和授權。
- User test：以任務成功率和錯誤點評估，不以「像不像 AI 圖」作結論。
- Versioned handoff：保存 prompt、參考圖、輸出、修改、測試和批准人。
AI 可以把第一個可討論版本提前，但真正節省時間的不是一次生成，而是把模糊想法轉成可驗收規格。當每個畫面都有狀態、每個元件都有規則、每次轉換都有 QA，參考圖、Demo 和文字 brief 才能穩定地走到可編輯、可合作、可開發的設計稿。
資料來源與引用
我們附上第一手及官方來源，方便你逐一核實。
- 1.Create docs, apps and more with Canvas — Google Gemini Apps Help
- 2.New ways to collaborate and get creative with Gemini — Google
- 3.Canvas safety & security in Gemini Apps — Google Gemini Apps Help
- 4.Gemini Apps Privacy Hub — Google Gemini Apps Help
- 5.Import HTML/CSS code — html.to.design
- 6.Import local files — html.to.design
- 7.Create and edit a functional prototype or web app — Figma
- 8.Attach designs and images to a prompt — Figma
- 9.Copy a Figma Make preview as design layers — Figma
- 10.Manage AI settings and content training — Figma
常見問題
Gemini Canvas 生成的是 Figma 設計稿嗎？
不是。Canvas 生成及預覽的是文件、程式碼或 app；影片所示流程先取得 HTML／CSS，再透過第三方工具轉成 Figma 圖層。轉換後雖可編輯，仍要人工建立 Auto layout、元件、variants、variables、文字樣式和設計 token。
一張參考圖能否真正 1:1 還原？
不要把 1:1 當保證。一張截圖欠缺原始字型、DOM、不同 viewport、hover／focus、內容長度、圖片裁切和互動規則。你可以提高接近度：寫明目標尺寸、量度間距和字級、提供合法素材、逐區重建，並以 overlay 或像素差異檢查；最後仍需人工驗收。
應用 html.to.design 的 Code、File 還是 URL 路線？
若 Canvas 輸出是可自成一頁的 HTML／CSS，可在 Code tab 貼上；本機有完整 .html、.htm 或 .zip 時可用 File tab；已部署頁面則可用 URL。官方文件提醒，本機 HTML 的外部圖片、CSS 或 JavaScript 若不可公開存取，未必能完整匯入。私人頁面要按工具文件使用授權 capture 流程，不要把登入內容變成公開網址。
甚麼情況應直接使用 Figma Make？
團隊本身在 Figma 工作、需要快速建立功能原型，又希望把某個預覽狀態直接複製到 Design 時，Figma Make 通常少一個 HTML 轉換步驟。若要比較其他生成模型、直接檢查 HTML／React 或先在 Gemini 迭代內容，Canvas 路線仍有價值。實際選擇亦受 plan、seat、AI 設定和使用限額影響。
Figma Make 的 Copy design 會保留互動嗎？
不會。Figma 官方說明，複製的是目前預覽狀態的設計圖層；圖層不連回 Make、不是互動原型，也不會自動綁定你的 design system。每個重要狀態要分別導出，並在 Design 重新建立元件和 prototype connections。
參考圖有客戶資料，可否直接上載？
不建議。先用虛構名稱、遮蓋個人資料、移除內部網址和識別碼，並確認合約及資料分類允許使用雲端 AI。Gemini 的提示、檔案和活動處理受帳戶設定影響；Figma 亦有團隊 AI 和 content training 設定。公司項目應先由管理員、私隱或法務確認。
為甚麼圖片、圖示或字型匯入 Figma 後會失效？
常見原因包括資源使用相對路徑、需要登入、CORS／hotlink 限制、字型未安裝、icon 由 JavaScript 動態產生，或 HTML 只引用線上 CDN。先在無痕瀏覽器直接開測試頁，確認所有資源可讀；再把必要資產本地化或使用有權限且穩定的公開來源。
AI 生成的 UI 可以直接交給工程團隊嗎？
只可作為經驗收的原型或起點。交付前至少要補齊元件狀態、響應式規則、design tokens、內容 schema、錯誤／空白／載入／成功狀態、鍵盤操作、焦點順序、對比、真實資料限制、事件追蹤和驗收準則。生成程式碼亦要經過依賴、安全、效能和授權審查。
本文遵循我們的 編輯準則.
關於作者
HK Learn AI 編輯部
HK Learn AI 編輯部負責研究、查證同編寫每一篇內容，並引用官方及第一手來源。
此主題相關文章
Gemini SVG 動畫教學：用自訂 Gem 與 Canvas 製作互動教材
由建立自訂 Gem、撰寫可重用指令、啟用 Canvas、選擇 Gemini 3.1 Pro，到生成地球季節、幾何與科學互動動畫。本文補上 prompt 範本、內容驗證、SVG／HTML 程式檢查、無障礙、私隱與分享安全清單。
ChatGPT Plus vs Pro：Codex 額度、5 小時限制與 Credits 實際比較
Plus 每 5 小時不是固定 200 次。本文按 OpenAI 最新官方資料，比較 Plus、Pro 5x、Pro 20x 的價格、模型用量範圍、每週上限、credits 和香港用家升級方法。
Codex 生圖完整教學：用 $imagegen 寫提示詞、評圖、局部修圖與素材歸檔
把一段 9 分鐘 Codex 生圖示範整理成可複製的工作流程：先定義用途、主體、風格、比例與限制，再設定可重用規則、調用圖片生成、逐項評圖、只修改有問題的局部，最後保存原圖、提示、版本和成品路徑。附去識別截圖、七段短片與目前官方做法修正。