Figma这场分享给AI团队的当头一棒：别等设计完，工程师要最早进场

大多数人以为“设计先行、工程跟进”是效率最高的协作方式，但这场来自 Figma Config 的分享直接反着来：设计师越早把工程师拉进 Figma，方案越成熟、返工越少。更重要的是，这套方法正在悄悄影响 AI 产品的协作范式。

最反直觉的一点：越不确定，越要拉工程师一起画

分享一开始，讲者就抛出一个很多设计师“心里懂但不敢做”的观点：不要等设计成熟了再给工程师看，而是在你最不确定的时候，就让他们进场。

她坦言，自己过去也对“过早和工程师协作”有犹豫——担心限制创意、担心被技术现实泼冷水。但真实经验恰恰相反：当工程师早早参与讨论，设计反而能走向“更有思想的解决方案”。

原因很简单：工程师天然关注系统边界、复用性和极端情况，这些往往是设计阶段最容易忽略、却在后期代价最高的部分。对 AI 产品尤其如此——模型能力、延迟、成本、推理路径，本质上都是设计的一部分，而不是“交付之后再说”的实现细节。

Strawman 不是草率，而是高效协作的起点

为了让讨论真正发生，讲者提到她做的第一件事不是精修视觉，而是快速做出一批 strawman mocks（示意性方案）。

这些方案的目标只有一个：把取舍显性化。

当你需要一个方案同时跑在多个应用、多个平台、多个流程里时，抽象讨论几乎没用。只有当画面被“钉死”在 Figma 里，工程师才能指出：哪些能复用，哪些会爆炸，哪些在某些场景下根本行不通。

她说了一句很关键的话：图片的价值，不是好看，而是“让我们足够具体”。这对 AI 团队尤为重要——prompt 结构、模型切换路径、异常反馈方式，如果不具体到界面和流程，讨论永远停留在理念层。

真正拉近关系的，不是工具，而是流程设计

整场分享中，一个被反复强调但容易被忽略的点是：协作不是靠一次会议完成的，而是靠流程设计。

她给出了几个非常“落地”的做法：
- 尽可能早地 review 设计，而不是等到“差不多了”
- 把 PM 一起拉进 Figma，让决策不只存在于文档或 Slack
- 善用版本管理，尤其是在高规范、强合规的环境中
- 尝试从开发者视角使用 Figma，而不是只站在设计师立场

这些听起来不像什么宏大理论，但恰恰是多数团队做不到的地方。AI 团队常见的问题也是如此：设计在 Notion，逻辑在脑子里，工程在代码仓库，等到对齐时，成本已经不可逆。

最后一个忠告：别追求完美流程，持续迭代才是正解

在结尾，讲者并没有给出一个“标准答案”，而是用一句非常工程师思维的话收尾：iterate on your process。

也就是说，不要指望一套流程一次性解决所有协作问题。团队会变、产品会变、技术约束会变，流程本身就应该像产品一样持续迭代。

这对 AI 从业者尤其重要。今天你用的是某个模型、某种交互，半年后可能全部推翻。唯一不该变的，是设计、工程、产品之间的“低摩擦协作习惯”。

总结

这场看似在讲 Figma 的分享，本质上讲的是一件更大的事：复杂系统时代，设计不再是前置步骤，而是协作过程本身。

对 AI 从业者来说，最大的 takeaway 是三点：第一，越不确定的东西，越要早暴露给工程师；第二，用具体界面和流程承载抽象讨论；第三，把协作流程当成产品一样持续打磨。

如果你发现团队总是在“设计完成后”才发现问题，不妨反过来试一次：在方案最粗糙的时候，就把 Figma 链接丢给工程师。你可能会少走很多弯路。

关键词： Figma， 设计与工程协作， AI产品开发， 跨职能协作， 设计流程

事实核查备注： 需要核查：视频发布时间（2020-05-06）；视频所属活动是否为 Figma Config；“strawman mocks”“review early”“iterate on your process”等表述是否为原话或近似转述。