Figma 響應式設計卡關診斷：三層病灶與修復順序

先看一個簡化過的情境：週五傍晚，客戶傳來一張手機跑版的截圖，主管要在週一看到修正稿。你打開 Figma 檔，桌機、平板、手機三份畫板各自為政，同一顆按鈕在三個 frame 各長各的樣子，改一處要手動同步三輪，改完還不敢保證沒有漏網。多裝置改版的工時就是這樣疊上去的：斷點越多，每個調整都被乘上一次，時程往往在你打開工具之前就已經緊繃。

這種局面背後常見兩個誤解。一個是把行動版當成桌機稿的等比縮小複製，以為尺寸按比例壓下去就沒事；另一個是認為難點出在缺一個神奇外掛，好像裝了它，多裝置稿就會自己長出來。兩個誤解指向同一個空洞：沒有判斷標準知道這次卡關該修哪裡。外掛能搬運你的結構，不會修理你的結構，把它裝在一份不可變形的稿上，只會更快產出三份對不上的畫面。比較有用的做法是分層診斷，把卡關歸到結構、流程、交付三層之一，先定位層級再對症動手，外掛只在其中一層扮演時間槓桿的角色。

快速重點：稿子不可變形屬結構層，修 Auto Layout、Constraints 與尺寸模式；每個斷點重抄畫板屬流程層，靠樣板與變體收斂；規格含糊被退件屬交付層，把行為講清楚。判斷順序是先定位、再動手，外掛放在結構過關之後。縮放不等於重排，重新編排的判斷在你手上。

先別急著開外掛：三個問題定位你的卡關層

多裝置稿一直出狀況，工具、方法、規格都可能是源頭，先別急著開外掛。用三個是非題把問題定位到結構、流程、交付三層之一，層級對了，修法就對了一半；層級定位錯了，裝再多外掛都只是把爆炸往後延，帳遲早連本帶利算回來。

三層的名字先說清楚，之後每一節各自處理一層：

• 結構債：稿子不可變形。Auto Layout 巢狀沒有套對、Constraints 沒有設，元素一換容器就散開，這種檔案配什麼工具都救不動，工具只會加速產出錯誤。
• 流程債：每個斷點都重抄一份畫板。桌機畫完抄去平板、平板抄去手機，改一個欄位要手動同步三處，抄漏一處就是線上事故。
• 交付債：規格講不清行為。標註只寫間距與字級，工程師只能用猜的，猜錯就退件，來回幾輪時程全毀。

三個是非題這樣問。改一顆按鈕，要動幾個 frame？答案超過一個，結構債已經存在。工程師上次退件，理由是版面還是行為？版面退件多指向結構，行為退件指向交付規格。手機版你是重排還是重畫？每個斷點都從空白畫板重畫，代表流程債正在吃你的週數。三題答完，問題落在哪一層通常已有輪廓，帶著不同症狀進來的讀者，可以從對應的節直接讀起。

分診的價值在商業端最明顯。層級不清楚的團隊，報多裝置專案時程只能憑感覺加乘，怕吃虧就往上墊，墊高了又接不到案；知道痛點在哪一層，時程就能拆開估：結構整建是一次性成本，樣板與變體是半一次性成本，之後每個頁面的邊際成本會降下來。估得出成本，才談得上把多裝置當成服務項目報價，而不是免費附贈的善意。

把 Figma 放回整條響應式鏈看，位置會更具體。設計決策在上游：資訊先後、欄數取捨、導覽收合成什麼形態，都由你決定；瀏覽器與實作在下游：CSS 依規則即時計算版面，不是照著你的畫板縮放。同一個手機版跑版的症狀，在三層的根因長相完全不同，可能是骨架不可變形，可能是三份畫板沒有對齊，也可能是規格從頭就沒講清楚。觀念需要補課的讀者，可以先回頭讀響應式網頁設計的基本盤，或看AWD 與 RWD 兩條路線的差異，知道自己站的路線，才知道 Figma 在這條路上能幫你多少；還在熟悉工具本身的讀者，Figma 的入門操作與元件系統值得先過一遍。

