从一个 SVG 清洗工具开始：设计师 howto 零帧起手开发 Figma 插件

作者：丹丹

在设计团队里，很多问题并不是"大问题"，但会反复消耗时间。

比如图标命名不统一、组件结构不规范、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 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 会被解析为一个 Frame
Frame 内包含多个矢量路径（Vector）
Stroke 未转为 Outline
多个路径未进行合并或展平
Icon 层级结构命名不统一，无法在 Icon Component 中作为属性进行切换

这些问题会导致：

Icon 库维护成本高，需要频繁的定位问题
Icon 无法作为 Component Property 正确切换
项目中使用 Icon 时一致性差、返工多

插件目标：

这个插件的目标是：

一键将外部 SVG 图标规范化为可以进入团队 Icon 库的标准图形。

更具体一点：

将描边图形转成可交付的矢量轮廓
将多个路径整理成稳定结构
保留或继承原始颜色
自动设置响应约束
支持自定义 Frame 名称和 Vector 名称
输出结果能直接进入团队设计系统

Step 4：给 AI 的需求描述示例

下面是一个更适合给 Cursor、Codex 或 Figma Agent 的需求描述：

我想制作一个figma插件，我已经创建了<font style="color:#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: SCALE ，vertical: SCALE 。请确认是在最终生成的 Vector 节点上设置，而不是只设置在外层 Frame 上。

这就是设计师和 AI 协作时最需要转变的地方：从"描述感受"变成"描述规则"。

插件维护建议

如果插件只是个人使用，可以保留在本地。

但如果是团队通用规范，至少做到这几件事：

使用 Git 做版本管理；
给每次更新写清楚变更内容；
明确插件支持和不支持的场景；
发布前检查是否包含内部敏感信息；
团队插件优先考虑内部私有分发，确认无风险后再发布到 Community。

一个插件最开始可能只是解决你自己的问题，但只要它稳定、清晰、可复用，就可能变成团队工作流的一部分。

设计师开发插件的真正价值

最后还是很推荐设计师尝试自己开发 Figma 插件。

原因不是"AI 让设计师也能写代码了"，而是设计师本来就很适合做这件事。

因为设计师最知道工作流里哪里重复、哪里低效、哪里容易出错；也最知道一个工具怎样才算真的顺手。

AI 时代，写代码这件事的门槛正在降低，但定义问题的能力反而更重要了。

你不需要一开始就懂完整的 Figma Plugin API，也不需要把 JavaScript 学到很深。你需要先从一个真实、具体、重复出现的问题开始，把它拆成清晰的输入、规则、输出和验收标准，然后让 AI 帮你把规则变成工具。

这也是我理解的"设计师开发插件"：不是从代码开始，而是从工作流开始。