Config官方观看源：config.figma.com/

变量

Variables rather than Design Tokens

变量支持四种类型

• 数字
• 字符串
• 颜色
• 布尔

作用范围

变量设置中可以定义变量的作用范围（针对哪些属性，比如圆角、宽高、间距、文本）

这里还有一个隐藏点：变量设置框里有一个“即将上线”的功能——代码高亮

以上提供的能力已经可被用于建立设计系统，那么接下来我们看看变量可以有哪些应用

应用场景

场景1：颜色模式

和变量同级别的设置项还有”颜色模式“，有点像颜色选集，但更像 web 应用中换肤功能所对应的底层定义，也就是每套皮肤（主题）所使用的颜色定义组合。

但这不止像演示中所呈现的亮暗色模式下的颜色定义，很明显它支持定义更多套的主题色配置，每套配置都在使用相同的颜色变量，但每个变量在每套主题下使用的颜色是不同的，这有点像 design tokens，但确实更接近于主题色的定义，因此这个配置项区别于变量，单独成为一个配置框完全合理。

一旦定义好不同颜色主题的配置，在容器级别的图层选择 Color modes，即可轻松实现快捷的”一键换肤“效果。

相比传统设计场景需要针对不同颜色主题需要提供多套设计，这一改变将使得 设计师 和 前端工程师 的使用效率都大大提高，想必当前端还原设计稿时也希望直接在同一个容器看到它在不同颜色模式下所对应的标注信息。

而这一切都是因为变量作为基础，所以产生了更简洁的呈现方式。正如编程语言中，借助变量在不同的场景下具有不同的值，从而使得程序在运行时拥有更多的变化。

场景2：布局密度

对于列表类的布局，通过对变量定义不同模式下的值，可以直接应用在图层的排布密度属性（Densities）上。当你定义了多套模式后，在设计稿中可以通过切换不同的模式查看同一个布局在不同密度下的视觉效果，这是不是解决了设计师常常反复调整元素间距以对比哪个效果更好的痛点呢

场景3：国际化（多语言）

如果你要做一款国际化的产品，需要考虑设计稿在不同语言下的视觉呈现是否一致。同样是借助变量，你可以直接定义多套语言模式，同一个词汇在不同语言模式下使用其对应语言的字符，然后同样在图层的”本地化“（Localization）属性下进行”一键切换“。

这里从开发视角补充一点，其实国际化功能在实现环节也是通过类似变量的方式定义同一个词汇在不同语言下的字符定义，类似如下方式

messages: {
  en: {
    message: {
      hello: 'hello world',
      greeting: 'good morning'
    }
  },
  ja: {
    message: {
      hello: 'こんにちは、世界',
      greeting: 'おはようございます'
    }
  }
}
messages: {
  en: {
    message: {
      hello: 'hello world',
      greeting: 'good morning'
    }
  },
  ja: {
    message: {
      hello: 'こんにちは、世界',
      greeting: 'おはようございます'
    }
  }
}
messages: {
  en: {
    message: {
      hello: 'hello world',
      greeting: 'good morning'
    }
  },
  ja: {
    message: {
      hello: 'こんにちは、世界',
      greeting: 'おはようございます'
    }
  }
}

参考：kazupon.github.io/vue-i18n/gu…

因此将变量能力带到设计环节，其实是对设计到实现的整个协作流程效率的提升，因为在设计环节的很多”动态定义“从此可以与开发人员共享了。

简单来说，就是从前对于多语种的展示，可能只有开发人员在维护，设计人员可能需要到开发的实现环节才能体验不同语种下的展示效果，或者设计师需要创建多套设计稿来展示同样内容使用不同语言的呈现效果。但因为有了变量，设计师和开发人员完全可以共享同一套”多语言配置“，这难道不是协作效率的飞跃吗

变量组合应用

如你所见，变量的魅力不止于此，一旦拥有变量，你可以更近一步，对他们进行组合使用。因为有了上面的颜色模式、密度模式和语言模式，从此你可以看到的不止是各个属性下不同模式的效果，而是各个模式的随意组合

样式能力增强

最大/最小宽度、最大/最小高度

这是前端 CSS 中一个很基本的属性，但到今天才被添加到设计工具内，算是补充了设计到开发环节的一个鸿沟。

因为这里原本的痛点在于设计稿往往对响应式设计依赖于做多套设计，而前端对于响应式的实现往往是通过最大/最小宽度和最大/小高度属性在不同宽度/高度范围内定义不同的布局属性和元素宽高值，可见这个环节从前在设计环节和开发环节的实现方式是不一致的。