結構層體檢：稿子能不能自己變形

這一層只問一個問題：稿子能不能自己變形。看起來排得好好的 Figma 檔，換個寬度就崩，原因幾乎都在骨架，不在表面。檢查的基準是瀏覽器的行為：網頁是活的，會依規則重算；畫板是快照，不會自己動。稿子的可變形性，必須由你親手蓋進結構裡。

把 Figma 檔和真實網頁擺在一起看，本質差異馬上浮現：瀏覽器是拿規則在跑版面的引擎，容器寬度一改，flex 與 grid 隨即把每個元素的尺寸和位置重新分配一次；Figma 的 Frame 雖能套 Auto Layout 這類規則跟著內容與容器變化，性質上仍不是瀏覽器，各斷點的資訊先後與導覽形態不會被它替你決定好。原生功能裡最貼近 CSS 行為的是 Auto Layout 與 Constraints，重現的卻只是一段邏輯；側邊欄在小螢幕該不該收成抽屜、四欄商品卡併成一欄之後要不要改橫向捲動，這一類重新編排的取捨，工具從頭到尾都交還給人。

把響應式拆成三個層次，觸診時才知道自己在看哪一層。流體層處理寬度隨視窗縮放的容器，Constraints 的貼齊與縮放就能模擬大部分行為；編排層處理欄數改變、區塊對調、側邊欄收合，是心力花最多的一層，也是工具幫不上判斷的一層；內容層處理同一個位置換圖、換文案、換比例，靠元件變體表達。三層共用同一批原生功能，差別在怎麼組合。

巢狀的判斷可以更具體。一張商品卡能不能優雅變形，取決於四層結構的角色：最外層的列表容器決定欄數與換行策略；卡片本身決定內部排列的方向；文字與圖片的容器決定誰跟著誰伸縮；最裡層的 icon 與標籤決定要不要保持原尺寸。任何一層偷懶用群組或絕對定位帶過，上層排得再好，變形到那一層就停住，後面的元素全部擠成一團。排查時從最內層往外測，先把單卡拉寬拉窄各一次，再測列表層，問題在哪一層會自己現形。

原生三個力學的分工，用一張對照表看最快，順便檢查自己是不是正在誤用。

↔ 左右捲動檢視完整表格

原生功能	對應的 CSS 概念	在響應式裡做的事	常見誤用
Auto Layout	flexbox	讓群組內的元素照方向、間距與留白自動排列	只在外層套，內層全是固定尺寸
Constraints	定位與貼齊錨點	決定元素相對 frame 邊界的對齊與縮放行為	設了貼齊卻沒開縮放，寬度一變就錯位
尺寸模式（Hug、Fill、Fixed）	寬高的自動或鎖定	決定元素要不要跟著容器變大變小	全部鎖 Fixed，等於親手關掉響應式

這三個功能骨子裡就是 CSS 排版的視覺化。CSS 盒模型的內外距與邊界觀念弄懂，回頭看 Auto Layout 的 padding 與 gap 會直接打通；觸診時搭配欄網格對照，哪個元件沒落在欄內、哪段間距是手動空格湊的，一眼就能抓出來。欄網格同時是與開發溝通的共同語言，設計端看欄、工程端看斷點，兩邊對得上，來回就少。

特別把 Resize 的三種模式拆開單獨講，誤解多半從這裡開始。Hug contents 把 Auto Layout frame 的大小交給子元素決定；Fill container 僅限 Auto Layout frame 的子元素使用，負責占滿父容器給定的空間；Fixed 則是把尺寸定在指定值。挑的時候分別核對父層排版、兩軸設定、內容長度與最小最大寬度，別把所有會伸縮的元素一律設成 Fill。把卡片寬度釘在 Fixed 是最常見的坑：1280 之下畫面體面，換到 375 就整排被推出螢幕外。卡片究竟用不用 Fill，交給容器結構與斷點需求判斷；需要跟著內容走的元素可用 Hug，尺寸有明確限制時，Fixed 搭配最小最大寬度也是正解。

