Figma 響應式設計教學：外掛輔助一鍵搞定行動版

為什麼桌機版畫得越漂亮，出手機版時反而越卡？在 Figma 裡把 1440、十二欄網格、留白都調得像雜誌內頁，結果要出 375 的行動版，卻盯著畫板發呆半小時，不知道該從哪一塊開始拆。更痛的是，工程師在交付會議上問你「手機版這個卡片是要堆疊還是橫向捲動」，你才發現自己根本沒想清楚。

答案其實很直接：Figma 沒有真正的「一鍵響應式」按鈕，但你可以用一套固定的斷點策略，搭配 Auto Layout、Constraints 與幾個挑過的外掛，把「桌機轉手機」變成一條可重複、可交接的流程，省下每次從零拼裝的痛苦。這篇要把這條流程拆開來講，包含實務專案會踩到的坑、外掛選擇的判斷邏輯，以及交付前一定要做的三件事。

為什麼 Figma 原生到現在還沒有「一鍵響應式」？先看工具的根本限制

很多人會問，Figma 為什麼沒有瀏覽器那種自動適應的功能。真正的差異在於，設計工具呈現的是設計狀態，瀏覽器則會依 CSS 規則、內容與視窗即時計算版面。

網頁在瀏覽器裡是活的，容器寬度一變，CSS 的 flex 與 grid 會即時重新計算每個元素的尺寸與位置。Figma 的畫板是死的，一個 frame 就是固定像素的快照，你放十個畫板，它就是十張互相獨立的圖。原生功能裡最接近瀏覽器行為的是 Auto Layout 與 Constraints，但它們只是「模擬」一部分 CSS 的邏輯，碰到複雜的重新編排，例如側邊欄在手機要變成抽屜、商品卡從四欄變一欄再加橫向捲動，還是得靠人去決定。

換句話說，Figma 不會像瀏覽器一樣，畫一個版就自動算出所有尺寸的結果。實務上更可靠的做法，是把「如何有效率地產出多個斷點」標準化，再用原生功能與外掛輔助檢查。

先分清楚：響應式設計的三種層次

在進入工具之前，實務上習慣先把響應式拆成三個層次，這樣後面選功能、選外掛時才不會買錯藥：

• 流體層（fluid）：寬度隨視窗縮放，例如整頁寬度的 banner、百分比容器。這層在 Figma 裡用 Constraints 的左右貼齊就能模擬。
• 編排層（layout shift）：欄數改變、區塊前後對調、側邊欄收合。這層是響應式設計最花心力的一層，也是外掛幫得上忙的主戰場。
• 內容層（content swap）：同一個位置，桌機用長圖、手機用短圖；桌機顯示完整文案、手機收合展開。這層通常靠元件變體（variants）與條件式內容處理。

把這三層放在心裡，你之後看到任何一個外掛的宣傳文案，問自己一句「它處理的是哪一層」，就不會被「一鍵搞定響應式」這種話術帶著走。大多數外掛只解決其中一層，沒有銀子彈。

響應式設計是重新編排的功夫：先決定你的斷點策略

最常見的新手誤解，是把行動版當成「桌機版等比例縮小」。這是災難的開始。字縮到 10px 沒人看得見、按鈕縮到 24px 點不到、側邊欄疊在主內容上面把 CTA 擠到第三屏。響應式的本質是重新編排，不是縮放。

決定斷點之前，先看一個事實：根據 Statista 的長期統計（2026 年 4 月），全球行動裝置佔網頁流量的比例長期維持在高檔，這不是一個可以延後再補的版面。

實務上斷點要設幾個、設在哪，應依內容開始擠壓或重排的位置決定；Bootstrap 官方文件的 Grid options（2026）列出的 576、768、992、1200px 可作為參考，不必照抄。若要先建立基本稿，可以從 375（手機）、768（平板）、1280（桌機）三個尺寸開始，再依真實內容補必要斷點。每多一個斷點，都會增加設計、標註、開發與測試成本，因此要有明確理由。

