作者丹丹在设计团队里很多问题并不是“大问题”但会反复消耗时间。比如图标命名不统一、组件结构不规范、UI 文案需要人工校验、外部 SVG 粘贴进 Figma 后图层混乱、描边和填充混杂、尺寸和约束不符合设计系统要求。这些事情单次处理并不复杂但如果经常性的重复做就会变成一种稳定的损耗。过去设计师遇到这类问题通常会先去 Figma Community 里找插件。Community 里的插件确实很丰富也能解决不少通用问题。但真实团队里的规范往往更具体每家公司有自己的组件命名方式、图标入库标准、研发协作流程和设计系统结构。这也是为什么设计师值得自己尝试开发 Figma 插件因为设计师最了解自己的工作流很多插件的价值不在于技术多复杂而在于它刚好解决了团队里那个每天都会遇到的小麻烦。Figma Agents 出来后插件开发变了吗变了但底层思路没有变。现在 Figma 已经支持通过 Figma Agent 生成插件。你可以在 Figma Design 里描述需求让 Agent 帮你生成一个可以运行在画布上的工具。官方把这类插件称为 Generative plugins也就是通过提示词生成的插件。同时传统的本地开发方式依然存在也就是 Classic plugins。你在本地用 VS Code、Cursor、Codex 等工具开发插件代码再通过 Figma 桌面端进行测试和发布。简单理解Figma Agent 适合快速验证想法比如批量整理图层、生成简单内容、修改选中对象、快速做一个内部小工具。本地开发适合长期维护比如需要复杂 UI、版本管理、接入外部接口、发布到 Community、团队多人协作维护。两者的核心能力都来自 Figma Plugin API区别主要在开发方式、可控程度和维护方式。所以哪怕你现在直接使用 Figma Agent 生成插件本文里的方法依然适用。真正重要的不是用哪个 AI 工具而是你能不能把一个设计工作流问题拆成清晰、可执行、可验证的规则。需要注意的是如果你使用 Figma Agent 生成插件它和本地 Classic plugin 的管理方式不一样。Figma Agent 生成的插件由 Figma 托管不会在你的电脑里生成code.js、ui.html、manifest.json这些本地文件。后续迭代也不是打开代码文件修改而是在 Figma 的 Agents 面板里通过/选择已有插件再继续描述你想调整的功能。所以如果只是快速验证一个工具想法Figma Agent 会更轻如果你需要完整代码控制、Git 版本管理、复杂 UI、接入外部接口或发布到 Community本地 Classic plugin 仍然更适合。参考官方文档Figma Plugin Developer DocsAbout building plugins in FigmaQuick start guide to generative plugins and shaders开发前需要准备什么如果你使用 Figma Agent可以直接在 Figma Design 里开始描述需求。如果你想用本地开发方式需要准备这些工具Figma 桌面端用于创建插件、导入 manifest、本地调试。VS Code / Cursor / Codex用于生成、修改和理解代码。基础的 HTML / CSS / JavaScript 概念不需要精通但要知道代码大概分工。一个明确的问题场景插件不是为了“做一个插件”而做而是为了把重复工作自动化。AI 可以帮你写代码但它不能替你判断设计规范你仍然是做决策的人AI 更像是执行者帮你把已经讲清楚的规则转成代码。先理解 Figma 插件的基本结构创建一个 Figma 插件后通常会看到几个核心文件manifest.json这是插件配置文件决定插件名称、入口文件、UI 文件、运行在哪类 Figma 文件中以及是否需要网络访问权限。初学阶段不需要深入研究每个字段但不要随意删除或改错。它相当于插件的“说明书”。code.js这是插件主逻辑文件负责读取和修改 Figma 画布上的内容。比如读取当前选中的图层、修改节点命名、设置颜色、调整尺寸、创建 Frame、处理 Vector 等主要都在这里完成。ui.html如果你的插件需要界面比如按钮、输入框、选项开关就会用到这个文件。可以简单理解为code.js负责操作 Figma 画布ui.html负责插件弹窗里的界面两者通过消息通信协作。如果插件只是执行一个简单命令也可以没有复杂 UI。但如果希望设计师可配置参数比如输入图层名称、选择是否保留原图、设置输出尺寸就需要 UI。下面的步骤主要以本地Classic plugin为例。如果你使用Figma Agent可以跳过本地文件创建部分直接从“Step 2不要先写代码先把问题讲清楚”开始。Step1 创建 Figma 项目新建一个新项目figma design创建插件菜单中选择Plugins找到Development点击 **New plugin **选择Figma design输入插件名称选择** Custom UI** Figma会在本地生成一个插件文件夹。这个文件夹就是后续要在Cursor、Codex或VS Code中打开的项目。如果在Figma Actions中没有看到本地插件可以通过**Plugins → Development → Import plugin from manifest **选择插件文件夹中的manifest.json手动导入。Step 2不要先写代码先把问题讲清楚很多设计师第一次让 AI 写插件时会直接说帮我做一个 Figma 插件把 SVG 整理好。这个描述太模糊。AI 不知道什么叫“整理好”也不知道你的团队规范是什么。更好的方式是把需求拆成几个问题输入对象是什么插件要处理什么是当前选中的 SVG选中的 Frame整个页面还是某个组件集里的所有图标处理规则是什么插件要按什么顺序处理比如先转描边再合并路径再重命名再设置约束。输出结果是什么最终希望得到什么是一个单独的 Vector一个 Frame 包裹的图标还是一个可以直接进入组件库的结构异常情况怎么处理如果用户没有选中图层怎么办如果选中了多个图层怎么办如果选中的是组件实例怎么办如果图层没有 stroke 怎么办怎么判断成功插件运行后哪些结果说明它是对的比如颜色不变、中心点不偏移、最终命名符合规范、图层数量符合预期、约束为 Scale / Scale。这一步很重要。设计师开发插件的关键不是懂多少代码而是能不能把“我感觉不对”变成“哪条规则不对”。Step 3用一个真实案例开始这里以我开发的插件举例SVG to Clean Vector | Figma。SVG to Clean Vector.mp4背景问题在日常设计中设计师经常从外部网站复制 SVG 图标比如从 Lucide 这类图标库复制图标再粘贴到 Figma 中。但默认粘贴结果经常存在这些问题SVG 会被解析为一个 FrameFrame 内包含多个 矢量路径VectorStroke 未转为 Outline多个路径未进行合并或展平Icon 层级结构命名不统一无法在 Icon Component 中作为属性进行切换这些问题会导致Icon 库维护成本高需要频繁的定位问题Icon 无法作为 Component Property 正确切换项目中使用 Icon 时一致性差、返工多插件目标这个插件的目标是一键将外部 SVG 图标规范化为可以进入团队 Icon 库的标准图形。更具体一点将描边图形转成可交付的矢量轮廓将多个路径整理成稳定结构保留或继承原始颜色自动设置响应约束支持自定义 Frame 名称和 Vector 名称输出结果能直接进入团队设计系统Step 4给 AI 的需求描述示例下面是一个更适合给 Cursor、Codex 或 Figma Agent 的需求描述我想制作一个figma插件我已经创建了font stylecolor:#000000;code.js/font和manifest.json文件接下来我要做的是准备好所有必要条件然后测试运行这个插件我现在遇到的问题是外部 SVG 导入 Figma 后规范乱比如描边/填充混杂、图层碎、命名不统一人工清洗成本高。我想要插件实现的功能是路径清洗对子图层做 outlineStroke描边转成可交付的矢量轮廓图层规整多个节点先按需要进行 Union 布尔合并颜色继承优先用原 Stroke 色作为最终 Fill响应规范自动设 SCALE / SCALE 约束命名可自定义 Vector 图层名和 Frame 名这类描述看起来比一句“帮我做插件”长很多但它会显著减少来回试错。AI 最怕的不是复杂需求而是模糊需求。Step 5开始调试一轮跑完就得到了一个初版的插件这个时候不需要急着看懂每一行代码第一轮更重要的是测试结果插件能不能打开点击按钮有没有反应是否能读取当前选中的图层生成结果是否在正确位置颜色是否符合预期图层结构是否符合设计系统规范命名是否正确如果 Figma Actions 里没有出现本地插件可以重新 Import from manifest。img如果插件能打开但运行报错可以把错误信息截图或复制给 AI让它定位问题。如果你对插件样式有要求可以在ui.html中调整界面。熟悉 CSS 的设计师可以自己微调不熟悉也可以把视觉目标描述给 AI让它帮你修改。Step 6调试时不要说“感觉不对”这是整个过程中最重要的一点AI 能帮你改代码但你需要告诉它到底哪里不对。下面这些例子来自 SVG 清洗插件但方法可以迁移到其他插件不要只说结果不对要说清楚输入、当前结果、期望结果和判断规则。当你发现最后实现位置的效果不符合预期❌ 不对继承原位置参数✅ 不对现在生成后的图形是按左上角定位的导致视觉位置发生偏移。请改成以前后图形的中心点为基准保持处理前后中心点一致。当你发现颜色未继承处理前的图形时❌ 不对颜色不要发生改变继承原始图形的值✅ 不对合并后的图形Fill应该等于原始图形的Stroke。如果原始图形没有Stroke再使用原始Fill。当你发现图层结构不对时❌ 不对图层还是乱的✅ 当前结果里仍然保留了多个Vector子图层。我的目标是最终只保留一个命名为Icon的Vector并放在一个命名为用户输入值的Frame中。当你发现约束不对时❌ 不对响应式没有设置好✅ 最终Vector的constraints需要设置为horizontal: SCALEvertical: SCALE。请确认是在最终生成的Vector节点上设置而不是只设置在外层Frame上。这就是设计师和 AI 协作时最需要转变的地方从“描述感受”变成“描述规则”。插件维护建议如果插件只是个人使用可以保留在本地。但如果是团队通用规范至少做到这几件事使用 Git 做版本管理给每次更新写清楚变更内容明确插件支持和不支持的场景发布前检查是否包含内部敏感信息团队插件优先考虑内部私有分发确认无风险后再发布到 Community。一个插件最开始可能只是解决你自己的问题但只要它稳定、清晰、可复用就可能变成团队工作流的一部分。设计师开发插件的真正价值最后还是很推荐设计师尝试自己开发 Figma 插件。原因不是“AI 让设计师也能写代码了”而是设计师本来就很适合做这件事。因为设计师最知道工作流里哪里重复、哪里低效、哪里容易出错也最知道一个工具怎样才算真的顺手。AI 时代写代码这件事的门槛正在降低但定义问题的能力反而更重要了。你不需要一开始就懂完整的 Figma Plugin API也不需要把 JavaScript 学到很深。你需要先从一个真实、具体、重复出现的问题开始把它拆成清晰的输入、规则、输出和验收标准然后让 AI 帮你把规则变成工具。这也是我理解的“设计师开发插件”不是从代码开始而是从工作流开始。