Figma标注与切图交付全链路：从设计稿到代码的规范实践

团队里最尴尬的一幕，大概是这样的：一个 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"到能被检索的结构

很多人觉得命名是洁癖，其实命名直接决定了后续所有自动化能不能跑起来。原因很简单：各类批量导出插件、开发者模式里的资源面板、乃至设计转代码的工具，识别"这是个图标"还是"这是个容器"，靠的就是图层类型加命名特征。

一套能用的命名规则不需要多复杂，关键是一致。我自己的习惯是：容器用页面语义，组件用组件语义，导出物用"用途_状态_尺寸"。

提示：命名里尽量不要出现空格和中文，尤其是要导出成资源文件的图层。带空格的名称在命令行、构建脚本、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 场景下的定位。左对齐、右对齐、居中、拉伸，这些规则标注出来比标坐标有用得多。标注一个绝对坐标x=137，遇到不同屏幕宽度立刻失效；标注"左边距固定 16、右边距固定 16、宽度自适应"，才是能落地的。

2.3 组件、变体与变量：把标注信息内置进去

这一步是分水岭。做了组件化的稿子，标注工作量能降一半以上，因为大量信息已经写在组件定义里了。

变体（Variants）解决的是状态问题。一个按钮的默认、按下、禁用、加载中，如果都做成变体，开发在资源面板里就能看到全部状态，不需要你再单独画一张"状态说明图"。而且变体属性名会直接暴露给开发者模式，读起来一目了然。

变量（Variables）解决的是数值问题。把主色、圆角、间距刻度定义成变量，标注时不需要逐个写数值，开发模式里会直接显示变量名和当前值。好处有两个：一是修改时全局联动，不会出现"这页改了那页忘了"；二是开发可以把变量名直接对应到自己的主题配置里，一套 token 打通设计和代码。

我一般会定三组基础变量：颜色（品牌色、中性色、语义色）、尺寸（间距刻度、圆角刻度）、字号与行高。别一上来就建几百个变量，那只会让选择变困难。够用、能覆盖八成场景就行，剩下的特例单独处理。

2.4 整理画布时顺手要做掉的四件事

第一，删掉画布外的废稿。开发者模式里能看到整页所有图层，一堆废弃的草稿会让资源面板变得无法阅读。第二，把隐藏图层确认一遍，有些图层被隐藏了但还在导出清单里，会导出空白图。第三，检查所有图片是否已填充完整，占位图要标清楚，别让开发以为是真实素材。第四，把所有用到但没嵌入的字体确认一遍，缺字体是交付后最常见、也最容易被忽略的问题。

这四件事加起来十分钟，能避免后面至少两轮返工。我现在的习惯是把它写成一个小清单放在文件首页的便签里，交付前逐条划掉。

3. 标注怎么做才对：读数、变量与静态补位

3.1 开发者模式到底解决了什么问题

Figma 的开发者模式（Dev Mode）把"读数"这件事从手工测量变成了自动读取。选中任意元素，右侧会显示它的尺寸、位置、内外边距、字号行高、颜色值、圆角、描边、阴影、混合模式，甚至可以一键复制成 CSS、Swift、Compose 等格式的代码片段。

它解决的核心痛点是"标注和实际值不一致"。以前手工标数字，稿子一动就全错；现在读数是实时的，图层怎么改，读数就跟着变。这是质的变化。

但它不是万能的，有三件事它管不了：一是规则，比如"这个列表在窄屏下变成两列"，这是逻辑不是数值；二是状态，比如加载中、空态、错误态，得你自己画出来；三是意图，比如"这里的投影要更柔和一些"，读数只能告诉你当前是多少，不能告诉开发这是刻意的还是随手拉的。

所以正确的用法是：读数交给开发者模式，规则和意图由你补写。二者缺一，标注都不算完整。

3.2 必须标出来的八类信息

把该标的列全，能避免九成的来回追问。我按实战频率排了个序。