CSS 的 container queries 讓元件能依所在容器的尺寸改變，而不只看整個視窗寬度。設計端可以用元件變體表達卡片在窄容器與寬容器中的行為，再由工程端用 container queries 或其他 CSS 規則落地。重點不是預測工具未來會怎麼改，而是把元件的重排規則交代清楚。

想更系統性理解斷點背後的設計取捨，可以回頭看這篇 AWD 自適應 vs RWD 響應式的完整比較，搞清楚兩種路線後，你會更知道 Figma 在哪一條路上能幫你多少。

桌機優先還是行動優先，這個選擇會決定你整個禮拜的心情

強烈建議是：除非流量數據明確顯示桌機佔比超過七成，否則一律從手機版開始畫。原因很實際，手機版的 375 寬是約束最強的畫板，所有東西都得擠在這裡，在這個約束下做出的資訊層級決策，通常是整個產品最誠實的優先級。把它搬到更大的畫板，是「放寬約束、增加資訊密度」的過程，比反過來容易得多。

如果這個概念對你還有點抽象，響應式網頁設計的基礎觀念這篇有更完整的鋪陳，看完再回來看工具操作會更踏實。

先把地基打穩：Auto Layout、Constraints、Resize，這三個原生功能做對了，外掛才有用

這是最多人想跳過、卻最不能跳過的一步。很多設計師外掛裝一堆，結果 frame 裡全是 absolute 定位、沒有任何 Auto Layout，外掛再強也救不回來。地基沒打，上面蓋什麼都會塌。

把這三個原生功能想像成蓋房子的三種力學：

原生功能	它對應的 CSS 概念	在響應式裡的角色	常見誤用
Auto Layout	flexbox	讓群組內的元素自動排列、自動撐開間距	只在最外層套，內層全用 fixed
Constraints	absolute + 定位錨點	元素相對於 frame 邊界的對齊與縮放行為	設了 Left/Right 卻沒設 Resize，結果只貼齊不縮放
Resize 行為（Hug/Fill/Fixed）	width/height auto vs fixed	決定元素要不要跟著容器變大變小	全部用 Fixed，等於完全關掉響應式

這張表裡的觀念其實就是 CSS 排版的骨架，如果你對 box model 還不夠熟，強烈建議先讀一遍 CSS Box Model 的完整指南，你會發現 Figma 的這三個功能根本就是在視覺化 CSS 的盒模型邏輯，懂了之後操作起來會有一種「啊原來是這樣」的通透感。

特別把 Resize 的三種模式拉出來講，因為它是最容易被誤解的一個。Hug 是元素跟著內容撐開，適合按鈕、標籤這種內容決定寬度的東西；Fill 是元素填滿父容器，適合主內容區、卡片容器這種要跟著斷點伸縮的東西；Fixed 是鎖死尺寸，只在你知道這個元素在任何斷點都不該變形時才用，例如 logo 或 icon。一個常見的錯誤是把卡片設成 Fixed 寬度，結果它在 1280 排得很漂亮，到了 375 卻整排溢出畫面外。記得一個原則：凡是會出現在彈性容器裡的東西，預設就用 Fill，除非有明確理由才鎖 Fixed。

一份必做的地基檢查清單

1. 任何會重複出現的卡片、列表項、導覽項，一律做成元件（component）並套 Auto Layout，不要用群組硬湊。
2. frame 內的主內容容器，寬度設 Fill，不要設 Fixed 數字，這樣換畫板寬度時才會跟著變。
3. 會跟著視窗縮放的圖片，設 Fill + Fill mode，並把外層容器的 aspect ratio 鎖好。
4. 側邊欄與主內容的並排關係，用 Auto Layout 的方向切換（row/column）來處理，避免用兩個 absolute 區塊硬排。
5. 任何間距一律用 Auto Layout 的 gap，不要手動空格，間距才能跟著斷點一致縮放。

這份清單看起來很基本，但能穩定做到的設計師，在多數團隊裡大概只有一半。差別不在天分，在於有沒有人一開始就告訴你「這些細節決定了你後面能不能用外掛量產斷點」。

五類響應式外掛的實戰角色：重點是怎麼選，不是給你排名

