1. 項目概述為什么“切圖規范”是UI設計師的必修課在任何一個移動端或Web端產品從設計稿到最終上線的漫長鏈路中UI設計師與前端工程師之間的協作往往是最容易“扯皮”的環節。設計師精心打磨的像素級視覺效果到了開發手里還原度可能大打折扣而開發工程師則常常抱怨設計師給的資源“沒法用”不是尺寸不對就是格式混亂或者命名讓人一頭霧水。這個矛盾的根源很大程度上就出在“切圖”這個看似簡單、實則暗藏玄機的環節上。UI設計切圖規范正是為了解決這一核心協作痛點而生的“工程化語言”和“協作契約”。它絕不僅僅是把設計稿上的圖標、按鈕“切出來”那么簡單。一套完善的切圖規范定義了從資源命名、尺寸規格、文件格式、輸出目錄到狀態管理的完整標準。它確保了設計師的視覺意圖能被無損、高效地傳遞給開發也保證了開發同學能快速、準確地獲取所需資源避免在溝通和返工上浪費寶貴時間。尤其是在如今多端適配iOS、Android、Web、小程序、多分辨率屏幕1x、2x、3x、4x成為標配的背景下沒有一套清晰的切圖規范項目幾乎寸步難行。這不僅是提升個人專業度的體現更是保障團隊協作順暢、項目質量穩定的基石。2. 切圖前的核心準備工作從源文件到思維框架很多新手設計師拿到設計稿后會迫不及待地開始用切片工具“框選”這是最大的誤區。切圖不是體力活而是需要精密規劃的技術活。在動刀之前必須完成以下幾項關鍵的準備工作這直接決定了后續所有工作的效率和準確性。2.1 設計稿的“清潔度”檢查與圖層管理一個混亂的源文件是災難的開始。在切圖前你必須像外科醫生術前準備一樣對設計稿進行徹底的“消毒”和整理。首先是圖層的規范化命名與分組。雜亂無章的圖層名稱如“圖層1 拷貝3”會讓后續的查找和導出變得極其困難。你需要為每一個可交互或獨立的視覺元素如按鈕、圖標、卡片的圖層或圖層組進行清晰的命名。命名應遵循“模塊_組件_狀態”的邏輯例如btn_primary_normal按鈕_主要_常態、icon_search_active圖標_搜索_激活態。同時將相關的圖層進行編組并隱藏或刪除所有在最終界面上不可見的輔助線、參考圖層和廢棄設計稿保持畫布的整潔。其次是確保所有元素的矢量化與柵格化邊界清晰。對于圖標、Logo等元素應盡量使用矢量形狀圖層Shape Layer或智能對象以保證在任何縮放倍數下都能輸出清晰的圖像。對于必須使用位圖如圖片背景的地方要確保其原始分辨率足夠高避免放大后模糊。一個關鍵技巧是在Sketch或Figma中使用“設置為導出項”或“創建組件”功能來預先標記需要導出的元素這能極大提升后續批量導出的效率。最后是建立統一的樣式庫和組件庫。在開始具體頁面設計前就應該定義好項目的色彩體系、文字樣式字體、字號、行高、投影、圓角等基礎樣式并創建按鈕、輸入框、導航欄等高頻組件的SymbolSketch或ComponentFigma。這不僅保證了設計的一致性在切圖時你只需要切出這些基礎組件一次開發即可通過代碼復用無需為每一個按鈕單獨切圖這是現代UI設計工作流的核心效率來源。2.2 明確適配策略一稿適配多端的核心邏輯“這個圖要切幾倍”這是前端工程師最常問的問題。答案取決于你的產品需要適配哪些平臺和屏幕。iOS平臺通常需要 1x、2x、3x 三種倍率的切圖。在750*13342x為基準的設計稿中1x的圖就是縮小到50%3x的圖就是放大到150%。但注意有些純矢量的圖標如用代碼實現的SVG或系統提供的SF Symbols可以只提供一份由系統自動縮放。Android平臺的密度體系更為復雜有ldpi、mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi等。目前最主流的做法是以xxhdpi通常對應1080p屏幕縮放倍率3x作為設計基準然后按比例生成其他密度的資源。許多設計工具和插件可以自動完成這個縮放過程。Web端的適配則更靈活。對于需要保持清晰度的圖標可以準備多倍圖如icon.png和icon2x.png通過CSS的image-set或srcset屬性讓瀏覽器根據設備像素比選擇加載。而更多的背景、裝飾性圖形則可以使用CSS3屬性如漸變、陰影或SVG矢量格式來實現減少對位圖的依賴。關鍵決策點在于哪些資源需要切圖哪些可以用代碼實現一個簡單的判斷原則是帶有復雜漸變、紋理、特殊形狀或動態效果的圖形需要切圖而純色填充、簡單圓角矩形、單色線條圖標應優先考慮用CSS或平臺原生控件繪制。與前端工程師提前溝通這個邊界能節省雙方大量時間。3. 切圖實操詳解工具、流程與核心參數設置準備工作就緒后我們進入具體的切圖操作環節。這里以目前主流的Figma/Sketch工具為例詳解每一步的操作要點和背后的原理。3.1 切片工具的使用與導出區域設定在Figma或Sketch中切片工具Slice或Export是你的手術刀。選中一個圖層或編組后右側面板會出現導出Export的設置區域。第一步正確框選導出范圍。對于圖標通常需要緊貼圖標內容邊緣不留多余透明像素這有助于減少文件體積也方便開發進行對齊。但有一個重要例外當圖標需要與文字或其他元素保持固定間距時有時需要保留一定的“安全內邊距”Padding這時導出的切片范圍就需要包含這部分空白。最佳實踐是與開發約定一個統一的Padding規則例如所有圖標都導出為實際尺寸外增加2px透明邊距的正方形畫布。第二步處理包含背景的組件。對于一個按鈕你可能需要導出整個按鈕的圖形也可能只需要導出按鈕上那個小小的“”圖標。這里涉及到“合并導出”與“單獨導出”的選擇。如果按鈕的背景是簡單的圓角矩形完全可以用代碼實現那么你只需要導出中間的“”圖標通常是SVG格式。如果按鈕有復雜的漸變、內陰影或紋理那就需要將按鈕作為一個整體切片導出。在切片時務必隱藏掉不必要的文本圖層文字通常由代碼渲染只保留圖形部分。3.2 文件命名規范讓機器和人都能讀懂混亂的命名是協作的噩夢。一套好的命名規范應該做到“見名知意”并且便于工具自動化處理。基本結構建議采用組件_類型_狀態_描述倍數.格式。組件 (Component):指明元素所屬的模塊或大類如nav導航欄、btn按鈕、icon圖標、tab標簽欄、bg背景。類型 (Type):在組件內進一步分類如btn_primary主要按鈕、btn_secondary次要按鈕。狀態 (State):描述元素的交互狀態這是最容易被忽略但至關重要的部分。常見狀態有normal常態、pressed/active按下/激活、disabled禁用、selected選中。例如btn_primary_pressed。描述 (Description):可選用于進一步區分同類型元素如icon_search、icon_close。倍數 (Scale):如2x,3x。對于SVG或PDF等矢量格式通常不加倍數后綴。格式 (Format):如.png,.jpg,.svg。示例btn_primary_normal2x.png主要按鈕-常態-2倍圖icon_back_disabled3x.png返回圖標-禁用態-3倍圖bg_home_header.jpg首頁頭部背景圖必須遵守的規則全小寫避免因系統大小寫敏感問題導致資源找不到。使用下劃線_連接不要使用空格、橫線-在部分腳本中橫線可能有特殊含義下劃線是兼容性最好的分隔符。語義化優先名稱應準確描述內容而不是“image1”、“pic2”這樣的無意義字符串。3.3 輸出格式選擇PNG、JPG、SVG與WebP的適用場景選擇正確的格式能在視覺效果和性能之間取得最佳平衡。PNG支持透明通道Alpha通道的位圖格式首選。適用于圖標、Logo、帶透明背景的UI組件。導出時務必注意顏色模式選擇RGB而非CMYK用于印刷。位深度選擇“24位 PNGRGB”加上“8位 Alpha通道”即通常工具中的“PNG-24”選項以確保色彩和透明度質量。優化勾選“導出為Web所用格式”或類似選項工具會進行無損壓縮大幅減小文件體積。對于簡單圖形也可以考慮PNG-8索引256色體積更小但需檢查色彩過渡是否出現斷層。JPG/JPEG適用于色彩豐富、沒有透明需求的照片、漸變背景或復雜紋理。它是一種有損壓縮格式可以通過調整壓縮比質量通常60%-80%即可在畫質和體積間權衡。絕對不要用它來保存帶純色邊緣或文字的圖形會產生難看的噪邊。SVG矢量圖形的王者。適用于圖標、簡單插畫。它由數學公式定義無限縮放不模糊且文件體積通常極小。在Web和現代移動開發中SVG的使用越來越廣泛。導出SVG時要注意在設計工具中確保圖形是真正的矢量路徑而不是柵格化后的位圖。導出前執行“輪廓化描邊”Convert Strokes to Outlines避免在某些環境下描邊顯示異常。清理不必要的元數據使用工具或在線服務如SVGO進行優化刪除隱藏圖層、冗余節點。WebP谷歌推出的現代圖像格式在同等質量下體積比PNG和JPG小很多同時支持透明度和動畫。它是Web性能優化的利器。雖然部分老舊瀏覽器不支持但可以通過picture標簽提供兼容方案。在設計工具中直接導出WebP可能選項有限通常由前端通過構建工具如Webpack進行自動轉換。格式選擇決策流需要透明嗎需要 - PNG 或 WebP。是圖標或簡單圖形嗎是 - 優先考慮 SVG。是照片或復雜圖像嗎是 - JPG 或 WebP。追求最佳性能和兼容性提供 PNG/JPG 后備主推 WebP。4. 多平臺與多狀態資源的特殊處理規范現代UI設計充滿動態交互一個按鈕有常態、按壓、禁用等多種狀態一個應用需要適配iOS、Android、Web等多個平臺。如何高效、清晰地管理這些資源是規范的高級課題。4.1 交互狀態切圖不僅僅是換顏色一個按鈕的“按壓”狀態可能不僅僅是顏色變深還可能伴有輕微的位移、陰影變化或微妙的紋理改變。切圖時必須為每一種明確定義的交互狀態輸出對應的資源。常見狀態包括Normal (默認狀態):元素的初始外觀。Pressed / Active (按壓/激活狀態):用戶點擊或按住時的反饋。Disabled (禁用狀態):元素不可交互時的外觀通常降低透明度或變為灰色。Selected (選中狀態):用于標簽欄、單選按鈕等表示已選中的情況。Hover (懸停狀態):主要用于Web端鼠標懸停時的效果。Focus (聚焦狀態):獲取鍵盤焦點時的狀態對于可訪問性至關重要。實操要點在設計稿中最好使用組件變體Figma Variants或符號覆蓋Sketch Overrides來管理這些狀態。切圖時通過切換組件的狀態分別對每個狀態進行切片和導出。命名上必須清晰體現狀態如btn_submit_normal.png和btn_submit_pressed.png。千萬不要只提供一個狀態圖然后告訴開發“按下時把顏色值改成#XXXXXX”對于帶有復雜背景、邊框或內部圖形的按鈕這種做法無法實現設計效果。4.2 多平臺適配iOS、Android與Web的差異化輸出不同平臺有其特定的設計語言和技術實現方式切圖也需要“因地制宜”。對于iOS (iPhone/iPad):格式偏好PNG是絕對主流對于App Icon等也需要提供特定尺寸的PNG。圖標資源通常放入.xcassets素材目錄中系統會自動管理1x, 2x, 3x。命名規范除了通用的語義化命名有時需要遵循蘋果的特定命名例如啟動圖LaunchScreen.png應用圖標AppIcon.png實際上一組不同尺寸的圖。切片注意iOS的導航欄、狀態欄、標簽欄圖標有標準的尺寸要求如44pt點擊區域切圖時需要遵守。對于Android:資源目錄結構資源按密度分目錄存放drawable-mdpi/,drawable-hdpi/,drawable-xhdpi/,drawable-xxhdpi/,drawable-xxxhdpi/。你需要將不同倍率的圖放入對應文件夾。格式與命名PNG同樣首選也支持WebP。命名規則與通用規范一致但不能使用大寫字母不能使用橫線-橫線在Android資源命名中用于分隔資源類型和配置限定符容易沖突堅持使用小寫字母和下劃線。.9.png 點九圖這是Android獨有的伸縮位圖格式用于聊天氣泡、按鈕背景等需要水平和垂直拉伸的區域。它通過圖片四條邊上的1像素黑線來定義可拉伸區域和內容填充區域。雖然現在更多使用矢量圖或代碼實現但在處理復雜背景拉伸時它仍是重要工具。導出時需要專門工具生成。對于Web:靈活性最高格式上PNG、JPG、SVG、WebP均可。命名規范主要服務于前端工程目錄結構。雪碧圖 (CSS Sprite) 的考量為了減少HTTP請求可以將多個小圖標合并到一張大圖上通過CSSbackground-position來定位。雖然HTTP/2普及后其必要性降低但在某些場景下仍有價值。如果需要提供雪碧圖除了提供合并后的大圖還必須提供一份詳細的坐標文檔通常由自動化工具生成。響應式圖像對于重要圖片可能需要提供不同尺寸非僅不同倍率的版本以適應從手機到桌面的不同視口。這通常通過img srcset...或picture標簽實現設計師需要提供至少兩到三個不同寬度的圖片版本。4.3 可拉伸元素的處理.9圖與矢量方案的抉擇前面提到的.9.png是Android處理可拉伸背景的傳統方案但它有幾個缺點制作稍復雜多倍圖需要分別制作且不適用于非矩形拉伸。現代更優的解決方案是使用矢量圖形。SVG (Web):在Web端SVG可以完美實現任意形狀的縮放且體積小。矢量繪圖指令 (iOS/Android):在移動端可以使用平臺提供的矢量繪圖API。例如在iOS中你可以用代碼描述一個帶圓角、漸變和陰影的矩形在Android中可以使用XML定義的shape或矢量圖vector。作為設計師你的職責是向開發提供精確的圖形參數如圓角半徑、漸變色標和位置、陰影的X/Y偏移和模糊度、邊框粗細和顏色等。這些參數應詳細記錄在設計文檔或標注工具中。決策路徑如果背景極其簡單純色圓角矩形直接給參數讓代碼實現。如果背景復雜但形狀規則帶線性漸變和陰影的圓角矩形優先提供參數代碼實現性能更好。如果背景是復雜的、不規則的圖案紋理如布紋、水彩邊緣那么使用.9.png或直接輸出一張足夠大的位圖是更現實的選擇。5. 標注與交付確保設計意圖的精準傳遞切圖文件本身只是原材料沒有準確的“說明書”開發仍然可能用錯。標注Specification就是這份說明書它告訴開發每個元素的尺寸、間距、顏色、字體和狀態變化規則。5.1 設計標注的核心內容不止于尺寸和色值傳統的標注工具如藍湖、Zeplin、Figma自帶標注可以自動生成很多信息但設計師需要有意識地檢查和補充關鍵內容尺寸與間距元素自身的寬高以及元素與元素之間、元素與屏幕邊緣之間的間距。特別注意對齊方式左對齊、居中對齊、右對齊。顏色提供HEX十六進制色值對于透明度Alpha提供RGBA或HSLA值。標注出所有用到的顏色并最好附上全局色彩樣式表。文字樣式字體、字重Regular, Bold等、字號、行高、字間距、對齊方式。行高Line Height尤其重要它直接影響多行文本的排版效果。圓角與邊框圓角半徑是統一值還是單獨設置邊框的粗細、顏色和類型實線、虛線。陰影與模糊陰影的X/Y偏移、模糊半徑、擴散范圍和顏色含透明度。對于背景模糊毛玻璃效果需要標注模糊度。交互狀態說明這是標注中最容易遺漏的部分。必須在標注中清晰地展示不同狀態如按下、禁用下上述所有屬性顏色、陰影等發生了哪些具體變化。可以用頁面鏈接或狀態切換的方式呈現。5.2 交付物清單與目錄結構規范將一堆散亂的文件扔給開發是不負責任的行為。專業的交付應該是一個結構清晰、內容完整的“資源包”。標準的交付物應包含設計源文件最新版的Sketch/Figma/XD文件鏈接或存檔。切圖資源文件夾這是核心交付物。目錄結構示例assets/ ├── icons/ # 圖標類資源 │ ├── common/ # 通用圖標 │ │ ├── ic_add2x.png │ │ └── ic_add3x.png │ └── tab/ # 標簽欄圖標 │ ├── ic_home_normal2x.png │ └── ic_home_selected2x.png ├── images/ # 圖片類資源 │ └── bg_login.jpg ├── components/ # 組件切片如按鈕背景 │ └── btn_large_normal2x.png └── splash/ # 啟動圖等特殊資源 └── launch2x.png可以按平臺再分一級目錄如assets/ios/,assets/android/。設計標注鏈接/文檔提供藍湖、Zeplin的在線鏈接或導出的PDF標注文檔。確保開發團隊所有成員都有訪問權限。設計規范文檔 (可選但推薦):一個獨立的PDF或Notion頁面系統性地闡述項目的設計語言包括色彩體系、字體階梯、間距系統、組件庫使用說明、動效原則等。這對于大型項目或長期迭代至關重要。更新日志 (Change Log):如果本次交付是版本更新應附帶一個簡單的文本說明列出新增、修改和刪除的資源清單幫助開發快速定位變更。交付流程建議使用協同工具如Figma、藍湖進行實時交付和更新是最佳實踐。如果必須發送文件包請使用壓縮包并確保包內結構清晰。在交付時通過團隊協作工具如Slack、釘釘、飛書明確告知開發同學并附上關鍵變更點的簡要說明。6. 版本迭代與協作流程中的規范維護設計不是一錘子買賣產品會持續迭代。如何在高頻的修改中保持切圖規范的效力避免資源混亂是更大的挑戰。6.1 資源更新與刪除的規范流程“只增不改”是理想狀態但現實是資源經常需要更新甚至刪除。更新資源當某個圖標或圖片需要修改時務必保持文件名不變只更新文件內容。這樣開發同學只需要替換舊文件而不需要修改代碼中的引用路徑。如果視覺變化巨大需要更改命名則應視為“新增廢棄”流程。刪除資源絕對不要直接從共享文件夾或協同工具中悄無聲息地刪除一個舊資源。正確的做法是在設計標注中將該元素標記為“已廢棄”或“待刪除”。與前端負責人溝通確認該資源在代碼中已無引用。雙方約定一個清理周期如下個版本迭代然后在周期內由開發移除代碼引用設計師再移除設計稿和資源文件。在交付清單的更新日志中明確記錄“刪除icon_old_feature.png”。新增資源嚴格按照既有的命名規范和目錄結構存放新文件。在更新日志中記錄新增項。6.2 使用協同工具固化規范現代設計協作工具Figma, Sketch with Abstract等本身就能成為規范的載體。組件庫與樣式庫將顏色、文本樣式、組件全部建立在團隊的共享庫中。當庫更新時所有使用該庫的設計文件都會收到更新通知。這從源頭上保證了設計元素的一致性也間接保證了切出資源的規范性。自動標注與切圖藍湖、Zeplin等插件可以自動從設計稿生成標注和切圖并保持與源文件的同步。當設計師更新主組件并發布庫后標注和切圖資源可以一鍵更新極大地減少了手動操作的錯誤和溝通成本。設計評審流程利用工具的評論和審批功能建立設計評審流程。在評審環節就可以檢查切圖規范、標注完整性將問題前置而不是等到交付開發時才暴露。6.3 建立團隊共識與文檔規范的生命力在于執行。再好的規范如果只有你一個人知道也形同虛設。團隊內宣導在項目啟動初期召集所有相關的UI/UX設計師和前端開發共同評審并確認這份切圖規范。讓大家理解每一條規則背后的原因例如為什么命名要用下劃線而不是橫線這比強制要求更有效。創建活文檔將最終的規范整理成一份團隊共享的文檔如Confluence、Notion、語雀頁面。這份文檔應該包含所有細節命名公約、目錄結構、格式標準、標注要求、交付流程、工具設置指南等。并且隨著項目演進和技術變化及時更新這份文檔。設立質量檢查點可以在設計評審的checklist中加入“切圖規范符合性”這一項。或者在將設計稿交付開發前由資深設計師或設計負責人進行一次快速的規范符合性檢查。從我過去在多個跨端項目中協作的經驗來看前期在規范制定和溝通上多花一天時間往往能在后期節省掉數十天因資源錯亂、溝通返工所浪費的時間。切圖規范本質上是一種預防性的工程思維它把設計師從重復、低效的“切圖民工”角色中解放出來讓其更專注于創造性的設計工作同時也為開發同學構建了一條清晰、可靠的“生產線”。當團隊每個人都習慣并信任這套規范時整個產品研發的流水線就會變得順暢而高效。