这八项里，前五项开发者模式能帮上大忙，后三项必须靠人。很多人交付时只做了前五项，所以开发才会说"标注看不懂"——他看不懂的不是数字，是数字之外的规则。

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 写出来要几十行而且没人维护得动的。

这里有个常见的分界线值得说清楚：图标如果不涉及多色和复杂路径，优先用矢量格式；如果图标需要跟随主题变色，矢量格式也优于位图，因为颜色可以直接由代码控制。

提示：涉及第三方品牌标识、字体、图片素材时，先确认使用授权再放进交付包。这类问题通常不在技术侧暴露，而是在上线后暴露，处理起来代价很高。

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-normal@2x.png、illus-empty-order.svg、img-banner-home@2x.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 class="frame-427"这种；二是响应式规则往往缺失或者过于简化；三是大量重复样式没有抽成变量；四是可访问性属性基本没有。

我的用法是把它当成脚手架：用它生成初始结构，然后手工重构命名、抽 token、补交互和响应式。这样能省掉三成的机械劳动，但不能指望它直接把稿子变成能上线的代码。

如果团队在用支持读取设计上下文的编辑器插件，有一点要提前确认：读取权限是按文件授予的，换文件或者换团队空间之后需要重新授权。这类授权问题在多人协作里最容易卡住新人，提前把步骤写成文档放在团队空间里，比每次都临时问人要高效。

5.4 插件使用的三条纪律

第一条，不要装来源不明的插件。设计文件里往往包含未公开的产品方案，权限过宽的插件存在信息外流风险。

第二条，不要在一个文件里叠加装太多同类插件。图层面板会变得极其拥挤，而且不同插件对同一图层的处理会互相干扰。

第三条，把团队常用的插件固定下来写进规范。每个人用不同的导出插件，导出的资源命名和参数就不一样，最后合起来就是一堆乱码。统一工具，比挑选最好的工具更重要。

6. 踩坑实录：那些交付后才发现的问题

6.1 导出相关的四个高频故障

导出图片模糊。九成情况是位图被放大使用，比如切了 1x 的图，在 2 倍屏上显示。排查方法是核对资源的实际像素尺寸和它的显示尺寸，比例必须是整数倍且不小于 1。剩下的一成是 SVG 内部嵌了位图，这种就得让原稿重新处理。

导出有白边或透明边。图层边界比可视内容大了一圈，导出时把空白也带上了。解决方法是导出前把图层边界收紧，或者在导出面板里勾选裁剪选项。

导出尺寸和标注不一致。多见于描边。描边如果对齐方式是居中，那么图层实际边界会比视觉边界大描边宽度的一半。标注 24×24 的图标，实际图层可能是 25×25，导出就是 25 像素。解决方法是把描边改成内描边，或者手工修正边界。

同一个图标颜色不对。SVG 里写死了填充色，代码侧改了颜色没生效。解决方法是导出时把填充改成currentColor，让颜色由代码控制。这个改动很小，但影响很大，尤其是需要跟随主题变色的图标。

6.2 字体与文本：交付后最容易暴露的问题

字体缺失排第一。设计稿里用了系统没装的字体，开发打开文件看到的是替代字体，字号行高全乱。交付前必须确认字体的可用性：如果是商用字体，确认授权范围；如果是系统字体，确认目标平台是否都有；如果是自定义字体，把字体文件和引用方式一起交出去。

文本换行不一致排第二。同一个文案，设计稿里一行，实际渲染成两行，高度差直接导致布局错位。原因是字间距、行高、字体渲染差异的叠加。解决办法是标注时给出"最长显示字数"和"超出后的处理方式"，而不是指望换行位置永远一致。

文字被截断排第三。多出现在按钮和标签上。建议在标注里明确写清楚：单行不换行、超出用省略号、容器宽度固定还是自适应。

6.3 颜色与阴影：看起来一样，数值差很多

颜色对不上通常有三个来源。一是设计稿里用了透明度叠加，实际渲染出来的颜色是混合后的结果，开发直接取十六进制值就偏了。二是色彩空间不同，某些工具会做色彩管理，同一个数值在不同环境显示略有差异。三是阴影和背景叠加，导致感知颜色变化。