網路上「十大 Figma 響應式外掛」這種文章很多，這裡不再給一張排名表，重點是分類邏輯，讓你之後看到任何新外掛，都能立刻判斷它屬於哪一類、要不要裝。響應式相關的外掛，不管名字怎麼取，本質上都落在五類裡。

類型	它解決的問題	適合什麼時候用	它的天限
斷點切換與預覽	同時顯示多個裝置尺寸，快速對照	簡報、客戶確認、自查	只是預覽，不會幫你改內容
自動縮放與搬移	把桌機 frame 的元素搬到手機 frame 並重新套 Auto Layout	大量相似頁面的批次轉換	複雜版面常需要手動修正
裝置框架與真機模擬	把設計包進 iPhone/Android 外殼，含瀏海、安全區域	提案視覺、App 設計	外殼會佔畫面，不適合做排版判斷
回應式元件變體	同一個元件的不同尺寸版本集中管理	設計系統成熟的團隊	前期建置成本高
標註與規格輸出	自動標出 padding、間距、斷點行為給工程師	交付階段	讀懂標註需要雙方有共同語言

選擇原則是這樣：同一類需求先挑一個工具，不必疊到七八個。Figma 的外掛要手動執行，收藏數量本身不會在背景拖慢檔案；真正的成本是團隊學習、權限風險，以及外掛執行後產生的大量圖層或素材。如果你還在摸索階段，先從「斷點切換與預覽」這類入門工具開始，挑選心法可參考 新手設計師的 Figma 必裝外掛清單。

一個挑外掛的判斷句

每次看到一個響應式外掛，都可以問自己同一句話：「這個外掛處理的是前面提的流體層、編排層、還是內容層？」如果它的宣傳影片只示範把整個 frame 等比例放大縮小，那它處理的是流體層，對真正的響應式幫助有限。如果它示範的是「桌機的 sidebar 在手機自動變成抽屜、卡片從四欄變一欄」，那它碰的是編排層，這才是值得投資的類型。把這個問句內建成一個直覺，你會少買很多看起來酷、實際上用不到兩次的外掛。

五個最常見的響應式反模式，與怎麼拆解

工具講完了，下面這張反模式表，整理自審稿、接手他人檔案常見的錯誤，它們有一個共同特徵：在 Figma 裡看不出問題，要等上了真機、或交付後被工程師退稿才會爆開。把這張表貼在你的 workspace 旁邊，比裝十個外掛更能救你。

反模式	在 Figma 裡的樣子	在真機上的後果	拆解方式
桌機思維套到底	375 直接是 1280 的等比縮小	字太小、按鈕點不到、資訊密度失衡	每個斷點獨立設計資訊層級，不只縮尺寸
主 CTA 被擠到第三屏	上方塞滿 banner、輪播、篩選器	轉換率崩盤，使用者根本滑不到	手機版把主 CTA 往上提，次要元素收合
手機版省略重要內容	手機版 HTML 未輸出桌機版的重要資訊	Google 主要從手機版內容建立索引，缺少的資訊可能無法被索引	用收合展開或重新編排，確保重要內容仍有輸出
絕對定位硬排	frame 裡全是 absolute，沒有任何 Auto Layout	換尺寸就錯位，外掛也救不回	全部改用 Auto Layout，地基重做
間距除以二	桌機間距 80，手機直接 40	手機頁面又長又散，滑動節奏破碎	手機用獨立的 spacing token 重新校準

這五個裡面，第三個特別要小心。很多人以為手機版「藏起來」等於「不用做」，但自從 Google 全面採用行動優先索引之後，被你藏掉的內容，等於在 Google 眼裡不存在。這不是設計問題，是 SEO 問題，而它恰恰是設計師最不會主動想到的視角。因此總要提醒設計夥伴：任何「在手機隱藏」的決定，都要跟負責 SEO 的人確認過，否則你可能在不知不覺中把網站的精華內容對搜尋引擎關上了門。

一份可重現的桌機轉手機工作流程：從 375 走到 1280