尺寸模式弄清楚之後，三步觸診照順序做，每一步都有明確的檢查對象。

1. 先看父層排版：這個元素的上一層有沒有 Auto Layout，方向是 column 還是 row，巢狀是否每一層都有。變形能力斷在哪一層，問題就從哪一層開始發作。
2. 再看 X 與 Y 軸：Constraints 貼齊設了左、右還是置中，縮放行為有沒有跟著開。只貼齊不縮放的元素，是寬度一換就走鐘的種子。
3. 第三步看最小與最大寬度：會伸縮的容器有沒有設下限，文字一長或語系一換，沒有下限的容器會把隔壁元素擠出畫面。

三步做完，不可變形的元件會自己浮出來：鎖死的關鍵元件、殘留的絕對定位、手動空格的間距，全都記下來。這份清單先過，稿子能自己變形，後面的流程設計與工具選擇才有意義；跳過這步直接上自動化，等於把歪的地基灌進模組裡。

斷點不是尺寸清單，是內容開始擠壓的位置

斷點的重點不在數字本身，在內容從哪個寬度開始擠壓、開始需要重排。多數商業網站用 375、768、1280 三個尺寸已經足夠，資料密集的後台才需要從桌機起手，再補一版手機退化版。數量與起手方向，用三個軸向決定，不是抄一套別人的清單。

第一軸是流量結構。依Statista 對全球網站流量的長期統計，行動裝置占網頁流量的比例長期維持高檔，對多數面向消費者的網站來說，手機版不是可以延後再補的版面，從小尺寸起手是對流量結構的誠實回應。第二軸是內容型態。表格、儀表板、多欄比較這類內容，在桌機才能展開，從桌機起手合理，但退化版要先設計好，不是上線後再說。第三軸是團隊負荷。一個人的團隊先做兩個斷點上線，第三個補在迭代裡，比一次開四個斷點然後全部延期務實。

三軸交出來的結果可以想成一張簡單的矩陣：行動流量高加上內容以文字與圖片為主，兩個斷點就能上線，第三個補在迭代裡；流量平均加上內容帶表格，三個斷點是基本盤，表格另做退化設計；桌機工作流主導加上團隊有餘裕，才考慮四個。矩陣的用處不是給標準答案，是讓「為什麼是三個」在團隊裡有共同的討論基礎，新成員不用重新踩一輪坑就能理解斷點怎麼來。

數值怎麼定，可以參照別人走過的路而不照抄。Bootstrap 格線系統的文件列出 576、768、992、1200px 幾個欄數切換點，那是它照顧自家格線的選擇；你的斷點應該長在自己的內容上。把稿子從寬往窄拉，看文字在哪裡開始換行換到難讀、卡片在哪裡開始擠到變形、導覽在哪裡開始放不下，擠壓發生的位置就是候選斷點，再把它收斂到離團隊樣板最近的常用值。

每多一個斷點，設計、標註、開發、測試四段成本同時增加，不是只多一張畫板的事。砍掉第四個斷點是商業決策，寫得出可以砍的條件就砍得安心：那個尺寸區間的使用者占比低於你們能接受的門檻、內容在那個區間沒有明顯擠壓、或那個區間可以直接共用相鄰斷點的規則。條件不成立就留下來，別讓「別人都做四個」代替你做判斷。

從小尺寸起手的機制理由很具體：375 是約束最強的畫板，所有內容都得在這裡排出先後，把它放大是放寬約束的過程，比反過來把桌機稿擠進小螢幕容易得多。還有一個容易漏的細節：滾動條占寬與 box-sizing 的計算方式，會讓設計端的 768 和工程端的 768 不是同一個 768。斷點數值要寫進專案文件，和開發當面對齊一次，不是各自認定。

