一项随机对照试验显示，使用 Figma Make 可让设计工作快 20%。不过，不能把这个数字直接乘到团队排期或人力成本上。真正值得借鉴的不是 20% 这个结论，而是其测量方法：在相同任务中，只改变是否使用 AI 这一项进行比较。
“快了 20%”这句话，可以相信到什么程度？
先说结论：有相当扎实的证据表明，在实验所包含的三项任务中，Figma Make 确实缩短了时间。Figma 的数据科学团队招募了共 100 人，包括 50 名产品设计师和 50 名产品经理。参与者被随机分为使用 Make 的实验组和不使用 AI 的对照组，两组都要修改同一个社交媒体界面。
任务包括将浅色模式改为深色模式、在设置菜单中添加帮助项目，以及创建评论出现的交互。他们混合了三类难度不同的任务，从 UI 外观变更到实现新视图和交互，并经过预先试点三次修改任务。为减少不同主持人提供帮助程度的差异，他们还使用了统一的主持脚本和故障排查指南。
所有参与者的累计完成时间减少了 20%，任务易用性评价提升 16%，主观易用性提升 15%。只看 PM 时，完成时间减少 23%，任务易用性提升 37%。分析使用了假设检验和 OLS 回归；Figma 表示，未另行标注的结果具有统计显著性。
有意思的是，决定效果的与其说是谁更熟练，不如说是谁承担了什么任务。PM 在两个相对简单、较短的任务中获得了显著的时间收益，但在最难的交互任务中没有。相反，产品设计师只在困难任务中表现出显著改善。因此，“这是面向设计师的工具，所以先给设计师部署”或“工作越复杂，AI 效果越大”这类简单的引入原则，都与这些结果不符。
应当直接借鉴这项研究的部分
研究没有比较经常使用 AI 的人与不使用 AI 的人的日常工作时间。他们通过随机分配来分散岗位、熟练度等差异，给予难度相同的任务，只改变能否使用 AI。内部试点越接近这一结构，就越能减少“快的人也更常用 AI”的错觉。
任务速度不等于团队生产力
最重要的局限是，20% 指的是三项受控任务的累计完成时间，而不是整个产品团队的发布速度或成本节省率。公开博客正文没有给出各任务的原始时间和置信区间，产出质量也没有被纳入主要结果指标。Figma 也将设计质量和协作效果留作未来的研究主题。
| 研究确认的内容 | 未确认的内容 |
|---|---|
| 三项指定任务的累计完成时间 | 包含研究、会议和审批的项目交付周期 |
| 对任务难易程度的评价 | 品牌契合度、无障碍性、易用性等最终质量 |
| 产品设计师与 PM 之间的效果差异 | 因各团队熟练度、设计系统和工作构成而异的效果 |
| 受控环境中获得 Make 访问权限的因果效应 | 扣除订阅费和 AI 积分后的财务 ROI |
当工具和工作环境发生变化时，AI 生产力实验的结果甚至可能连方向都改变。Google 针对 96 名工程师的随机实验估计，AI 功能在复杂的内部任务中将工作时间减少约 21%，但置信区间很宽，研究人员也指出该结果不能直接套用到其他生态系统。 相反，METR 的研究发现，16 名在熟悉的开源代码库中工作的资深开发者，在允许使用 AI 时完成 246 项任务的平均时间反而增加了 19%。参与者自己却感觉快了 20%。
只询问主观节省时间的方法也需要单独看待。在英国政府的 AI 编程工具试验中，424 名受访者报告平均每天节省 56 分钟，但报告本身将乐观偏差和各任务节省时间可能重叠列为局限。由于无法在不同调查时间点关联受访者，追踪变化也很困难。 “你觉得自己快了多少？”是满意度信号，不是与秒表测得的时间同等的证据。
实际运营 Figma Make 时还会出现成本变量。每发送一次提示词都会消耗 AI 积分，消耗量会因模型、任务复杂度和处理的上下文量而变化。 过长的对话记录、模糊的首个提示词和超出需要的重型模型，都会增加返工和积分消耗。相反，Figma 文档也建议，将小幅颜色和间距修改通过 point-and-edit 或直接修改代码来处理，会更快、更高效。
不要用 20% × 年薪来计算节省金额
要让剩余时间真正转化为人力成本降低，节省出的时间需要被重新分配到其他有价值的工作，或减少外包费、加班和招聘需求。先比较每个通过的产出物的总时间，再把只有可回收的时间换算为成本会更稳妥。
NIST 也指出，在 AI 测量中，应将特定任务的评估结果能否推广到其他使用场景或领域作为一个独立问题来处理。 因此，Figma 的 20% 不应作为购买结论，而应被视为值得在自己团队中验证的先验假设。
如何在两周内测量团队的 Figma Make 效果
与其先制定大规模引入计划，不如挑选三个经常重复、完成标准明确的工作，做一个小型交叉实验。小规模结果不能被称为全公司的因果效应，但对于选择扩展席位和工作流而言，它已经是足够有用的证据。
选择三个有完成标准的任务
从近期工作中选择能在 20 至 90 分钟内完成的任务，例如深色模式变体、使用现有组件添加设置页面，或实现可点击的交互。针对每项任务，用检查清单固定必需状态、要使用的组件、无障碍条件和允许的错误数量。如果只有“看起来不错”这类会因评分者而变的标准，速度比较就会失效。
制作难度相近的 A/B 版本并混合顺序
同一个人两次制作完全相同的界面时，第二次会因学习效应而更快。制作功能和难度相近但内容不同的 A/B 版本，让一半参与者先用 Make 完成 A，另一半先手动完成 B。使用相同的设备、库和时间限制，并预先规定主持人介入时的用语。
同时记录时间、质量、返工和积分
在同一行中记录从开始到提交的经过时间、实际操作时间、生成等待时间、修改次数和使用的 AI 积分。由不知道工作方式的评审者用同一份检查清单对结果评分。未通过的结果即使完成得快，也不要计入节省；应累加直到通过所需的修改时间。
按岗位×任务的中位数确定部署范围
用(手动中位时间 - Make 中位时间) ÷ 手动中位时间计算节省率，但务必与质量通过率并列查看。先从效果显著的组合开始扩大，例如 PM 的简单界面修改、设计师的复杂交互。如果时间减少但通过率很低，或积分和返工大幅增加，就让该任务保留在手动工作流中。
最后，请保留实验文件和提示词记录。对于 Figma Make，清晰的首个提示词、结构化的画框、计划模式以及指定特定元素的编辑等输入方式，都会影响结果和积分消耗。 当工具版本或团队指南发生变化时，应使用相同任务重新测量，才能与先前结果比较。
如果想进一步深入了解
Measuring Time Savings From Figma Make — 介绍 100 人随机对照试验的参与者构成、三项任务和按岗位划分结果的基础资料。 figma.com
Create a Figma Make file — 可按实际菜单了解从创建文件、附加画框、计划模式、提示词构成到积分使用方式的指南。 help.figma.com
Best practices for optimizing AI credits in Figma Make — 汇总模糊的首个提示词和过长的对话记录为何会增加返工成本，以及何时应使用直接编辑的官方文档。 help.figma.com
How much does AI impact development speed? An enterprise-based randomized controlled trial — 通过随机实验估计 AI 生产力效果，同时说明宽置信区间和泛化局限的研究。 arxiv.org
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — 主观感觉变快与实际测量时间相反的案例，有助于理解自报节省时间的风险。 arxiv.org