前面講了那麼多觀念，這裡給你一條實務上穩定可行的流程。它不是唯一正解，但它穩定、可交接、新人來了照著做也不會出大錯。這套流程在電商、內容站、品牌官網、後台介面都適用，流程本身幾乎不用改，只是斷點數字會依專案調整。

第一步：建立斷點 frame 樣板

在一個獨立的 page 放三個標準 frame：375、768、1280，並把它們存成 template。每開新專案，直接複製這組樣板。這聽起來沒什麼，但實務上常見太多團隊每次都自己手動開 frame、畫板寬度還亂設，結果同一個專案裡出現 375、380、360 三種手機寬度，交付時工程師崩潰。標準化的價值，是在這種地方默默幫你省掉溝通成本。

第二步：從最小斷點開始畫主結構

先在 375 裡把頁面的主結構畫出來，只畫骨架：header、主內容、footer，全部用 Auto Layout 的 column 排好。這個階段不要碰視覺細節，只確認資訊層級與流向。實務上習慣在這一步用鉛筆感的灰階，逼自己不去想配色，只看結構。結構對了，後面再漂亮的視覺才有地方掛。

第三步：放大到桌機，做「加法」

把 375 的主結構複製到 1280，這時候是做加法：側邊欄跑出來、卡片從一欄變三欄、banner 變寬。因為底層是 Auto Layout，很多時候你只要把 column 切成 row、把 gap 調大，版面就會自己重排。這也是前面強調地基的原因，地基對了，這一步會快到讓你訝異。

第四步：用外掛做細節微調與對照

結構搞定後，才動用外掛。這時候通常會開斷點預覽類外掛，把三個尺寸並排，檢查有沒有哪個斷點的間距、字級、按鈕大小明顯失衡。以服飾電商的產品列表頁為例，桌機六欄商品卡很氣派，縮到手機時卻可能把促銷 banner、篩選器、商品卡全擠進 375px，主 CTA 被推得太後面。從手機開始常能提早暴露內容優先順序，但仍應依主要使用情境與流量資料決定設計起點。

第五步：元件變體與內容層處理

同一個卡片元件，做桌機版與手機版兩個變體，差異在於圖片比例、文案長度、按鈕位置。這一層是很多人漏掉的，他們以為同一個元件套到底就好，結果手機上的文案把版面撐爆，或桌機上的留白在手機上變成空洞。變體不是偷懶，是承認不同斷點需要不同的資訊密度。

如果你想把這套流程接到更完整的 UIUX 原型方法論上，UI 原型設計的實戰思路可以接著讀，它會幫你把「畫面」跟「互動」串起來，響應式不只是靜態版面的問題，也是互動流程在不同裝置上的重新安排。

響應式圖片是另一個戰場：在 Figma 裡就要想好資產策略

多數設計師把響應式的注意力全放在版面與文字上，圖片卻用一張高解析大圖打通關。如果工程端沒有用 srcset、sizes 或圖片服務提供合適尺寸，手機瀏覽器可能下載遠超顯示需求的檔案，拖慢首屏。響應式圖片需要設計與工程一起決定裁切方式、比例與輸出尺寸。

實務上在 Figma 裡會做三件事來預埋圖片的響應式策略。第一，每張關鍵圖都準備至少兩個裁切版本：一個給桌機的寬幅構圖，一個給手機的直式或方型構圖，因為同一張圖直接縮到 375 寬，主體常常被壓到看不清，這在業界叫 art direction。第二，把每張圖的外層容器鎖好 aspect ratio，並用 Fill 模式讓圖片填滿容器，避免被容器拉伸變形，這樣換尺寸時裁切行為是可預測的。第三，在交付標註裡明確標示這張圖的手機版與桌機版各是哪一張、各自建議的壓縮格式與最大寬度，讓工程師知道要實作對應的 srcset 與 picture 元素。

這些細節會反映在載入效能與使用者體驗上。Google 的排名系統會使用部分網頁體驗訊號，但它們只是眾多訊號之一。圖片最佳化的完整做法可以看 圖片 SEO 最佳化，延遲載入的觀念則在 網站效能的延遲載入機制裡有更深的拆解。設計端先把圖片資產策略想好，工程端才有條件把效能做好。

