figma-use

figma-use 技能概览

figma-use 是做什么的

figma-use 是在 Figma plugin API 工作流中安全、正确调用 use_figma 的必备技能。它面向那些需要用 JavaScript 写入、更新、检查或结构化 Figma 文件，而不是手工操作的 agent。如果你的任务包含编辑节点、绑定变量、调整 auto layout、创建组件，或者以程序方式读取文件结构，这个技能就是合适的入口。

适合安装给谁

如果你需要在 agent 运行中稳定地处理 Figma 文件，尤其是在 Design Implementation 场景下仅靠 prompt 指导太模糊时，就应该安装 figma-use skill。当结果取决于文件上下文、已有组件，或是 generic coding prompt 常常忽略的 Figma 特有约束时，它尤其有用。

它在实际工作中的价值

figma-use 的核心价值不只是提供 API 访问，更在于它会帮你把“什么时候调用 use_figma、先加载什么上下文”这件事卡住。这样可以减少错误调用、遗漏前置条件和无效迭代。对于需要在真实 Figma 文件上可预测执行的任务尤其重要，因为操作顺序和文件状态都可能改变最终结果。

如何使用 figma-use 技能

先安装并加载它

按照你的 skills manager 提供的安装路径先完成安装，然后确保 agent 在任何 use_figma 工具调用之前就已加载 figma-use。仓库里的规则写得很明确：调用 use_figma 时要传入 skillNames: "figma-use"。如果任务是完整页面或多分区屏幕搭建，还要同时加载 figma-generate-design，这样才能把 API 规则和屏幕构建工作流结合起来。

先从正确的文件开始读

在使用 figma-use 时，先读 references/plugin-api-standalone.index.md 了解 API 范围，然后在写代码前检查 references/common-patterns.md、references/gotchas.md 和 references/validation-and-recovery.md。如果你正在处理组件、变量或样式，就直接跳到对应的 pattern 文档，不要把整个仓库从头扫一遍。

把模糊需求转成可执行提示

给 figma-use 的输入要明确写出目标文件区域、对象类型和预期变化。例如：“在选中的 frame 里，使用现有本地组件创建一个三卡片横向布局，保持间距与当前页面一致，并返回创建的 node IDs。”这比“做得好看一点”更有效，因为这个技能需要的是可执行结构，而不是主观审美方向。

能显著提升输出质量的工作流

更好的 figma-use 工作流是：先检查文件或选中节点，确认可用的组件和样式，再做最小且安全的改动，最后验证结果。做 Design Implementation 时，优先采用增量式组装，而不是一次性生成。先读 agents/openai.yaml 了解工具上下文，再把 references 文件夹当作 API 行为和常见失败案例的事实来源。

figma-use 技能 FAQ

figma-use 只是用来写代码吗？

不是。figma-use skill 适用于任何需要用 JavaScript 调用 Figma Plugin API 的操作，包括程序化文件检查或结构发现这类“只读”任务。如果任务依赖实时文档状态，就应该放在这里处理。

什么时候不该用它？

如果只是静态建议、粗略设计点评，或者根本不用碰文件就能完成的任务，就不要用 figma-use。只要你没有真的要调用 use_figma，这个技能的价值就很有限，还可能拖慢流程。

它适合新手吗？

适合，但前提是你按仓库顺序来，并且把需求写具体。新手通常会卡在“直接要一个完成稿”却没有提供目标 frame、已有组件选择或约束条件。只要从当前文件状态和一个窄目标出发，它就会更容易上手。

它和普通 prompt 有什么区别？

普通 prompt 可以描述意图；figma-use 则帮助你按照 Figma 的真实 API 规则去执行。这个区别在 Design Implementation 场景里尤其重要，因为很多 Figma 操作都取决于 node 类型、页面上下文或支持的 Plugin API 方法。这个技能通过把工作流锚定在文档化的模式和 gotchas 上，减少了猜测成本。

如何改进 figma-use 技能

提供更好的文件上下文

最有效的改进，是把已经存在的内容说清楚：选中的 frame、页面名称、组件库、variable collection 或本地样式集。如果你不写这些信息，agent 就只能猜是该新建资产还是复用现有资产。对 figma-use 来说，上下文通常比啰嗦更重要。

说明结构，而不只是审美

“做得更干净一点”这种要求太弱了。更好的输入应该像这样：“把选中的 marketing section 转成一个 12 栏响应式 frame，复用本地 text styles，并让 CTA 与现有按钮组件对齐。”这样能帮助 figma-use 选对 API 路径，也能避免输出看起来精致，却不适配文件结构。

留意常见失败模式

最常见的问题包括：没有加载技能就调用 use_figma、跳过 API reference index、以及想在一轮里做太多事。另一个常见问题是没检查和 node placement、component properties 或 variable modes 相关的 gotchas。如果结果不对，先去检查与失败操作相匹配的 references，再重试。

用具体修改做迭代

第一次输出之后，要通过明确说明“保留什么、替换什么、哪些必须保持不动”来继续优化。例如：“保留当前 component instances，把垂直间距减小 8px，只改 secondary label 的文本样式。”这种改法，比要求重新设计一版，更能让 figma-use 在第二轮做得更好。