Gemini Canvas UI 設計完整教學：由參考圖、互動 Demo、文字 Brief 生成可編輯 Figma 稿

想把 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 設定。

一、先選路線：你手上有甚麼輸入？

三條路線不是互相排斥。成熟做法通常先用文字定義目標和狀態，再以一至兩張參考圖約束視覺；若已有設計系統，則把 components、tokens 和 guidelines 放在生成之前，而不是等結果出現後才要求 AI「變得一致」。

二、方法一：參考圖 → Gemini Canvas → 可運行 UI

步驟 1：整理一張可用的參考圖

1. 確認你有權使用圖中的版面、相片、圖示、字型和品牌元素。
2. 刪除姓名、電郵、電話、帳戶餘額、內部網址和識別碼；用虛構資料替換。
3. 記錄截圖原始 viewport，例如 390 × 844；不要只寫「手機版」。
4. 標示這是「盡量重建版面」還是「只參考風格」。兩者的驗收準則完全不同。
5. 若畫面很長或很複雜，拆成 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 或把所有內容硬塞到一個檔案。

儲存前檢查

1. 完整性：有沒有 <html>、<head>、viewport meta、CSS 和必要 script？
2. 資源：相片、字型、SVG 和 CSS 是 data URL、本機相對路徑，還是需要登入的外部網址？
3. 安全：搜尋 fetch(、script src、token、analytics 和未核對網域。
4. 可重現：保存生成日期、使用模型、原始 prompt、參考圖版本和修改紀錄。
5. 本機測試：以瀏覽器直接開檔，檢查 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 若不存在或不可公開存取，可能無法完整匯入。

建議匯入次序

1. 在新 Figma 草稿檔建立獨立 page，例如 AI import — raw。
2. 只從官方 Figma Community／供應商網站安裝 plugin，核對名稱、開發者、權限和目前收費。
3. 若是自包含 HTML，優先試 Code／File；若有複雜外部資源，在你有權限的情況下考慮官方 capture 方法。
4. 選明確 viewport，先匯入一個手機尺寸，不要同時產生大量未驗收 breakpoint。
5. 匯入後立即 duplicate 一份 raw snapshot；在另一份做清理，方便比較。

不要把「可編輯」等同「可交付」

五、方法二：低保真互動 Demo → 視覺化原型

低保真 Demo 比單張參考圖多了一層流程資訊，但上載到 Canvas 的仍通常只是一張或數張截圖。AI 看不到你沒有提供的點擊路徑、條件分支和資料更新，因此要把 Demo 分解成「狀態清單 + 轉移規則」。

先製作流程表

把主觀風格字轉成 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 再加功能、逐步迭代，複雜畫面要一至兩張逐批加入。

目前的建議步驟

1. 在 Figma file browser 建立 Make file；若沒有入口，核對 plan、seat、管理員 AI toggle 和目前 rollout。
2. 加入一個清楚 brief；有設計系統時加入相關 library／guidelines，不要一次把整個產品倒進 context。
3. 只要求第一個核心畫面和 default state；完成後再加 interaction。
4. 使用 Point and edit／prompt 指向具體區域修正；不要每次重新生成全頁。
5. 在 Preview 到達要交付的狀態，例如某個 tab、modal 或 expanded menu。
6. 按目前官方說明使用 Copy design，等待轉換完成，再到 Figma Design 貼上。
7. 每個關鍵狀態分別複製；貼上後建立 components、variants、variables 和 prototype connections。

八、Gemini + HTML 匯入，還是 Figma Make？

選工具時不要只比較「第一張圖誰較漂亮」。請用同一份 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 版本、測試結果和已知限制。

十、常見失敗與修正

十一、一個可重複使用的團隊工作流

1. Brief review：產品、設計、工程先確認目標、資料、狀態和禁止事項。
2. Input sanitisation：移除私隱和機密，核對素材權利。
3. Prototype pass：用 Canvas 或 Make 每次生成一頁、一個狀態。
4. Functional QA：瀏覽器實測 flow、viewport、console 和 network。
5. Design extraction：HTML import 或 Copy design，保留 raw snapshot。
6. System pass：建立 tokens、components、variants、Auto layout 和 naming。
7. Accessibility pass：鍵盤、focus、對比、labels、reduced motion 和長內容。
8. Engineering review：決定哪些 code 可參考、哪些必須重寫；記錄依賴和授權。
9. User test：以任務成功率和錯誤點評估，不以「像不像 AI 圖」作結論。
10. Versioned handoff：保存 prompt、參考圖、輸出、修改、測試和批准人。

AI 可以把第一個可討論版本提前，但真正節省時間的不是一次生成，而是把模糊想法轉成可驗收規格。當每個畫面都有狀態、每個元件都有規則、每次轉換都有 QA，參考圖、Demo 和文字 brief 才能穩定地走到可編輯、可合作、可開發的設計稿。