CSS 的 container queries 讓元件依所在容器而非視窗寬度變化，設計端對應的做法，是用元件變體表達同一張卡片在窄容器與寬容器裡各自的行為，把重排規則交代清楚，實作端自然有依據。設計決策要能被工程驗證，可以對照WordPress 主題實作的斷點行為，看數值如何落進主題設定；兩邊講的是同一套數字，來回就少。

外掛搬運結構，不修理結構

外掛能自動化的是切換與對照，不是編排判斷。明天要給客戶看，用預覽並排類買時間；要交給開發長期維護的資產，走原生加元件變體；要批量產出多裝置稿，先把結構層體檢過了再考慮自動化。順序錯了，工具只是把錯誤放大三份。

先把反命題說清楚：外掛是時間槓桿，不是地基。帶著「按一個按鈕就自動產出各裝置版面」的期待去挑工具，每個外掛都會讓你失望；它搬運你的結構，不會替你決定側邊欄收成抽屜之後，裡面的按鈕該放哪。看任何外掛的示範，先問它處理的是流體層還是編排層：示範裡只有整個 frame 等比放大縮小的，處理的是流體層，對重新編排幫助有限；示範裡出現欄數切換、區塊重新排列的，碰的才是編排層。這句問話內建成直覺，能省下大量裝了又刪的時間。

市面上處理響應式議題的外掛，名稱再怎麼變化，角色不出五類。先以類型理解，不給排名，也暫不點名。

↔ 左右捲動檢視完整表格

類型	解決的問題	適用時機	天限
斷點預覽切換	同屏並排多個裝置尺寸，快速對照	客戶確認、交付前自查	只是預覽，不會改變內容
自動縮放搬移	把桌機 frame 的元素搬進小尺寸 frame	大量相似頁面的批次轉換	複雜版面仍需手動修
裝置框架模擬	把設計包進手機外殼與安全區域	提案與簡報視覺	外殼占畫面，不利排版判斷
變體管理	集中管理同一元件的不同尺寸版本	設計系統成熟的團隊	前期建置成本高
標註輸出	把間距與行為規格輸出給開發	交付階段	讀懂它需要雙方有共同語言

什麼時候不用外掛，條件比什麼時候用更值得寫進規範：檔案要交接給別的團隊、團隊裡沒有人願意維護外部依賴、斷點只有兩個。這三種情況裡，原生流程的成本已經夠低，引入依賴換到的節省有限。順帶拆一個常見迷思：收藏外掛的數量本身不影響檔案效能，真正的成本在學習曲線、權限管理，與自動化跑完之後多出來的圖層。剛開始建立挑選標準的人，可以從新手挑外掛的原則讀起，先認識類型再談選擇。

導入的順序也有講究。先在單一專案試一類，跑完一個交付週期再決定要不要進團隊規範；同時引進三類，出問題時分不清是哪一環造成的，學習成本也會互相干擾。權限面要留意團隊方案對第三方工具的授權範圍，企業版檔案對某些外掛並不開放，採用前先拿同一份測試稿驗過，比事後退回手動劃算。

第三方依賴的風險邊界也要誠實面對。外掛能不能繼續用，取決於作者的維護意願與 Figma API 的變動，兩件事都不在你手上；實務上就存在外掛在某次平台更新後失效一兩週的情況，那陣子團隊只能退回手動，產能明顯下滑。把風險控制住的做法有三個：關鍵流程永遠保留一份無外掛的走法；外掛產出的結果當成草稿，進交付前一定再人工過一遍；用到的依賴寫進交接文件，讓接手的人知道哪些環節帶著外部條件。

近年 Figma 自己往 AI 與自動化的方向走，原生與外掛的界線在移動。Figma AI 功能的現況值得定期回看，判斷哪些過去要裝外掛的能力已經原生化；規格寫得夠具體之後，讓 AI 讀 Figma 稿產出 UI 的流程也是一條路。同樣只給適用條件，不給排名：規格與結構越清楚，產出越接近你的稿，這句話對人與對機器都成立。

從 375 走到 1280 的修復動線