自动布局 功能对于设计与实现环节的一致性曾迈出了重要的一步，而最大/最小宽度和最大/最小高度功能则是补齐了响应式实现在设计到前端的另一块拼图

换行属性

这是网页技术中实现多列布局响应式的关键属性，因为它决定了元素在限定的布局内超出一行后应如何显示，也许你说使用 网格布局 可以做到同样的事情，但如果你想使用 自动布局（对应前端的弹性布局），那换行属性必不可少

原型

使用原型作为产品初始功能演示是很重要的，因为在它还没有被完整实现以前，可以快速地进行意见收集和改进。但对于一个功能复杂的应用，使用原型模拟出所有操作路径会很复杂。

会有多复杂呢，看看 Figma 内部的使用情况

使用设计工具以往所提供的能力，原型中的步骤线可能会非常多，因为你需要创建同一个页面在不同操作后的不同结果，因此最终原型内的关系会变得非常难以维护。

原型+变量

如果依托变量能力，原型可以变得怎样呢？

你可以为原型中使用到的 状态 定义变量，比如对于电商应用，你可以定义不同商品的名称、数量、价格等等。当定义完这些以后，你就像拥有了一个小型的数据库（数据库这个概念熟悉吗？Notion 的 表格 正是利用数据库方式存储表格数据，从而做到将同一份数据源以不同视图模式进行展示的效果）

动作使用变量

交互属性内的动作使用变量

比如当你点击某个元素时，你可以对变量的值进行更新，更新的值可以是在变量当前值的基础上增加计算逻辑，从而得到新的状态值。

这样的计算逻辑称为“表达式（expression）”

比如当你在购物车对某个商品点击加号时，理想的变化应该仅仅是商品展示的数量从 1 变成 2 即可，而使用以往的原型演示，这一效果可能需要拷贝一份容器，然后在新的版本内将数量改为 2。

怎么样？感受到变量的力量了吗，因为有了变量，这个场景下的原型交互可以直接省去一个重复的容器去展示不同的状态，而仅仅是通过变量的变化来表达状态的变化。

原型预览

这是另一个工作流上的效率提升点，以往的原型预览是在一个新的标签页内展示的，如今你可以直接在原型设计页面弹出一个和容器一样大的弹窗，直接看到一个像样机一样的页面呈现在你眼前，然后在此基础上进行调整。

这一交互其实源自苹果应用的开发，熟悉苹果 App 开发的人应该知道，苹果官方提供了专用的工具用于开发苹果系列的产品，叫做 Xcode。当你在 Xcode 内运行代码后，就会在弹出一个独立窗体用于展示你的 App，然后你可以在不需要切换标签页的情况下直接预览你的 App 在这一刻的效果，从而在此基础上进行调整。

将这种交互应用在原型功能上，可以说是将原型使用者的体验提升到与开发者类似了。

条件语句

这也是源自编程语言的理念，因为有了条件语句，你可以对逻辑增加条件判断，从而使逻辑走向不同条件下的分支。但看似简单的能力，却可以产生丰富的结果。

用在原型场景，原本对于不同元素的点击，下一步要展示的页面可能需要拷贝多份并做出对应的修改才能达成，而这就是原型趋向复杂的关键。

使用条件语句，你可以对交互增加条件逻辑声明，当你点击商品列表中的苹果时，在跳转商品详情页时应该展示的是苹果对应的详情，包括苹果的价格和数量。当点击香蕉时，详情页应该展示香蕉的商品详情。当你在购物车将所有商品的数量减少为0时，页面应该展示空态，而这些判断都是通过条件判断实现的。

开发模式

Ready for dev

解决痛点：开发找错设计稿

以往是如何解决的？在页面名称上标清哪些是草稿，哪些是定稿的，这里的”定稿“也就是所谓的”ready for dev，准备好用于开发“。

在开发模式下，页面仅展示准备就绪的设计稿，其他未就绪的页面将默认收起，这里突现了”保持简洁，仅展示必要信息“的原则，这也是一个优秀的软件应该遵守的设计原则。

变更对比

功能价值

作为开发，最先想到的就是 code diff。因为在实际生产中，每个变更都应该是小心翼翼的，因此当你变更一段代码时，理应通过 diff 工具对改动前后的代码进行逐行确认，确保你的这次变更足够合理。

相似功能

其实 变更对比 这件事如今已经被应用到很多场景了，比如 jira 文档的版本对比、云文档的变更记录等，使用对比工具可以直观看出一次改动所带来的 具体差异。对于 操作者 来说，这是能够使其更加坚定进行保存的信心来源。

功能分析

