UI设计切图规范：提升团队协作效率与产品还原度的关键

1. 项目概述：为什么我们需要一套切图规范？

在任何一个UI设计项目里，从设计稿到最终上线的产品，中间有一个环节至关重要，却常常被忽视或草率处理，那就是“切图”。你可能有过这样的经历：设计师精心打磨的界面，到了开发手里，还原度大打折扣，图标模糊、间距错位、点击区域不对，甚至因为一个按钮的多种状态缺失，导致前端反复找你确认。这背后的核心原因，往往不是设计能力或开发水平的问题，而是缺乏一套清晰、统一、可执行的UI设计切图规范。

简单来说，切图规范就是设计师与工程师之间的一份“交付契约”。它规定了设计稿中哪些元素需要被提取为图片资源、以何种格式和尺寸输出、如何命名、如何标注间距，以及如何处理适配和交互状态。没有这份契约，沟通成本会急剧上升，项目进度和质量都难以保障。尤其是在如今多端适配（iOS、Android、Web、小程序）和敏捷开发的背景下，一套好的切图规范能像润滑剂一样，让设计与开发的协作流程顺畅无比。

我经历过太多因为切图不规范而引发的“血案”：一个简单的列表项，因为切图时没有考虑拉伸区域，在安卓不同尺寸屏幕上直接变形；一个带阴影的按钮，开发直接用了带背景的PNG，导致无法动态修改文字；图标资源命名混乱，开发在成百上千个文件里大海捞针。所以，今天我想系统性地梳理一下，一个资深UI设计师在实际项目中，应该如何建立并执行一套高效、严谨的切图规范。这不仅关乎效率，更关乎最终产品的品质和团队的专业性。

2. 核心原则与前期准备：规范不是限制，是提效工具

在动手切图之前，我们必须明确几个核心原则。规范的目的不是为了给设计师套上枷锁，而是为了提升整个产品研发链路的效率和一致性。

2.1 原则一：以开发思维进行设计

这是最重要的一条。设计师不能只停留在视觉美观层面，必须理解前端如何实现你的设计。例如，一个圆角矩形按钮，是应该切整个按钮的图，还是只提供圆角半径和纯色背景，由代码实现？后者显然更灵活（支持动态换色、修改文字）。一个渐变色背景，如果面积很大，切图会导致文件巨大，是否可以用CSS线性渐变实现？在设计之初就带着这些思考，能从根本上减少不必要的切图工作，并赋予产品更好的可维护性和性能。

注意：与开发团队在项目启动初期就对齐实现方案至关重要。了解他们常用的UI框架（如React、Vue、Flutter）和组件库，知道哪些效果可以轻松用代码实现，哪些必须依赖图片资源。

2.2 原则二：一致性高于一切

规范的生命力在于执行的一致性。这包括命名的一致性、尺寸体系的一致性、输出格式的一致性。一个项目中，所有图标的命名逻辑应该相同，所有可拉伸元素的切法应该相同。这样，开发同学在接入资源时才能形成肌肉记忆，减少出错概率。例如，如果你决定图标使用icon_功能_状态@2x.png的命名方式，那么整个项目的所有图标都必须遵守，不能出现btn_close.png和icon_search_normal@2x.png混用的情况。

2.3 原则三：为适配而生

如今的设计必须考虑从最小的手机屏幕到最大的平板甚至桌面端。切图规范必须包含完整的适配策略。这不仅仅是提供@1x,@2x,@3x倍图那么简单，更需要考虑：

• 等比缩放元素：哪些图标或图片在放大时应该保持清晰（需要提供多套倍图或矢量格式）？
• 可拉伸元素：哪些背景、边框、装饰条是可以水平或垂直拉伸而不失真的（如何定义拉伸区域）？
• 内容布局：哪些间距和尺寸是相对单位（如百分比、rem），哪些是绝对像素，需要在标注中明确。

2.4 工具准备：选对工具，事半功倍

工欲善其事，必先利其器。现代UI设计工具已经深度整合了切图和标注功能。

• 设计工具：Figma、Sketch、Adobe XD 是主流。以 Figma 为例，其 Auto Layout（自动布局）功能能极大地方便开发理解间距关系，而内置的 Export 面板和 Inspect 模式（对应开发侧的“Dev Mode”）是生成切图和查看标注的核心。
• 标注与协作平台：蓝湖、Zeplin、Pixso 等。这些平台可以自动生成CSS、Swift、XML等代码片段，极大提升交付效率。但请注意，平台只是辅助，设计师必须理解其生成的逻辑，并能检查和修正可能的错误。
• 版本控制意识：虽然我们讨论的是切图规范，但设计源文件的版本管理同样重要。使用清晰的文件命名和图层结构，便于回溯和团队协作。这间接影响了切图资源的可追溯性。

