Figma Make：先把真实约束喂给 AI，再让它生成原型
Figma Make 把生产组件、使用规则和真实项目资料提前放进生成过程，让 AI 原型更早暴露真实产品的约束与边界。
Figma Make 是 Figma 的 AI prompt-to-app 工具：用户可以从一句描述或现有 Figma 设计出发，生成可运行的原型、网页应用和交互界面，再通过对话继续修改。Figma 把它放在设计探索和产品讨论之间，适合产品经理、设计师和工程师一起验证一个方案到底怎么用。1
AI 生成界面最容易卡在第二步：第一版看起来完成，里面的组件、文案、数据和异常状态却与真实产品脱节。团队接下来要花时间把占位内容换掉，把通用组件换回自己的组件，再重新讨论那些原型从未呈现的边界条件。
Figma Make 的设计选择很具体：先把生产组件和项目资料放进生成过程，再让 AI 组装原型。Make kits 负责设计系统层面的组件、样式、变量和使用规则；Make attachments 负责项目层面的 PDF、Markdown、CSV、JSON、截图、品牌规范、法务文案和真实媒体。2
亮点一：先教 AI 使用生产组件，再让它开始生成
Make kits 把设计系统从“生成以后再套上去的检查项”，提前变成“生成时就能使用的材料”。Figma 对 Make kit 的定义包含代码组件、样式、设计变量和使用指南；团队可以把公共 npm 包或私有包接入，也可以同步 Figma 组件库里的样式和 token。使用指南还要告诉 Make 某个组件应该怎样组合，而不只是告诉 Make 组件存在。2
这项设计解决的是“第一版原型和真实产品说着两种语言”的问题。假设团队要验证一个设置流程，普通生成器可能先画出一套看起来合理的表单；Make kit 则让原型从团队已有的表单组件、校验方式和样式变量开始。模型仍然决定页面如何组合，组件的结构和使用边界已经由团队写进了生成材料里。
Figma 把这种变化说得很直白：使用 Make kits 后，原型从生产环境里的组件开始，组件结构也能与代码库保持一致。工程师看到原型时，可以先讨论流程和取舍，再处理“这个控件到底是不是我们自己的”这类翻译问题。2
设计含量就在这个顺序里。传统做法把设计系统放在生成之后：先让 AI 追求一个看起来完整的结果，再由设计师替换组件、整理间距、补齐规则。Make kits 把一部分判断前移，模型生成的对象从“任意界面”变成“在既有产品语言里组合页面”。自由度缩小了，评审对象却更接近真正要交付的东西。
代价也随之落到组件库维护上。组件名称、字段和使用指南写得越含糊，模型越容易生成需要返工的组合；组件库没有覆盖的能力，单靠补一条提示也无法凭空出现。Make kit 解决的是生成起点与产品系统之间的距离，解决不了系统本身缺少组件和规则的问题。
亮点二：把真实资料当作原型的一部分
组件库只说明“页面应该长什么样”，项目资料才说明“页面必须面对什么内容”。Make attachments 允许用户把 PDF、Markdown、CSV、JSON、截图、品牌指南、法务文案、图片、视频和 SVG 直接附到提示中。Figma 给出的理由是，附件能让 Make 参考真实资料，减少把全部背景压缩进一段长提示的需要。2
真实资料会改变原型需要回答的问题。法务文案可能比占位句长很多，CSV 里的字段可能会出现空值，截图里的旧页面可能暴露一个新流程必须兼容的入口。Figma 的产品说明把结果概括为：真实数据会更早暴露布局约束，边界状态也会更早出现在界面里。2
这里的巧思不是“让模型读更多资料”。关键动作是把原型的输入从抽象描述换成项目正在使用的材料。产品团队评审的对象因此从“理想情况下的页面”变成“带真实长度、真实字段和真实限制的页面”。原型仍然是探索工具，却开始承担一次小型的可行性检查。
一条可复用的操作顺序
Make kits 和 Make attachments 解决的是两层不同的问题。前者规定生成器可以使用哪些产品部件，以及这些部件怎样使用；后者提供当前项目需要面对的内容和限制。使用时，把两层资料分开准备，再让它们在同一个原型里相遇。
- 先准备生产组件。 把实际会进入产品的组件、样式、变量和使用指南整理成 Make kit。先检查组件是否覆盖当前流程，以及指南是否写清了组合方式；只登记组件名称，模型仍然要猜规则。
- 再附真实项目资料。 把当前流程需要的样例数据、法务文案、品牌规范、旧页面截图或接口说明附到提示中。附件的作用是让原型面对真实输入，资料类型按项目需要选择，不必把所有文件一次性塞进去。
- 把验证目标写成用户动作。 与其只说“做一个设置页”，不如写清“用户填写一条较长的公司名称、跳过可选项、提交失败后重新修改”。这一步把组件和资料转成可观察的交互结果。
- 在运行中的原型里检查边界。 Figma Make 支持在预览中指向具体区域继续修改，也提供代码编辑和对话迭代。先走一遍长文案、空数据、错误反馈和返回路径，再决定哪些问题属于产品方案，哪些问题属于实现细节。1
- 把结果交回正确的工作对象。 需要在 Figma Design 里继续讨论时，Make 可以把当前预览状态复制成可编辑图层；帮助中心明确写明，当前 Figma Design 里的图层修改不会自动回写 Make 文件。需要跨浏览器保存状态、登录、保存文本或图片时，团队还要为原型配置后端。3
这条顺序把一次生成拆成三个可检查的问题：AI 是否使用了团队认可的组件，原型是否承受了真实资料，用户是否能在运行状态里验证关键路径。三个问题都能回答，原型才有资格进入下一轮评审。
边界：可运行原型仍然需要接管点
Figma Make 的强项是把设计讨论变成可以操作的东西。团队可以把原型嵌入 FigJam、Figma Design 和 Figma Slides，让讨论者直接点击流程、比较方案，再把反馈带回 Make。Figma 在 2026 年 1 月的产品更新里把这种方式概括为“show, don't tell”：真实交互比截图更容易暴露用户路径中的空缺。4
原型的可运行性与生产交付之间仍然有一段距离。Figma Make 可以发布网页应用，也可以通过后端保存跨浏览器状态、账号和内容；这些能力需要额外配置。把预览复制成设计图层时，当前流程仍然是单向的。13
所以，Figma Make 值得借鉴的地方不是“让 AI 生成得更快”，而是把生成器放进产品已有的语言和材料里。做 AI 原型时，可以先检查三件事：生成器使用的组件是否来自真实系统，输入内容是否覆盖长文本和异常状态，评审者是否能在可运行的路径里接管判断。先把这些约束交给 AI，后面的生成自由度才有实际意义。
References
- 1Explore Figma Make – Figma Learn - Help Center
help.figma.com
- 2
- 3
- 4
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.