企业官网建设流程全解析

我见过太多次这样的场面：一个同学 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 显示尺寸，但你团队可能全用 px；Figma 导出时默认用图层名当文件名，但你的图层名是"矩形 12"；Figma 的间距显示的是测量值，而 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，然后给这个集合加两个 Mode：Light 和 Dark。切到 Dark 时，color/bg/surface的值变了，稿子自动变色，你不需要维护两套画板。开发那边看到的就是同一套令牌名对应两组值，代码里写var(--color-bg-surface)，主题切换交给 CSS 变量或者构建时替换。

除了颜色，数值型变量（Number）同样好用。建一组space/1=4、space/2=8、space/3=12、space/4=16、space/5=24、space/6=32，所有 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，这样批量工具一条规则就能筛出来。

命名规范上，业界比较通行的组件命名法是层级/类别/变体/状态，落到实际大概是这样的：

提示：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 导致首屏加载慢一秒。我把常见的选择逻辑整理成一张表，遇到犹豫的时候直接对照。

这里有一个特别容易踩的坑：在 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 的尺寸单位可以在偏好设置里切换成 px，Dev 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 交付前自检清单

我自己的习惯是，每次提测前过一遍这张清单。它不长，但每一条都是被坑出来的。

清单本身不复杂，难的是每次都执行。我的做法是把它做成交付模板的一部分，在文件里放一个 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 一张速查表

把上面这些高频问题压缩成一张表，遇到类似症状可以先按表排查，再考虑深挖。

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 与设计稿取数

最近一年，围绕设计稿和代码之间的取数方式，多了一些新东西。简单说，就是让本地的编码工具能够直接读取设计文件里的节点结构，而不是靠人肉搬运。常见的形式是提供一个服务端，把设计文件的结构信息暴露给编码助手，助手再据此生成或修改代码。

这类工具确实能省事，尤其是做「照着设计稿搭页面骨架」这种机械劳动时。但用之前得想清楚两件事。一是它读的是结构数据，不是审美判断：你的稿子如果间距随意、命名混乱，它生成的代码就是把混乱忠实复刻一遍，速度越快，债务积累越快。二是它拿不到的东西依然需要人工补：动效、交互反馈、边界情况、媒体裁切规则，这些还是得有人写在稿子里、写在文档里。

关于访问令牌的获取，各家工具的入口不太一样，通常在个人账号的设置区域里能找到与开发相关的选项。要提醒的是，这类令牌的权限和账号绑定，拿到之后不要提交进代码仓库，也不要在公共场合截图暴露，用环境变量管理是基本操作。

我个人的判断是：这类工具会越来越普及，但它改变的是"信息怎么传"，不改变"信息本身有没有被生产出来"。标注和切图这两件老事，本质是让设计意图变得可读、可复用、可验证——工具换了多少代，这个目标没变过。真要说有什么变化，那就是规范的收益被放大了：一份干净的设计稿，交给人和交给工具，产出都是又快又准；一份混乱的稿子，交给谁都是返工。