3. 切图资源分类与输出标准详解

不是设计稿上的每一个像素都需要被切出来。我们需要对UI元素进行科学的分类，并为每一类制定明确的输出标准。

3.1 资源分类：明确什么该切，什么不该切

我将需要处理的资源分为四大类：

1. 图标类：包括系统图标（如返回、关闭、搜索）、业务图标（如购物车、消息）、状态图标（如成功、错误、加载）。这类资源通常尺寸固定，需要高清晰度。
2. 图片类：包括产品图、运营Banner、用户头像、背景图等。这类资源内容多变，尺寸不固定，更注重视觉质量和压缩。
3. 控件背景类：包括按钮、输入框、标签、卡片、导航栏、标签栏的背景。这类资源的核心在于“可拉伸性”，通常通过.9.png（Android）或 Slicing（iOS/Web）技术实现。
4. 动效与特殊效果类：包括Lottie动画、CSS可实现的简单动效（需提供参数）、复杂的粒子效果（可能需要序列帧或视频）。这类资源需要和开发深度讨论实现方案。

3.2 输出格式：PNG、JPG、SVG、WebP 如何选择？

格式选择直接影响最终产品的性能和视觉效果。

实操心得：一个常见的误区是“一切皆PNG”。对于纯色图标，一个几KB的SVG文件比一个几十KB的PNG@2x图要好得多。在最近的一个项目中，我们将顶部导航栏的整套图标从PNG换为SVG，整个资源包的体积减少了70%，且在任何高清屏上都锐利无比。

3.3 尺寸与倍率：一图适配多端的秘密

为了在不同像素密度的屏幕上保持清晰，我们需要提供同一资源的多种尺寸，即“倍图”。

• iOS：以@1x(原始尺寸)、@2x、@3x为主流。例如，一个在设计中为24x24pt的图标，需要输出24px(@1x)、48px(@2x)、72px(@3x) 三个物理像素尺寸的文件。关键点：在Sketch/Figma中，画板（Artboard）应设置为@1x逻辑尺寸，导出时选择对应的倍率。
• Android：通常使用mdpi(@1x)、hdpi(@1.5x)、xhdpi(@2x)、xxhdpi(@3x)、xxxhdpi(@4x) 等密度限定符。同样一个24dp的图标，需要输出24px(mdpi)、36px(hdpi)、48px(xhdpi) 等。
• Web：情况更复杂。对于响应式网站，图标可能使用SVG（首选）或字体图标。对于必须用位图的图片，通常会准备1x和2x两套，并通过srcset属性让浏览器根据设备选择加载。

我的工作流：在设计工具中，我会为需要多倍图的元素创建一个组件（Component），然后利用Figma的“Export”面板，一次性添加1x，2x，3x的导出设置。这样，当需要更新图标时，只需修改主组件，所有倍图都会自动同步更新，极大减少了手动操作和出错的可能。

4. 命名规范与组织架构：让资源一目了然

混乱的命名是开发工程师的噩梦，也是项目维护的毒药。一套好的命名规范，应该做到“见名知意”，并且便于工具自动化和检索。

4.1 命名公式：模块_功能_状态_描述@倍率.格式

我推荐使用以下层级式命名结构，各部分用下划线_连接：

模块名_元素类型_功能描述_状态_额外描述@倍率.格式

• 模块名：表示资源所属的功能模块，如home（首页）、user（用户中心）、product（商品）。对于小型项目可以省略。
• 元素类型：表明这是什么，如icon（图标）、btn（按钮）、bg（背景）、img（图片）、tab（标签栏）。
• 功能描述：核心功能，如close（关闭）、search（搜索）、submit（提交）。
• 状态：元素的交互或显示状态，如normal（默认）、pressed（按下）、disabled（禁用）、selected（选中）。
• 额外描述：可选，用于进一步区分，如small（小尺寸）、red（红色变体）。
• @倍率：如@2x，@3x。
• 格式：如.png，.svg。

示例：

• icon_nav_close_normal@2x.png（导航栏关闭图标，默认状态，2倍图）
• btn_primary_submit_pressed@3x.png（主要按钮，提交功能，按下状态，3倍图）
• bg_card_default.9.png（卡片默认背景，Android九宫格图）
• icon_common_alert.svg（通用警告图标，矢量格式）