处理方式是把透明度标清楚，或者干脆把混合后的最终值算出来直接给开发。阴影则要标全参数：水平偏移、垂直偏移、模糊半径、扩散半径、颜色与透明度。多层阴影要逐层标。

顺带提醒一句，渐变的标注经常被漏掉。线性渐变要标方向角或者起止点坐标，径向渐变要标中心点和半径，否则开发只能凭感觉调，来来回回能耗掉半天。

6.4 沟通卡点：开发说"看不懂标注"时怎么破

遇到这句话，先别急着解释，先问三个问题：你是在哪个页面卡住的？你需要的数值我在哪里没写？如果按你的理解，这个间距应该是多少？

第一个问题定位范围，第二个问题定位缺失项，第三个问题往往能直接暴露理解偏差。我遇到过好几次，开发其实不是看不懂标注，而是他假设了某种布局规则，而我在稿子上表达的是另一种。这时候补一句文字说明就够了，不需要重做标注。

再分享一个实用的小办法：在交付文件里放一个"提问区"便签，谁有疑问直接在上面写，集中解决。比在聊天工具里刷屏高效得多，也留下了记录。

7. 一套可以照着做的交付清单

7.1 交付前的自检顺序

我自己的顺序是固定的，换项目也不变：结构整理 → 命名统一 → 变量化 → 检查字体 → 打开开发者模式通读一遍 → 补齐静态标注 → 列切图清单 → 按规范导出 → 抽查渲染效果 → 打包附说明。

这个顺序里有个关键点值得强调：开发者模式通读一遍这一步不能省。它会强迫你以开发的视角看一次自己的稿子，很多平时看不见的问题在这一步会暴露出来，比如某个元素没有用 Auto Layout 导致间距读不出来，比如某个颜色是硬编码的，比如某个图层被隐藏了但仍在导出列表里。

7.2 交付包该包含什么

一份完整的交付包包含四部分：设计文件链接（并开启正确的权限）、资源文件目录、token 定义文件、以及一份验收说明。

资源目录按类型分包，命名统一，倍率齐全。token 文件用统一的格式，方便代码侧直接引用。验收说明写清楚每个页面的关键尺寸和规则，让测试能逐条对照。

注意：交付链接的权限设置要和交付对象匹配。给外部合作方时只给查看权限，避免误改主文件。这一点在跨团队协作里最容易出问题，改错一次可能影响好几天的进度。

7.3 长期维护：让这份交付不要过期

设计文件是会过期的。三个月后有人改了一个间距，没通知任何人，代码和设计就悄悄分叉了。防这种情况，靠的是约定而不是工具。

我的做法是给每个页面在说明区标一个版本号和更新时间，改动大的时候同步更新。同时把组件化的范围扩大——凡是能抽成组件的都抽出来，改一处全局生效，减少"只改了一个页面"这种局部修改的机会。

7.4 最后几句实在话

我从截图交付一路走到现在的变量加开发者模式，最大的感受是：工具在进步，但交付质量的分水岭从来不在工具上，而在有没有把"对方拿到之后能不能一次做完"当成自己的责任。

插件可以装几十个，模板可以存几十套，但如果图层还是叫Frame 427，颜色还是散落的十六进制，切图还是想切哪张切哪张，那不管用什么工具，交付都还停在"传文件"的阶段。

我自己踩过最惨的一次坑，是一整套活动的切图全部按 1x 导出，上线之后在大屏手机上一片模糊，半夜重新导出重新提包。那次之后我养成了一个习惯：任何资源交付前，先在真机上把关键页面过一遍，尤其是图标和插画。这一步花五分钟，能省掉一个通宵。

还有一个一直很管用的小技巧：把常用的标注文字做成组件，比如"超出截断：单行省略号""最长 12 字，超出换行"。拖出来改两个字就能用，比每次重新敲一遍快得多，也保证了措辞一致。这种小积木攒得越多，交付这件事就越不像在打仗。