觸控目標、文字級距、間距：行動版三個最常被放過的細節

流程跑完了，版面也排好了，但魔鬼藏在這三個細節裡。它們不是 Figma 教學會主動講的東西，卻是決定你的行動版「能不能用」的關鍵。這裡把它們獨立成一節，因為這三項是團隊稿子 review 時回退次數最多的項目。

觸控目標至少 44pt，這不是個人主觀建議，而是 Apple 的指引

按鈕、連結與其他可點擊元素，要提供足夠的命中區域。Apple 人機介面指南的 Buttons 條目（2026）可作為設計參考，實際尺寸仍要配合平台、間距與真機測試。很多設計為了「精緻」，把次要按鈕做得太小，實機上容易誤觸相鄰連結。

一個實用的做法：在 Figma 裡把每個可點擊元件的 hit area 用獨立的透明圖層畫出來，這個圖層至少 44pt，視覺元素可以小一點，但命中區域要夠。同樣的邏輯也適用到其他互動元件，滑桿元件的互動規格就是另一個值得單獨核對的例子。這個習慣一開始會覺得麻煩，但它會救你無數次客訴。

文字級距要為斷點重新設計，不是等比例縮小

桌機標題 48px，手機直接縮成 24px 是錯的。手機的閱讀距離比桌機近，加上螢幕小，級距的縮減幅度應該小於寬度的縮減幅度。實務上常用的比例是：桌機到平板，標題縮 75%；平板到手機，標題縮 85%。內文則幾乎不縮，維持 16px 上下，因為內文再小就傷眼了。

這部分的判斷牽涉到字體本身的視覺特性，中文字與英文字的級距感受差很多。如果你做的是中英混排的內容站，這篇 字體與版面配置的設計要點能幫你建立更細的字級判斷框架，響應式字級不是憑感覺，是有方法的。

間距用手機版本的邏輯重新校準

桌機的留白到了手機，通常要縮小，但不能等比例縮。一個常見的錯誤是桌機 section 間距 80px，手機直接變 40px，結果手機上每個區塊之間還是顯得太鬆，頁面變得又長又散。實務上的習慣是手機的垂直節奏壓得更緊，用一套獨立的 spacing token，不要直接沿用桌機的數字除以二。間距的本質是節奏，手機的滑動節奏跟桌機的掃視節奏本來就不一樣。

第三方外掛的維護風險，與避險做法

這一節想誠實講一件很少人提的事：第三方外掛的穩定性，取決於作者的維護意願與 Figma API 的變動，這兩件事都不在你的控制範圍內。實務上常見外掛在某次 Figma 更新後失效一兩週的情況，整個團隊的響應式流程跟著卡住，只能手動硬幹，那陣子的產出效率大概只剩平時的一半。

這樣說無意嚇退你不用外掛，重點是要你把外掛當成「加速器」，把它視為「地基」之上的輔助，別把它當地基本身。地基永遠是原生功能，外掛掛了，你回到 Auto Layout 與 Constraints 還是能交付，只是慢一點。但如果你把整個流程綁死在某一個外掛上，它一掛，你就停擺。這兩種心態的差別，是成熟的設計團隊與新手的分水嶺。

三個避險動作

1. 關鍵流程永遠保留一份「無外掛版本」的走法，哪怕它慢三倍。這份備案存在的價值，是在外掛失效那天讓你還能動。
2. 不把外掛產出的結果當成最終交付物。外掛跑完的 frame，一定再手動過一遍，因為自動化一定會有它判斷不了的邊界情況。
3. 同一類功能至少認識兩個替代品。裝的主要那個壞了，你知道下一步找誰，不會在 panic 裡亂 google 裝到來路不明的東西。

這三個動作看起來保守，但它們讓人能放心地把外掛用滿，因為最壞的情況兜得住。風險管理的本質不是不用工具，是用了之後還睡得著覺。

順帶一提，近年 Figma 自己也往 AI 與自動化的方向走，原生能力一直在補強。如果你想了解官方自己的 AI 工具做到哪裡、能不能取代部分外掛，可以看 Figma AI 功能的完整解析，原生與外掛之間的界線正在移動，這會直接影響你未來的響應式工具選擇。

