
2026 AI 設計趨勢報告:當設計師開始「寫規則」,而不只是畫畫面
91% 設計師每週用 AI、一半把成品程式碼推上線。對照《AI in Design Report 2026》兩份章節與我們的真實專案:設計師如何從畫畫面,變成把判斷寫成 AI 讀得懂的規則。
先講一個數字:91%
2026 年 6 月,設計創投 Designer Fund 與 Foundation Capital 發布了第二屆《AI in Design Report 2026》,訪談了來自 60 多個國家、906 位設計師(其中六成擁有 10 年以上設計資歷),得到一組讓人很難忽視的數字:91% 的設計師現在每週都用 AI 工作、75% 每天都用,而且有一半的人,已經把 AI 生成的程式碼推上了正式環境。一年前,每週使用的比例還只有 54%。
換句話說,這不是一個「未來會發生」的趨勢,而是「已經發生」的現實。過去這段時間,我們替一個公部門單位改版一套大型表單系統——欄位龐雜、規則彼此牽動,又有嚴格的法規與一致性要求。在這個專案裡,我們幾乎把報告描述的每一條趨勢,都親身走過了一遍。
基於保密協定,這篇文章不會出現任何客戶名稱、真實畫面或資料——但這恰好不影響重點。因為報告最有價值的發現,從頭到尾都不在「做出了什麼畫面」,而在設計師「怎麼工作」這件事本身。
設計師正在變成 toolmaker,而不只是工具使用者
報告的工具篇(Tools)有幾條很關鍵的線:78% 的設計師使用 Claude、65% 使用 Claude Code,AI 編碼工具首度超越過去的通用工具王者;設計師的工具箱也從平均 3 個膨脹到 7 個。但最關鍵的一句話是——設計師正在從「使用工具的人」,變成「製造工具的人(toolmaker)」。
設計師從「用工具」變成「做工具」,正是我們整個專案的核心做法——但一開始並不是。專案初期,我們也是老老實實地用 Figma 和 Pencil 一張一張畫畫面。問題是,這個案子從設計到開發完成只有短短幾個月,期間除了畫圖,還得不斷和業主來回協調、訪談、修改需求,而最後做出來的前端畫面,還要能接上真實的後端資料。在這種時間壓力下,「一張畫面一張畫面慢慢畫」很快就撐不住了。
於是我們換了個做法:與其畫每一張畫面,不如先把設計系統與設計判斷本身,寫成一份 AI 讀得懂的規則。這些原本只存在資深設計師腦袋裡的「品味與默契」,被一條一條外顯成可執行的規範。
舉幾個例子,這份「判斷 → 規則」大概長這樣:
| 原本靠「感覺」的設計判斷 | 固化成可執行的規則 |
|---|---|
| 這裡的藍色該用哪個藍? | 一律使用設計變數 --primary,禁止隨手寫死色碼 |
| 內文、標題各該多大? | 字級走固定階層:內文 --font-size-md、標題、輔助文字各有對應變數 |
| 間距抓多少才對? | 一律走 8px grid 的 --spacing-*,不憑感覺填數字 |
| 圓角、陰影怎麼給? | 統一用 --radius-* 等設計變數,不逐處微調 |
| 表單欄位用什麼元件? | 一律用共用元件(下拉、日期、單選…),不混用原生 HTML 元素 |
| 資料要用表格還是卡片? | 欄位 ≥ 5 欄就改用卡片,不硬塞成橫向表格 |
有了這份規則,AI 產出的每一個畫面,顏色、間距、元件就天然一致——一致性不再靠人一個個盯,而是寫在規則裡。
於是 AI 不再是「幫我畫一張圖」的工具,而是「讀我的設計系統、照我的規則產出」的協作者。這其實呼應了我們先前的一個觀點:設計系統真正該整理的,不是元件,而是判斷方式。
交付的是「能動的原型」,不是靜態稿
報告的工藝篇(Craft)講得更直接:50% 的設計師已經把 AI 生成的程式碼推上正式環境;43% 的公司現在期待設計師交出「能動的原型」,而不是靜態 mockup。一位受訪設計師的話很傳神:「做一個原型可能要花兩週,但花兩週的並不是『想清楚』,而是要花工夫使用工具,把每一個必要的細節做到位。」
我們的專案也走過同樣的轉變。前面提到,最初我們是用 Figma 和 Pencil 畫靜態稿;但很快就發現,靜態稿只能讓人「看」表單長什麼樣,看不出實際「用起來」會發生什麼。於是交付物逐漸從靜態稿,轉向可互動的高保真原型——能點、能切換狀態、能走完整個流程。可互動原型能讓人「用」,那些藏在流程裡的狀態、條件顯示、邊界情況,就在做的當下被逼出來、被討論、被修正,而不是等到開發後期才爆炸。
實際上,很多問題是「點下去」才看得到的:
| 靜態稿看不出來的 | 可互動原型當下就驗到 |
|---|---|
| 沒有資料時,畫面長怎樣? | 空狀態、載入中、錯誤狀態 |
| 選了「有」之後才出現的欄位 | 條件欄位顯示是否合理、會不會擠 |
| 表單填錯會發生什麼? | 即時驗證、錯誤提示的位置與時機 |
| 資料很多的時候呢? | 分頁、捲動、表格會不會爆版 |
這些都是靜態稿上「看起來沒問題」、真的用下去才會發現的細節。提早做成能動的原型,等於把問題從開發後期搬到設計階段解決,省下的往往是整個團隊的時間。
還有一個我們在這個專案裡很有感的好處:業主常常不希望只看到「一種設計」,而是想在 demo 當下比較不同呈現、再決定哪個適合。可互動原型剛好能滿足這件事——同一筆資料,現場一鍵切換不同版型給對方挑,而不必事先備好一疊靜態稿、改一版就重畫一次。例如同一份列表,就能在「表格」和「卡片」之間即時切換,讓業主自己選:
親自試試:這不是截圖,是能點的原型——切換「表格 / 卡片」看同一筆資料怎麼換版
| 項目名稱 | 日期 | 地點 | 類別 | 狀態 |
|---|---|---|---|---|
| 春季公益講座 | 115/3/15 | 文化中心 2F | 講座 | 報名中 |
| 社區親子工作坊 | 115/4/2 | 市民活動中心 | 工作坊 | 已額滿 |
| 假日健走活動 | 115/4/20 | 河濱公園 | 戶外 | 籌備中 |
欄位 ≥ 5 欄 → 改用卡片設計。手機上表格會擠,卡片更好讀——這條判斷寫進規則後,AI 產出時就會自動套用。AI 不會替你做判斷:速度與品質的拉扯
報告沒有把這件事講得太浪漫,我們也不想。工具篇(Tools)誠實點出:62% 的設計師認為「output 不一致」是最大障礙;工藝篇(Craft)則說,80% 的設計師,品質與創意方向最終仍然靠自己的判斷。換句話說,AI 把「執行」加速了,但「要做對的東西」這件事,還是人的責任。
這也是那份規則文件真正的用途——它不只是給 AI 的指令,更是我們把品質「固化」下來、對抗「快,但不一致」的護欄。AI 產得越快,越需要一個明確的標準告訴它「什麼叫做『對』」。而那個標準,是設計師的品味,不是模型的預設值。
實務上,我們會清楚切開「交給 AI」和「人來把關」這兩件事:
| AI 擅長、放心交出去的 | 仍然得由設計師把關的 |
|---|---|
| 照規則套版面、產出重複性高的畫面 | 資訊的優先級:什麼該放大、什麼該收起來 |
| 產生表單、列表、卡片的初版骨架 | 流程合不合理、使用者會不會卡住 |
| 維持顏色、間距、元件的一致性 | 文案語氣、用詞,以及該不該問使用者 |
| 快速做出多個版本讓人挑 | 最終哪個版本對、為什麼對 |
AI 把「做得快」這件事解決了,但「做對的東西」還是人的責任。而且這不只關乎設計師——在 AI 時代,PM、FDE、RD 各自把關的判斷,反而更難被 AI 取代。
至於怎麼把 AI 真正接進產品工作流、而不是只做一個漂亮的 demo,我們在另一篇談得更細。
一張數據快照
把報告裡幾個最有力的數字放在一起看,會更清楚這股浪潮的方向:
| 數據 | 意義 |
|---|---|
| 91% | 設計師每週使用 AI(一年前為 54%) |
| 78% | 設計師使用 Claude |
| 75% | 設計師每天使用 AI |
| 53% | 因為 AI 而工作滿意度提升 |
| 50% | 已把 AI 生成的程式碼推上正式環境 |
| 2 倍 | 會用 AI 出 code、做原型的設計師,覺得自己更有創造力的機率,是「不動手做」設計師的 2 倍 |
這些數字背後其實是同一件事:設計師的價值,正在從「產出畫面」往上移動到「定義什麼是對的」。
把判斷寫下來,是 2026 設計師的新手藝
AI 沒有取代設計,它只是把設計師的價值,從「產出畫面」推到「定義什麼是對的」。當畫面可以被快速生成,設計師唯一不能外包的,就是那份「知道什麼好、為什麼好」的判斷。把這份判斷寫下來、變成規則、交給 AI 去執行——這大概就是 2026 年的設計師,正在學會的新手藝。
Luffy Design 在做的,正是把「設計 × AI 工作流」直接做成能上線的真實產品,而不是停在一份漂亮的設計稿。如果你也想把這套做法用在自己的產品上,歡迎看看我們怎麼做產品,或直接跟我們聊聊。
引用出處
本文數據與觀點引用自《AI in Design Report 2026》(由 Designer Fund 與 Foundation Capital 於 2026 年 6 月發布):
文中所有專案描述均經去識別處理,不包含任何受保密協定保護之客戶身分、畫面、欄位或資料。