figma 这次做的是对一个文件进行两个版本的左右对比，形式有点像”找不同“游戏。但对于图片的差异比较，基本也只能做到这个程度。

然而真的仅此而已吗？当然不，figma 总能给人惊喜。它还提供将两个版本进行重叠的方式进行差异对比，因为图片是二维内容，左右对比对于一维的文本内容来说可能足够了，但对于图片的差异对比如果要依赖人的肉眼去”找不同“，还是有点费力的。

此次对于版本对比体验的提升，像极了上面提到的 原型同屏预览，同样是对既有功能的体验提升。

就版本对比来说，相比原本的历史版本切换，实在进步了不少，因为比起完整查看新的版本和历史版本，人眼对于细微差异往往是难以察觉的，因此原本的历史版本功能显得并不实用。

此外，figma 更进一步，既然两个版本的差异已经能够呈现在页面上，那么应用本身一定是具有两个版本之间差异的完整信息，那么何不直接把这些信息暴露给用户呢，这个场景的用户就是开发者，开发者希望看到更多的细节。

差异信息体现在图层属性的新增、修改和删除，这些变化仿佛就在扮演着以往协作场景中的设计师角色，以往设计师可能需要通过口头告知或额外维护一个文档来传达最新发生的修改具体是什么。

功能延伸

“寻找差异”这种方式无论放在哪个领域，往往都是更高效的对比方式。

这里举一些运用”差异“思维的应用实例，比如云计算的基础是在云端存储大量数据，而对于同一份数据，可能每时每刻都在发生变化，如果想全量存储这些数据在不同时间的状态几乎是不可想象的成本。因此早在云计算诞生之初，人们就想出”差量“备份的思路，对于数据不同时间的存储，仅存储其和前一个版本之间的差异。在调取历史版本时，通过当前版本以及此前发生过的所有变更来计算出原始状态。这样虽然牺牲了一点历史版本查看的性能，但却节省了大量的存储空间去存放那些完全相同的数据。

那么既然谈到云存储，自然可以联想到 MacOS 的 时间机器 功能，它可以为你保存电脑数据在某一时刻的”快照“，当你想让电脑恢复至某一个历史时刻，你就可以像搭乘”时间机器“一样回到过去的某个时刻。这个功能显然也会利用”差量备份“的方式进行历史版本存储，否则你的时间机器对于电脑的磁盘占用将会是 版本数 乘以 某一个时刻的存储占用 那么多。

还有最经典的 Git，它是用于管理代码历史版本的工具，记录着开发者每一次提交记录的差异，从而可以回看所有的历史提交。这样仅仅通过记录每次的改动差异就能形成一个代码仓库的完整历史，不得不说”差异对比“思想绝对算得上是存储算法中的核心基石。

那么回到 figma 这个应用，从这次上线的版本对比功能来看，figma 大概率之前也是对文件历史版本进行”差异“保存的，只是直到现在才把这个原本用于开发实践的思想搬到用户眼前。

图层检查增强

这个改动对于开发者来说确实更加深入人心，因为前端工程师往往对于一个在浏览器中访问的 web 应用进行调试时，通过工具看到的也会是所有图层在同一层（当然也有例外，比如绝对布局会在垂直轴上产生新的的”层“）。但大多时候，我们调试网页时看到的是如下的效果

虽然在实际的 HTML 中，元素是“一层一层”的，但当元素被渲染成页面时，内容仍然是“一块一块”的。因此当我们调试每块内容的 样式属性 时，我们并不希望发现它们竟然有 层 的关系，甚至我们还需要通过 双击 某一层才能选中”下一层“，因为单击某个图层在设计模式下将会是”选中图层“的效果。

图标导出

这也是之前设计模式下”反效率“的一个点，在线设计工具原始图稿信息丰富虽好，但对于图标导出可能并不友好。如果开发者选中了错误的图标容器，导出的可能会是缺失图层的图标或是包含多余边距的图层。

这些以往对于开发人员造成困扰的多余信息将在开发模式下消失，从此对于图标图层，在开发模式下仅会有一个可选中对象，那就是图标本身。这样的一个细小变化，对于图标、切图这类标准化的交付场景将会是一个 SOP 级别的提升。

元素单位选择

这让我想起了微信小程序开发工具，因为小程序应用不同于 web 应用，web 的运行环境是浏览器，而小程序应用的运行环境是 APP。因此 web 应用内使用的单位是交给浏览器理解的，因此常见的单位是 px、百分比、rem/em 和 vw/vh。但小程序运行时实际在使用手机操作系统的渲染器进行元素绘制，但移动端设备的种类太多，因此小程序需要自定义一套元素单位来降低开发者的心智负担。

