Figma给设计×工程协作的答案：别交接，直接一起跑

在这场 Config APAC 2024 演讲里，Figma 工程经理 Noga Mann 抛出一个反直觉观点：设计和工程最大的效率杀手不是工具不够强，而是“交接”本身。她展示了 Figma 团队如何用原型、Dev Mode 和持续反馈，把协作从接力赛变成一场长期并跑。这套方法，对今天的 AI 产品团队尤其致命地有效。

最反直觉的一点：问题不在设计稿，而在“交接”这个动作

很多团队默认一种节奏：设计做完 → 交给工程 → 工程实现 → QA 兜底。Noga 一上来就否定了这套模式。在 Figma 内部，他们不把设计到开发看成接力赛，而是“跑步俱乐部”——设计和工程从一开始就并排跑。

这里的反直觉点在于：他们并不追求一开始就高保真的设计或优雅的代码。相反，设计从低保真开始，工程也允许“hacky code”存在。关键不是早期质量，而是节奏一致。如果工程跑太快，设计没跟上，会返工；如果设计跑太快，工程被拖死，同样浪费。

这对 AI 产品尤其重要。模型能力、交互方式、推理延迟，很多关键决策在早期根本无法一次性想清楚。把“交接”推迟，换成持续并行，是减少 AI 项目返工成本的真正秘诀。

为什么 Figma 把赌注压在原型，而不是“直接上生产”

Noga 反复强调一个原则：大想法一旦进生产，几乎不可逆；但原型可以随时推翻。Figma 团队大量使用无代码交互原型，用来快速对齐内部共识、验证交互是否成立。

更有意思的是，他们并不执着于“原型一定是设计师做的”。在 Dev Mode 的注释功能开发中，工程师 Roshan 直接用代码做了一个端到端原型，提前跑通了缩放、悬停、最小化等复杂交互。这个原型并不是最终 UI，但它让整个团队在设计规格定稿前，就看到了“东西真的跑起来是什么感觉”。

Noga 给了三个极实用的原型共识问题：我们想学什么？这个原型被扔掉的概率有多高？反馈来自谁？这套方法对 AI 团队尤其致命有效——在模型、交互、性能三者强耦合的情况下，用原型逼迫团队尽早面对真实约束。

Dev Mode 的真正价值：不是更强的标注，而是减少无意义返工

任何做过前端或 AI 应用的人，都经历过这种崩溃时刻：花半天实现一个复杂组件，结果设计改了。Noga 直说，这正是 Figma 新 Dev Mode 功能要解决的问题。

“Ready for Dev” 不只是一个标签，而是一个协作协议。设计一旦变更，状态变黄，Slack 自动通知，工程可以直接对比差异，决定是否继续或暂停实现。新引入的 completed 状态，甚至把‘这件事真的做完了吗’这件模糊的事变成了可追踪的事实。

对 AI 产品来说，这种机制尤为关键。Prompt、参数、UI 文案、推理结果展示，经常在最后一刻才调整。让变化显性化、可对比，远比要求‘一次设计定终局’更现实。

高质量不是靠 QA，而是靠设计和工程一起“挑刺”

Figma 没有在每个团队配专职 QA。取而代之的是 bug bash、设计×工程 pairing、以及大量对细节的偏执。

Noga 提到一个细节：一个打开慢一点的菜单、一个模糊的提示文案，单看都不致命，但每天被用上百次，就会变成真实的痛点。这也是为什么他们强调 annotations、compare changes、Code Connect 这些看似“细枝末节”的功能。

尤其值得 AI 团队警惕的是：当你把注意力全放在模型指标上时，用户真正感知到的，往往是延迟、反馈是否清晰、失败时有没有兜底解释。这些问题，只有设计和工程并肩坐在一起，才能快速被消灭。

总结

Figma 这场分享真正想说的，并不是“我们 Dev Mode 很强”，而是一个更底层的判断：复杂产品的确定性，是在并行中一点点长出来的，而不是在交接中被保证的。对 AI 从业者来说，这意味着三件事：第一，用原型而不是文档推动决策；第二，把变化设计成系统的一部分，而不是意外；第三，尽量减少“等别人定完我再动手”的时刻。下一个问题值得你带回团队讨论：在你的项目里，有哪些返工，其实只是因为跑步节奏没对齐？

关键词： Figma， 设计与工程协作， Dev Mode， 原型驱动， AI产品开发

事实核查备注： 需要核查的关键事实：1）演讲者身份：Noga Mann 为 Figma 工程经理，负责 Dev Mode；2）视频发布时间：2024-07-30；3）提到的功能发布时间：Ready for Dev 新视图与 Dev Mode 功能在演讲前一周上线；4）Maker Week 自 2018 年起已举办 10 次；5）案例人物姓名拼写：Roshan Bala、Oscar Nelson、Mika、Martin。