瞬时设计
在过去的一个长周期内，数字产品开发领域普遍奉行一种被视为“最佳实践”的工作流：即在 Figma 与代码中同时维护两套高度保真、互为镜像的单一事实来源（source of truth）。然而，随着设计的过度工程化导致维护成本激增，以及 AI 对软件开发产能的革命性释放，这一双重真理模型正在让所有设计师变得烦闷和低效。
瞬时设计（Ephemeral Design）的出现将设计师从双重真理中解放出来。设计文件回归其作为草稿与沟通介质的本质，仅保留设计系统作为持久资产，设计师和工程师以代码环境为中心展开协作。
第一章：双重真理
1.1 Design 本不应该是真理
单一事实来源原则规定任何数据元素只能在一个地方被掌握或编辑，以确保系统的一致性。然而，数字产品开发近几年一直在违背这一原则，建立了一种事实上的双重真理架构：
- 意图的真理 (Truth of Intent)： 存在于 Figma 等设计工具中，代表了产品“应该长什么样”的理想状态。
- 实现的真理 (Truth of Implementation)： 存在于 GitHub 等代码仓库中，代表了产品“实际长什么样”及“如何运行”的物理状态。
这种二元对立在工程成本高昂的时代具有其合理性：修改代码极其昂贵，因此需要在廉价的设计环境中进行详尽的模拟和验证。然而，随着行业的发展，这种架构逐渐演变成一种沉重的负担。当设计师们以像素级的精度模拟最终产品的所有状态、所有响应和所有逻辑分支时，实际上是在创建一个平行宇宙。
设计文件本就是个相对虚假的事实来源。无论多么高保真，它本质上仍是一个模拟器。它缺乏真实的网络延迟、缺乏真实的复杂数据状态、缺乏浏览器的渲染机制、缺乏无障碍功能的真实反馈。相比之下，代码是用户最终交互的实体，是唯一包含所有系统细节的产物。
1.2 对齐与沟通成本
顶着高昂的沟通成本与对齐成本强行维护复制真实产品的设计文件，是当前许多团队的痛点。这种维护成本并非线性的，而是随着产品复杂度的提升呈指数级增长。
在传统的产品开发中，设计师经常在临时或开发结束后，回过头来更新 Figma 文件以匹配最终实现的代码——这是一种为了文档的一致性而进行的表演性劳动。这种劳动不产生任何用户价值，其唯一目的是为了让设计文件看起来像是一个真理。
翻译损耗
高保真模型往往掩盖了技术实现的复杂性。一个在 Figma 中看似简单的输入框，在代码中可能涉及到复杂的后端验证、错误状态处理和旧系统的兼容性问题。当设计师交付一个完美的静态模型时，往往会给工程师造成一种决策已定的心理暗示，导致工程师在早期不愿提出技术异议，而在中后期不得不提出，导致产品开发流程的混乱。
设计师在真空中构建了完美的乌托邦，工程师在现实的泥潭中挣扎还原。双方的沟通成本大量消耗在解释“为什么这个阴影在 Android 上实现不了”或者“为什么这个数据在列表加载时无法获取”等细节上。
漂移的必然性
在拥有成熟设计系统的顶尖团队中，设计与代码的漂移也难以避免。Shopify 的一项内部审计显示，即便它们拥有成熟的设计系统，在其高度标准化的管理界面项目中，在一年后也有 14% 的实现与设计系统产生了偏差。这种漂移并不是因为工程师懒惰，而是因为代码环境是动态的、受环境影响的，而设计环境是静态的、受控的。只要设计文件和代码是分离的，它们之间的漂移是绝对的，而同步则是相对的和暂时的。
1.3 行业现状
当前的协作模式在某种程度上甚至演变成了设计与工程之间的“冷战”。设计师通过引入更复杂的工具（如 Figma 的 Dev Mode 标注、Variables、Tokens 等复杂的变量逻辑）试图左右代码的实现；而工程师则通过忽略这些复杂性，直接在代码中构建仅仅是视觉上相似 UI，来应对快速迭代的压力。
这种对抗不仅增加了内耗，更重要的是，它模糊了产品的真实定义。当出现 Bug 时，团队往往需要辨别是“设计文件错了”还是“代码实现错了”，而不是简单地关注“用户体验受损”。
第二章：Figma 成为了陷阱
2.1 设计系统的过度工程化
Figma 通过 Token 等新功能让组件系统过于复杂，增加了设计行业的内耗。这一现象在 2024 年至今的讨论中得到了广泛的共鸣。
Figma 引入 Variables、Modes 和其它高级原型逻辑，初衷是为了弥合设计与代码的代沟，让设计文件更接近代码的逻辑结构。然而，在实际应用中，这导致了设计系统的过度工程化 (Over-engineering)。
认知负荷的转移
设计师现在被要求掌握类似软件架构师的技能。建立和维护一个多层结构的系统，需要极强的逻辑抽象能力。设计师必须在脑海中构建复杂的依赖树，管理不同情景下的变量映射。
这种工作方式将设计师的注意力从“用户体验创新”转移到了“系统架构维护”上。设计师不仅要做创意工作，还变成了管理 Figma 的数据库管理员，花费大量时间调试变量连接断裂、组件属性冲突等技术问题，而非思考交互流程和落地产品愿景。
脆弱的逻辑模拟
更糟糕的是，Figma 中的这些逻辑结构是脆弱的。在代码环境中，各种修改和重构都有 IDE 的强力支持，有 Lint 工具的检查，有测试覆盖的保障。而在 Figma 中，修改一个底层变量的名称可能会在不经意间破坏数百个组件的连接，影响范围遍布所有团队，且没有有效的自动化和报错提示，直到大家打开文件时才发现系统乱套了，而修复和回滚也远比有版本控制的代码环境更复杂。
这种脆弱性导致设计师必须小心翼翼地维护文件结构，甚至为了避免出错而不敢进行有意义的设计探索。工具本应是延伸设计师能力的杠杆，现在却变成了束缚手脚的镣铐。
2.2 投资回报率的断裂
如果这种复杂的配置能直接转化为代码或大幅提高全局的工作效率，那么这种投入或许是值得的。但现实往往并非如此。绝大多数团队并没有建立起从 Figma 变量直接同步到代码库的自动化流水线，更不用说更复杂的自动化了。
这意味着，设计师在 Figma 中精心配置的点击跳转逻辑、悬停状态、响应式断点等数值，在交付给开发时，往往被直接忽略。开发人员通常只看最终的视觉效果，然后用自己的代码逻辑重新实现一遍，达成他们觉得“差不多了”的效果。
这种双方单向的努力构成了巨大的资源浪费。设计师花费 10 小时构建的智能组件，其内部逻辑在交接的那一刻就死了，变成了没有任何复用价值的僵尸逻辑。为了维持工具内的完美逻辑而付出的劳动，不仅没有转化为最终产品的代码资产，还每天都在产生挫败感和工作动力的流失。这也是设计行业的竞争力和薪酬长期承压和下滑的原因之一。
2.3 经济与心理的双重挤压
除了工作流的摩擦，经济因素也在推动这一变革。Figma 等工具的定价策略调整引起了社区的广泛不满。
对于许多团队来说，全功能席位费用在 ROI 上越来越难以通过。这种经济压力迫使团队重新思考：我们真的需要在只有设计师在真正使用的工具中维护一个庞大复杂的真理吗？如果代码仓库（既有成本）才是最终的真理，为什么还要在设计工具上投入如此多的预算？
心理层面上，设计师也开始出现工具疲劳。不断的版本更新、不仅要学设计还要学类似编程的逻辑配置，使得许多设计师感到职业倦怠。很多设计师对改善产品的真实体验感到无能为力，逐渐麻木。回归设计的本源：解决问题、创造美感，才能让行业重新焕发活力。
第三章：AI 时代的协作重构
3.1 代码成本的加速下降
AI 正在大幅增加工程的产能，逐渐改变了产品开发流程中的成本结构。
在传统的软件经济学中，代码是昂贵的，像素是廉价的。因此，在写代码之前，最好通过廉价的像素（设计稿）反复验证，以降低试错成本。但传统的软件工程通过组件化降低代码成本后，叠加在上面的 AI 正在将代码变得更加廉价和快速：
- 通过自然语言描述或简单的手绘草图，在几分钟内生成足够用来做早期验证的代码。
- 利用构建好的设计系统组件，AI 可以瞬间完成常见页面的构建工作。
当构建一个原型的时间成本从 3 天缩短到 3 小时，甚至低于画一个高保真原型的时间（需要处理图层、自动布局、变量）时，继续在 Figma 中进行高保真模拟的经济基础就不复存在了。
3.2 Vibe Coding
在这种模式下，创造者不需要逐行编写代码，而是通过自然语言向 AI 描述产品的功能需求和交互逻辑，由 AI 完成具体的实现。
尽管这种方式还不能开发完整功能或解决复杂问题，但这对于设计师意味着它们可以直接通过 AI 实现简单的改动，并直接了解产品的真实状态，而无需成为程序员或耗费时间精力去对接、理解、学习。事实上，很多顶尖团队的优秀设计师已经在这样工作了。
3.3 No Handoff
在 AI 加速软件开发流程和改变软件开发周期的背景下，传统设计流程中的交付流程正在消亡。取而代之的是工程师和设计师高度合作的工作流。这种趋势在追求敏捷的小型公司和初创团队中尤为明显。
在这种工作流中，设计和开发不再是串行的上下游关系，而是并行的共创关系：
- 早期介入： 工程师在设计阶段就介入，利用 AI 快速搭建功能原型。
- 持续迭代： 设计师不再等待开发完成后进行 QA，而是直接在开发环境中取代工程师进行微调。
这种模式不仅消除了对齐成本，还让产品在早期就经过了真实代码环境的检验，避免了“设计无法落地”或“开发脱离设计先行”的尴尬。
第四章：新范式，瞬时设计
基于上述分析，我们正在见证一种新的设计工程范式的诞生。设计师只维护很简单的设计文件和精简但准确的设计系统，具体设计通过用完即弃的草稿设计文件快速迭代。这一范式可以总结为瞬时设计 (Ephemeral Design)。
“瞬时”意味着设计文件不再是永久的资产，而是过程性的工具。瞬时设计的核心原则如下：
- Figma 作为白板 (Figma as whiteboard)： 在 Figma 中，重点是思维的发散和逻辑的梳理，通过粗糙的设计快速探索多种可能性。（“粗糙”指的并非一定是低保真的线框图，而是绕过了严谨的结构和繁琐维护的设计文件，它们在视觉上通常依然是高保真的）。
- 用完即弃 (Dispose after ship)： 一旦功能进入开发阶段甚至大致成型，对应的设计稿就失去了维护价值。它应被归档作为历史记录，而不是作为未来的修改基准。如果未来需要修改该功能，应该直接参考线上产品（也就是代码），而不是回到几个月前的设计稿上做无用功。
- 轻量 Design System 是唯一的持久性资产： Figma 中唯一或极少数值得长期维护的资产，是轻量化且与代码高度对齐的，以供设计师快速取用组件。
第五章：实施建议
5.1 明确适用边界
在推广 No Handoff 的工作流之前，需要客观承认瞬时设计的适用场景。它目前更适合重逻辑、水平优秀、快速迭代的团队。对于极度追求视觉表现力（如产品官网、营销活动），放弃设计稿仍需要更多的探索。
5.2 团队落地的具体行动
为了实现这一转型，很多前沿团队采取了以下变化：
1. 文化重塑：重新定义“草稿”
- 明确告知利益相关者：Figma 文件是草稿和概念验证，不是最终合同
- 建立文件归档机制，每个 Sprint 结束后，将相关设计文件标记为归档，不再维护
- 给予懂工程的设计师和优秀设计师更多的话语权，团队逐步转向结果驱动
2. 瘦身设计系统
- 代码里没有的逻辑和组件，Figma 里就不该有
- Figma 中的组件、tokens、variants 等必须与代码完全一致
3. 鼓励设计师拥抱 AI 与代码环境
- 请设计师使用 Cursor 或其它 AI 辅助编程工具。不要让设计师觉得触碰代码是越界或增加压力，而应将其视为工具箱中的常规工具之一，趁手时随时使用
- 优化开发者体验，使所有相关人员都能够轻松拉取代码、运行 Storybook、提交简单的 PR、创建 Staging 环境进行测试
4. 建立“代码预览”作为新的沟通语言
- 鼓励使用代码的预览链接，代替或配合 Figma 原型链接进行沟通。让所有人都习惯于基于真实的体验进行点评和决策
回归本质的必然
设计师们向瞬时设计范式的转变，是对当前生产关系的一次深刻洞察，也是符合“形式服从内容”原则的健康自救。
设计的本质是规划与解决问题，而不是制作精美的说明书。曾经，维护全套高保真设计稿是降低工程风险的必要手段；但随着软件工程自身效率的提升，代码的生产成本大幅降低，叠加在 Figma 内进行设计的成本逐渐升高，原有设计流程的边际效益已接近于零，甚至为负。
放弃 design source of truth，是设计师的一次解放。它将设计师从繁琐的伪设计工作中释放出来，去关注更高维度的系统设计、用户洞察和产品创新，重新激发整个设计行业的活性与效率。