設計交付前的三件事：裝置預覽、標註、設計 token 對齊

稿子畫完不是結束，是另一段工程的開始。響應式設計的交付，比單一斷點複雜得多，因為你要講清楚「同一個元件在三個尺寸下分別長怎樣、行為怎樣」。這裡是每次交付前必做、也要求團隊必做的三件事。

第一件：真的用裝置預覽，不要只看 Figma 桌面

Figma 桌面端以 CSS 像素呈現設計，但桌機與手機的像素密度、觀看距離和操作方式不同。一個在桌面預覽看起來剛好的按鈕，丟到真機上可能不容易點擊。所以任何要上線的稿，都應用 Figma Mirror 或瀏覽器的裝置模擬，再到真機實際操作。這個步驟能抓出桌面預覽不容易察覺的問題。

第二件：標註要標「行為」，不只是標「數字」

多數人交付標註只寫 padding 是多少、字級是多少。但響應式交付真正該標的是行為：「這個容器在 768 以下從 row 變 column」「這個圖片在 375 時填滿寬度並裁切上下」「這個區塊在桌機顯示、手機隱藏」。數字工程師看得到，行為看不到，而響應式的靈魂就在行為裡。標註類外掛這時候就很有價值，它幫你把這些行為講清楚，省下無數次的 Slack 往返。這些行為描述在交接給 AI 時同樣關鍵，Claude Code 讀 Figma 稿產出 UI 的流程裡，寫得越具體，產出的響應式越接近你的稿。

第三件：設計 token 與開發端對齊

你的間距、字級、顏色，最好都對應到一套命名過的設計 token，而且這套命名要跟工程師的 CSS 變數一致。例如你的 spacing-md，在 Figma 是 24px，在工程的 CSS variable 也叫 spacing-md 也是 24px。這件事的好處是，當斷點切換時，你只要告訴工程師「手機版 spacing-md 改成 16px」，他就知道改哪一個變數，全程不用對照表。建立 token 系統前期辛苦，但它是讓響應式設計能長期維護的關鍵投資。如果你的團隊還沒開始這件事，Figma 完整教學裡對元件與樣式系統的說明是很好的起點。

舉一個具體的命名陷阱讓你感受 token 對齊的價值。很多團隊會用數字直接命名，例如 padding-16、padding-24，這看起來直覺，但會埋下一個炸彈：當手機版需要把 24 改成 20 時，你的 token 名字就跟實際值對不上了，於是又要全局改名，改到崩潰。比較健康的命名是用語意，例如 spacing-section（區塊之間的大間距）或 spacing-inline（行內元素的小間距），讓名字描述用途，不綁死在數字上。這樣手機版的 spacing-section 設成 40、桌機版設成 80，名字不變，工程師只要在一個變數的媒體查詢裡改數字就好。這個觀念看起來是命名學問，骨子裡是讓你的響應式系統能夠演化而不崩潰的結構設計。

響應式設計的最終驗收：看真實手機，別只信 Figma 裡的完美

設計再漂亮，仍要回到使用者在真實網路、真實裝置上的體驗。Google 已全面採用行動優先索引（mobile-first indexing），也就是主要使用手機版內容進行檢索與索引。這是索引方式，不是額外的「手機版排名加分」；如果重要內容只存在桌機版，才可能因手機版缺少資訊而影響可索引內容（見 2023 年 10 月的 Google Search Central Blog 說明〈Mobile-first is here〉）。

這件事對設計師的意義是：你的手機版不只是「順便做做」，它是 Google 認識你網站的主視角。如果手機版的內容被收合隱藏、主 CTA 被擠到第三屏、圖片沒有做好載入優化，這些都會直接反映在搜尋表現上。響應式設計做完之後，務必接著看網站在手機上的實際效能指標，這部分可以參考 Core Web Vitals 與 SEO 的關係，把設計端的響應式與工程端的效能串成一條線，才算真正閉環。

響應式驗收的三個提問