这里 figma 支持了元素大小单位的选择，是拓展了其设计支持能力的边界，因为设计交付的场景既可能是网页，也可能是手机 APP 甚至小程序，这一能力从此能够适应不同应用类别下的单位选择。

组件 playground

这像是把 storybook 的一部分功能搬进了 figma 的弹窗，从此团队对于组件库的维护不再限于设计师单方面的创造和维护。开发人员在开始模式下可以共享设计师对于组件信息的管理，这一能力有望打破原本对于组件库这一资产在设计师和前端开发之间的重复劳动。

因为 playground 对于组件实现了不同 token 下的视觉预览，而不再是枯燥无味的组件名。这种对于组件的维护方式可以直接提高前端开发人员在 figma 页面的停留时长，因为从此对于团队资产不再需要另外打开一个网站或者文档去查看它的具体参数和信息了。

开发资源

这是一个小功能，但也让团队资产管理更加完整。因为在今天，互联网团队对于资产的管理本就是一半在本地一半在“云”上，在云上的部分可能是各个 web 服务下的组合，比如设计稿存储在 figma 账号中，而组件库代码则是维护在 gitlab 或 github 上。

代码片段增强

从前的代码是展示在 标注模式 下的，而如今因为有了 开发模式，因此代码标注信息将以更加接近开发者的使用方式呈现。比如按照前端开发中的 BEM 原则，布局、样式和修饰符在 CSS 中应该进行清晰的区分，这样才更有利于构建复杂的UI，而 figma 显然是懂这一点的。

对于这些细节的改动，每一个单点看起来可能都不起眼，但汇聚在一起，就是对于使用体验的整体升级，让使用者真正感受到工具的“趁手”。

开发模式插件

D2C 是 web 应用发展衍生出的交付形态——design to code，设计图转代码。这在此前被认为是一种理想的交付形态，因为这节省了开发人员还原设计稿的时间，从而可以快速将设计稿直接转换为可部署的网页形态。但随着近几年 web 技术发展的成熟，一些实践使得这项技术成为可能（比如微软之前提出的 sketch2code，草图生成代码）。

而 figma 将插件功能集成到开发模式下的代码标注区域，是一次 设计稿转代码片段 的尝试。因为代码不同于样式信息，使用代码描述组件，可以使其具有更好的拓展性和可复用性。因此如果能够根据设计稿信息给出组件的代码片段，那么后续开发模式就可能发展成便利的 Low Code 工具。

看似又一个平淡无奇的尝试，实则孕育着更多的可能性和产品形态延展。

补充阅读：Anima是什么？www.animaapp.com/

VS Code 插件

如果你是一名开发者你才会明白，开发者在工作时并不想离开 IDE 环境。一切能在 IDE 完成的事情，不应切换窗口去到其他地方。因为在开发环节，程序员需要保持聚焦，否则思路可能会被打断。因此，IDE 市场才会有众多插件满足开发者在 IDE 内实现大多事情。

详见 VS Code 插件市场：marketplace.visualstudio.com/vscode

Figma 做了其配套的 VS Code 插件，可见它是尊重开发者使用习惯的，如果能在 IDE 内访问 Figma 文件，何乐而不为呢？更何况 IDE 不仅是开发工具，也可以是基本的文件编辑器，当使用 VS Code 管理自己的 Figma 文件时，仿佛就像是在本地文件夹管理你的设计文件，并且它还支持查看设计文件中的标注信息，这是因为 VS Code 支持直接在其内部打开 web 应用的能力，就像使用浏览器一样。

另外，Figma for VS Code 还支持在代码编辑时提示当前文件页内选中的图层样式，从而实现“一键代码填充”。这样的开发体验非常接近现有的编程辅助工具，比如 tabnine 和 copilot，但这类工具大多依赖 AI 进行代码提示，也就是它们提供的虽然是可用代码，但并不是符合团队共用的“标准代码”。而 Figma 的样式提示能力则大概率是通过 Typescript 的类型推导能力实现的组件样式映射，也就是对于同样的样式属性，所有人提示的代码均会是与设计稿严格保持一致的标准代码。

写在最后

开发模式的诞生，意味着 figma 将“一人分饰两角”，在同一款软件内实现两种生产角色的同等使用体验。而做到这一点的推动力是因为 figma 的用户画像——设计师与开发者用户量1:1，这样来看，figma 推出开发模式既艰难又合理，但对于同类软件却是一个值得慎重考虑的事情，因为并不是所有软件都具备同样的痛点。

未来需要更多的思考者和实践者让协作变得更好。