診斷完、決策下完，動手順序是五段：樣板、骨架、加法、對照、收尾。順序顛倒的代價很具體：先畫視覺再調結構，會得到一堆對不上的畫板；跳過樣板直接開稿，同一個專案裡會出現三種手機寬度，交付時工程端對不上任何一種。

• 樣板：在獨立 page 放三個標準 frame，存成範本，新專案直接複製。做完的判準：專案裡只存在一組手機寬度，不會出現 375、380、360 各說各話。
• 骨架：在 375 畫主結構，header、主內容、footer 用 Auto Layout 的 column 排好，灰階進行，只看層級與流向。做完的判準：每一塊內容都答得出排在第幾順位、為什麼。
• 加法：把骨架放大到 1280，側邊欄出現、欄數增加、間距拉開。底層是 Auto Layout 時，column 切 row、gap 調大，版面會自己重排。做完的判準：放大過程不需要手動搬任何元素。
• 對照：三個尺寸並排輪流看，檢查間距、字級與按鈕大小的相對關係有沒有失衡。
• 收尾：同一個元件做桌機與手機兩個變體，差異放在圖片比例、文案長度、按鈕位置。做完的判準：手機上最長的文案不會撐破版面，桌機的留白不會在手機上變成空洞。

對照這一段，把 375、768、1280 三個 frame 並排開著輪流看，驗的是資訊排序與溢出，不是美感。以服飾電商的產品列表為例：桌機六欄商品卡的氣派，縮到手機時常變成促銷橫幅、篩選器、商品卡全部擠進 375 的編排難題，主行動按鈕被推到很後面。從手機尺寸開始做，常能提早暴露這類內容優先級的衝突；至於起點站哪一端，回到主要使用情境、流量結構與團隊負荷一併衡量，別把單一方向當成教條。

骨架階段的排序方法很樸素：把每一塊內容寫下來，先刪到只剩三塊非存在不可的，再把刪掉的依重要性插回去。這個動作在 375 的畫板上做，因為空間會逼你表態；在 1280 上做，永遠排得進去，排序就永遠不會被真正決定。插不回去的內容，就是「其實沒有人要看」的候選，設計階段刪掉它，比上線後在手機版偷偷藏起來便宜得多。

視覺語彙跨斷點的取捨，原則是先分類再決定。依賴背景模糊的玻璃質感，在中階手機上的成本與效益要重新計算，取捨方式可以參考毛玻璃效果在行動版的處理；環繞文字這類裝飾排版，縮到手機常不是等比縮小，而是簡化文案或改換形態，環形文字的斷點取捨是現成的例子。字級級距要為每個斷點重新設定，不是把桌機數字等比壓縮；間距用行動版自己的節奏校準，字體與版面的級距判斷提供更細的框架。

動線走完的產出物，剛好對應下一節的交付檢查項：三個尺寸的畫板、每個元件的變體、標示清楚的行為。要連互動流程一起驗證的，接著看UI 原型的驗證方法，把畫面與互動在不同裝置上的安排串起來，靜態版面與動態流程才不會各講各的話。

五種在畫板裡看不出、上線才爆的退件症狀

這五種症狀的挑選標準只有一條：後果不會顯示在設計工具裡。它們在 Figma 裡都長得體面，要等真機、或工程師退件那天才爆開。每一種給當下修法與源頭預防兩層處方，照著做，退件理由會少一大半。

• 等比縮小到底：375 只是 1280 的縮小版，字級小到難讀、按鈕點不到。當下修法：為手機重設級距與命中區域；源頭預防：把「每個斷點獨立排資訊層級」寫進樣板說明。
• 主行動按鈕沉到第三屏：上方塞滿橫幅、輪播、篩選器，使用者根本滑不到。當下修法：手機版把主按鈕往上提，次要元素收合；源頭預防：骨架階段就確認首屏包含主行動。
• 手機版實質省略重要內容：桌機版有的資訊，手機版沒有輸出。當下修法：補回內容，或以收合形態保留；源頭預防：任何刪減先與負責 SEO 的人核對。
• 絕對定位硬排：frame 裡全是 absolute，沒有任何 Auto Layout，換尺寸就錯位。當下修法：退回結構層體檢重做骨架；源頭預防：樣板裡明訂主內容不得用絕對定位。
• 間距與字級直接砍半：桌機的數字除以二當手機版，閱讀節奏破碎。當下修法：用行動版自己的級距與節奏重新校準；源頭預防：token 以語意命名，斷點切換只改值。

