Figma 内部 AMA 曝光：高手做原型，第一步竟然先不用变量

一场看似轻松的 Office Hours，意外揭开了 Figma 团队做原型和用户测试的真实套路：在变量之前，高手已经把 80% 的问题解决了。更反直觉的是，命名、结构和“局部状态”，才是原型能不能跑起来的分水岭。

最反直觉的一点：别急着上变量

在这场 AMA 的一开始，Figma 团队就抛出了一个让很多资深设计师都会愣住的观点：原型和用户测试的前半程，完全可以不碰变量。

他们把整场分享拆成了两半——前半段专讲“没有变量你还能做什么”，后半段才进入变量。这种结构本身就很有态度：变量不是原型的起点，而是放大器。

Nico 在演示时一句话点破本质：把几个屏幕连起来，就已经“experienceable”了。能被体验，才是原型的最低门槛。很多团队一上来就纠结状态管理、条件判断，结果原型复杂到连测试对象都不知道该点哪。

对 AI 产品尤其如此：当你的核心不确定性是“用户会不会理解这个交互”，而不是“状态切换是否优雅”，变量只会拖慢你得到反馈的速度。

原型跑不跑得动，80% 输在结构和命名

在片段中，有一个看似不起眼却被反复强调的细节：命名和位置。

Garrett 点出了一个常被忽视的事实——真正让原型变得“有力量”的，不是多炫的交互，而是你如何命名对象、把它们放在哪些 frame 里。当你需要快速修改、演示、或者临时在用户测试前“救火”时，结构清晰的文件几乎是救命稻草。

这对做 AI 应用的团队尤其重要。原型往往不是你一个人用，而是产品经理、研究员、甚至工程师都会来“翻”。如果他们需要花 30 秒找一个按钮，你的原型已经在默默消耗信任。

一个隐含的行业共识在这里被说破了：原型不是一次性作品，而是一个会被反复篡改的系统。系统，就需要秩序。

他们后悔没早点学会的能力：用 Section 管理“局部状态”

Anna 在分享中有一句非常真诚的话：“这是我人生中学得太晚的一件事。”她指的是用 Sections 来做更高效的“本地状态管理”。

这里的洞察非常关键：不是所有状态都值得被抽象成变量。很多时候，你只需要在一个范围内，让几个对象一起变化。Sections 天然提供了这种边界。

这点对 AI 原型简直是刚需。比如一个 AI 助手的回复区、加载状态、推荐模块，它们的变化往往是局部的、情境化的。如果一开始就全局变量化，复杂度会指数级上升。

Figma 团队的经验很清晰：先用结构解决问题，再用变量优化体验。顺序错了，后面全是返工。

变量真正有价值的地方，不是“炫”，而是“稳”

当话题终于进入变量，语气反而变得克制了。

Anna 总结变量价值时，并没有强调高级技巧，而是强调“为什么值得”。变量让你能在一个地方修改，多处生效；让状态切换更可控；让复杂交互不至于失控。

在 AMA 中，他们提到可以用变量去显示、隐藏对象，调整高度，甚至控制一系列看似细碎的交互——这些在内部被戏称为“noodles”。这个称呼很妙：变量不是宏大的架构，而是一根根把体验串起来的细线。

对 AI 产品来说，这意味着什么？意味着当你开始验证多个假设、多个路径时，变量让你不用重做 10 个版本，而是快速切换 10 种可能。

为什么这场 AMA，特别值得 AI 从业者反复看

这不是一场教你“怎么用 Figma 新功能”的分享，而是一场关于如何思考原型和测试顺序的示范。

Figma 团队反复强调的是节奏：先让东西跑起来，再让它跑得优雅；先服务测试，再服务架构。这和很多 AI 团队当前的痛点高度重合——模型、能力、想法都很多，但验证太慢。

当你把原型当成验证认知的工具，而不是展示能力的舞台，很多设计决策都会自动变简单。

总结

这场 Office Hours 给出的最大启发，并不是某个具体技巧，而是一种取舍哲学：在不确定性最高的阶段，拒绝过度复杂。对 AI 从业者来说，你完全可以明天就行动——下一个原型，先问自己：不用变量，我能不能跑一次测试？如果答案是“能”，那你已经赢过了大多数人。真正的问题不是工具够不够强，而是你有没有足够快地学到用户的真实反馈。

关键词： Figma 原型， 用户测试， 变量设计， AI 产品设计， 交互原型

事实核查备注： 视频发布时间为 2023-11-22；视频为 Figma Config 官方 Office Hours AMA；分享者包括 Anna、Nico、Garrett；内容分为无变量原型与使用变量两部分；Sections 被用于局部状态管理的观点需保持原意不夸大。