上周一个做 UI 的朋友甩给我一张截图问 Figma 里拉红线标尺寸的插件现在叫什么名字。我当时有点哭笑不得——Dev Mode 都出来这么久了还有人把 Figma 当成 Sketch 时代的标注工具在用。Figma 里的标注和切图这两件事本质上前前后后换过两轮逻辑第一次是共享链接让开发自己看第二次是设计与开发模式分离把抄数字变成了读规则。很多人卡在第一轮甚至卡在插件时代。这篇东西不打算讲 Figma 的入门操作而是想聊清楚为什么你标了那么多尺寸开发还是要来问为什么你导出的图标上线之后就是糊的以及在 Figma 到代码、Figma 接 AI 工具这些新链路上标注和切图到底该做到什么程度。适合已经会用 Figma、但交付环节总是反复返工的设计师也适合想搞清楚该向设计要什么的前端。顺便说一句标注这个词在不同圈子里含义差得挺远做算法的说数据标注、图像标注做机械的说公差标注做设计文档的说参考文献交叉引用标注。这篇只聊设计交付语境下的那一类别的场景不掺和。1. 还在拉红线标间距Figma 里的标注早就换了一层含义1.1 从 Markman 红线到 Dev Mode标注的职责发生了转移早些年用 Sketch 的时候交付流程基本是固定的设计师画完稿用 Markman后来叫 Sketch Measure跑一遍插件在图层旁边生成一堆红线、坐标数字、色值方块再导出一张标注图发给开发。开发对着这张图写样式遇到歧义就截图问。那时候标注的本质是翻译——把设计稿里客观存在的数字人工抄写一遍给另一个人看。Zeplin 这类工具做的是同一件事只是把抄变成了上传后自动读取。Figma 第一次改写这件事是把 inspect 面板直接挂在共享链接上。设计师发一个链接给开发对方点开任意图层右侧就能看到坐标、尺寸、填充、描边、字体、行高。红线插件在这个阶段就已经是多余的了因为它读的是同一份数据只是换了个展示形式。第二次改写是 Dev Mode。设计模式和开发模式被拆成两个视图设计师看到的还是图层和组件开发点进 Dev Mode 看到的是代码片段、变量名、组件属性面板以及可以直接复制的间距值。这个变化最容易被忽略的地方在于——开发看到的不再是这个元素在画布上的坐标而是这个元素在布局里的位置。这两者的区别很关键。坐标是绝对的是设计师摆出来的结果布局是相对的是可推导的规则。当你的容器用了 Auto Layout开发在 Dev Mode 里看到的 gap 是 8、padding 是 16这些值本身就是规则不需要任何人再用红字标一遍。反过来如果你的稿子全靠手拖那 Dev Mode 也只能告诉你这个图层 X 坐标是 243开发拿到这个数字还得自己反推该写多少 margin。1.2 工具能自动读到的信息就别再手写第二遍我把这件事拆成两张清单你对照一下自己的稿子看看是不是在做无用功。Figma 自动就能读到的信息不要标图层的绝对坐标、宽高、旋转角度Auto Layout 容器的 gap、padding、对齐方式填充色、描边色、描边宽度、圆角半径字体族、字号、字重、行高、字间距、对齐方式图层层级与遮挡关系阴影、模糊、混合模式等效果参数导出资源的尺寸和倍率工具读不到、必须由人表达的信息一定要写交互状态与触发条件hover 是什么样按下是什么样禁用是什么样边界与异常态列表为空、文本超长、图片加载失败、网络超时断点行为窄屏下这个卡片是换行还是横向滚动栅格怎么收缩动效的时长与缓动曲线可点击区域的最小尺寸无障碍相关的语义标签、对比度要求内容截断规则是省略号还是渐隐最多几行业务规则金额保留几位小数、时间显示相对还是绝对这份清单背后的判断标准只有一条能否被工具从文件结构里读出来。能读出来的你手写一遍就是重复劳动而且一旦改了稿子忘了改标注反而制造矛盾读不出来的才是标注真正的价值所在也是开发最容易漏、最容易返工的地方。我见过太多稿子间距标得密密麻麻但一个加载中状态都没画开发只能自己拍脑袋转圈圈或者留白最后验收时两边都不满意。1.3 一个真实返工场景间距到底是 24 还是 23说个我亲身遇到的例子。一个列表页卡片之间的间距看起来很均匀设计师交付时说间距 24。上线后做视觉走查发现长列表滚动到底部时卡片之间会出现一条比预想中宽一点的缝累积起来整页比设计稿长了十几个像素。排查过程其实很简单。打开原稿选中卡片看右侧的 X/Y/W/H——X 是 0、Y 是 23.5。也就是说设计师是手拖的实际间距是 23.5取整后接近 24但列表里每张卡片的 Y 值都积累了 0.5 的偏差滚到底部就明显了。开发按 24 实现本身没问题问题出在稿子本身就没有一个唯一真值。修复方式也很直接把卡片包进一个纵向 Auto Layout 容器gap 设为 24之后无论怎么增删卡片间距永远只有这一个来源。注意间距不是标出来的是定义出来的。凡是需要你手写一个数字去告诉开发这里间距多少的地方大概率说明这个布局还没有被正确地结构化。顺带提一下栅格。8pt 栅格在移动端已经是默认共识但真正落地的不多。我的做法是间距只允许取 4 的倍数常用的就 4、8、12、16、24、32 这几档超过这个范围要么是设计出了问题要么是场景特殊需要单独说明。把间距收敛成有限几档比标注几十个数字有用得多因为它让这个间距该是多少从一个需要问的问题变成了一个可以推导的答案。2. 切图导出十次九次被吐槽问题基本不在导出按钮上2.1 切图交付的其实是一份资源清单不是一个 png很多人理解的切图是选中图层右下角加个 2x点导出。但从开发的角度看他需要的是一份能直接放进项目目录的资源清单而不是一堆散落在下载文件夹里的图片。举个具体的例子一个返回箭头图标。它有正常态、按下态、禁用态三种状态产品还要求支持深色模式。这就意味着同一个语义的图标实际要交付 6 个文件。如果命名毫无规律比如箭头.png、箭头-1.png、箭头 copy.png、未命名-32x.png开发只能靠肉眼比对接一次需求骂一次人。我在团队里推的命名规则大概是这个样子模块_功能_状态_主题倍率.后缀 nav_back_normal_light2x.png nav_back_pressed_light2x.png nav_back_disabled_dark2x.png icon_cart_normal3x.png规则不必跟我一样但必须有规则而且要在团队里形成默认。命名里有几个坑值得单独说不要用中文名。有些构建流程对非 ASCII 文件名的处理不一致尤其是走 CDN 或者做资源压缩的时候。不要用空格。空格在 URL 里会被转义成%20路径解析容易出问题用下划线或者短横线。不要在文件名里带最终版修改版(1)这类信息。版本管理交给 Git 或者设计文件的版本历史文件名只描述内容。状态和主题的字段顺序要固定。今天是back_pressed_normal明天写成back_normal_pressed开发写映射表的时候就会疯。2.2 SVG 还是 PNG一份可以直接照着用的对照表格式选择是切图里最容易拍脑袋的环节。我的经验是看「是否需要动态改变外观」和「是否包含复杂光栅效果」这两个维度。资源类型推荐格式主要原因需要额外注意单色图标SVG任意缩放不糊可改色体积极小硬编码 fill 要去掉改用可继承的颜色多色扁平图标SVG体积小、清晰图层要合并避免嵌套过深需要跟随主题换色的图标SVG一个文件适配多主题别在路径上写死颜色带复杂渐变、内外阴影、发光PNG 2x/3xSVG 在不同渲染引擎下差异明显提前定好画布尺寸别后期缩放照片、纹理、噪点背景JPG 或 WebP体积优势明显质量控制 80 左右通常够用会动的图标Lottie JSON体积可控、可编程控制导出后核对帧率和循环设置需要被 Unity / 原生绘制的资源PNG 序列引擎兼容性好倍率和命名要跟工程约定对齐关于倍率移动端常见的是 2x 起步高端机型需要 3xWeb 端基本以 SVG 为主位图用 1x 和 2x 两套即可。这里有个容易被忽略的点倍率不是越高越好。全量出 3x 会让资源包体积明显膨胀而收益在中低端设备上完全体现不出来。我一般的做法是图标全走 SVG位图只出 2x特殊场景比如启动页大图才单独讨论。2.3 图标发虚、被拉伸、边缘有白边三个高频根因的排查链路这三个问题几乎每个设计师都遇到过但根因往往是同一个东西的不同表现。我按排查顺序整理一下。第一步看坐标是不是整数。选中图层看右侧 X/Y/W/H 的值。如果出现 23.5 或者 17.33 这种数字导出时抗锯齿会沿着非整数边界计算边缘就会出现一层半透明的虚边。尤其在深色背景上会很明显。解决办法是把图层吸附到像素网格或者干脆用 Auto Layout 约束位置。第二步看画布是不是方的尺寸是不是整数。一个返回箭头如果画布是 24×25被放进 24×24 的容器里就会被拉伸或压缩视觉上要么变形要么被裁。图标的通行做法是统一方画布24×24、32×32、48×48路径在画布内居中边缘留出 1 到 2 像素的安全距离。第三步检查描边是否压在画布边缘上。Figma 的描边默认是居中的也就是说 2px 描边有一半落在路径外侧。如果路径正好贴着画布边缘导出的图标外侧就会被裁掉一半看起来像缺了一块或者有奇怪的毛边。处理方式有两种把描边改成内描边或者把描边轮廓化outline stroke之后手动调整路径。还有一类问题藏在 SVG 的导出细节里。Figma 导出的 SVG 如果包含剪切蒙版clip path或者图层模糊、外发光这类效果很可能会退化成内嵌位图体积一下子涨上去改色也失效了。导出之后用文本编辑器打开看一眼如果看到大段的image和 base64 字符串基本就是这个情况得回稿子里把效果处理平。2.4 导出前我一般会做的三个动作全选所有图标图层扫一眼 X/Y/W/H 有没有非整数有就批量吸附。提前在 Export settings 里配好倍率和格式选中多个图层一次性导出避免一个个点。导出后随机抽三五个图标分别放在浅色和深色背景上看一眼重点看边缘和透明度。这三步加起来不到两分钟但能挡掉大部分上线后才被发现的视觉问题。3. 让尺寸自己说话组件、变量与导出预设的工程化3.1 Auto Layout 是标注的地基但不是所有场景都该用它Auto Layout 的价值不在于看起来专业而在于它把间距和边距从一个视觉结果变成了一个有名字的规则。开发在 Dev Mode 里看到的是一个容器的 gap 是 8、padding 是 12而不是两个元素之间差了 8 个像素。这两句话对开发的含义完全不同前者可以直接映射成 flex 的 gap后者需要他自己判断该用 margin 还是 padding。但也不是所有东西都该塞进 Auto Layout。绝对定位的装饰元素、需要自由绘制的插画、刻意做重叠的文字标题这些用 Auto Layout 反而别扭。我的处理原则是布局层用 Auto Layout装饰层单独放进一个独立的 frame。这样即使装饰元素是手摆的它也不会污染布局层的结构开发一眼就能看出哪些是结构、哪些是贴图。另外提醒一个细节Auto Layout 的嵌套深度要控制。我见过有人为了做对齐把 Auto Layout 套了五六层每层只是为了让某个元素多偏移 2 像素。这种稿子在 Dev Mode 里生成的代码会长得离谱开发看着一堆嵌套的 div 会直接放弃。能用 padding 解决的就不用嵌套能用对齐方式解决的就不用占位元素。3.2 变量与样式颜色和字号不该靠截图传递Variables 这个东西刚出来的时候我也觉得是锦上添花真正用起来才发现它是解决改一次颜色要改几十个地方的正解。具体做法是把颜色、间距、圆角、字号这些会变化的数值都定义成变量命名按语义分层color/text/primary # 主文本色 color/text/secondary # 次要文本色 color/bg/surface # 卡片背景 space/4 4 space/8 8 space/16 16 radius/card 12然后在 Light 和 Dark 两个 mode 里分别指定具体值切换 mode 就能整体换主题不需要复制一整套画板。这一点在深色模式需求越来越多的今天是刚需复制画板那套做法维护成本太高了改一个颜色要改两遍迟早出岔子。文字样式和效果阴影、模糊用 Styles 管理理由一样。开发从 Dev Mode 里读到的是color/text/primary这个变量名而不是#1A1A1A这个具体值。变量名的意义在于它在开发那边也有一套对应的 token 定义改主题的时候两边同时生效。提示变量的命名要在团队里统一尤其是层级分隔符用斜杠还是短横线。命名风格不统一Dev Mode 里读出来的字符串就会五花八门工具再好也白搭。3.3 一份能直接抄的命名与导出对照表把组件命名和导出配置绑在一起考虑能省掉大量沟通。下面是我现在用的一套你可以直接改改拿去用。层级命名方式示例导出配置页面模块名Home、OrderDetail不导出区块模块/区块home/banner、order/list不导出组件类别/名称/尺寸/状态button/primary/large/default一般不导出图标icon/名称icon/arrow-leftSVG24×24 画布插画illust/名称illust/empty-orderSVG 或 PNG 2x位图img/名称img/product-placeholderPNG 2x状态不要用复制图层的方式做用 Variants 属性。一个按钮组件有 default、hover、pressed、disabled、loading 五个状态做在 Variants 里开发在 Dev Mode 里看到的是一组可以切换的属性如果是五个独立图层他看到的就是五份互不相关的代码片段还得自己去猜它们之间怎么映射。3.4 我踩过的一个坑组件改了导出目录里还是旧文件这个坑挺隐蔽的。一个图标组件原来叫icon/back后来因为命名规范调整改成了icon/arrow-back。稿子改了重新导出的时候忘记清空输出目录结果新文件名和旧文件名同时存在。开发拿到资源包不知道该用哪个就把旧的也一起打包进去了上线后发现有两个功能重复的图标资源。后来我固定了一个动作导出前先清空目标目录导出后做一次差集比对。如果团队里有脚本可以让脚本按组件名生成清单导出后自动比对少了什么、多了什么。没有脚本的话导出后在文件管理器里按修改时间排序旧文件一眼就能看出来。这个坑的另一面是组件改名要同步通知开发因为代码里的引用路径可能也跟着变了。命名规范最大的价值其实不是好看而是让改名这件事变成一次可追溯的操作而不是一次偷偷摸摸的修改。4. 当交付对象变成工具和 AIFigma 到代码这条路能走多远4.1 Dev Mode 生成的代码是参考译文本不是能上线的成品先说结论Dev Mode 里那段代码片段可以看可以抄数值但基本不能直接粘进项目里上线。生成的 CSS 通常能准确反映间距、颜色、字号、圆角这部分是可信的。问题出在两个地方一是类名和结构它给出来的是一堆语义不明的嵌套二是布局方式如果原稿用了绝对定位生成的会是position: absolute加一串left/top这跟响应式布局压根不是一回事。开发如果直接抄后面适配各种屏幕尺寸时会全部推翻重写。所以我对开发的建议一直是把 Dev Mode 当成一个精确的尺子和取色器。间距不确认、色值不确定、圆角不确定的时候去那里看看完自己写样式。指望它生成成品代码最后省下来的时间会在改 bug 的时候加倍还回去。4.2 MCP 这类工具到底解决了什么问题以及它的上限在哪最近问得比较多的一类问题是关于 Figma 接各种 AI 编辑器、接 MCP 的。这类工具的思路是让编辑器里的助手直接读取 Figma 文件的结构信息——图层、变量、组件、样式——然后在本地上下文里生成代码而不是靠你一张张截图粘贴。接入的基本流程大同小异在账号设置里生成一个访问令牌权限只勾选需要的那几项通常文件读取就够了别一把梭全勾把令牌放到本地环境变量里写进编辑器的配置文件。这里有一条必须强调令牌不要提交到代码仓库也不要写在会被共享的配置文件里。这个东西等同于你的账号访问凭证泄露了别人可以读你账号下的文件。实际用下来的感受是这样的稿子结构规整、组件化做得好、变量命名清晰的情况下效果相当好。它能把变量名和图层层级一起带过来生成的结构跟设计意图基本对得上尤其适合标准的中后台列表页、表单页。稿子是随手拖的、大量使用分组和绝对定位的情况下效果会明显下降。它读到的是一堆没有语义的 frame 和 group生成的代码会非常啰嗦反而比手写还费时间。所以这类工具的上限本质上不取决于工具本身而取决于你的文件有多干净。这又回到了第 3 节讲的那些事——Auto Layout、变量、命名规范。你前三节做到位了第四节这些工具才有用武之地前面没做好换个再强的模型也读不出一份结构混乱的稿子想表达什么。4.3 双向转换的适用边界什么场景值得用什么场景别碰设计稿转代码这类工具我的判断标准是看布局的标准程度。标准的两栏、卡片列表、表单用工具生成骨架能省不少时间但带有复杂动效、自定义绘制、大量状态联动的页面工具生成的代码只能当参考最后还是得手写。反过来把已上线的页面导回 Figma 这类方向真实用途主要有两个给历史项目补设计稿或者拿线上页面做改版的起点。要提前有个心理准备——导进来的结果一定伴随着大量无意义的嵌套和混乱的图层命名需要人工清理一遍才能用。把它当成起点而不是成品期望值就对了。这东西的定位说到底是加速器不是替代品。它能帮你跳过从零画框这一步但结构梳理、语义命名、状态补全这些真正费脑子的活还是得人来。5. 那些被反复问到的具体问题5.1 语言、字体、客户端三个最容易踩的环境坑关于界面语言优先在官方设置里找语言选项切换不要为了图快装来路不明的浏览器扩展或者第三方工具来处理界面文字。这类工具需要读取页面内容权限给出去容易出问题而且版本一更新就失效得不偿失。字体问题在设计协作里非常高频。你在本地装了某个字体画稿子的时候用上了同事打开文件时机器上没有这个字体文本就会被替换成默认字体字宽变了原本刚好放下的标题溢出了容器整个布局错位。解决办法有两个方向一是团队统一字体清单所有人都装同一套二是尽量用系统自带字体或者有广泛支持的字体特殊字体只用在图片化的标题上。交付前一定要检查文本有没有溢出尤其是按钮和标签这种宽度受限的容器。客户端和网页版的选择也值得说一下。客户端对本地字体的支持更完整、大文件的性能更稳定、支持一些桌面端的快捷键操作网页版免安装、换设备就能用、分享链接更方便。团队一起协作的时候建议确认大家用的是同一端同一版本避免同一份文件在不同环境里表现不一致——尤其是在字体渲染和效果参数上差异有时候还挺明显。5.2 和 Axure、Xmind 的定位差异其实没什么好比的经常看到有人问这几个工具哪个更好用。我的看法是它们各自管着流程里不同的一段拿来横向对比本身就没什么意义。Axure 的强项是复杂交互逻辑和条件判断做可用性测试用的高保真原型尤其是带状态跳转、带变量计算的原型它的表达力确实更强。Figma 的原型功能覆盖了日常百分之八十的场景页面跳转、悬停、滚动、组件状态切换都能做但遇到复杂的逻辑分支就会有点吃力。Xmind 属于更上游的工具管的是信息架构、需求拆解、脑图梳理它不产出界面产出的是思考过程。真正的问题往往不是工具选得不对而是用错了阶段。在信息架构还没理清的时候就开始画高保真界面画到一半发现页面结构要推翻重来这才是时间浪费的大头。5.3 交付前的自检清单照着走一遍能省掉大半返工我把这些年反复被返工的地方整理成了一张清单交付前挨着过一遍基本能挡掉大部分问题。检查项判断标准常见问题布局结构布局容器都用了 Auto Layout嵌套不超过三层手拖导致间距非整数间距取值全部是 4 或 8 的倍数出现 13、23.5 这类值颜色字号引用变量或样式没有孤立硬编码值同一个色值有五个略微不同的版本组件状态状态做在 Variants 里不是复制图层开发不知道状态怎么映射异常态空、加载、失败、超长文本都画了开发自己拍脑袋补资源命名符合统一规则无中文、无空格、无版本词导出目录一堆副本导出配置格式和倍率齐全画布尺寸是整数图标边缘发虚主题适配深色模式切换后对比度和层级正常深色下阴影全丢点击区域移动端不小于 44×44小图标点不中标注说明只写工具读不到的规则不重复标数值红线标了一堆异常态一个没有这张表不长但每一条背后都是实实在在的返工。尤其是异常态那一行我见过太多项目上线后才发现没有加载状态的样式临时由开发补一个风格跟整体完全不搭。最后说个我自己的小习惯每次交付前我会把稿子关掉隔十分钟再打开用完全陌生的视角从第一屏开始往下滑。这个动作能发现很多在长时间编辑中已经看习惯了的问题——比如某个间距明显大了、某个文字的对比度不够、某个状态忘了画。人对着同一份稿子看久了会失去判断力隔一会儿再看问题自己就跳出来了。这比任何清单都管用。