五個症狀裡，第三個的代價最容易被低估。不少團隊把手機版的收合與隱藏當成眼不見為淨，可行動優先索引早已是 Google 的預設視角：手機版實際移除的重要內容，Google 能查到的資訊會變少；把相同內容放進可展開的收合區塊或頁籤，則不算從頁面上消失。嚴格說這已經跨出設計的範圍，落到 SEO 的地盤，偏偏設計師很少主動往這個方向想。所以慣例要守住：任何讓手機版實質缺少重要內容的決定，先和負責搜尋流量的人確認一次；跳過這一步，等於悄悄把站上最值錢的內容向搜尋引擎上了鎖。

觸控的物理限制併進處方看，不是單獨立一條禮節。可點擊元素的命中區域，Apple 人機介面指南對按鈕的說明以 44pt 作為參考下限，實際尺寸仍依平台、間距與真機測試調整；在 Figma 裡另開一層透明圖層專門標出命中區域：視覺可以縮小，可點擊的範圍不行。橫向捲動與輪播是誤觸的重災區，滑動手勢與點擊目標搶同一塊面積，滑桿元件的互動規格示範怎麼把這類衝突寫成可檢查的規則。

溢出的偵測可以半自動化。把三個尺寸的 frame 並排，逐一選取會伸縮的容器，看它在最小寬度時的右邊界有沒有超過畫板；開啟標示溢出的設定時，問題元素會以紅線提示。一時找不到元兇的破版，多半是某個鎖住尺寸的元素連鎖觸發，從最靠近破版處的元素往回追，兩三步就會撞到它。

還有一類症狀與效能相關：原型階段看不出載入成本，上線後才以指標現形。設計工具回答不了這題，得上真機與實際資料，例如以 LCP 等指標量測首屏主要內容出現的時間；想把這條線串起來，看Core Web Vitals 指標與搜尋的關係。指標是量測工具，不是排名保證，讀的時候記得這條邊界。

什麼樣的稿子不會被退？

交付前的完成定義有三個判準：裝置預覽實測過、標註標了行為而不只是數字、間距字級對應到與開發同名的語意化 token，再加上圖片資產規格講清楚。三項齊了，稿子才算可判斷為完成；網站上線後的體驗，另以真機與實際指標驗收。

token 命名是很多團隊跌過的坑。用數字命名，padding-24 這種名字一開始直覺，手機版把 24 改成 20 的那天，名字與值就脫鉤，接下來就是全局改名。語意命名讓名字描述用途：spacing-section 是區塊之間的大間距，spacing-inline 是行內的小間距；手機版設 40、桌機版設 80，名字不動，工程師只在自己的變數裡改值，斷點切換從此不需要對照表。

標註範本該有的是行為欄位：這個容器在哪個寬度從 row 變 column、圖片在小尺寸怎麼裁切、哪個區塊在哪個斷點隱藏、互動狀態有哪幾種。數字開發自己量得到，行為只有你知道；這份欄位清單同時是交接給 AI 工具的輸入，寫得越具體，後續的自動化越站得住。

交接文件的最小內容，跟著行為欄位走：斷點清單與各斷點的欄數變化、每個元件的變體對照、圖片資產的裝置版本、互動狀態的定義。這份文件不必精美，能讓接手的人在沒有你在場的情況下，把三個尺寸的行為重建出來就達標；做不到這點的文件，裝訂得再漂亮也只是裝飾。

上線前的驗收提問，三個就夠：

