团队里最尴尬的一幕大概是这样的一个 Figma 用得很熟的同事画稿飞快组件、变体、自动布局都玩得很溜稿子也干净结果一到交付环节甩来一句你按这个截图做吧间距你估一下。对面接手的开发也懒得多问两张图贴进项目代码写完还原度七成剩下三成靠来回拉扯。最后复盘谁都没错但谁都憋屈。标注和切图这两件事在 Figma 已经普及到这种程度的今天依然有人问、依然有人做不明白原因从来不是软件不会用而是没把设计稿到实现这一步当成一条正经的交付链路来设计。会画不等于会交付会用工具不等于能省别人的时间。这篇东西聊的就是这条链路Figma 里的标注该怎么标、标到什么颗粒度切图该怎么判断、用什么格式、怎么命名、导出来往哪放哪些工作可以交给工具自动完成哪些必须人来做判断以及最容易踩的那些坑比如导出模糊、颜色对不上、开发说看不懂标注到底卡在哪儿。不管你是刚接手交付工作的设计师还是被设计稿折磨过几百次的前端或者是要验收还原度的测试和产品都能从里面挑到能直接用的东西。1. 为什么会用 Figma和能交付是两码事1.1 标注和切图的本质是信息压缩不是画图很多人对标注的理解停留在在图上标数字。这其实只看到了结果没看到目的。设计稿是给人看的代码是给机器执行的这两者之间隔着一层不可逆的信息损耗人看一眼能理解这里大概空一点机器只认margin: 12px。标注干的事就是把大概差不多感觉这些模糊词压缩成一组精确、可复现、无歧义的数值和描述。切图同理。设计师眼里那个搜索结果的小图标到代码里可能是一个 24×24 的 SVG、一个 72×72 的位图、或者字体图标里的一个码位。选错了载体后面就是无休止的修改图标放大就糊、颜色改不了、打包体积暴涨。所以这条链路的第一个认知转折是交付物的第一读者不是人是下一个要动手的人手里的那套工具链。你要照顾的不是他能不能看懂图而是他能不能不看图就写出来。判断标准很简单——如果他需要给你发消息问第二遍说明你的标注还没做完。我见过最典型的反例一整套流程、一页详情页所有间距都靠一条水平参考线加一句统一 16 的倍数。看起来很规整实际上开发要自己去猜每一个元素属于哪一档。这不是标注这是谜题。1.2 三种角色在交付环节的诉求完全不同把一个界面交付出去收到它的人有三拨各自关心的事情差异极大混在一起谈必然出问题。设计师关心的是能不能还原我的设计意图尤其是那些视觉上很微妙的部分——投影的柔度、边框的透明度、渐变的方向。前端关心的是这些数字能不能直接落成代码他需要数值、需要单位、需要知道哪些是弹性的哪些是固定的。测试关心的是我怎么判断它对不对他需要的是一份可以逐条对照的验收清单而不是一张图加一句照着来。这三拨人的需求是可以统一在一份交付物里的但前提是你得分开写。把数值和规则写在一起把验收标准单独列一段把设计意图里的为什么这样作为补充说明。这比多花十分钟能省掉后面几轮返工。顺带说一句产品经理往往还有第四种诉求他需要知道这份稿子在极端情况下长什么样——文字超长、数据为空、图片加载失败、网络异常。这类状态不标出来上线后一定会出问题而且出问题的时候通常没人认账。1.3 五个高频误区看看你中了几个截图交付把画布框一块截下来发给开发。截图丢失了所有结构化信息颜色被压缩、边缘有锯齿、尺寸不精确开发只能靠肉眼估。口头描述在群里说这个按钮圆角再大一点点。一点点是多少下次还能复现吗一把梭全导出把所有图层都导出成 PNG包括那些本来就该用 CSS 写的圆角矩形和渐变。包里多出几十个没用的文件维护时没人敢删。标注和实际值不一致稿子上写的间距是 16但图层实际位置差 3 像素开发按标注写完发现对不上从此不信任你的标注。只标静态稿不标规则给了三个断点但没说断点之间怎么过渡。开发只能自己拍脑袋结果就是大屏看着还行中间尺寸全乱。这五个坑里前三个是习惯问题后两个是认知问题。习惯好改认知得靠流程约束。我自己的做法是交付前强制自己用陌生人视角走一遍——假设我明天离职接手的人只有这份文件他能不能独立做完1.4 一个健康的交付流程大概长什么样流程不复杂但要固定下来整理画布结构 → 建立变量和样式 → 打开开发者模式的读数 → 补齐静态标注 → 判断切图清单 → 按规范导出并命名 → 打包输出并附验收清单。真正决定效率的不是单步做得多快而是顺序对不对。先整理结构再标注标注就是体力活先标注再整理结构那就是白干——图层一动所有手写的标注全部错位。这个顺序上的浪费我在早期项目里吃过不止一次。2. 图层结构决定交付上限动手前先整理画布2.1 命名规范从Frame 427到能被检索的结构很多人觉得命名是洁癖其实命名直接决定了后续所有自动化能不能跑起来。原因很简单各类批量导出插件、开发者模式里的资源面板、乃至设计转代码的工具识别这是个图标还是这是个容器靠的就是图层类型加命名特征。一套能用的命名规则不需要多复杂关键是一致。我自己的习惯是容器用页面语义组件用组件语义导出物用用途_状态_尺寸。图层类型错误示范可用的命名说明页面容器Frame 427OrderDetail / Page用业务语义方便跳转定位区块Group 88OrderDetail-Header区块名前缀带上所属页面组件实例Button/Primary/DefaultButton-Primary-Default斜杠在 Figma 里会形成层级注意别乱用图标Vector 12icon-search-normal前缀统一方便批量筛选导出插画未命名illus-empty-order明确是插画避免和图标混淆待导出位图image 1img-banner-home-750带上宽度避免后期忘记倍率提示命名里尽量不要出现空格和中文尤其是要导出成资源文件的图层。带空格的名称在命令行、构建脚本、URL 里都可能被截断或转义后期排查起来非常烦。一个额外的小技巧给所有需要导出的图层加统一的英文前缀比如图标统一以icon-开头。之后在图层面板里按名称排序所有图标会自动聚在一起勾选导出时不会漏也不会多。这个习惯看着土实测下来省的时间比任何插件都多。2.2 Auto Layout 与约束让间距可以推导而不是靠量手工量间距是低效交付的万恶之源。为什么因为你量出来的是一组孤立的数字开发拿到之后只能一对一硬编码一旦内容变化整个布局就崩了。Auto Layout 的价值在于它把间距从结果变成了规则。你设置的itemSpacing就是元素之间的实际间距padding 就是容器内边距开发看到的不再是一堆散点而是一套可以映射到display: flex; gap的结构。举个具体的例子。一个列表卡片内部结构是图标 标题 副标题右侧跟一个箭头。手工画的话你得分别量图标到文字的间距、标题到副标题的间距、内容到右边的间距。用 Auto Layout 的话外层一个水平容器 padding 设置为 16/12内层一个垂直容器 gap 为 4图标与文字之间的 gap 为 12。这时候开发要读的只有四个数字而且每个数字都对应一个明确的 CSS 属性。约束Constraints则负责非 Auto Layout 场景下的定位。左对齐、右对齐、居中、拉伸这些规则标注出来比标坐标有用得多。标注一个绝对坐标x137遇到不同屏幕宽度立刻失效标注左边距固定 16、右边距固定 16、宽度自适应才是能落地的。2.3 组件、变体与变量把标注信息内置进去这一步是分水岭。做了组件化的稿子标注工作量能降一半以上因为大量信息已经写在组件定义里了。变体Variants解决的是状态问题。一个按钮的默认、按下、禁用、加载中如果都做成变体开发在资源面板里就能看到全部状态不需要你再单独画一张状态说明图。而且变体属性名会直接暴露给开发者模式读起来一目了然。变量Variables解决的是数值问题。把主色、圆角、间距刻度定义成变量标注时不需要逐个写数值开发模式里会直接显示变量名和当前值。好处有两个一是修改时全局联动不会出现这页改了那页忘了二是开发可以把变量名直接对应到自己的主题配置里一套 token 打通设计和代码。我一般会定三组基础变量颜色品牌色、中性色、语义色、尺寸间距刻度、圆角刻度、字号与行高。别一上来就建几百个变量那只会让选择变困难。够用、能覆盖八成场景就行剩下的特例单独处理。2.4 整理画布时顺手要做掉的四件事第一删掉画布外的废稿。开发者模式里能看到整页所有图层一堆废弃的草稿会让资源面板变得无法阅读。第二把隐藏图层确认一遍有些图层被隐藏了但还在导出清单里会导出空白图。第三检查所有图片是否已填充完整占位图要标清楚别让开发以为是真实素材。第四把所有用到但没嵌入的字体确认一遍缺字体是交付后最常见、也最容易被忽略的问题。这四件事加起来十分钟能避免后面至少两轮返工。我现在的习惯是把它写成一个小清单放在文件首页的便签里交付前逐条划掉。3. 标注怎么做才对读数、变量与静态补位3.1 开发者模式到底解决了什么问题Figma 的开发者模式Dev Mode把读数这件事从手工测量变成了自动读取。选中任意元素右侧会显示它的尺寸、位置、内外边距、字号行高、颜色值、圆角、描边、阴影、混合模式甚至可以一键复制成 CSS、Swift、Compose 等格式的代码片段。它解决的核心痛点是标注和实际值不一致。以前手工标数字稿子一动就全错现在读数是实时的图层怎么改读数就跟着变。这是质的变化。但它不是万能的有三件事它管不了一是规则比如这个列表在窄屏下变成两列这是逻辑不是数值二是状态比如加载中、空态、错误态得你自己画出来三是意图比如这里的投影要更柔和一些读数只能告诉你当前是多少不能告诉开发这是刻意的还是随手拉的。所以正确的用法是读数交给开发者模式规则和意图由你补写。二者缺一标注都不算完整。3.2 必须标出来的八类信息把该标的列全能避免九成的来回追问。我按实战频率排了个序。序号标注项具体内容常见遗漏1尺寸与间距宽高、内外边距、元素间隔忽略默认字号带来的行高差2字体字族、字号、字重、行高、字间距只写字号不写行高3颜色文字色、背景色、描边色、透明度忽略透明度叠加后的实际值4圆角与描边各角圆角、描边宽度与对齐方式描边是内描边还是外描边5阴影与层次偏移、模糊、扩散、颜色多层阴影只标一层6布局规则对齐方式、自适应策略、断点变化只给一个尺寸的设计稿7状态默认、悬停、按下、禁用、加载、错误交互态完全没画8边界情况超长文本、空数据、图片缺失、极限数量上线后才发现这八项里前五项开发者模式能帮上大忙后三项必须靠人。很多人交付时只做了前五项所以开发才会说标注看不懂——他看不懂的不是数字是数字之外的规则。3.3 用变量替代硬编码让标注能跟着改假设品牌色从深蓝调成浅蓝。如果所有稿子里的颜色都是硬编码的十六进制值你得挨个改改完还得重新标注一遍开发也要跟着改一遍。如果用的是变量改一处全项目的引用一起变开发那边只需要改 token 定义里的一个值。具体做法是把颜色、间距、圆角、字号全部变量化并在命名上保持和代码侧一致。比如设计侧叫color/brand/primary代码侧的 token 就叫color-brand-primary中间只差一个分隔符映射关系一眼可见。{ color: { brand: { primary: #2B6CFF, primaryHover: #1F55D6 }, text: { primary: #1A1D23, secondary: #5C6370, disabled: #A8ADB8 }, bg: { page: #F5F6F8, card: #FFFFFF } }, space: { xs: 4px, sm: 8px, md: 12px, lg: 16px, xl: 24px }, radius: { sm: 4px, md: 8px, lg: 12px, full: 9999px } }这份 token 文件本身就是最好的标注。开发拿到它不需要再去稿子里挨个抄数值前端只要写padding: var(--space-lg)和设计侧的space/lg一一对应。后面新增页面时只有特例需要单独沟通。注意变量命名千万别用蓝色一号、大圆角这种描述性命名。一旦品牌色换了蓝色一号变成了橙色命名就成了笑话。用语义命名比如brand、danger、surface色值变了名字也不用变。3.4 静态标注还得补什么变量和开发者模式覆盖了主体剩下的部分要靠静态标注补位。我一般会在画布旁边留一块说明区用文字加箭头的方式写清楚四类内容。第一类是交互说明点击哪里跳转哪里、滑动手势的方向、长按是否有菜单。这类信息在视觉稿里完全看不出来但开发必须知道。第二类是异常状态接口失败显示什么、超时显示什么、权限不足显示什么。通常只要一个文案加一个插画但必须画出来。第三类是边界规则名字最长显示几个字、超出用什么方式截断、列表最多显示几条、超过之后如何翻页。这类规则写清楚能省掉大量这里怎么处理的追问。第四类是动效意图从哪个方向进入、持续多久、是否循环。动效没法用静态图表达写清楚参数比画十帧更有效。3.5 标注的颗粒度怎么把握标太细一页几十个数字开发看着就烦标太粗等于没标。我的经验是把标注定在会不一致的地方。判断方法很简单凡是你在画稿时做过一次以上主观决定的数值就该标。比如这个列表项高度设为 64 是因为刚好放得下两行字那 64 就该标而整个页面左右各 16 的边距这种全局规则写一次在首页说明里就够了不需要每一屏都重复。还有一个反直觉的建议不要把开发者模式能自动读出的东西再手写一遍。重复标注除了制造不一致没有任何价值。留出时间去标那些读不出来的规则收益高得多。4. 切图全流程判断、参数、命名、落地4.1 先判断该不该切这是最容易做错的一步切图做错的成本比标注高得多因为多导出的文件会进包体、进构建流程后期清理起来很麻烦。判断原则其实就一句话能用代码画出来的就不要切图。按这个原则过一遍大部分元素都不该切。纯色背景、圆角矩形、单色边框、简单渐变、纯色文字这些用 CSS 几行就写完了切图反而会带来模糊、无法换主题、体积膨胀三个问题。真正该切的主要是这几类复杂矢量图标、多色插画、位图照片、以及极端复杂的装饰性图形——那种用 CSS 写出来要几十行而且没人维护得动的。这里有个常见的分界线值得说清楚图标如果不涉及多色和复杂路径优先用矢量格式如果图标需要跟随主题变色矢量格式也优于位图因为颜色可以直接由代码控制。元素类型推荐做法理由纯色按钮不切CSS 实现可换色、无模糊、体积小单色线性图标切 SVG可缩放、可改色、体积小多色扁平插画切 SVG 或高清位图视复杂度决定照片、真实图像切位图多倍率必须保留细节复杂装饰背景视情况优先 CSS 渐变用代码写更易维护第三方品牌标识切 SVG注意授权保持原样不失真提示涉及第三方品牌标识、字体、图片素材时先确认使用授权再放进交付包。这类问题通常不在技术侧暴露而是在上线后暴露处理起来代价很高。4.2 格式与倍率数字是怎么算出来的格式选择的逻辑很直接。矢量图形用 SVG位图用 PNG 或 WebP需要打印或高保真输出时用 PDF。JPG 只适合照片类且不需要透明通道的场景因为它有损压缩会在边缘产生杂色。倍率的计算是很多人含糊的地方这里说透。设计稿如果按 375 宽绘制那它是 1 倍逻辑宽度。要让它在 2 倍密度屏幕上清晰就要导出 750 像素宽的资源3 倍屏则导出 1125 像素宽。具体到图标一个在稿子上标注为 24×24 的图标各倍率下的导出尺寸是1x → 24×24 像素2x → 48×48 像素3x → 72×72 像素对应到移动端的密度分组大约是 1x 对应 mdpi、2x 对应 xhdpi、3x 对应 xxhdpi。实际项目里不必每种都出常见做法是出 1x/2x/3x 三套或者干脆只出矢量图让系统自己缩放。Web 端的情况略有不同。现在主流的做法是位图只出 2x配合srcset让浏览器按需选择或者干脆用 WebP 加降级方案。多倍率的好处是清晰代价是体积和构建复杂度。我的建议是图标和简单插画全部走 SVG只有照片类走多倍率位图这样能把整体资源体积压下来一大截。导出参数上还有几个容易忽略的点。SVG 导出时注意是否包含图层 ID勾上会让文件变大且不利于缓存描边要确认是转成了路径还是保留描边属性转路径更稳但不可编辑。位图导出时注意是否裁剪到图层边界不裁剪会导出一圈透明边前端拿到之后发现图标看着变小了其实就是这个透明边在作祟。4.3 命名规范与批量导出命名是切图环节里回报率最高的投入。一套规则定好之后前端引用、构建打包、缓存更新全都能省事。我用的规则是类型-用途-状态-倍率用短横线连接全小写。比如icon-search-normal2x.png、illus-empty-order.svg、img-banner-home2x.webp。批量导出的流程可以这样跑给所有待导出图层加统一前缀 → 在图层面板按名称排序 → 逐个勾选导出设置 → 在导出面板里一次性选中多张 → 导出到本地文件夹。如果项目里资源量大可以进一步用脚本做批量重命名和归类。下面这段脚本的作用是把导出目录里的文件按前缀分到不同子目录顺手把2x、3x这类后缀统一成构建工具习惯的形式。#!/usr/bin/env bash # 把导出的资源按前缀归类到 icons / images / illustrations set -euo pipefail SRC./export DST./assets mkdir -p $DST/icons $DST/images $DST/illustrations for f in $SRC/*; do name$(basename $f) case $name in icon-*) mv $f $DST/icons/$name ;; img-*) mv $f $DST/images/$name ;; illus-*) mv $f $DST/illustrations/$name ;; *) echo 未匹配前缀跳过: $name ;; esac done echo 归类完成共处理 $(ls -1 $DST/* | wc -l) 个文件脚本本身很土但它强制了命名规范。凡是没按前缀命名的文件都会被跳过等于给你一个自动化的检查项。跑两次之后团队里所有人都会记得改名字。4.4 资源落地从导出到进项目之间还差一段导出完成不等于交付完成。中间还有几件事。第一是校验。把导出的资源在目标环境里实际渲染一遍看看有没有模糊、有没有白边、有没有尺寸错位。最常见的模糊原因是位图被放大使用或者 SVG 里带了位图。第二是瘦身。SVG 用工具去掉无用属性位图按需压缩通常能压掉三到六成的体积。第三是目录结构。按类型分目录比按页面分目录更好维护因为图标是跨页面复用的。第四是版本管理。资源文件不要直接覆盖改动大的时候在提交信息里写清楚改了哪个图标、为什么改。这一条听着啰嗦但等到线上某个图标突然变了样你会感谢自己当初留了记录。5. 插件与外部工具怎么选5.1 标注类插件什么时候需要什么时候不需要官方开发者模式覆盖了绝大多数读数需求所以标注类插件的作用已经大幅收窄。它们现在主要解决两类问题一是需要把标注导出成一份独立文档交给外部合作方二是需要在一个视图里看全所有元素的数值而不是逐个点选。选插件时看三点是否还在维护、权限是否较宽、导出格式是否通用。权限这一条尤其要注意很多插件要求读取文件全部内容甚至访问外部网络装之前想清楚它是不是真的需要这些权限。5.2 切图与资源类插件解决的是批量问题这类插件的价值在批量场景里最明显。比如一次性导出一个页面所有带特定前缀的图标、自动按倍率生成多套资源、导出时自动按命名规则重命名。手工做十张图不费劲做一百张就完全是另一回事了。但要注意插件生成的结果一定要抽查。尤其是自动命名和自动倍率不同插件的行为差异很大有的会把2x加在扩展名之前有的加在之后直接扔进构建流程可能会找不到文件。5.3 设计转代码类工具能省力但不能省脑子这两年设计转代码的工具进步很快从最早的导出静态 HTML到能读取设计上下文、生成组件代码甚至通过一些协议让编辑器直接读取设计文件的内容。这类工具有个共同特点生成的代码是起点不是终点。生成出来的代码通常在结构上没问题但有几个系统性缺陷。一是命名是机器味div classframe-427这种二是响应式规则往往缺失或者过于简化三是大量重复样式没有抽成变量四是可访问性属性基本没有。我的用法是把它当成脚手架用它生成初始结构然后手工重构命名、抽 token、补交互和响应式。这样能省掉三成的机械劳动但不能指望它直接把稿子变成能上线的代码。如果团队在用支持读取设计上下文的编辑器插件有一点要提前确认读取权限是按文件授予的换文件或者换团队空间之后需要重新授权。这类授权问题在多人协作里最容易卡住新人提前把步骤写成文档放在团队空间里比每次都临时问人要高效。5.4 插件使用的三条纪律第一条不要装来源不明的插件。设计文件里往往包含未公开的产品方案权限过宽的插件存在信息外流风险。第二条不要在一个文件里叠加装太多同类插件。图层面板会变得极其拥挤而且不同插件对同一图层的处理会互相干扰。第三条把团队常用的插件固定下来写进规范。每个人用不同的导出插件导出的资源命名和参数就不一样最后合起来就是一堆乱码。统一工具比挑选最好的工具更重要。6. 踩坑实录那些交付后才发现的问题6.1 导出相关的四个高频故障导出图片模糊。九成情况是位图被放大使用比如切了 1x 的图在 2 倍屏上显示。排查方法是核对资源的实际像素尺寸和它的显示尺寸比例必须是整数倍且不小于 1。剩下的一成是 SVG 内部嵌了位图这种就得让原稿重新处理。导出有白边或透明边。图层边界比可视内容大了一圈导出时把空白也带上了。解决方法是导出前把图层边界收紧或者在导出面板里勾选裁剪选项。导出尺寸和标注不一致。多见于描边。描边如果对齐方式是居中那么图层实际边界会比视觉边界大描边宽度的一半。标注 24×24 的图标实际图层可能是 25×25导出就是 25 像素。解决方法是把描边改成内描边或者手工修正边界。同一个图标颜色不对。SVG 里写死了填充色代码侧改了颜色没生效。解决方法是导出时把填充改成currentColor让颜色由代码控制。这个改动很小但影响很大尤其是需要跟随主题变色的图标。6.2 字体与文本交付后最容易暴露的问题字体缺失排第一。设计稿里用了系统没装的字体开发打开文件看到的是替代字体字号行高全乱。交付前必须确认字体的可用性如果是商用字体确认授权范围如果是系统字体确认目标平台是否都有如果是自定义字体把字体文件和引用方式一起交出去。文本换行不一致排第二。同一个文案设计稿里一行实际渲染成两行高度差直接导致布局错位。原因是字间距、行高、字体渲染差异的叠加。解决办法是标注时给出最长显示字数和超出后的处理方式而不是指望换行位置永远一致。文字被截断排第三。多出现在按钮和标签上。建议在标注里明确写清楚单行不换行、超出用省略号、容器宽度固定还是自适应。6.3 颜色与阴影看起来一样数值差很多颜色对不上通常有三个来源。一是设计稿里用了透明度叠加实际渲染出来的颜色是混合后的结果开发直接取十六进制值就偏了。二是色彩空间不同某些工具会做色彩管理同一个数值在不同环境显示略有差异。三是阴影和背景叠加导致感知颜色变化。处理方式是把透明度标清楚或者干脆把混合后的最终值算出来直接给开发。阴影则要标全参数水平偏移、垂直偏移、模糊半径、扩散半径、颜色与透明度。多层阴影要逐层标。顺带提醒一句渐变的标注经常被漏掉。线性渐变要标方向角或者起止点坐标径向渐变要标中心点和半径否则开发只能凭感觉调来来回回能耗掉半天。6.4 沟通卡点开发说看不懂标注时怎么破遇到这句话先别急着解释先问三个问题你是在哪个页面卡住的你需要的数值我在哪里没写如果按你的理解这个间距应该是多少第一个问题定位范围第二个问题定位缺失项第三个问题往往能直接暴露理解偏差。我遇到过好几次开发其实不是看不懂标注而是他假设了某种布局规则而我在稿子上表达的是另一种。这时候补一句文字说明就够了不需要重做标注。再分享一个实用的小办法在交付文件里放一个提问区便签谁有疑问直接在上面写集中解决。比在聊天工具里刷屏高效得多也留下了记录。现象大概率原因处理方式图片模糊位图被放大使用补足倍率或改矢量图标变色无效SVG 内写死填充色改用 currentColor布局在中间尺寸错乱只给了首尾两个断点补断点或改用弹性布局按钮文字换行未约定单行与截断规则补充文本规则标注阴影过重或过轻多层阴影只实现了一层逐层标注阴影参数圆角看着不对各角圆角不一致未标注分别标注四角圆角列表项高度跳动未规定最小高度补充最小高度与对齐方式颜色偏色透明度叠加未换算提供最终混合色值7. 一套可以照着做的交付清单7.1 交付前的自检顺序我自己的顺序是固定的换项目也不变结构整理 → 命名统一 → 变量化 → 检查字体 → 打开开发者模式通读一遍 → 补齐静态标注 → 列切图清单 → 按规范导出 → 抽查渲染效果 → 打包附说明。这个顺序里有个关键点值得强调开发者模式通读一遍这一步不能省。它会强迫你以开发的视角看一次自己的稿子很多平时看不见的问题在这一步会暴露出来比如某个元素没有用 Auto Layout 导致间距读不出来比如某个颜色是硬编码的比如某个图层被隐藏了但仍在导出列表里。7.2 交付包该包含什么一份完整的交付包包含四部分设计文件链接并开启正确的权限、资源文件目录、token 定义文件、以及一份验收说明。资源目录按类型分包命名统一倍率齐全。token 文件用统一的格式方便代码侧直接引用。验收说明写清楚每个页面的关键尺寸和规则让测试能逐条对照。注意交付链接的权限设置要和交付对象匹配。给外部合作方时只给查看权限避免误改主文件。这一点在跨团队协作里最容易出问题改错一次可能影响好几天的进度。7.3 长期维护让这份交付不要过期设计文件是会过期的。三个月后有人改了一个间距没通知任何人代码和设计就悄悄分叉了。防这种情况靠的是约定而不是工具。我的做法是给每个页面在说明区标一个版本号和更新时间改动大的时候同步更新。同时把组件化的范围扩大——凡是能抽成组件的都抽出来改一处全局生效减少只改了一个页面这种局部修改的机会。7.4 最后几句实在话我从截图交付一路走到现在的变量加开发者模式最大的感受是工具在进步但交付质量的分水岭从来不在工具上而在有没有把对方拿到之后能不能一次做完当成自己的责任。插件可以装几十个模板可以存几十套但如果图层还是叫Frame 427颜色还是散落的十六进制切图还是想切哪张切哪张那不管用什么工具交付都还停在传文件的阶段。我自己踩过最惨的一次坑是一整套活动的切图全部按 1x 导出上线之后在大屏手机上一片模糊半夜重新导出重新提包。那次之后我养成了一个习惯任何资源交付前先在真机上把关键页面过一遍尤其是图标和插画。这一步花五分钟能省掉一个通宵。还有一个一直很管用的小技巧把常用的标注文字做成组件比如超出截断单行省略号最长 12 字超出换行。拖出来改两个字就能用比每次重新敲一遍快得多也保证了措辞一致。这种小积木攒得越多交付这件事就越不像在打仗。