注意事项：坚决避免使用中文、空格和特殊字符（除了下划线）。命名全部使用小写字母。状态描述要统一，整个项目要么都用normal/pressed，要么都用default/active，不要混用。

4.2 文件夹组织：逻辑清晰的资源树

将资源文件分门别类地放入文件夹，是项目管理的基本功。我通常按以下结构组织交付给开发的资源包：

assets/ ├── icons/ # 所有图标 │ ├── common/ # 通用图标 (如关闭、返回、箭头) │ ├── tabbar/ # 标签栏图标 │ └── feature-a/ # 特定功能A的图标 ├── images/ # 内容图片 │ ├── products/ # 商品图 │ ├── avatars/ # 头像 │ └── banners/ # 运营横幅 ├── backgrounds/ # 背景、纹理、可拉伸元素 │ ├── buttons/ # 按钮背景 │ ├── inputs/ # 输入框背景 │ └── cards/ # 卡片背景 └── lottie/ # Lottie动画JSON文件

这种结构让开发能够快速定位资源，也便于后续的增量更新和版本管理。在交付时，我会提供一个README.md文件，简要说明文件夹结构和命名规范。

5. 标注与交付：把设计意图精准传达

切图只是交付物的一部分，如何告诉开发“这里该怎么实现”同样重要。这就是标注（Specs）的工作。

5.1 标注的核心内容：尺寸、间距、颜色、字体

1. 尺寸与间距：这是标注的重中之重。标注所有元素的宽高、圆角半径，以及元素与元素之间、元素与容器边界的距离。在Figma或蓝湖中，可以直接点击元素查看其width、height和与其他元素的distance。
2. 颜色：标注所有使用的色值，包括填充色、边框色、阴影色、渐变色的起止色值。必须提供HEX和RGBA两种格式，并注明颜色对应的设计系统变量名（如--color-primary），方便开发对接全局主题。
3. 字体：标注字号（font size）、字重（font weight，如Regular、Medium、Bold）、行高（line height）、字间距（letter spacing）。同样，需要关联到设计系统的文本样式（如text-heading-h1）。
4. 阴影与模糊：标注阴影的X/Y偏移、模糊半径、扩散半径和颜色。对于背景模糊效果，需注明模糊类型（如背景模糊）和数值。
5. 可拉伸区域：对于.9.png或 Slicing 资源，必须在设计稿上清晰图示出可拉伸的区域（通常用红线标出），并单独说明。

5.2 交付流程：自动化与人工检查相结合

1. 设计稿整理：在切图前，确保你的设计稿是干净、规范的。所有图层、画板命名清晰，分组合理，使用组件和样式库。删除所有隐藏的、无用的图层。
2. 上传至协作平台：将整理好的设计稿上传至蓝湖、Zeplin等平台。平台会自动生成大部分标注和基础切图。
3. 人工补充与校验：平台不是万能的。你必须人工检查：
   • 自动标注的间距是否正确？（有时平台会识别错关联元素）
   • 所有交互状态（如按钮的按下、禁用态）是否都创建了画板并正确标注？
   • 复杂的嵌套组件的间距，平台可能无法解析，需要手动添加标注。
   • 检查自动切图的输出格式和倍率是否符合你的规范。
4. 导出切图包：对于平台无法完美处理的资源（如特定格式的SVG、.9.png），需要在设计工具中手动导出，并按照前述的文件夹结构进行组织。
5. 交付与同步：将最终的资源包（包含切图文件和设计稿链接）通过团队协作工具（如Git仓库、内部云盘）交付给开发。务必在交付时进行一次简短的同步会议，口头解释规范的重点、特殊资源的处理方式，并建立反馈渠道。

6. 高级技巧与常见问题排查

掌握了基础规范后，一些高级技巧和“坑点”能让你和团队的协作更上一层楼。

6.1 高级技巧：提升协作效率的秘诀

