1. 为什么“从白稿开始”是改版效率的最大陷阱
做过中后台系统改版的人大概都有这种经历：产品经理丢过来一句“这个页面太旧了，重新设计一版”，然后设计师打开 Figma，新建一个 1440 宽的 Frame，从零开始摆导航、摆表格、摆按钮。三天后交稿，开发一看说“这个布局跟我们现在的组件库对不上”，于是又改两天。最后上线时发现，真正被用户感知到的变化，可能只有配色和圆角。
问题出在哪？出在起点选错了。
“白稿”指的是完全空白的画布，没有任何现有界面的约束。从白稿开始做改版，本质上是在做一次“重新发明”，而不是“重新设计”。重新发明的问题在于，你会不自觉地按照理想状态去画，而不是按照系统实际运行的状态去画。理想状态下的表格列宽是均匀的，实际运行中某一列因为数据太长被撑开了；理想状态下的弹窗是居中的，实际运行中因为父容器 overflow 设置不对，弹窗被裁掉了一半。
这些差异，白稿里全都看不见。
所以我的做法是反过来的：改版的第一步不是打开 Figma，而是把当前正在运行的界面“带回去”。带回去的方式有很多种，截图是最基础的，但截图是静态的、扁平的，丢失了层级关系和交互状态。更好的方式是用工具把运行界面的 DOM 结构、样式、甚至组件树抓下来，转成 Figma 可以识别的图层。
这就是标题里说的“先把运行界面带回去”的真正含义。它不是让你把截图贴进 Figma 当参考图，而是让运行界面成为设计稿的基底。你在真实结构上做修改，而不是在空白画布上做想象。
这个思路的转变，带来的效率差异是数量级的。我做过一个对比：同一个列表页改版，从白稿开始平均需要 2.5 天出第一版可评审稿，从运行界面导入开始只需要 0.5 天。省下来的时间不是偷懒省出来的，是因为你不需要再画一遍已经存在的东西。
注意：这里说的“带回去”不是让你照抄现有界面。现有界面是起点，不是终点。你要做的是在真实结构上做减法、做重组、做视觉升级，而不是从零搭建一个看起来很像但结构完全不同的东西。
2. 把运行界面搬进 Figma 的三种路径与选型逻辑
“把运行界面带回去”这句话说起来简单，但具体怎么带，有不同的技术路径。我实际用过的主要有三种，各有各的适用场景和坑。
2.1 截图 + 手动描摹：最笨但最可控
这是最原始的方式：截一张运行界面的图，拖进 Figma，降低透明度，然后在上面手动描图层。听起来很蠢，但它在某些场景下反而是最优解。
什么时候用？当运行界面的结构极其复杂，但你需要改动的部分很局部的时候。比如一个数据看板，上面有十几个图表组件，你只想改顶部的筛选栏。这时候用工具把整个页面导入 Figma，反而会带来大量无用的图层，拖慢文件性能。截图描摹只针对你要改的区域，干净利落。
手动描摹的关键技巧是：不要描得太细。你是在做设计稿，不是在复刻像素。把主要的容器边界、间距关系、层级关系描出来就够了。文字内容可以直接用截图上的，不需要重新打字。
这种方式的问题也很明显：不可复用。下次改另一个页面，你得重新描一遍。所以它只适合一次性、局部性的改版任务。
2.2 浏览器插件导出：速度最快，但结构会失真
市面上有一些浏览器插件可以把当前页面的 DOM 结构导出成 Figma 文件。原理大概是遍历 DOM 节点，读取计算样式，然后生成对应的 Figma 图层。我用过几个，导出速度确实快，点一下按钮，几秒钟就能在 Figma 里看到页面结构。
但问题在于“结构会失真”。DOM 是嵌套的，Figma 的图层也是嵌套的，理论上可以一一对应。但实际上，CSS 的布局模型（flex、grid、absolute）和 Figma 的自动布局（Auto Layout）并不是完美映射的。一个用 flex 实现的水平排列，导出后可能变成一堆绝对定位的图层，你一动就全乱了。
还有一个更隐蔽的问题：伪元素和背景图。很多界面的装饰性元素是用::before、::after或者background-image实现的，这些在 DOM 遍历中往往会被忽略或者处理不当。导出后的 Figma 文件看起来“少了点什么”，但你一时半会儿说不清楚少了什么。
所以这类工具适合什么场景？适合结构简单、以文本和基础容器为主的页面。比如一个设置表单页，全是 label + input 的垂直排列，导出效果就很好。但如果是复杂的仪表盘或者带有大量自定义绘制的页面，导出结果基本没法直接用。
2.3 设计系统反向映射：最理想，但前提是你有设计系统
这是最理想的方式：如果你的项目已经有一套完整的设计系统（组件库 + 设计令牌），那么运行界面上的每一个元素都可以反向映射到设计系统里的组件。你不需要导出图层，你只需要知道“这个页面用了哪些组件、哪些变体、哪些令牌”，然后在 Figma 里用对应的组件重新拼装一遍。
这种方式的好处是：产出的设计稿天然与代码实现对齐。开发看到设计稿，直接就能对应到组件库里的组件，不需要再做“翻译”。而且因为用的是组件实例，改起来也快，改一个主组件，所有实例同步更新。
但它的前提条件很苛刻：你得有设计系统，而且设计系统和代码实现得是同步的。很多团队号称有设计系统，但实际上 Figma 里的组件库和代码里的组件库是两套东西，各走各的。这种情况下，反向映射就无从谈起。
我的建议是：如果你所在团队有维护良好的设计系统，优先用这种方式。如果没有，先用第二种方式快速导入，然后在 Figma 里手动把关键组件替换成设计系统里的组件。这个过程虽然麻烦，但一次投入，后续所有页面改版都能受益。
| 路径 | 适用场景 | 速度 | 结构保真度 | 可复用性 |
|---|---|---|---|---|
| 截图描摹 | 局部改版、复杂页面 | 慢 | 高（人工控制） | 低 |
| 插件导出 | 简单页面、快速原型 | 快 | 中低 | 中 |
| 设计系统映射 | 有成熟设计系统的团队 | 中 | 高 | 高 |
3. 运行界面导入后的图层清理与结构重建
不管你用哪种方式把运行界面带进 Figma，导入后的第一件事都不是开始设计，而是清理图层。这一步很多人会跳过，觉得“反正能看就行”，但后面会吃大亏。
3.1 为什么导入后的图层必须清理
插件导出的图层结构，反映的是 DOM 的嵌套关系，而不是设计的逻辑关系。DOM 里为了布局方便，会加很多无意义的包裹层。比如一个按钮，DOM 结构可能是div > div > button > span，导出到 Figma 就变成四个嵌套的 Frame，但实际上你在设计时只需要一个按钮组件。
这些多余的嵌套层会带来三个问题：第一，文件体积膨胀，打开和操作变卡；第二，自动布局难以应用，因为层级太深；第三，开发看设计稿时会被误导，以为需要那么多层嵌套。
清理的原则很简单：合并视觉上无差别的图层，删除纯布局用的空容器，把语义相关的元素归组。具体操作上，我会按这个顺序走：
- 先看最外层，把页面级的容器保留，删除多余的 wrapper。
- 再看每个区块，把区块内的元素按功能分组，比如“搜索区”“表格区”“分页区”。
- 最后看单个组件，把组件的内部结构简化到最小必要层级。
这个过程大概会花掉 10 到 15 分钟，但后续所有操作都会因此顺畅很多。
3.2 用命名规范把“运行结构”翻译成“设计结构”
清理完图层之后，下一步是重命名。导入的图层名字通常是Frame 123、Group 456这种，完全不可读。你需要把它们改成有语义的名字。
命名规范我建议直接用设计系统里的组件名。比如Button/Primary/Default、Input/Text/Default、Table/Header/Cell。这样做的好处是，当开发拿到设计稿时，看到图层名就知道对应哪个组件，减少沟通成本。
如果团队没有设计系统命名规范，那就用最直白的业务命名：搜索栏、数据表格、操作按钮组。关键是一致，同一个东西在所有页面里叫同一个名字。
提示：Figma 的“重命名图层”功能支持批量操作。选中多个图层，按
Cmd+R（Mac）或Ctrl+R（Windows），可以用正则表达式批量替换名字。比如把所有Frame前缀去掉，或者把Group统一改成Section。
3.3 把静态图层转成自动布局的时机判断
自动布局是 Figma 里最核心的功能之一，但并不是所有图层都适合立刻转成自动布局。我的经验是：先清理和命名，再考虑自动布局。因为自动布局会改变图层的父子关系和排列方式，如果在图层还很乱的时候强行转，只会更乱。
判断一个区块是否适合转自动布局，看两个条件：第一，这个区块内的元素是否有明确的排列方向（水平或垂直）；第二，这个区块是否需要响应式伸缩。如果两个条件都满足，那就转。如果只是固定尺寸的装饰性元素，保持绝对定位反而更简单。
转自动布局的时候，注意间距的设置。导入的图层间距往往是靠 margin 或 padding 实现的，转成自动布局后，要用 Auto Layout 的 gap 和 padding 来还原。这里有个小技巧：先用截图量一下实际间距，然后在 Figma 里设置对应的数值。不要凭感觉设，凭感觉设出来的间距，开发实现时会对不上。
4. 在真实结构上做改版的实操节奏
把运行界面带回来、清理好、命名好之后，才真正进入“改版”环节。这时候你的画布上是一个结构清晰、命名规范、与线上实现对齐的基底。在这个基底上做修改，和从白稿开始做修改，体验完全不同。
4.1 先做减法：删掉不需要的元素
改版最容易犯的错误是“只加不减”。看到旧界面，觉得这个也要保留，那个也要保留，最后改出来的东西比原来还臃肿。正确的做法是先做减法。
具体怎么减？我会问三个问题：这个元素用户真的需要吗？这个元素的信息能否合并到其他地方？这个元素删掉后，用户完成任务会不会受阻？如果三个问题的答案分别是“不确定”“能”“不会”，那就删。
比如一个后台列表页，顶部有六个筛选条件。实际上根据数据，80% 的用户只用其中两个。那改版时就可以把另外四个收进“高级筛选”里，默认只展示两个。这就是减法。
减法的好处是，页面变清爽了，剩下的元素有更多呼吸空间，视觉升级也更容易做出效果。而且删元素比加元素的风险低，因为删掉的东西如果用户真的需要，反馈会很快上来，加回去也容易。
4.2 再做重组：调整信息层级和操作路径
减法做完之后，剩下的元素需要重新组织。重组的目标是让信息层级更清晰，操作路径更短。
信息层级方面，我会用“三秒测试”：把设计稿给一个没用过这个系统的人看三秒，然后问他“这个页面是干什么的”“最重要的信息是什么”“下一步该点哪里”。如果答不上来，说明层级有问题。
操作路径方面，核心原则是“高频操作前置，低频操作后置”。比如一个订单管理页面，最常用的操作是“查看详情”和“发货”，那这两个按钮就应该放在列表项最显眼的位置，而不是藏在“更多”菜单里。
重组的时候，可以借助 Figma 的“内容比例”功能来测试不同屏幕宽度下的表现。把 Frame 拉宽拉窄，看布局是否还能保持合理。这一步能提前发现很多响应式问题，避免开发阶段再返工。
4.3 最后做视觉：配色、间距、圆角的统一升级
视觉升级是改版里最直观的部分，但也是最容易做过头的地方。我的建议是：视觉改动要有节制，一次只改一个维度。
比如这次改版只调间距体系，把所有间距统一到 4 的倍数（4、8、12、16、24、32）。下次改版只调圆角，把按钮、卡片、输入框的圆角统一到一套值。再下次调配色，把主色、辅助色、语义色重新定义。
为什么不要一次全改？因为一次全改，你无法判断哪个改动带来了正面效果，哪个改动带来了负面反馈。而且全改的工作量巨大，评审时也很难聚焦。
如果非要一次全改，那就用设计令牌（Design Token）来管理。在 Figma 里用 Variables 定义好颜色、间距、圆角的令牌，然后批量应用到所有图层。这样改一个令牌值，所有引用它的地方同步更新。这是目前效率最高的视觉升级方式。
5. 从 Figma 到代码：让改版稿真正可落地
设计稿做得再漂亮，如果开发实现不出来或者实现出来走样，那改版就是失败的。所以从 Figma 到代码的衔接，必须在设计阶段就考虑进去。
5.1 标注不是万能药，结构对齐才是关键
很多设计师习惯在交付时写一大堆标注：这里间距 16px，那里字号 14px，这个按钮圆角 8px。但开发真正需要的不是这些数值，而是结构对应关系。
什么意思？开发看到设计稿，第一反应是“这个页面由哪些组件组成”。如果设计稿里的组件和代码里的组件能一一对应，开发实现起来就很快。如果设计稿里是一个自定义的复杂布局，代码里没有对应的组件，开发就得从头写，这时候标注再详细也没用。
所以我在做改版稿的时候，会尽量使用设计系统里的组件实例。如果某个地方必须自定义，我会在设计稿里明确标注“此区域为自定义布局，建议实现方式为……”。这个建议不是命令，而是给开发一个参考，减少他们的决策成本。
5.2 用 Figma 的 Dev Mode 减少沟通损耗
Figma 的 Dev Mode 是近几年对开发最友好的功能之一。它可以把设计稿里的图层直接映射到代码片段，显示间距、颜色、字体等属性的具体值，还支持导出资源。
但 Dev Mode 的效果取决于设计稿的规范程度。如果图层命名混乱、结构嵌套过深、用了大量自定义样式，Dev Mode 给出的代码片段也是混乱的。反过来，如果设计稿结构清晰、命名规范、使用了设计令牌，Dev Mode 就能给出接近可直接使用的代码。
我实测下来的经验是：在设计阶段就把 Dev Mode 的预览打开，一边设计一边看它给出的代码提示。如果发现某个地方的代码提示很离谱，说明设计稿的结构有问题，当场调整。这样交付时，开发拿到的就是一份“代码友好”的设计稿。
5.3 改版上线后的验证：用真实数据反哺下一轮设计
改版上线不是终点。上线后一周，我会做一次数据验证：对比改版前后的关键指标，比如任务完成率、平均操作时长、错误率、用户反馈。
这些数据会直接反哺下一轮设计。比如发现某个按钮的点击率远低于预期，可能是位置不对或者文案不清晰；发现某个页面的跳出率很高，可能是信息层级有问题。
更重要的是，这些数据会告诉你“哪些改动是有效的”。有效的改动可以沉淀到设计系统里，成为后续改版的默认选项。无效的改动则记录下来，避免下次再犯。
这个闭环一旦建立起来，改版就不再是“拍脑袋想出来的”，而是“有数据支撑的迭代”。从运行界面带回来，在真实结构上改，用真实数据验证，这才是一个完整的改版循环。
6. 几个容易踩的坑和我的处理方式
最后分享几个我在实际项目中踩过的坑，以及后来怎么处理的。
第一个坑：导入的图层太多，Figma 文件卡到无法操作。处理方式是分批次导入，不要一次性把整个页面导进来。先导你要改的区域，改完再导下一块。另外，导入后立刻把不需要的图层删掉，不要留着“以后可能用得上”。Figma 文件超过 5000 个图层就会明显变卡，控制图层数量是保持流畅的关键。
第二个坑：设计稿和线上实现不一致，开发说“这个效果实现不了”。处理方式是在设计阶段就用真实数据填充。Figma 支持通过插件填充真实数据，比如用真实的用户名、订单号、金额来替换占位符。这样你能提前看到极端情况下的表现，比如超长文本会不会撑破布局，大数字会不会换行。提前发现，提前调整。
第三个坑：改版后用户不买账，说“还是旧版好用”。处理方式是保留旧版入口，给用户一个过渡期。同时在改版上线时，用引导提示告诉用户“哪些地方变了，为什么变”。用户抵触往往不是因为新版不好，而是因为不习惯。给一点适应时间，配合清晰的引导，抵触会小很多。
第四个坑：设计系统组件和实际需求不匹配，强行用组件导致设计受限。处理方式是允许“合理的例外”。设计系统是工具，不是枷锁。如果某个场景确实需要自定义组件，那就自定义，但要在设计稿里标注清楚，并考虑是否值得把这个自定义组件沉淀到设计系统里。设计系统本身也需要迭代。
这些坑的共同点是：它们都不是技术问题，而是流程和协作问题。把运行界面带回来，本质上也是在解决流程问题——让设计从真实出发，而不是从想象出发。这个思路一旦建立起来，改版的效率和质量都会有明显的提升。