• 不滾動的第一屏，看得到主行動按鈕嗎？這是行動版成敗的第一條線。
• 直轉橫，版面有沒有錯亂？只測直向的人，把橫向的問題留給使用者發現。
• 換到慢速網路，第一屏的主要內容多久才生得出來？這題上線後以真機搭配 LCP 類指標實測，別拿「兩秒」這種單一口號充當門檻；版面伸縮與載入速度，也該分開驗收。

搜尋端的背景補在這裡：Google 已全面採用行動優先索引，以手機版內容作為認識網站的主要視角（見 2023 年 10 月Google Search Central Blog 的說明）。這是索引方式，不是手機版的排名加分；它對設計師的意義是，手機版不是順便做做的副產品，而是網站被理解的主要路徑，重要內容在這個版本裡缺席，代價會在搜尋端反映出來。

實測設備的選擇有個務實邏輯：多數使用者的設備等級低於設計師手上的旗艦機。準備一支兩三年前的中階機當測試機，旗艦機上順暢的動畫、一秒載完的圖，在中階機加一般網路環境下可能是另一個世界。測試機是流程的標準配備，不是偶爾為之的儀式，這個視角任何設計工具都給不了。

圖片資產的規格併進交付判準：每張關鍵圖準備寬幅與直式兩個裁切版本，外層容器鎖好比例，標註寫明每張圖的裝置版本、格式與最大寬度，工程端才有條件實作對應的尺寸切換。圖片的搜尋端處理可以接著看圖片 SEO 的做法，載入策略的延後與觸發時機，在延遲載入的機制裡有完整拆解。排名系統只把網頁體驗當眾多訊號之一，這裡做的是把可控的部分做好，不是對排名開支票。

把診斷收成一頁決策卡

全文收斂成一張以症狀為索引的決策卡，欄位五個：症狀、疑似層級、兩分鐘確認法、處方、做完的判準。放在設計系統文件，或專案範本的首頁，下次卡關時不用重新辯論，翻卡就能定位到層級與修法。

把判斷標準寫進文件，省的不只是時間，還有會議。要不要裝某個外掛、第四個斷點砍不砍，這類爭論在沒有準則的團隊裡每次都從零開始；有了決策卡，討論縮成「這個情況落在哪一格」。判斷標準沉澱成團隊資產，品質才不會隨人事變動歸零，新人照著卡片走，也能到達可交付的水準。

決策卡需要回看，頻率一季一次夠用。回看時只問兩個問題：這季的退件理由有沒有卡片沒涵蓋的新症狀；卡片上的處方，實際執行時有沒有被證明太貴或太繞。有就更新欄位，沒有就原樣放回去。卡片的目的在收斂判斷，不在囊括所有可能，別讓它長成沒有人看完的百科。

收斂成六個動作，照著做就是一輪完整的循環：

1. 定斷點：專案文件第一頁寫下要做幾個斷點、各是多少寬，預設 375、768、1280，加第四個要有明確理由。
2. 建樣板：獨立 page 放標準 frame 範本，團隊共用，不各開各的畫板。
3. 依主要情境定起點：行動流量與任務占比高，從 375 起手；桌機工作流主導的後台，先畫桌機再補退化版，兩端都要及早驗證。
4. 地基先於外掛：重複元件套 Auto Layout、容器寬度用 Fill、間距用 gap，這層沒做完不開自動化。
5. 每類外掛只挑一個：預覽、縮放、框架、變體、標註五類各一，夠用就好。
6. 真機驗收：交付前先用 Figma 的行動預覽確認畫面與原型互動；網站實際上線後，再以真機檢視 CTA、誤觸與載入表現。

要排優先順序，先做斷點樣板與起點策略這兩個：成本最低、槓桿最大，擋掉的問題卻不少。誠實的邊界也要一起寫下來：Figma 驗的是設計決策的品質，上線後的速度、體驗與成效，以真機與實際資料為準；任何人向你保證排名、流量或轉換的確定數字，都值得追問依據。下一個專案開檔時，先把樣板建起來，這個動作花不了幾分鐘，回收在每一次不必重抄畫板的迭代裡。