• 使用设计令牌（Design Tokens）：将颜色、字体、间距、圆角等视觉属性抽象为命名的变量（如$color-primary,$spacing-unit-4）。在设计工具（Figma Variables）和代码中同步这些令牌。这样，当需要修改主题色时，只需改动一个令牌值，设计和代码会自动全局更新，从根本上保证一致性。
• 为图标建立矢量组件库：将所有图标制作成Figma/Sketch的矢量组件，并严格统一画板尺寸（如24x24）。导出时，无论图标内部图形多大，都以其画板尺寸为基准输出，确保所有图标在代码中占据相同的空间，避免对齐问题。
• 处理多端差异：iOS和Android在细节上常有不同，如状态栏高度、系统图标风格、字体渲染。切图时，可以为两端准备略有差异的资源。例如，同一个返回图标，iOS用<形状，Android用←形状。在资源命名或文件夹层级上加以区分（如assets/ios/,assets/android/）。
• 自动化脚本：对于重复性的切图导出和命名工作，可以探索使用设计工具的插件或脚本（如Figma的Plugin API， Sketch的Runner）进行半自动化处理，能节省大量时间。

6.2 常见问题排查实录：那些年我们踩过的坑

即使规范再完善，实际协作中还是会遇到各种问题。这里记录几个典型场景和解决方案：

问题1：开发说图标在手机上发虚（模糊）。

• 排查思路：
  1. 检查倍率：确认提供的图片尺寸是否是设计尺寸的整数倍（2x, 3x）。提供1x图给3x屏肯定会模糊。
  2. 检查导出设置：在Figma/Sketch中导出PNG时，是否勾选了“将对象合并为位图”？对于复杂矢量图形，有时不合并会导致边缘半像素渲染问题，从而模糊。尝试勾选此选项后重新导出。
  3. 检查代码使用方式：确认开发是否正确设置了图片的显示尺寸。例如，一个48x48@2x的图，在代码中应该显示为24x24pt（逻辑点）。如果错误地设置为48x48pt，相当于被放大了一倍，也会模糊。
• 解决方案：提供正确倍率的资源，并在标注中明确写出该资源的“逻辑尺寸”（如24x24pt）和“物理尺寸”（如48x48px）。

问题2：可拉伸的背景图（.9.png或Slicing）拉伸后内容区域变形。

• 排查思路：
  1. 检查拉伸区域定义：对于.9.png，检查四周的1像素黑线是否画在了正确的位置。黑线包围的区域是可拉伸区域，黑线之外、内部区域是内容保护区域。如果按钮的文字区域被划入了可拉伸区，文字就会被拉宽。
  2. 检查切片设置：在Figma中做Slicing时，检查导出框的“Sizing”属性。对于水平拉伸的背景，应设置为“Horizontal”；对于水平和垂直都可拉伸的，应设置为“Slice”。并预览拉伸效果是否正确。
• 解决方案：重新制作.9.png或在设计工具中调整切片边界，并在交付时附上一张示意图，用箭头明确标出可拉伸的方向和内容安全区。

问题3：资源文件体积过大，影响应用加载速度或包体积。

• 排查思路：
  1. 审计资源类型：是否大量使用了PNG格式的纯色图标？是否使用了未压缩的JPG大图？
  2. 检查图片尺寸：提供的图片物理尺寸是否远大于其实际显示尺寸？例如，一个只在列表中显示为60x60px的头像，你却提供了1000x1000px的原图。
• 解决方案：
  • 格式优化：纯色/简单图标转SVG；照片类图片使用工具（如TinyPNG、ImageOptim）进行无损或有损压缩；在Web端考虑使用WebP格式。
  • 尺寸优化：根据图片最大显示尺寸来提供资源。如果用户上传的头像会显示在多个不同大小的位置，可以要求后端或CDN服务生成不同尺寸的缩略图，而不是前端加载大图再缩放。
  • 懒加载：对于非首屏图片，建议开发实现懒加载技术。

问题4：深色模式（Dark Mode）下的资源如何处理？

• 现代解决方案：对于颜色、背景等，应尽量通过设计令牌和代码逻辑实现动态切换，而不是切两套图。
• 必须切图的情况：如果图标或图片本身的内容（而非颜色）在深色模式下需要变化，则需要提供两套资源。命名上可以加后缀区分，如icon_search_light@2x.png和icon_search_dark@2x.png。并在标注中明确说明其应用场景，由开发根据系统主题动态切换。

建立并执行一套严密的UI设计切图规范，初期可能会觉得有些繁琐，但它所带来的团队协作效率提升和产品质量保障是巨大的。这不仅仅是设计师的单方面输出，更是与前端、客户端工程师达成的一种默契。规范需要在项目中不断磨合、优化和迭代。每次项目复盘时，都可以回顾一下切图环节出现的问题，并将其解决方案沉淀到规范文档中。久而久之，这套规范就会成为团队最宝贵的资产之一，让每个人都能把精力集中在创造更有价值的事情上，而不是消耗在无尽的沟通和返工上。