我见过太多次这样的场面一个同学 Figma 已经用了两三年组件库搭得整整齐齐Variables 也配了可一到交付那一步群里还是那句老话——这个帮我切一下间距标一下。问题不在于他会不会用 Figma而在于他从没把「标注」和「切图」当成一门需要专门设计的手艺。Figma 这个工具本身早就把答案摆在那儿了Dev Mode、变量、Auto Layout、批量导出、Code Connect一样不缺。真正卡住人的是交付链路上那些没人写进文档里的默认规则——谁负责切、切什么格式、标到什么颗粒度、哪些信息本该由结构表达而不是靠人肉口述。这篇内容我打算把这件事从头到尾捋一遍一套 Figma 设计稿从画完到交给开发、再到上线中间关于标注和切图的所有关键决策点。适合三类人看——刚接手交付工作的设计师、需要自己从设计稿里扒资源的前端、以及带着小团队想把流程固定下来的负责人。不管你 Figma 处在哪个水平看完至少能做到两件事不再问这个图怎么切不再靠截图加红框去标间距。1. 先把标注和切图这两件事说清楚1.1 设计语境下的标注到底在标什么标注这个词在不同行当里指的东西差得很远。机械制图里说 1:2.5问的是锥度还是斜度那是一套完全独立的符号体系写论文时参考文献连续引用怎么标注 [1-3]那是排版规则做模型训练的人说数据标注脑子里浮现的是 labelme、CVAT 这类工具标的是框和掩码。而在 Figma 这个语境里标注只有一个意思把设计稿里隐含的实现信息显式地表达出来让开发不用猜。它标的东西其实就那么几类。第一类是几何信息尺寸、间距、圆角、描边宽度、元素的对齐关系。第二类是视觉信息颜色值、透明度、字体字号字重、行高字距、阴影和模糊参数。第三类是结构与行为信息层级关系、哪个容器会撑开、哪个元素是固定的、超长文本怎么处理、不同状态之间怎么切换。第四类是资源信息哪些节点需要导出成图片或矢量、导出成什么格式、什么倍率、叫什么名字。这四类里前两类 Figma 早在几年前就能自动给出了选中一个元素右边栏全部列出来。真正让人反复问的永远是第三类和第四类——因为它们无法被读取只能被规定。你不在稿子里说清楚输入框聚焦时边框变什么颜色开发就只能来问你你不说这个图标导出 24 还是 32开发就只能自己猜一个。所以标注这件事的本质不是把数字抄下来而是把设计决策翻译成可实现、无歧义的约束。理解了这一点后面所有的工具选择才有意义。Auto Layout 不是排版玩具它是几何信息的结构化表达Variables 不是主题切换的噱头它是视觉信息的唯一真源Dev Mode 不是给开发看的皮肤它是第三类和第四类信息的承载容器。1.2 切图不是导出一张图那么简单很多人对切图的理解停留在右键导出 PNG。真做起来会发现同一张设计稿交给不同的人切产出能差出十万八千里有人导的图标边缘被裁掉半个像素有人导的插画是 1x 放到 2x 屏上糊成一团有人导了 40 个 PNG 却没一个能对上代码里的文件名。切图这件事本质上要同时满足四个约束。格式约束这个资源是矢量的还是位图的、要不要透明通道、会不会有渐变和阴影。尺寸约束在什么屏幕密度下使用、需要几套倍率、逻辑尺寸和物理像素怎么换算。体积约束一张首屏插画导出来 800KB用户流量是实打实被吃掉的这时候该考虑压缩格式和分级加载。命名约束这是最容易被忽略但代价最高的一条——如果导出的文件名和代码里的引用路径对不上开发就得手动重命名几十个文件改一次就是一次人为失误的机会。我个人的习惯是把切图当成一次数据交付而不是一次文件导出。你在导出之前脑子里应该已经有目标目录长什么样、文件名长什么样、构建工具怎么引用它。这个念头一旦建立切片的方式、命名的方式、目录的组织方式全都会跟着变后面第三章会展开讲具体怎么做。1.3 为什么工具升级了问题却没消失这里有个反直觉的现象Figma 每年都在变强可标注切图这四个字在群里的出现频率并没有明显下降。原因有三个都挺现实。第一工具的默认行为不一定匹配团队的实际约定。Figma 默认按 pt 显示尺寸但你团队可能全用 pxFigma 导出时默认用图层名当文件名但你的图层名是矩形 12Figma 的间距显示的是测量值而 Auto Layout 里的 gap 和 padding 叠加后量出来可能是另一个数。这些差异不会自己消失必须有人去对齐。第二信息只有被放在对的位置才会被看见。你把交互备注写在一个没人会打开的隐藏 Frame 里等于没写。Figma 有专门承载这类信息的位置——Annotations、组件描述、页面说明、Dev Mode 的状态标记。放错地方的信息就是噪音。第三AI 工具让一部分人产生了不需要规范了的错觉。现在确实有工具能把 Figma 节点读给 AI 编码助手让模型直接吐出一段页面代码也有工具把设计稿里的组件映射到代码仓库里的真实组件。但这些工具读的是结构数据不是像素。你稿子里的间距是随手拖的 13px、颜色用了三种近似蓝AI 照样会把这份混乱一比一复刻到代码里只是速度更快而已。工具越强前期规范的收益越大这个逻辑没变过。2. 让设计稿自带规格标注的地基怎么打2.1 Auto Layout把间距写进结构里如果说标注有地基那一定是 Auto Layout。原因很简单Auto Layout 把间距从一次测量变成了一次声明。你设了 gap 是 12那就是 12开发看到的也是 12你用两个 Group 上下摆放中间的间距是你手动拖出来的 12.3开发量出来是 12但换个屏幕就崩了。实际用起来有几条经验值得说。第一尽量避免纯 Group 存在。Group 在 Auto Layout 眼里不是容器它不会参与布局计算也不会随内容撑开。能用 Frame 就用 Frame这是保住结构清晰度的第一步。第二明确每个子元素的 sizing 语义Hug 表示我跟着内容走Fill 表示我吃掉剩余空间Fixed 表示我就是这个尺寸。这三个词对应的其实是 CSS 里的width: fit-content、flex: 1、width: 320px。你在 Figma 里做对了开发几乎不用问这个卡片怎么自适应。第三给会撑开的容器设 min/max。比如一个标签组件文字只有两个字时宽度是 48文字很长时不能无限撑。这时候给 Frame 设一个 min-width 和 max-width开发看代码片段时就能直接拿到约束条件。注意Auto Layout 里 gap 和 padding 是叠加的。如果你给父容器设了 16 的 padding又给子元素设了 8 的 margin 效果通过套一层带 padding 的 Frame 实现那实际间距是 24 不是 16。这类量出来和设的对不上的问题九成出在这里排查时先看容器套了几层。2.2 Variables 与 Modes一套稿子撑起多套主题Variables 是这几年 Figma 变化最大的一块也是把标注从一次性输出变成长期一致的关键。它的核心价值在于颜色、间距、圆角、字号这些值不再散落在各个图层上而是被集中管理图层只是引用它们。举个具体例子。你建一个颜色变量集合里面放color/brand/600、color/text/primary、color/bg/surface然后给这个集合加两个 ModeLight 和 Dark。切到 Dark 时color/bg/surface的值变了稿子自动变色你不需要维护两套画板。开发那边看到的就是同一套令牌名对应两组值代码里写var(--color-bg-surface)主题切换交给 CSS 变量或者构建时替换。除了颜色数值型变量Number同样好用。建一组space/14、space/28、space/312、space/416、space/524、space/632所有 padding 和 gap 都从这里选。这个动作最大的收益不是省时间而是消灭了13px、14px、15px这种脏数据。你可以自己做个实验随便翻一个用了半年的项目把所有间距值统计一遍如果出现了 7 个以上的不同值那开发在还原时必然会有肉眼可见的偏差。有一点需要提醒Variables 和原有的 Styles 是有重叠的。我的用法是颜色、间距、圆角、尺寸走 Variables文字样式走 Text Styles。原因是文字样式包含字号、行高、字重、字距的组合用 Variables 拼会很啰嗦而 Text Styles 天然就是整套组合开发看到body/regular/14也更容易对应到自己的排版体系。2.3 命名与图层结构最便宜也最有效的标注如果只能选一件事去改我会选命名。理由很直接命名是零成本的标注它跟着文件走不需要额外维护。你花十分钟把图层命好能省掉后面几十次解释。图层结构上我建议遵循三个原则。第一页面按用途分区比如01 Foundations、02 Components、03 Screens、04 Exports别把所有东西堆在 Page 1。第二Frame 名描述的是业务含义而不是视觉外观写Home/Hero Banner别写大横幅2。第三需要导出的节点统一加前缀比如全部放在04 Exports页面下或者统一命名成export/icon/search这样批量工具一条规则就能筛出来。命名规范上业界比较通行的组件命名法是层级/类别/变体/状态落到实际大概是这样的场景推荐命名说明主按钮默认态Btn/Primary/Default层级用斜杠Figma 会自动归组主按钮禁用态Btn/Primary/Disabled状态放在最后便于批量筛选搜索图标icon/24/search数字表示画布尺寸方便核对商品卡片Card/Product业务名词在前通用名词在后需要切图的插画export/illustration/empty用 export 前缀区分交付物提示Figma 里用斜杠命名组件会自动生成层级分组但斜杠不要滥用。超过四层之后右侧面板的树会变得很难读反而不如用点号或者短横线。2.4 文本与颜色样式的收敛样式收敛这件事做起来枯燥收益却极大。判断标准很朴素同一份稿子里正文的字号不应该超过三种主色不应该超过两个色阶梯度圆角不应该超过四种。我来解释为什么这个数字重要。开发在写样式时通常会把设计稿里的值抽象成一套令牌比如--font-size-sm/md/lg、--radius-sm/md/lg。如果你的稿子里有 8 种字号开发要么全都写进去样式的可维护性崩掉要么自己合并还原度就开始飘。两种结果都不好。而如果你只给了三种开发就会老老实实建三个令牌后面所有页面都复用这套整站的视觉一致性反而更高。具体操作上我会在01 Foundations页面里放两块内容一块是颜色表每个色块旁边标上变量名一块是文字样式表把heading/1、heading/2、body/regular、body/caption逐个列出来每行显示字号、行高、字重。这块内容本身就是一份活文档新同学入职看一眼就懂比写十页说明文档都管用。行高这块有个小坑值得单独说。Figma 的行高可以设成百分比或者固定像素导出到代码里对应的是无单位line-height: 1.5或者line-height: 21px。同一份稿子里尽量不要混用因为混用之后开发很难判断你到底想要哪种行为——是跟着字号等比缩放还是永远固定。我个人偏好用百分比因为它在多端适配时更稳但如果你在做的是后台系统这种字号基本不变的场景固定像素也没问题前提是统一。2.5 什么时候还需要人工写备注Variables 和 Auto Layout 能解决 80% 的标注问题剩下的 20% 必须靠人写。这不是工具不行而是有些信息天然无法被结构化——它们描述的是行为和边界而不是属性。需要手写备注的典型场景有这些交互反馈比如点击后是缩放还是变暗、按下的位移是多少像素、动效时长和缓动曲线是什么边界情况超长文本截断还是换行、空列表显示什么、加载中是骨架屏还是转圈、请求失败后按钮变成什么状态媒体处理图片是等比裁切还是留白、裁切时以哪条边为准、视频的宽高比是多少因平台差异导致的特殊处理比如某个圆角在网页端要用border-radius实现在移动端因为性能原因要换成背景图。写这些备注的位置我推荐用 Figma 的Annotations功能它挂在具体节点上切到开发视角就能看到不会像评论区那样被冲掉。如果你们用的是免费版没有这个功能退而求其次的方案是在画板旁边放一个说明 Frame用同样的命名前缀方便查找——但千万别把备注写在图层名里长度有限而且一改就断。3. 切图全流程从导出设置到交付目录3.1 格式选型PNG、SVG、WebP、JPG 到底怎么选格式选错的代价很具体图标用 PNG 导致在高分屏模糊插画用 SVG 导致体积从 30KB 涨到 300KB背景照片用 PNG 导致首屏加载慢一秒。我把常见的选择逻辑整理成一张表遇到犹豫的时候直接对照。资源类型首选格式备选关键理由线性图标、简单图形SVGPNG矢量无损可改色体积小带复杂渐变/滤镜的图标PNGSVGSVG 遇到模糊和混合模式会内嵌位图体积反而暴增多色插画SVGWebP优先矢量化除非节点数过多照片、写实背景JPGWebP有损压缩体积优势明显需要透明通道的照片PNG-24WebP保证边缘平滑注意体积需要透明通道的大图WebPPNG同样画质下体积通常更小动效资源GIF / Lottie / 视频APNG首选交给动效方案而非切图这里有一个特别容易踩的坑在 Figma 里给矢量图形加了阴影Drop shadow或图层模糊Layer blur再导出 SVG结果里面会包一张 base64 的位图。你以为交出去的是矢量实际是一个比 PNG 还大的 SVG而且缩放时会糊。排查方法很简单导出后把 SVG 用文本编辑器打开搜一下image或者base64如果有说明图形被位图化了。解决办法是改用 CSS 实现阴影或者干脆按 2x 导 PNG。3.2 倍率与尺寸换算的那些坑倍率的本质是适配不同像素密度的屏幕。逻辑像素和物理像素的换算关系是物理像素 逻辑像素 × 设备像素比。设计稿一般按 375pt 或者 1440px 的逻辑宽度来画导出时用 1x、2x、3x 生成三套代码里通过srcset或者目录区分来选择。实际操作里有几种情况需要区别对待。矢量资源不需要倍率SVG 本身就是无限缩放的导 1x 和 3x 得到的是同一个文件多此一举。位图资源至少导 2x现在主流手机屏幕基本都在 2x 以上只给 1x 就是自找模糊。图标如果非要用位图考虑导 3x因为图标的细节线条更细对模糊更敏感。尺寸取整这件事也值得单独提。设计稿里出现 23.5px、46.7px 这种数值开发还原时要么四舍五入视觉上出现半像素错位要么用transform: scale()硬撑文字会糊。我的做法是导出前统一检查一遍所有需要交付的节点的宽高和关键间距尽量落在偶数上。如果你的设计体系以 4 为基准那所有数值都应该是 4 的倍数检查起来就是一眼的事。注意Figma 的尺寸单位可以在偏好设置里切换成 pxDev Mode 里也能切换显示单位。如果你们团队习惯用 px 沟通双方都切到 px能省掉不少这个是 dp 还是 pt的扯皮。3.3 批量导出面板、插件与命令行导出量小的时候Figma 自带的 Export 面板够用选中节点右侧 Add export settings选格式和倍率点 Export。这里有个提效细节——Export 设置可以批量套用同一份配置你只要给一个图标设好 2x PNG然后选中其他图标面板里会显示同样的设置直接导出即可。量大了就得靠工具。社区插件里有一批专门做批量导出的特点是能按命名规则过滤节点、按前缀生成目录结构、支持批量重命名。这类插件的选择标准我总结为三条能不能按命名规则筛选、能不能保持目录层级、能不能记住配置。三者缺一第二次用就会烦。再往上一个层次是命令行导出适合把切图接进 CI。思路是通过 Figma 提供的开放接口读取文件节点把指定页面下的节点批量导成资源再配合 SVG 优化工具压缩。大致流程和配置结构长这样具体参数以你所用工具版本的文档为准# 安装命令行工具与 SVG 压缩插件 npm install -D figma-export/cli figma-export/output-components-as-svg figma-export/transform-svg-with-svgo// figma.config.js —— 结构示意字段以实际版本为准 module.exports { commands: [ [ components, { fileId: 你的文件ID, onlyFromPages: [04 Exports], // 只处理导出页 transformers: [ require(figma-export/transform-svg-with-svgo)({ plugins: [{ name: preset-default }] }) ], outputters: [ require(figma-export/output-components-as-svg)({ output: ./src/assets/icons }) ] } ] ] };# 通过环境变量传入访问令牌不要写进代码仓库 export FIGMA_TOKEN你的个人访问令牌 npx figma-export use-config figma.config.js这套流程的价值在于可重复。设计稿更新后跑一条命令资源自动覆盖到指定目录文件名稳定SVG 顺手被压缩。前端那边不需要重新拉文件、重新命名、重新优化因为文件名从来没变过。提示访问令牌和个人账号绑定效力等同于账号权限。绝对不要把它提交进 Git用环境变量或者 CI 的密钥管理功能注入。这是最容易被忽视、后果也最严重的一条。3.4 命名规范与目录结构可直接抄导出文件名这块我的经验是让文件名承担一部分文档职责。一个合格的图标文件名应该能让人在不打开文件的情况下知道它长什么样、用在哪里、多大尺寸。推荐的结构是类别-名称-尺寸-状态.扩展名比如icon-search-24-default.svg、icon-search-24-active.svg、illustration-empty-state-320.png。其中尺寸用画布的逻辑尺寸状态只在多态资源上出现单一状态的资源不加后缀。目录结构上图标、插画、位图分开是底线再往下按业务模块分。示意如下assets/ ├── icons/ │ ├── nav/ │ │ ├── icon-home-24-default.svg │ │ └── icon-home-24-active.svg │ └── action/ │ ├── icon-search-24-default.svg │ └── icon-close-24-default.svg ├── illustrations/ │ ├── illustration-empty-list-320.png │ └── illustration-network-error-320.png └── images/ └── banner-home-750x420.jpg这套结构有个隐性好处它逼着设计侧保持资源数量可控。当你发现icons/action下面已经堆了 60 个文件你会本能地去合并和删除冗余资源而不是无止境地加。我见过一个项目导出过 200 多个图标最后前端用了不到 40 个剩下的全是历史遗留——这种浪费只有把资源当成目录来管理的时候才会被发现。4. Dev Mode 与交付协作把反复问变成自己查4.1 Dev Mode 的正确打开方式Dev Mode 的定位很明确它是给开发看的视图屏蔽掉编辑功能突出实现信息。切换到 Dev Mode 后你能看到选中节点的尺寸、间距、变量名、样式名还有一段可复制的代码片段。要让 Dev Mode 真正好用设计侧需要在交付前做几件事。第一把状态标成 Ready for dev这样开发打开文件能直接筛选出待实现的画板不用在一堆草稿里翻。第二确保所有视觉属性都引用了变量或样式如果某个颜色是手填的十六进制Dev Mode 里只会显示一个色值开发拿到的信息就是断的。第三用 Annotations 承载行为备注让备注跟着节点走。开发侧的使用技巧也有几个。单位切换Dev Mode 里可以在 pt、dp、px、rem 之间切换显示团队用什么就切什么避免自己心算。代码片段要当参考而不是答案它生成的是基于视觉属性的机械映射不会考虑你项目里的组件抽象、命名习惯、状态管理。我见过有人直接把生成的代码贴进项目结果一个按钮写了 40 行内联样式后面维护起来非常痛苦。版本对比功能值得用起来设计更新后可以对比两个版本的差异看到哪些节点被改了这比重新看一遍稿子高效得多。4.2 从设计令牌到代码变量Dev Mode 里读到的变量名最好和代码里的 CSS 变量名保持可映射的关系。做法很简单设计侧的变量命名直接采用代码侧的命名约定。如果代码里写的是--color-text-primary设计侧的变量就叫color/text/primary斜杠换短横线就完事。落到代码里大概是这样:root { /* 颜色 */ --color-brand-600: #2563eb; --color-text-primary: #111827; --color-text-secondary: #6b7280; --color-bg-surface: #ffffff; /* 间距 */ --space-1: 4px; --space-2: 8px; --space-3: 12px; --space-4: 16px; --space-5: 24px; --space-6: 32px; /* 圆角与描边 */ --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px; --border-width-thin: 1px; }如果项目用原子化样式方案可以把同一套令牌映射进配置文件// tailwind.config.js —— 只保留映射关系具体结构以使用的版本为准 module.exports { theme: { extend: { colors: { brand: { 600: var(--color-brand-600) }, text: { primary: var(--color-text-primary), secondary: var(--color-text-secondary) } }, spacing: { 1: var(--space-1), 2: var(--space-2), 3: var(--space-3), 4: var(--space-4) }, borderRadius: { sm: var(--radius-sm), md: var(--radius-md), lg: var(--radius-lg) } } } };这么做的收益在第 5 章会体现出来——当设计稿改了主色你只需要改一个变量的值全站生效不需要全仓库搜色值。这也是为什么我一直劝人别用工具里的一键取色去拿颜色取色器取到的可能是叠加后的结果值而不是设计意图值一旦涉及半透明图层取出来就是错的。4.3 交付前自检清单我自己的习惯是每次提测前过一遍这张清单。它不长但每一条都是被坑出来的。检查项合格标准常见不合格表现尺寸完整性所有节点有明确宽高无残留拖拽值出现 23.5、47.3 这类小数间距一致性gap 与 padding 均来自变量手填 13px、17px颜色引用全部使用变量无游离色值出现 3 种近似蓝文字样式使用 Text Styles无孤立字号同一页出现 5 种正文大小文本溢出明确截断或换行策略长文本直接把布局撑破状态覆盖默认、悬停、按下、禁用、加载、空态齐备只画了默认态导出资源命名规范格式倍率正确图层名叫矩形 12行为备注动效与特殊逻辑有 Annotation靠嘴说版本状态画板标记为待实现混在草稿里清单本身不复杂难的是每次都执行。我的做法是把它做成交付模板的一部分在文件里放一个 Checklist 页面每次交付前对着打勾团队里谁交付谁负责比挂在嘴上靠谱得多。4.4 容易吵架的四个细节有几个细节几乎每个团队都为此争论过提前说清楚能省下大量沟通成本。第一1px 是不是真的 1px。在高密度屏幕上1px 的物理线对应 0.5 个逻辑像素浏览器渲染时可能出现忽粗忽细。常见处理是把细线改成 1 个逻辑像素在 2x 屏上等于 2 个物理像素或者用背景渐变实现真正的半像素线。这不是设计能单独决定的需要两端一起定标准。第二阴影的对应关系。Figma 的多层阴影在 CSS 里是可以一比一还原的box-shadow支持逗号分隔多个值顺序、偏移、模糊、扩散、颜色都能对上。所以设计侧不要偷懒只画一层多层阴影能导出的信息尽量导出来开发照着写就行。第三颜色空间的差异。设计工具支持更广的色域而网页和移动端在绝大多数场景下按标准色域渲染同一组数值在不同色域下的观感会有差异。稳妥做法是在项目里统一使用标准色域的颜色值别用超出范围的取色否则开发按数值实现出来跟设计看到的永远不一样谁都说不清是谁的问题。第四字体的可用性。设计侧装了某款商用字体画稿时一切正常开发那边没有字体文件还原出来就是另一副样子。这个问题的解法只有一个交付时确认字体的授权和使用方式把字体文件和对应的字重一起给到开发并且在样式里明确可否回退到系统字体。字体缺失是最容易被低估的交付事故因为它不影响开发写代码只影响上线后的观感。5. 常见问题排查实录5.1 导出类问题图标导出后边缘被削掉半像素。大概率是画布尺寸和图形实际边界不一致图形超出了 Frame 边界。解决办法是选中图形后看它的边界是否完全落在 Frame 内或者导出时勾选包含内容裁切的选项再不行就在四周留出 1 到 2 像素的余量。SVG 打开是一堆乱码路径但用起来正常。这是压缩工具处理过的结果属于正常现象。真正需要警惕的是前面提到的 base64 内嵌用文本搜索image和base64就能确认。如果只是路径被压缩体积更小反而是好事。导出的 PNG 在高分屏上发糊。九成是倍率不够。检查导出设置里是否只导了 1x改成 2x 或 3x 重导即可。另一种可能是图形本身在 Figma 里就用了一张低清位图这种情况放大也救不回来要回源头换素材。批量导出时漏掉了几个节点。常见原因是这些节点没有被正确命名不符合批量工具的筛选规则或者是它们被放在了非导出页面里。排查时先确认节点所在页面再看命名是否符合约定前缀。5.2 标注类问题开发量出来的间距和设计说的对不上。第一步看有没有嵌套容器。Auto Layout 的 gap 加 padding 会叠加父级 padding 16 加子级 padding 8实际就是 24。第二步看有没有绝对定位的元素绝对定位不参与 Auto Layout 计算测量值会跳。第三步看有没有元素因为内容撑开而改变了实际尺寸。颜色看起来一样值不一样。出现这种情况说明稿子里有游离色值。用查找功能搜一遍十六进制把散落的色值统一替换成变量引用。这一步做完通常能一次性消掉十几个色值。圆角在实现后视觉上偏小。有一种情况是设计侧给的是外圆角实现时被应用到了内层元素上视觉半径会变小。另一种情况是描边宽度影响了圆角观感。我的建议是在稿子里把外框圆角和内层圆角分别标清楚不要让开发去猜。文字的实际占位和稿子对不上。通常是行高差异造成的。设计侧用的行高是百分比实现时被写成了固定像素或者反过来。还有一种情况是字体不同导致字宽不同这类问题只能靠统一样式表和字体文件解决光调行高治标不治本。5.3 协作类问题有人误改了主组件全站样式跑偏。这类事故的预防成本很低组件库页面设置为只读或者用分支功能做修改改完再合并。另外养成习惯改主组件之前先看一眼当前有多少地方在用右侧面板会显示实例数量数字大的组件要格外谨慎。评论堆成山重要信息被冲掉。我的建议是评论只用于讨论不用于交付。交付用的信息一律走 Annotations 和组件描述这两处跟着节点走不会被新评论顶下去也不会因为画板移动而失效。文件版本混乱分不清哪版是最终稿。建立一套简单的版本标记约定就够了画板命名带日期或者版本号状态明确标成草稿、待评审、待实现。别看这事小团队里因为我改的是这版造成的返工一周能积累出好几个小时。5.4 一张速查表把上面这些高频问题压缩成一张表遇到类似症状可以先按表排查再考虑深挖。症状最可能的原因第一排查动作间距对不上嵌套容器的 padding 叠加数清容器层级把 padding 加总颜色不一致存在游离色值搜十六进制统一替换为变量图标模糊导出倍率不足改为 2x 或 3x 重导SVG 体积异常大阴影或模糊被位图化文本搜 base64改用 CSS 实现布局在长文本下崩缺 min/max 约束给容器设宽度上下限圆角观感偏小内外圆角混用分别标注内外层半径多端颜色有差异色域不一致统一使用标准色域取值上线字体变了字体文件未交付补字体文件并明确回退策略6. 团队层面怎么把规范落下去6.1 一份可执行的交付清单规范写在文档里没人看写进流程里才会被执行。我推荐的做法是把规范做成文件本身的一部分在项目文件里固定一个页面叫00 Checklist里面放三块东西——命名规则速查、交付自检表、常见错误对照。所有参与项目的人一开始就看到它比事后拉群讲十遍有效。交付动作的具体流程可以固定成四步。第一步清理删掉废弃画板检查游离色值和孤立字号。第二步结构化确认所有容器都是 Frame布局关系由 Auto Layout 表达。第三步补信息写好状态、边界情况和行为备注。第四步出资源按命名规范导出切进04 Exports页面跑一遍批量导出脚本。这四步里最容易被跳过的是第一步。但恰恰是清理带来的收益最直接——稿子越干净后面的沟通成本越低。我自己的体感是清理花掉的十分钟大概能省掉后面半小时的解释。6.2 前端侧如何承接设计令牌设计侧的规范要真正生效前端那边得有对应的承接结构否则变量名再漂亮代码里还是一堆硬编码。比较务实的做法是三步走。第一步把令牌落成一份单一来源的配置可以是一个 JSON也可以直接是 CSS 变量文件。第二步用一份映射把它接到项目用的样式方案上原子化方案接配置文件传统方案接 Sass 变量或者 CSS 自定义属性。第三步在代码审查里加一条规则新增的样式必须引用令牌直接在组件里写色值和像素值的一律打回。有一个细节值得强调令牌的粒度要克制。我见过有团队给每个组件的每个属性都建了令牌结果令牌数量膨胀到几百个改一个主色要动几十处维护成本比硬编码还高。合理的粒度是语义级别——颜色按用途分文字、背景、边框、品牌、状态间距按梯度分4、8、12、16、24、32圆角按大小分小、中、大。数量控制在几十个以内才有人愿意记、愿意用。6.3 工具链的新变化MCP 与设计稿取数最近一年围绕设计稿和代码之间的取数方式多了一些新东西。简单说就是让本地的编码工具能够直接读取设计文件里的节点结构而不是靠人肉搬运。常见的形式是提供一个服务端把设计文件的结构信息暴露给编码助手助手再据此生成或修改代码。这类工具确实能省事尤其是做「照着设计稿搭页面骨架」这种机械劳动时。但用之前得想清楚两件事。一是它读的是结构数据不是审美判断你的稿子如果间距随意、命名混乱它生成的代码就是把混乱忠实复刻一遍速度越快债务积累越快。二是它拿不到的东西依然需要人工补动效、交互反馈、边界情况、媒体裁切规则这些还是得有人写在稿子里、写在文档里。关于访问令牌的获取各家工具的入口不太一样通常在个人账号的设置区域里能找到与开发相关的选项。要提醒的是这类令牌的权限和账号绑定拿到之后不要提交进代码仓库也不要在公共场合截图暴露用环境变量管理是基本操作。我个人的判断是这类工具会越来越普及但它改变的是信息怎么传不改变信息本身有没有被生产出来。标注和切图这两件老事本质是让设计意图变得可读、可复用、可验证——工具换了多少代这个目标没变过。真要说有什么变化那就是规范的收益被放大了一份干净的设计稿交给人和交给工具产出都是又快又准一份混乱的稿子交给谁都是返工。 Figma 标注与切图全流程：从设计稿到前端交付
我见过太多次这样的场面一个同学 Figma 已经用了两三年组件库搭得整整齐齐Variables 也配了可一到交付那一步群里还是那句老话——这个帮我切一下间距标一下。问题不在于他会不会用 Figma而在于他从没把「标注」和「切图」当成一门需要专门设计的手艺。Figma 这个工具本身早就把答案摆在那儿了Dev Mode、变量、Auto Layout、批量导出、Code Connect一样不缺。真正卡住人的是交付链路上那些没人写进文档里的默认规则——谁负责切、切什么格式、标到什么颗粒度、哪些信息本该由结构表达而不是靠人肉口述。这篇内容我打算把这件事从头到尾捋一遍一套 Figma 设计稿从画完到交给开发、再到上线中间关于标注和切图的所有关键决策点。适合三类人看——刚接手交付工作的设计师、需要自己从设计稿里扒资源的前端、以及带着小团队想把流程固定下来的负责人。不管你 Figma 处在哪个水平看完至少能做到两件事不再问这个图怎么切不再靠截图加红框去标间距。1. 先把标注和切图这两件事说清楚1.1 设计语境下的标注到底在标什么标注这个词在不同行当里指的东西差得很远。机械制图里说 1:2.5问的是锥度还是斜度那是一套完全独立的符号体系写论文时参考文献连续引用怎么标注 [1-3]那是排版规则做模型训练的人说数据标注脑子里浮现的是 labelme、CVAT 这类工具标的是框和掩码。而在 Figma 这个语境里标注只有一个意思把设计稿里隐含的实现信息显式地表达出来让开发不用猜。它标的东西其实就那么几类。第一类是几何信息尺寸、间距、圆角、描边宽度、元素的对齐关系。第二类是视觉信息颜色值、透明度、字体字号字重、行高字距、阴影和模糊参数。第三类是结构与行为信息层级关系、哪个容器会撑开、哪个元素是固定的、超长文本怎么处理、不同状态之间怎么切换。第四类是资源信息哪些节点需要导出成图片或矢量、导出成什么格式、什么倍率、叫什么名字。这四类里前两类 Figma 早在几年前就能自动给出了选中一个元素右边栏全部列出来。真正让人反复问的永远是第三类和第四类——因为它们无法被读取只能被规定。你不在稿子里说清楚输入框聚焦时边框变什么颜色开发就只能来问你你不说这个图标导出 24 还是 32开发就只能自己猜一个。所以标注这件事的本质不是把数字抄下来而是把设计决策翻译成可实现、无歧义的约束。理解了这一点后面所有的工具选择才有意义。Auto Layout 不是排版玩具它是几何信息的结构化表达Variables 不是主题切换的噱头它是视觉信息的唯一真源Dev Mode 不是给开发看的皮肤它是第三类和第四类信息的承载容器。1.2 切图不是导出一张图那么简单很多人对切图的理解停留在右键导出 PNG。真做起来会发现同一张设计稿交给不同的人切产出能差出十万八千里有人导的图标边缘被裁掉半个像素有人导的插画是 1x 放到 2x 屏上糊成一团有人导了 40 个 PNG 却没一个能对上代码里的文件名。切图这件事本质上要同时满足四个约束。格式约束这个资源是矢量的还是位图的、要不要透明通道、会不会有渐变和阴影。尺寸约束在什么屏幕密度下使用、需要几套倍率、逻辑尺寸和物理像素怎么换算。体积约束一张首屏插画导出来 800KB用户流量是实打实被吃掉的这时候该考虑压缩格式和分级加载。命名约束这是最容易被忽略但代价最高的一条——如果导出的文件名和代码里的引用路径对不上开发就得手动重命名几十个文件改一次就是一次人为失误的机会。我个人的习惯是把切图当成一次数据交付而不是一次文件导出。你在导出之前脑子里应该已经有目标目录长什么样、文件名长什么样、构建工具怎么引用它。这个念头一旦建立切片的方式、命名的方式、目录的组织方式全都会跟着变后面第三章会展开讲具体怎么做。1.3 为什么工具升级了问题却没消失这里有个反直觉的现象Figma 每年都在变强可标注切图这四个字在群里的出现频率并没有明显下降。原因有三个都挺现实。第一工具的默认行为不一定匹配团队的实际约定。Figma 默认按 pt 显示尺寸但你团队可能全用 pxFigma 导出时默认用图层名当文件名但你的图层名是矩形 12Figma 的间距显示的是测量值而 Auto Layout 里的 gap 和 padding 叠加后量出来可能是另一个数。这些差异不会自己消失必须有人去对齐。第二信息只有被放在对的位置才会被看见。你把交互备注写在一个没人会打开的隐藏 Frame 里等于没写。Figma 有专门承载这类信息的位置——Annotations、组件描述、页面说明、Dev Mode 的状态标记。放错地方的信息就是噪音。第三AI 工具让一部分人产生了不需要规范了的错觉。现在确实有工具能把 Figma 节点读给 AI 编码助手让模型直接吐出一段页面代码也有工具把设计稿里的组件映射到代码仓库里的真实组件。但这些工具读的是结构数据不是像素。你稿子里的间距是随手拖的 13px、颜色用了三种近似蓝AI 照样会把这份混乱一比一复刻到代码里只是速度更快而已。工具越强前期规范的收益越大这个逻辑没变过。2. 让设计稿自带规格标注的地基怎么打2.1 Auto Layout把间距写进结构里如果说标注有地基那一定是 Auto Layout。原因很简单Auto Layout 把间距从一次测量变成了一次声明。你设了 gap 是 12那就是 12开发看到的也是 12你用两个 Group 上下摆放中间的间距是你手动拖出来的 12.3开发量出来是 12但换个屏幕就崩了。实际用起来有几条经验值得说。第一尽量避免纯 Group 存在。Group 在 Auto Layout 眼里不是容器它不会参与布局计算也不会随内容撑开。能用 Frame 就用 Frame这是保住结构清晰度的第一步。第二明确每个子元素的 sizing 语义Hug 表示我跟着内容走Fill 表示我吃掉剩余空间Fixed 表示我就是这个尺寸。这三个词对应的其实是 CSS 里的width: fit-content、flex: 1、width: 320px。你在 Figma 里做对了开发几乎不用问这个卡片怎么自适应。第三给会撑开的容器设 min/max。比如一个标签组件文字只有两个字时宽度是 48文字很长时不能无限撑。这时候给 Frame 设一个 min-width 和 max-width开发看代码片段时就能直接拿到约束条件。注意Auto Layout 里 gap 和 padding 是叠加的。如果你给父容器设了 16 的 padding又给子元素设了 8 的 margin 效果通过套一层带 padding 的 Frame 实现那实际间距是 24 不是 16。这类量出来和设的对不上的问题九成出在这里排查时先看容器套了几层。2.2 Variables 与 Modes一套稿子撑起多套主题Variables 是这几年 Figma 变化最大的一块也是把标注从一次性输出变成长期一致的关键。它的核心价值在于颜色、间距、圆角、字号这些值不再散落在各个图层上而是被集中管理图层只是引用它们。举个具体例子。你建一个颜色变量集合里面放color/brand/600、color/text/primary、color/bg/surface然后给这个集合加两个 ModeLight 和 Dark。切到 Dark 时color/bg/surface的值变了稿子自动变色你不需要维护两套画板。开发那边看到的就是同一套令牌名对应两组值代码里写var(--color-bg-surface)主题切换交给 CSS 变量或者构建时替换。除了颜色数值型变量Number同样好用。建一组space/14、space/28、space/312、space/416、space/524、space/632所有 padding 和 gap 都从这里选。这个动作最大的收益不是省时间而是消灭了13px、14px、15px这种脏数据。你可以自己做个实验随便翻一个用了半年的项目把所有间距值统计一遍如果出现了 7 个以上的不同值那开发在还原时必然会有肉眼可见的偏差。有一点需要提醒Variables 和原有的 Styles 是有重叠的。我的用法是颜色、间距、圆角、尺寸走 Variables文字样式走 Text Styles。原因是文字样式包含字号、行高、字重、字距的组合用 Variables 拼会很啰嗦而 Text Styles 天然就是整套组合开发看到body/regular/14也更容易对应到自己的排版体系。2.3 命名与图层结构最便宜也最有效的标注如果只能选一件事去改我会选命名。理由很直接命名是零成本的标注它跟着文件走不需要额外维护。你花十分钟把图层命好能省掉后面几十次解释。图层结构上我建议遵循三个原则。第一页面按用途分区比如01 Foundations、02 Components、03 Screens、04 Exports别把所有东西堆在 Page 1。第二Frame 名描述的是业务含义而不是视觉外观写Home/Hero Banner别写大横幅2。第三需要导出的节点统一加前缀比如全部放在04 Exports页面下或者统一命名成export/icon/search这样批量工具一条规则就能筛出来。命名规范上业界比较通行的组件命名法是层级/类别/变体/状态落到实际大概是这样的场景推荐命名说明主按钮默认态Btn/Primary/Default层级用斜杠Figma 会自动归组主按钮禁用态Btn/Primary/Disabled状态放在最后便于批量筛选搜索图标icon/24/search数字表示画布尺寸方便核对商品卡片Card/Product业务名词在前通用名词在后需要切图的插画export/illustration/empty用 export 前缀区分交付物提示Figma 里用斜杠命名组件会自动生成层级分组但斜杠不要滥用。超过四层之后右侧面板的树会变得很难读反而不如用点号或者短横线。2.4 文本与颜色样式的收敛样式收敛这件事做起来枯燥收益却极大。判断标准很朴素同一份稿子里正文的字号不应该超过三种主色不应该超过两个色阶梯度圆角不应该超过四种。我来解释为什么这个数字重要。开发在写样式时通常会把设计稿里的值抽象成一套令牌比如--font-size-sm/md/lg、--radius-sm/md/lg。如果你的稿子里有 8 种字号开发要么全都写进去样式的可维护性崩掉要么自己合并还原度就开始飘。两种结果都不好。而如果你只给了三种开发就会老老实实建三个令牌后面所有页面都复用这套整站的视觉一致性反而更高。具体操作上我会在01 Foundations页面里放两块内容一块是颜色表每个色块旁边标上变量名一块是文字样式表把heading/1、heading/2、body/regular、body/caption逐个列出来每行显示字号、行高、字重。这块内容本身就是一份活文档新同学入职看一眼就懂比写十页说明文档都管用。行高这块有个小坑值得单独说。Figma 的行高可以设成百分比或者固定像素导出到代码里对应的是无单位line-height: 1.5或者line-height: 21px。同一份稿子里尽量不要混用因为混用之后开发很难判断你到底想要哪种行为——是跟着字号等比缩放还是永远固定。我个人偏好用百分比因为它在多端适配时更稳但如果你在做的是后台系统这种字号基本不变的场景固定像素也没问题前提是统一。2.5 什么时候还需要人工写备注Variables 和 Auto Layout 能解决 80% 的标注问题剩下的 20% 必须靠人写。这不是工具不行而是有些信息天然无法被结构化——它们描述的是行为和边界而不是属性。需要手写备注的典型场景有这些交互反馈比如点击后是缩放还是变暗、按下的位移是多少像素、动效时长和缓动曲线是什么边界情况超长文本截断还是换行、空列表显示什么、加载中是骨架屏还是转圈、请求失败后按钮变成什么状态媒体处理图片是等比裁切还是留白、裁切时以哪条边为准、视频的宽高比是多少因平台差异导致的特殊处理比如某个圆角在网页端要用border-radius实现在移动端因为性能原因要换成背景图。写这些备注的位置我推荐用 Figma 的Annotations功能它挂在具体节点上切到开发视角就能看到不会像评论区那样被冲掉。如果你们用的是免费版没有这个功能退而求其次的方案是在画板旁边放一个说明 Frame用同样的命名前缀方便查找——但千万别把备注写在图层名里长度有限而且一改就断。3. 切图全流程从导出设置到交付目录3.1 格式选型PNG、SVG、WebP、JPG 到底怎么选格式选错的代价很具体图标用 PNG 导致在高分屏模糊插画用 SVG 导致体积从 30KB 涨到 300KB背景照片用 PNG 导致首屏加载慢一秒。我把常见的选择逻辑整理成一张表遇到犹豫的时候直接对照。资源类型首选格式备选关键理由线性图标、简单图形SVGPNG矢量无损可改色体积小带复杂渐变/滤镜的图标PNGSVGSVG 遇到模糊和混合模式会内嵌位图体积反而暴增多色插画SVGWebP优先矢量化除非节点数过多照片、写实背景JPGWebP有损压缩体积优势明显需要透明通道的照片PNG-24WebP保证边缘平滑注意体积需要透明通道的大图WebPPNG同样画质下体积通常更小动效资源GIF / Lottie / 视频APNG首选交给动效方案而非切图这里有一个特别容易踩的坑在 Figma 里给矢量图形加了阴影Drop shadow或图层模糊Layer blur再导出 SVG结果里面会包一张 base64 的位图。你以为交出去的是矢量实际是一个比 PNG 还大的 SVG而且缩放时会糊。排查方法很简单导出后把 SVG 用文本编辑器打开搜一下image或者base64如果有说明图形被位图化了。解决办法是改用 CSS 实现阴影或者干脆按 2x 导 PNG。3.2 倍率与尺寸换算的那些坑倍率的本质是适配不同像素密度的屏幕。逻辑像素和物理像素的换算关系是物理像素 逻辑像素 × 设备像素比。设计稿一般按 375pt 或者 1440px 的逻辑宽度来画导出时用 1x、2x、3x 生成三套代码里通过srcset或者目录区分来选择。实际操作里有几种情况需要区别对待。矢量资源不需要倍率SVG 本身就是无限缩放的导 1x 和 3x 得到的是同一个文件多此一举。位图资源至少导 2x现在主流手机屏幕基本都在 2x 以上只给 1x 就是自找模糊。图标如果非要用位图考虑导 3x因为图标的细节线条更细对模糊更敏感。尺寸取整这件事也值得单独提。设计稿里出现 23.5px、46.7px 这种数值开发还原时要么四舍五入视觉上出现半像素错位要么用transform: scale()硬撑文字会糊。我的做法是导出前统一检查一遍所有需要交付的节点的宽高和关键间距尽量落在偶数上。如果你的设计体系以 4 为基准那所有数值都应该是 4 的倍数检查起来就是一眼的事。注意Figma 的尺寸单位可以在偏好设置里切换成 pxDev Mode 里也能切换显示单位。如果你们团队习惯用 px 沟通双方都切到 px能省掉不少这个是 dp 还是 pt的扯皮。3.3 批量导出面板、插件与命令行导出量小的时候Figma 自带的 Export 面板够用选中节点右侧 Add export settings选格式和倍率点 Export。这里有个提效细节——Export 设置可以批量套用同一份配置你只要给一个图标设好 2x PNG然后选中其他图标面板里会显示同样的设置直接导出即可。量大了就得靠工具。社区插件里有一批专门做批量导出的特点是能按命名规则过滤节点、按前缀生成目录结构、支持批量重命名。这类插件的选择标准我总结为三条能不能按命名规则筛选、能不能保持目录层级、能不能记住配置。三者缺一第二次用就会烦。再往上一个层次是命令行导出适合把切图接进 CI。思路是通过 Figma 提供的开放接口读取文件节点把指定页面下的节点批量导成资源再配合 SVG 优化工具压缩。大致流程和配置结构长这样具体参数以你所用工具版本的文档为准# 安装命令行工具与 SVG 压缩插件 npm install -D figma-export/cli figma-export/output-components-as-svg figma-export/transform-svg-with-svgo// figma.config.js —— 结构示意字段以实际版本为准 module.exports { commands: [ [ components, { fileId: 你的文件ID, onlyFromPages: [04 Exports], // 只处理导出页 transformers: [ require(figma-export/transform-svg-with-svgo)({ plugins: [{ name: preset-default }] }) ], outputters: [ require(figma-export/output-components-as-svg)({ output: ./src/assets/icons }) ] } ] ] };# 通过环境变量传入访问令牌不要写进代码仓库 export FIGMA_TOKEN你的个人访问令牌 npx figma-export use-config figma.config.js这套流程的价值在于可重复。设计稿更新后跑一条命令资源自动覆盖到指定目录文件名稳定SVG 顺手被压缩。前端那边不需要重新拉文件、重新命名、重新优化因为文件名从来没变过。提示访问令牌和个人账号绑定效力等同于账号权限。绝对不要把它提交进 Git用环境变量或者 CI 的密钥管理功能注入。这是最容易被忽视、后果也最严重的一条。3.4 命名规范与目录结构可直接抄导出文件名这块我的经验是让文件名承担一部分文档职责。一个合格的图标文件名应该能让人在不打开文件的情况下知道它长什么样、用在哪里、多大尺寸。推荐的结构是类别-名称-尺寸-状态.扩展名比如icon-search-24-default.svg、icon-search-24-active.svg、illustration-empty-state-320.png。其中尺寸用画布的逻辑尺寸状态只在多态资源上出现单一状态的资源不加后缀。目录结构上图标、插画、位图分开是底线再往下按业务模块分。示意如下assets/ ├── icons/ │ ├── nav/ │ │ ├── icon-home-24-default.svg │ │ └── icon-home-24-active.svg │ └── action/ │ ├── icon-search-24-default.svg │ └── icon-close-24-default.svg ├── illustrations/ │ ├── illustration-empty-list-320.png │ └── illustration-network-error-320.png └── images/ └── banner-home-750x420.jpg这套结构有个隐性好处它逼着设计侧保持资源数量可控。当你发现icons/action下面已经堆了 60 个文件你会本能地去合并和删除冗余资源而不是无止境地加。我见过一个项目导出过 200 多个图标最后前端用了不到 40 个剩下的全是历史遗留——这种浪费只有把资源当成目录来管理的时候才会被发现。4. Dev Mode 与交付协作把反复问变成自己查4.1 Dev Mode 的正确打开方式Dev Mode 的定位很明确它是给开发看的视图屏蔽掉编辑功能突出实现信息。切换到 Dev Mode 后你能看到选中节点的尺寸、间距、变量名、样式名还有一段可复制的代码片段。要让 Dev Mode 真正好用设计侧需要在交付前做几件事。第一把状态标成 Ready for dev这样开发打开文件能直接筛选出待实现的画板不用在一堆草稿里翻。第二确保所有视觉属性都引用了变量或样式如果某个颜色是手填的十六进制Dev Mode 里只会显示一个色值开发拿到的信息就是断的。第三用 Annotations 承载行为备注让备注跟着节点走。开发侧的使用技巧也有几个。单位切换Dev Mode 里可以在 pt、dp、px、rem 之间切换显示团队用什么就切什么避免自己心算。代码片段要当参考而不是答案它生成的是基于视觉属性的机械映射不会考虑你项目里的组件抽象、命名习惯、状态管理。我见过有人直接把生成的代码贴进项目结果一个按钮写了 40 行内联样式后面维护起来非常痛苦。版本对比功能值得用起来设计更新后可以对比两个版本的差异看到哪些节点被改了这比重新看一遍稿子高效得多。4.2 从设计令牌到代码变量Dev Mode 里读到的变量名最好和代码里的 CSS 变量名保持可映射的关系。做法很简单设计侧的变量命名直接采用代码侧的命名约定。如果代码里写的是--color-text-primary设计侧的变量就叫color/text/primary斜杠换短横线就完事。落到代码里大概是这样:root { /* 颜色 */ --color-brand-600: #2563eb; --color-text-primary: #111827; --color-text-secondary: #6b7280; --color-bg-surface: #ffffff; /* 间距 */ --space-1: 4px; --space-2: 8px; --space-3: 12px; --space-4: 16px; --space-5: 24px; --space-6: 32px; /* 圆角与描边 */ --radius-sm: 4px; --radius-md: 8px; --radius-lg: 12px; --border-width-thin: 1px; }如果项目用原子化样式方案可以把同一套令牌映射进配置文件// tailwind.config.js —— 只保留映射关系具体结构以使用的版本为准 module.exports { theme: { extend: { colors: { brand: { 600: var(--color-brand-600) }, text: { primary: var(--color-text-primary), secondary: var(--color-text-secondary) } }, spacing: { 1: var(--space-1), 2: var(--space-2), 3: var(--space-3), 4: var(--space-4) }, borderRadius: { sm: var(--radius-sm), md: var(--radius-md), lg: var(--radius-lg) } } } };这么做的收益在第 5 章会体现出来——当设计稿改了主色你只需要改一个变量的值全站生效不需要全仓库搜色值。这也是为什么我一直劝人别用工具里的一键取色去拿颜色取色器取到的可能是叠加后的结果值而不是设计意图值一旦涉及半透明图层取出来就是错的。4.3 交付前自检清单我自己的习惯是每次提测前过一遍这张清单。它不长但每一条都是被坑出来的。检查项合格标准常见不合格表现尺寸完整性所有节点有明确宽高无残留拖拽值出现 23.5、47.3 这类小数间距一致性gap 与 padding 均来自变量手填 13px、17px颜色引用全部使用变量无游离色值出现 3 种近似蓝文字样式使用 Text Styles无孤立字号同一页出现 5 种正文大小文本溢出明确截断或换行策略长文本直接把布局撑破状态覆盖默认、悬停、按下、禁用、加载、空态齐备只画了默认态导出资源命名规范格式倍率正确图层名叫矩形 12行为备注动效与特殊逻辑有 Annotation靠嘴说版本状态画板标记为待实现混在草稿里清单本身不复杂难的是每次都执行。我的做法是把它做成交付模板的一部分在文件里放一个 Checklist 页面每次交付前对着打勾团队里谁交付谁负责比挂在嘴上靠谱得多。4.4 容易吵架的四个细节有几个细节几乎每个团队都为此争论过提前说清楚能省下大量沟通成本。第一1px 是不是真的 1px。在高密度屏幕上1px 的物理线对应 0.5 个逻辑像素浏览器渲染时可能出现忽粗忽细。常见处理是把细线改成 1 个逻辑像素在 2x 屏上等于 2 个物理像素或者用背景渐变实现真正的半像素线。这不是设计能单独决定的需要两端一起定标准。第二阴影的对应关系。Figma 的多层阴影在 CSS 里是可以一比一还原的box-shadow支持逗号分隔多个值顺序、偏移、模糊、扩散、颜色都能对上。所以设计侧不要偷懒只画一层多层阴影能导出的信息尽量导出来开发照着写就行。第三颜色空间的差异。设计工具支持更广的色域而网页和移动端在绝大多数场景下按标准色域渲染同一组数值在不同色域下的观感会有差异。稳妥做法是在项目里统一使用标准色域的颜色值别用超出范围的取色否则开发按数值实现出来跟设计看到的永远不一样谁都说不清是谁的问题。第四字体的可用性。设计侧装了某款商用字体画稿时一切正常开发那边没有字体文件还原出来就是另一副样子。这个问题的解法只有一个交付时确认字体的授权和使用方式把字体文件和对应的字重一起给到开发并且在样式里明确可否回退到系统字体。字体缺失是最容易被低估的交付事故因为它不影响开发写代码只影响上线后的观感。5. 常见问题排查实录5.1 导出类问题图标导出后边缘被削掉半像素。大概率是画布尺寸和图形实际边界不一致图形超出了 Frame 边界。解决办法是选中图形后看它的边界是否完全落在 Frame 内或者导出时勾选包含内容裁切的选项再不行就在四周留出 1 到 2 像素的余量。SVG 打开是一堆乱码路径但用起来正常。这是压缩工具处理过的结果属于正常现象。真正需要警惕的是前面提到的 base64 内嵌用文本搜索image和base64就能确认。如果只是路径被压缩体积更小反而是好事。导出的 PNG 在高分屏上发糊。九成是倍率不够。检查导出设置里是否只导了 1x改成 2x 或 3x 重导即可。另一种可能是图形本身在 Figma 里就用了一张低清位图这种情况放大也救不回来要回源头换素材。批量导出时漏掉了几个节点。常见原因是这些节点没有被正确命名不符合批量工具的筛选规则或者是它们被放在了非导出页面里。排查时先确认节点所在页面再看命名是否符合约定前缀。5.2 标注类问题开发量出来的间距和设计说的对不上。第一步看有没有嵌套容器。Auto Layout 的 gap 加 padding 会叠加父级 padding 16 加子级 padding 8实际就是 24。第二步看有没有绝对定位的元素绝对定位不参与 Auto Layout 计算测量值会跳。第三步看有没有元素因为内容撑开而改变了实际尺寸。颜色看起来一样值不一样。出现这种情况说明稿子里有游离色值。用查找功能搜一遍十六进制把散落的色值统一替换成变量引用。这一步做完通常能一次性消掉十几个色值。圆角在实现后视觉上偏小。有一种情况是设计侧给的是外圆角实现时被应用到了内层元素上视觉半径会变小。另一种情况是描边宽度影响了圆角观感。我的建议是在稿子里把外框圆角和内层圆角分别标清楚不要让开发去猜。文字的实际占位和稿子对不上。通常是行高差异造成的。设计侧用的行高是百分比实现时被写成了固定像素或者反过来。还有一种情况是字体不同导致字宽不同这类问题只能靠统一样式表和字体文件解决光调行高治标不治本。5.3 协作类问题有人误改了主组件全站样式跑偏。这类事故的预防成本很低组件库页面设置为只读或者用分支功能做修改改完再合并。另外养成习惯改主组件之前先看一眼当前有多少地方在用右侧面板会显示实例数量数字大的组件要格外谨慎。评论堆成山重要信息被冲掉。我的建议是评论只用于讨论不用于交付。交付用的信息一律走 Annotations 和组件描述这两处跟着节点走不会被新评论顶下去也不会因为画板移动而失效。文件版本混乱分不清哪版是最终稿。建立一套简单的版本标记约定就够了画板命名带日期或者版本号状态明确标成草稿、待评审、待实现。别看这事小团队里因为我改的是这版造成的返工一周能积累出好几个小时。5.4 一张速查表把上面这些高频问题压缩成一张表遇到类似症状可以先按表排查再考虑深挖。症状最可能的原因第一排查动作间距对不上嵌套容器的 padding 叠加数清容器层级把 padding 加总颜色不一致存在游离色值搜十六进制统一替换为变量图标模糊导出倍率不足改为 2x 或 3x 重导SVG 体积异常大阴影或模糊被位图化文本搜 base64改用 CSS 实现布局在长文本下崩缺 min/max 约束给容器设宽度上下限圆角观感偏小内外圆角混用分别标注内外层半径多端颜色有差异色域不一致统一使用标准色域取值上线字体变了字体文件未交付补字体文件并明确回退策略6. 团队层面怎么把规范落下去6.1 一份可执行的交付清单规范写在文档里没人看写进流程里才会被执行。我推荐的做法是把规范做成文件本身的一部分在项目文件里固定一个页面叫00 Checklist里面放三块东西——命名规则速查、交付自检表、常见错误对照。所有参与项目的人一开始就看到它比事后拉群讲十遍有效。交付动作的具体流程可以固定成四步。第一步清理删掉废弃画板检查游离色值和孤立字号。第二步结构化确认所有容器都是 Frame布局关系由 Auto Layout 表达。第三步补信息写好状态、边界情况和行为备注。第四步出资源按命名规范导出切进04 Exports页面跑一遍批量导出脚本。这四步里最容易被跳过的是第一步。但恰恰是清理带来的收益最直接——稿子越干净后面的沟通成本越低。我自己的体感是清理花掉的十分钟大概能省掉后面半小时的解释。6.2 前端侧如何承接设计令牌设计侧的规范要真正生效前端那边得有对应的承接结构否则变量名再漂亮代码里还是一堆硬编码。比较务实的做法是三步走。第一步把令牌落成一份单一来源的配置可以是一个 JSON也可以直接是 CSS 变量文件。第二步用一份映射把它接到项目用的样式方案上原子化方案接配置文件传统方案接 Sass 变量或者 CSS 自定义属性。第三步在代码审查里加一条规则新增的样式必须引用令牌直接在组件里写色值和像素值的一律打回。有一个细节值得强调令牌的粒度要克制。我见过有团队给每个组件的每个属性都建了令牌结果令牌数量膨胀到几百个改一个主色要动几十处维护成本比硬编码还高。合理的粒度是语义级别——颜色按用途分文字、背景、边框、品牌、状态间距按梯度分4、8、12、16、24、32圆角按大小分小、中、大。数量控制在几十个以内才有人愿意记、愿意用。6.3 工具链的新变化MCP 与设计稿取数最近一年围绕设计稿和代码之间的取数方式多了一些新东西。简单说就是让本地的编码工具能够直接读取设计文件里的节点结构而不是靠人肉搬运。常见的形式是提供一个服务端把设计文件的结构信息暴露给编码助手助手再据此生成或修改代码。这类工具确实能省事尤其是做「照着设计稿搭页面骨架」这种机械劳动时。但用之前得想清楚两件事。一是它读的是结构数据不是审美判断你的稿子如果间距随意、命名混乱它生成的代码就是把混乱忠实复刻一遍速度越快债务积累越快。二是它拿不到的东西依然需要人工补动效、交互反馈、边界情况、媒体裁切规则这些还是得有人写在稿子里、写在文档里。关于访问令牌的获取各家工具的入口不太一样通常在个人账号的设置区域里能找到与开发相关的选项。要提醒的是这类令牌的权限和账号绑定拿到之后不要提交进代码仓库也不要在公共场合截图暴露用环境变量管理是基本操作。我个人的判断是这类工具会越来越普及但它改变的是信息怎么传不改变信息本身有没有被生产出来。标注和切图这两件老事本质是让设计意图变得可读、可复用、可验证——工具换了多少代这个目标没变过。真要说有什么变化那就是规范的收益被放大了一份干净的设计稿交给人和交给工具产出都是又快又准一份混乱的稿子交给谁都是返工。