• 用真機滑一遍，主 CTA 在不滾動的情況下看得到嗎？這是行動版轉換的生死線。
• 切換裝置方向（直轉橫），版面有沒有錯亂？很多人只測直向，橫向的 bug 全留給使用者發現。
• 弱網環境下，首屏內容能不能在兩秒內出現？響應式不等於效能好，但兩者會互相綁架。

這三個問題沒有一個是 Figma 能回答的，它們只能靠真機與真實環境驗證。把這一步加進流程，你的響應式設計才從「畫面正確」升級到「體驗正確」。

實務上的習慣是每個專案都準備一支舊一點的手機做測試機，挑兩三年前的中階機就好，不必執著於最新旗艦。原因很實際：你的使用者大多用這個等級的設備，鮮少是設計師手上那支最新款。旗艦機跑起來順的動畫，在中階機上可能卡頓到讓人想離開；旗艦機上一秒載完的圖，在中階機加 4G 網路下可能要五秒。用中階機測試，等於強迫自己看到多數使用者的真實體驗，這個視角是任何設計工具都給不了你的。把測試機當成響應式流程的標準配備，別只當成偶爾為之的儀式，你的行動版品質會有一個明顯的檔次提升。

從這裡開始：一套你可以今天就照做的行動方案

講了這麼多，給你一組可以直接複製到下一次專案的具體動作。這裡把它拆成六步，照著走，你的響應式流程會在一兩個專案內穩定下來。這六步不是憑空發明的，是從一次又一次的交付失誤裡慢慢長出來的，每一步背後都有一個常見的坑。你不需要全部一次到位，但請從斷點樣板與手機優先這兩步先做起，因為它們的槓桿最大、成本最低，卻能擋掉後續八成的問題。

執行的時候有一個心態要先建立起來：響應式流程是團隊資產，不是個人英雄主義。你一個人把樣板、token、外掛流程都跑通了，如果沒有寫成文件、沒有讓團隊一起遵守，下次換同事接手還是會亂。所以這六步的每一步，都建議把這些落成一份簡單的設計規範文件，放在團隊共用的空間。文件不用寫得漂亮，能讓新人照著做不出錯就夠了。流程標準化的真正價值，在於讓你的響應式品質不會因為人事變動而歸零，這個長期效益遠勝於當下省下多少時間。

1. 定斷點：在專案文件第一頁寫死你要做幾個斷點、各是多少寬度。預設是 375/768/1280，除非有明確理由才加第四個。
2. 建樣板：開一個獨立 page 放標準 frame 樣板，團隊共用，禁止任何人自己手開畫板。
3. 依主要情境決定起點：手機流量與任務占比高時，可從 375 起手；桌機工作流明顯更重要時，先畫桌機也合理，但兩端都要及早驗證。
4. 地基先於外掛：所有重複元件套 Auto Layout、所有容器寬度用 Fill、所有間距用 gap。這層沒做完，不准開外掛。
5. 每類外掛只挑一個：斷點預覽、自動縮放、裝置框架、元件變體、標註，五類各一個就夠，多了只會亂。
6. 真機驗收：交付前用 Figma Mirror 在自己手機滑一遍，檢查 CTA 可見性、誤觸、載入感受。

這六步沒有一步是炫技，全部是減少失誤、減少溝通、減少返工的笨功夫。但響應式設計的穩定輸出，靠的就是這種笨功夫，不是某一個神奇外掛。

響應式設計在 Figma 裡之所以讓人挫折，真正的關鍵在於它把「設計」與「工程」的邊界整個攤開來了。你畫的不只是一個畫面，而是一組會在各種尺寸下變形的規則。一旦你接受這個本質，把 CSS 的盒模型邏輯內建進腦袋，把流程標準化，響應式會從最痛苦的環節，變成你最穩的輸出。現在就開一個新檔案，把你下一個專案的斷點樣板建起來吧。別等到設計全部畫完才想手機版，那是最貴也最痛的做法。從樣板、從手機優先、從地基這三件事起步，剩下的會自然跟上。這套流程不會讓你一夕變成響應式大師，但它會讓你每一個專案都比上一個更順，而這才是工程能力累積的真實樣貌。