前阵子有个老朋友问我：“我团队里的设计还在用PS和Sketch，最近老听人聊Figma，它到底是个啥？值得转吗？”这个问题看起来基础，但真要讲透，还真不是一两句话能说完的。我从PS时代一路用到Sketch，再到现在整个团队彻底切到Figma，中间踩过的坑、绕过的弯太多了。这篇就把我这些年对Figma的理解、团队的落地过程、还有新手最常见的那几个问题（汉化、字体、标注、插件那些）一次性讲清楚。
Figma首先是设计工具，但它跟PS、Sketch有一个本质区别——它把“设计”这件事从单机软件变成了一个云端协作平台。你以为它只是换了个画图的地方，实际上它连工作流程都改了。这篇文章我会从问题出发，讲它到底解决什么、核心功能怎么用、新手容易在哪儿卡住、以及从设计稿到开发交付这条链路怎么打通。不管你是设计师、前端开发，还是负责引入工具的团队负责人，都能从中找到你需要的东西。
1. 先搞清楚一件事：Figma到底解决的是什么问题
1.1 设计文件的共享与交接，是传统工具最大的痛点
用PS或Sketch做UI设计的老人都知道，一个项目做到中期，磁盘里必然躺着这么一堆文件：“首页_v8_最终版”、“首页_v8_最终版2”、“首页_v8_打死也不改了.sketch”。这些文件不仅命名混乱，而且体积巨大，传起来费劲，打开更费劲。最要命的是团队协作：设计师A改完一版，要发给设计师B继续调，得用网盘、U盘或者各种IM传来传去。传到后来，谁也不知道自己手里到底是不是最新版。
Figma把文件存在云端，所有成员都从同一个地址打开同一个文件。你改完我立刻就能看到，不存在“发来发去”这个过程。而且它的保存逻辑跟Google Docs一样，不用手动Ctrl+S，每敲一个字符、每次拖动一个图层，改动都会实时同步到云端。文件历史里可以回溯任意时间点的版本，就算改崩了也能一键恢复。这件事看起来简单，但对设计团队来说，是从“串行交接”到“并行协作”的根本转变。
1.2 实时协作不是锦上添花，是工作方式的重构
没实际用Figma协作过的人，意识不到“多人同屏操作”意味着什么。我的团队做一次版本迭代，设计师、交互、前端三个人会同时打开同一个文件。设计师调整按钮颜色的时候，前端就在旁边看着，顺便在评论区里跟一句“这个圆角值帮我记一下”；交互同学直接拖着原型框图去跟需求方对流程。大家像用共享文档一样用设计稿，谁在哪个画板、在编辑什么东西，光标和人名都看得清清楚楚。
这种模式直接砍掉了大量“过稿同步会”。以前改一版设计要拉个会议，对着截图讲半天“我改哪儿了”；现在所有人盯的是一个活文件，改完那一瞬间大家就都知道了。尤其是远程办公的场景，靠的就是这种东西把大家拉回同一张桌子上。我用了一年多之后回头看，协作能力才是Figma真正的护城河，画图功能本身反而只是基本功。
2. 从Sketch和PS时代转过来，为什么就回不去了
2.1 组件、样式与变量：设计系统的地基
Sketch现在也有组件和样式，但Figma对“设计系统”的支持颗粒度更细。你把一个按钮做成组件（Component），然后在几十个页面里复制粘贴它的实例（Instance），哪天想统一改圆角，只需要改主组件，全部实例跟着变。这一点Sketch也能做到，但Figma因为文件在云端，组件库可以被多个项目文件共享，跨项目同步设计规范非常方便。
更进阶的是Variables（变量），可以理解成给设计稿里的颜色、字体、间距这些属性建立起“语义化”的命名词典。比如主色不叫#0A66C2，而叫“Brand/Primary”；间距不用每次手敲8、16、24，而是定义成“Space/SM”，开发在代码里也对应这样一个token变量。这样一来，设计稿和代码在命名上就能对齐，设计的修改可以通过变量批量生效，而不是全局替换一个颜色然后半张图全乱掉。这是传统工具里很难做到的，也是想建立组件库的团队最该尽早投入的部分。
2.2 Auto Layout：让设计稿像网页一样“自己长”
Auto Layout（自动布局）是很多人用Figma之后“真香”的起点。它用类似前端Flexbox的思路去约束元素排列方式，你告诉Figma：这三个按钮是横向排列，间距16px，左右padding 24px，顶底padding 12px。之后不管你是把文字改成两行，还是把按钮数量从3个变成4个，整个卡片都会自动撑开，不用再手动一个个挪位置。
很多人问“Figma自由布局怎样随文字大小变化”，答桉就在这：给文本节点套上Auto Layout容器，容器设置成Hug contents（包裹内容），文字变长，容器和旁边元素的位置就会自动撑开。这种设计方式极大减少了纯手工对齐的体力活。我团队的UI稿从起稿到交付，基本不出现“这块没对齐、那块间距不对”这种低级返工，因为约束已经写死在框架里了。
2.3 Dev Mode与开发交付：设计稿就是注释文档
Figma在2023年推出的Dev Mode（开发模式），进一步降低了设计到开发的沟通成本。前端打开Dev Mode，点击设计稿里任意一个元素，右侧面板直接展示它的尺寸、间距、字体大小、字重、颜色、圆角、阴影等全部属性，还能导出对应切图。设计师不需要再辛苦地标红、画线、加注释，因为标注信息本身就是实时的，你改了什么开发那边立刻看到最新值。
这个模式推出来之后，我们团队沟通设计的语言统一多了。以前“这个按钮稍微圆一点”这种口头的模糊表达，现在直接变成“你把radius从8改成12”，一版就能改到位。再配合样式变量映射到代码的token，开发基本不需要对着设计稿猜来猜去。
3. 新手上路：下载、汉化、字体，这三道坎怎么过
3.1 Figma怎么下载，选客户端还是网页版
Figma的官方客户端本质上是一个浏览器壳，但比直接用网页版体验好不少，尤其是文件多、加载复杂原型的时候，内存管理和本地字体渲染都更稳定。Windows用户直接去官网下载Windows安装包，装完登录账号就能用。免费版和个人版在功能上足够做大量日常设计，真正需要付费的是团队协作的历史记录深度、多人同时编辑的席位上限这类企业级能力。
还有一点值得注意：Figma的客户端会帮你管理本地字体，这点跟网页版不同。网页版在调用设计稿里的系统字体时偶尔会“认不出来”，客户端则能直接读取你电脑安装的字体文件，所以如果你重度依赖某些特殊字体，建议别只用浏览器，装个客户端会省心很多。
3.2 没有官方中文怎么办：界面汉化的几种现实选择
Figma的官方界面目前没有完整的中文方案，这对很多英语一般的设计师来说确实是一道门槛，尤其是刚接触时一堆专业术语容易劝退。社区里因此出现了不少汉化插件和方法，基本思路分三类：
- 浏览器插件注入汉化包，改的是网页版界面，比较适合临时用；
- 社区开发者做的汉化插件，直接在Figma里以插件形式运行，把常用面板、右键菜单汉化掉；
- 客户端层面做一些语言包替换，本质上是魔改安装目录，更新版本之后可能失效。
我的建议是，如果你英语底子还行，尽快适应英文界面并不是坏事，因为Figma的社区讨论、官方文档、插件生态绝大部分都是英文的，你逃避汉化就会错过一手信息。如果团队里实在有人看英文很吃力，可以先用汉化插件过渡，但在团队规范里建议以官方英文面板为最终目标。界面汉化只是学习工具的辅助，别让它变成依赖。
3.3 Figma安装字体的那些坑：为什么设计稿里中文/特殊字体会乱
“Figma安装字体”是搜索量特别高的一个问题。它的原理在于：Figma云端存储文件的时候，不会把字体文件本身打包进去，只记录“这里用什么字体”。当你本地没有装这个字体，Figma就临时用默认字体替代显示，所以你打开别人的文件会看到一堆字挤在一起或者全部变成系统默认样式，这不是文件坏了，只是缺字。
解决办法有两条路。第一条最直接，把自己用的字体安装到操作系统里，然后重启Figma客户端，让它重新扫描字体库。第二条是用Figma的“共享字体”方案，团队统一通过字体管理工具（比如一些企业级字体托管服务）把字体文件同步给大家，确保每个成员环境一致。这里我特别提醒一句：中文字体文件通常很大，动辄几十MB，在Figma里批量加载会拖慢性能，能用系统字体或者通用字体就尽量别打包特殊中文字体，实在要体现特殊字重，再考虑嵌入。
4. 从设计稿到真正落地：标注、蓝湖、AI和MCP生态
4.1 Figma里怎么看UI的位置标注，前端别只会截图
很多前端同学刚接手Figma项目时，还在用“截图到PS里量距离”这种老办法，这完全浪费了Figma的优势。看标注最标准的方式是这样的：选中一个图层，右侧设计面板会显示它的X/Y坐标、宽高、旋转角度；按住Alt键再悬停到另一个元素上，Figma会直接显示两个元素之间的间距，这个距离是动态计算的，拖动任何一侧数值都会实时更新。
如果要看一整个区块的布局参数，就在Dev Mode下点击任意元素，右侧会把margin、padding、gap这些类CSS属性以结构化的方式列出来。用这类标注信息写代码，基本要做到“设计稿看到的数值，直接复制到代码里就能跑”。我见过太多前端拿着设计稿还反复跟设计确认“这个字是多少号”，其实答案就在你手边的面板里，只是没人告诉你而已。
4.2 Figma怎样导出到蓝湖：国内团队绕不开的一环
蓝湖（Lanhu）在国内设计团队里使用率很高，它承担的是“设计图+标注+协作+素材管理”的综合平台角色，很多公司要求设计稿必须进蓝湖归档。Figma里导出内容到蓝湖，不是靠Figma自带功能，而是靠蓝湖提供的Figma插件。操作步骤很简单：在Figma社区搜索“蓝湖”插件并安装，然后选中你要上传的画板或页面，运行插件，授权蓝湖账号，选择分组和项目，上传即可。上传完成后，开发在蓝湖里就能看到和Figma几乎一致的标注信息和切图资源。
这个链路有个好处：蓝湖里沉淀的是“某个版本”的快照，适合做版本归档和需求评审，而Figma实时文件则用于高频迭代。两条链路并行，既能保证团队的数据沉淀，又不影响实时协作。我见过一些团队想把Figma直接当蓝湖用，其实它们定位不完全重合，历史版本和项目管理上蓝湖更成熟，Figma强在创作协同本身。建议两个工具配合使用，而不是二选一。
4.3 Figma MCP：AI工具开始直接“读”设计稿了
最近一年，跟Figma相关的最热关键词一定包含MCP（Model Context Protocol，模型上下文协议）。简单说，MCP是一个标准化的接口协议，它让AI工具能够通过统一的方式读取外部工具的数据。Figma MCP就是这样一个桥：AI编程助手（比如Trae、Codex、CodeBuddy这类工具）装上对应的Figma MCP插件后，就可以直接从你的Figma文件里读取设计稿的结构、样式、文案、标注信息，然后把这些信息转化成前端代码。
我实测下来，目前最常用的场景是：在AI编程工具里配置好Figma MCP的链接地址和Access Token，然后在对话里自然询问“读取这个页面的设计稿，把列表卡片部分用React写出来”。AI会通过MCP接口去拉取Figma文件的数据节点，理解设计结构，再生成对应的代码。这么做的好处是，AI“看到”的不再是人肉描述的文字，而是和真实设计稿一致的数值，代码还原度大幅提升。
不过要提醒一句：MCP读的是结构化数据，不是你视觉上看到的图形，所以复杂的视觉效果、特殊字体、动效，AI仍然无法完整还原。MCP现阶段最擅长的是把布局结构、颜色、间距、文案等底层信息抽出来，这也是前端还原设计稿最耗时的部分。对做AI辅助开发的团队来说，尽早把Figma文件的命名规范、图层层级管理好，MCP读出来的数据结构才越干净，AI输出代码的质量也就越高。
至于开源社区Figma MCP（community版本）的安装，一般就是在GitHub上下载对应的MCP服务端，然后在你的AI工具里以命令行方式注册进去，再配置Figma的开发者令牌。不同工具配置入口略有差异，但核心三步是固定的：拿到Figma Personal Access Token、把MCP服务跑起来、在AI工具中指向这个服务。配置完成后，AI工具就能按需调用Figma文件里的数据了。
5. 团队落地Figma一年后，我总结的几条避坑经验
5.1 文件权限和团队管理，越早规范越好
Figma的权限系统非常灵活，但也意味着容易混乱。文件、页面、团队可以设置不同的查看、编辑、管理员权限。我的团队早期在权限上吃过亏：给外包设计师开了某个项目的编辑权限，结果他为了找参考图，直接把共享文件结构挪了个遍，第二天大家打开文件发现首页全变成了他的试验品。从那以后我规定：
- 外包和临时协作者只给查看权限，除非明确需要他们提交改动；
- 内部成员按项目分团队，页面级的权限严格控制；
- 关键的版本分支不要放在同一个页面里，用不同的Figma文件来隔离。
权限问题看着是管理小事，但放任不管，用得越久整理成本越高。
5.2 性能问题：大型文件卡顿，不能只会喊Figma不行
Figma在浏览器和客户端里跑得很顺畅，但也不是没有上限。文件到了几百个页面、几千个复杂组件的时候，照样会明显卡顿。我的经验是，遇到性能问题先自查，不要一股脑怪工具。常见原因：
- 设计稿里嵌入了大量高清位图，你拖一张5MB的截图进去，等于设计稿里多了5MB的负担，而且每个实例都会加载一遍；
- 组件嵌套层数过深，尤其是一个人把某个区块套了十几层Frame，每层都有效果，渲染性能就会指数级下降；
- 多人同时在线编辑同一个复杂页面，每个人的光标、选中框都会实时同步，也会加重渲染压力。
解决办法也很朴素：大图尽量用外链或压缩后再放进Figma；建组件的时候控制嵌套层级；页面内不建议堆太多复杂原型逻辑。还有一点，团队里最好约定一个“文件瘦身日”，定期清掉没用的组件、隐藏图层和废弃画板。
5.3 设计规范和命名习惯，决定协作的天花板
最后一条是我的个人执念，但真的帮我们省了太多事。Figma再智能，也架不住图层名字叫“矩形 248”“Frame 293”。这类默认命名的图层在团队协作里尤其致命：开发拿着标注截图问“哪个是按钮、哪个是图标”，设计师自己在隔了三天之后回来看文件都得靠猜。MCP之类的AI工具读设计稿的时候更是“看”这种命名，你图层叫“矩形 248”，AI生成的代码注释就是“// 矩形 248”，毫无意义。
我建议从第一天就定几个简单规则：所有组件、图标、Frame用“模块/用途/状态”这种格式命名，比如“Button/Primary/Hover”；样式里定义清楚颜色、字体的token名；画板按页面流程命名并分组。刚开始做会觉得繁琐，但坚持一两个月后，设计师改稿速度、开发查标注速度都会明显快一大截，因为这些“隐性收益”全在日常操作里体现出来了。
用Figma这两年，我从单纯把它当成一个“画图工具”，到后来把它当成整个团队的设计协作枢纽，前后心态变化很大。它确实不是完美的，性能、价格、生态都有各自的槽点，但它把“协作”这件事的体验拉到了一个新高度。如果你正准备从传统工具切过来，我的建议是不要贪多求全，先让全组人都把文件搬上去、养成云端协作的习惯，再慢慢引入Auto Layout、组件库、变量和MCP这套东西。等你们用顺手了再回头看，大概率也会有我这种感觉：回不去了，也没必要回去了。
