瞬时设计
2024 年以来，我就再没见过一份持续更新、完整复刻产品 UI 的 Figma 文件。唯一还在被认真维护的，只有 design system。其他设计文件，大家都是需要的时候现开一个，用完就放在一边。
一开始我以为这只是团队偷懒。后来发现几乎每个团队都这样，而且这样做的团队并没有变差，很多反而走得更快。我开始觉得，设计流程是在自己找一个更合适的形态。
我把这种做法叫作瞬时设计（Ephemeral Design）：设计文件回到草稿和沟通工具的位置，design system 是唯一需要长期维护的资产，设计师和工程师围绕代码协作。
两份真相
很长一段时间里，团队把同时维护两份高保真的产品当作最佳实践：一份在 Figma，一份在代码。Figma 里的是意图，产品应该长什么样；代码里的是实现，产品实际长什么样、怎么运行。
在写代码很贵的年代，这样做是合理的。改代码又慢又贵，所以先在便宜的设计稿里把一切模拟清楚，再动手写。可模拟越做越细，设计师开始把每个状态、每种响应、每条逻辑分支都画到像素级，这就等于在代码之外又造了一个平行宇宙。
设计文件再怎么高保真，也只是一个模拟器。它没有真实的网络延迟，没有复杂的真实数据，没有浏览器的渲染，也没有读屏软件的反馈。用户真正接触的是代码，只有代码包含了系统的全部细节。
维护这个平行宇宙的代价很高。最常见的，是功能上线后设计师回头更新 Figma，让它和实现对上。这件事不产生任何用户价值，唯一的作用，是让设计文件看起来还像真相。
高保真的设计稿还会藏住实现的复杂度。一个在 Figma 里看起来很简单的输入框，在代码里可能牵扯到后端校验、错误状态和旧系统的兼容。一份完美的静态稿交出去，会给人一种决定都已经做完了的感觉，工程师早期不好意思提技术上的异议，等到中后期不得不提，流程就乱了。双方的时间耗在解释“这个阴影在 Android 上做不出来”“这个数据在列表刚加载时还拿不到”这类细节上。
漂移也躲不掉。Shopify 的 Polaris 团队花了一年，把 admin 的 design system 覆盖率推到 86.6%。后来他们做了一次全局的视觉升级，更新 Polaris 之后，大约 86% 的 admin 自动跟着变了，最费力的是剩下那 14% 已经偏离了 Polaris 的代码（原文）。同一个代码库里的 design system 都会有这样的偏离，一份独立在 Figma 里的复刻，更不可能一直跟得上。
到最后，设计和工程之间常常像在打一场冷战。设计师在 Figma 里加上 Dev Mode 标注、variables 和 tokens，想更多地控制实现；工程师赶着上线，干脆忽略这些复杂度，在代码里做一个看起来差不多的版本。出了 bug，大家先争是设计稿错了还是代码错了，用户体验坏了这件事反而排在后面。
Figma 变重了
Figma 这几年加的 variables、modes 和各种原型逻辑，初衷是缩小设计和代码之间的距离。可在很多团队里，结果是 design system 被过度工程化了。
设计师被要求像软件架构师一样思考，在脑子里维护依赖树，管理不同场景下的变量映射。注意力从用户体验转到了系统维护上，很多时间花在修断掉的变量绑定和冲突的组件属性上，活得像个 Figma 管理员。
这些逻辑还很脆弱。在代码里重构，有 IDE、lint 和测试兜底。在 Figma 里改一个底层变量的名字，可能悄悄弄坏几百个组件的连接，影响所有团队，没有任何报错，直到有人打开文件才发现，回滚也比有版本控制的代码麻烦得多。于是设计师越来越小心，有时为了不弄坏系统，连有意义的探索都不敢做。
如果这些配置能直接变成代码，或者明显提高整个团队的效率，投入也许值得。可很少有团队真正搭起了从 Figma variables 同步到代码的流水线。设计师在 Figma 里配好的交互、hover 状态、响应式断点，交接时大多被直接忽略，工程师看一眼最终视觉，再用自己的方式重写一遍。设计师花好几个小时做出来的“智能”组件，内部逻辑在交接那一刻就死了，成了僵尸逻辑：辛辛苦苦搭出来，从来没被用过。
代码变便宜了
过去的逻辑是代码贵、像素便宜，所以先用设计稿把想法验证透，再写昂贵的代码。组件化已经让代码便宜了不少，AI 又往前推了一大步：几分钟就能从一段描述或一张草图生成够用的原型代码，用现成的 design system 组件拼出常见页面，也几乎是一瞬间的事。以前要几天的原型，现在几个小时就能做出来，有时比在 Figma 里搭一个带 auto layout 和 variables 的高保真稿还快。到了这一步，在 Figma 里做高保真模拟就很难算得过账了。
设计师不用成为程序员也能用上这一点。用 Cursor 这类工具描述想要的改动，AI 写代码，设计师提一个 PR。调间距、改动画、修视觉 bug，不用再开 ticket 等排期。很多优秀团队的设计师已经在这样工作了。
交接（handoff）也在慢慢消失，尤其是在节奏快的小团队里。工程师在设计阶段就加入，用 AI 很快搭出能跑的原型；设计师也不用等开发结束才做 QA，直接在开发环境里接手很多原本属于工程师的微调。设计和开发从上下游变成了同时进行，“设计落不了地”和“开发跑在设计前面”这两种尴尬都少了很多。
瞬时设计
把这些放在一起，就是我开头看到的那种做法。设计师只维护很少的设计文件和一套精简但准确的 design system，具体的功能设计都在草稿文件里快速迭代，用完就放下。“瞬时”的意思是把设计文件当成过程工具，而不是长期资产。
它有三条原则。
第一，Figma 是白板。在 Figma 里，重点是发散和理清逻辑，用粗糙的稿子快速试多个方向。这里的粗糙指的是跳过繁琐的结构搭建和维护，视觉上它们常常依然很精致。
第二，上线后就归档。功能进入开发后，对应的设计稿就失去了维护价值，归档当作历史记录就好。以后要改这个功能，参考线上的产品，也就是代码，而不是几个月前的旧稿。
第三，轻量的 design system 是唯一需要长期维护的资产。Figma 里值得长期维护的，只有一套精简、和代码紧密对齐的组件库，让设计师能很快把想法拼出来。它真正的源头在代码里，这也是 Shopify 那 86% 能自动更新的原因。
这套做法并不适合所有团队。它目前最适合重产品逻辑、节奏快、成员水平高的团队。在视觉表现本身就是产品的地方，比如官网、营销页和品牌体验，完全放下传统设计稿还需要更多尝试。
怎么开始
转得比较顺的团队，大多做了这几件事。
先重新定义草稿。明确告诉 stakeholder，Figma 文件是草稿和概念验证，不是最终合同。每个 sprint 结束，把相关设计文件标成归档，不再维护。决策上，给有 taste、也懂技术的设计师更多话语权，让团队慢慢转向看结果。
再给 design system 瘦身。代码里没有的组件和逻辑，Figma 里也不该有；Figma 里的组件、tokens 和 variants 要和代码保持一致。
然后让设计师自在地进入代码环境。鼓励大家用 Cursor 这类 AI 编程工具，写代码既不算越界，也不成负担，只是手头多一件顺手的工具。同时改善开发者体验，让每个人都能轻松拉代码、跑 Storybook、提 PR、开 staging 环境测试。
最后，把代码预览当成新的共同语言。用真实代码的预览链接代替或配合 Figma 原型来沟通，让大家习惯基于真实的体验做判断。
设计一直是关于规划和解决问题的。维护全套高保真稿，曾经是降低工程风险的必要手段；当代码变得又快又便宜，Figma 里的复杂度又越来越高，这套流程的边际价值已经接近零，很多时候甚至是负的。放下“设计稿是真相”这个想法之后，设计师就能把时间还给真正重要的事：理解用户，决定做什么、不做什么。