05 Figma 插件不是普通小软件:我第一次被 AI 和工程问题联手教育

前几篇文章里，我一直在说 Vibe Coding 让设计师有机会把想法做成工具。

但做「灵犀表格 / Tablesense」时，我很快被现实教育了一次：

用 AI 做一个普通小工具，和用 AI 做一个 Figma 插件，不是一回事。

Figma 插件不同于普通的小工具，它运行在 Figma 的插件架构里，会受到 Figma API、插件沙箱、UI iframe、manifest 配置、打包方式等限制。

AI 再强，如果缺少这些上下文，也很容易一本正经地写错。

而我也是在这个阶段意识到：完全不懂开发基础，遇到问题真的会两眼一抹黑。

01 插件能打开，不代表它真的“开发顺利”

最开始，我看到插件窗口能弹出来时很兴奋。

因为对当时的我来说，能让一个本地插件在 Figma 里打开，已经很不容易了。

但后来我才发现，这只说明“壳子”跑起来了。

真正难的是后面这些事：

让插件读取 Figma 画布内容；

让插件调用组件库里的组件；

让 UI 里输入的信息传给插件主逻辑；

让插件在画布中生成表格；

让 AI 生成的数据替换到组件实例里；

让这些功能在反复修改后仍然稳定。

从这一刻开始，我遇到的问题就不再是“按钮没写好”这么简单了。

很多报错，背后其实是 Figma 插件架构的问题。

02 Figma 插件和普通小软件最大的区别：它活在别人的规则里

如果你用 AI 做一个本地笔记工具、音乐播放器、小网页，很多东西可以按普通 Web 应用的思路来。

但 Figma 插件不是这样。

它至少有几层限制：

插件主逻辑运行在 Figma 的插件环境里，不是普通网页。

插件 UI 通常运行在 iframe 里，和主逻辑不是一回事。

UI 和主逻辑之间需要通过消息通信。

插件能不能访问网络，要看 manifest 里的权限配置。

操作画布必须遵守 Figma API 的能力边界。

组件库里的组件变更后，如果没有发布，插件可能读到的还是旧内容。

TypeScript、模块拆分、import/export 这些东西，最终都要正确打包成 Figma 能运行的 code.js。

这也是我后来最深的体会：

AI 不是不能写 Figma 插件，但你必须让它理解“这是 Figma 插件”，而不是普通前端项目，而Figma的框架是有很多限制的。

03 第一次被坑：AI 把代码越写越大

刚开始做插件时，我没有太多工程意识。

只要能跑，我就让 AI 继续往里加功能。

结果代码越写越大。

一个文件里塞了越来越多逻辑，最后甚至接近“巨型文件”的状态。

短期看，这样确实方便。

AI 写得快，我也不用理解太多项目结构。

但问题很快出现：

AI 修改一个功能时，很容易误伤其他功能。

后面想加新功能，定位代码越来越困难。

报错后不容易判断问题发生在哪一块。

AI 自己也越来越难稳定理解上下文。

于是我开始让 AI 做模块拆分。

这一步本身是对的。

但新的坑马上来了。

04 模块拆分后，插件反而打不开了

我让 AI 把代码拆成多个文件后，原本是为了让项目更清晰。

但因为 Figma 插件主入口不是普通网页环境，最终运行的 code.js 需要是 Figma 能识别的格式。

如果代码里直接留下 import/export 这类模块语法，但最终产物没有正确打包，导致插件入口文件里残留了 Figma 当前配置无法直接运行的模块语法，插件就可能直接打不开。

这类问题特别折磨。

因为从表面上看，代码似乎没什么大问题。

AI 也会说“逻辑是对的”。

但插件就是启动失败。

我当时修这个问题修了很多天，GPT 和 Claude 也绕了很久。

它们不是完全不会，而是经常缺少一个关键判断：

Figma沙箱的JS引擎比较旧，高版本的 JS 特性可能不被支持，所以容易出现语法兼容问题，而且拆分文件后必须用 webpack 等打包工具将所有代码打包到单文件。

后来我才慢慢理解：

code.ts 可以拆模块开发。

src 目录可以放拆分后的逻辑。

但最终要通过构建工具打包成 Figma 能运行的 code.js。

manifest.json 里的 main 通常应该指向 code.js。

最终产物里不应该残留 Figma 环境不支持的模块加载方式。

这件事让我第一次真正意识到：

所谓“打包”“构建”“模块语法兼容”，不是程序员故意把事情搞复杂，而是项目真的会因为这些东西打不开。

05 第二个坑：AI 不懂 Figma 插件上下文时，国内外模型都一样会懵

那段时间我试过很多模型。

国产的 DeepSeek、GLM。

国外的 Claude、GPT。

它们各有强弱，但在某些 Figma 插件问题上，表现其实很接近：

只要缺少足够准确的插件背景信息，它们都会开始猜。

有时候它们会给出普通前端项目的解决方案。

有时候会建议修改一些和问题无关的代码。

有时候会在“看似合理”的方向上反复尝试。

这不是单纯哪个模型不行。

更准确地说，是 Figma 插件这个场景有自己的规则。

如果 AI 不知道这些规则，或者你没有把官方文档、架构限制、报错信息喂给它，它就很容易被带偏。

我也是从那时开始，意识到一个很重要的方法：

遇到 Figma 插件问题，不要只问 AI 你觉得哪里错了。要让 AI 基于官方文档、报错信息和当前项目结构来判断。

06 后来我开始把官方文档当成唯一准则

去年 AI 自己联网搜索和判断资料的能力还没有现在这么稳定。

有时候它搜索到的内容不准。

有时候它会把普通 Web 开发经验套到 Figma 插件上。

有时候它甚至会一本正经地编一个不存在的 API 或配置方式。

所以后来我干脆把 Figma 官方 API 文档、插件教程、相关说明复制下来，作为上下文喂给 AI。

这个方法虽然笨，但非常有效。

因为 AI 的问题往往不是不会写代码，而是不知道该遵守哪套规则。

当我把官方文档给它以后，它至少有了更可靠的参照物。

不再完全靠经验猜。

这也成为我后面用 AI 编程的一个习惯：

只要是平台型开发，比如 Figma 插件、浏览器插件、Electron、某个 SDK，就尽量把官方文档给 AI。

不要只让它凭记忆写。

07 第三个坑：组件库不是你改了，插件就一定读到最新

灵犀表格的核心功能，是调用 Figma 组件库里的表格组件。

这里也有一个很容易忽略的坑：

组件修改后，需要发布。

如果你只是在组件库文件里改了组件，但没有发布更新，插件读取到的可能还是旧内容。

这时候你很容易以为是代码错了。

AI 也可能会带着你疯狂改代码。

但真正的问题，可能根本不在代码里。

还有一个坑是 component 和 component set 的关系。

Figma 里的组件、组件集、变体并不是一回事。

如果做组件映射时没有处理好这些差异，就可能出现匹配不准、识别失败、拿到的不是预期组件等问题。

这类问题非常具体，也很“Figma”。

它们不是普通编程教程里会重点讲的内容。

但你做 Figma 插件时，就是会被它们卡住。

08 我为什么开始补开发基础

以前我觉得，既然有 AI，我是不是不用学开发基础了？

后来被这些问题折磨后，我的看法变了。

你当然可以不系统学编程，也能用 AI 做出东西。

但如果你希望自己不只是“会让 AI 写”，而是在出问题时能有一点判断力，那最好还是补一点基础概念。

至少要知道：

iframe 是什么，为什么插件 UI 和主逻辑不是同一个环境。

postMessage 是什么，为什么 UI 要把消息传给主逻辑。

import/export 是什么，为什么模块语法可能导致运行失败。

打包和构建是什么，为什么写的源代码不能直接等于最终运行代码。

manifest 是什么，为什么入口文件和权限配置会影响插件能不能跑。

API 文档为什么重要，为什么不能完全相信 AI 凭空生成的答案。

这些知识不一定要学得很深。

但只要懂一点，你遇到问题时就不会完全懵。

你会开始有一些开发意识：

这个问题是不是构建失败？

是不是入口文件没指对？

是不是 UI 和主线程通信出了问题？

是不是 Figma API 能力边界导致的？

是不是组件库没有发布？

是不是 AI 把普通 Web 项目的写法套进插件项目了？

有了这些意识，你给 AI 的反馈也会更准确。

09 你要学会建立工程意识

走过这些坑，我想说的是：

Vibe Coding 可以让你快速开始，但复杂一点的项目会逼你建立工程意识。

一开始，我只想让 AI 帮我把功能写出来。

后来我慢慢意识到，项目能不能长期改、能不能稳定跑、出了问题能不能定位，背后都不是一句“AI 写代码”能解决的。

你需要大致知道项目结构。

需要控制文件复杂度。

需要理解构建流程。

需要知道规则限制，尤其是你在做Figma插件，谷歌浏览器插件等在别的软件中使用的插件时。

需要学会查官方文档。

需要让 AI 在正确上下文里工作。

这些东西听起来不如“一句话生成产品”性感。

但它们决定了你能不能把一个小玩具，推进成真正可用的工具。

10 写在最后

做灵犀表格的过程中，我最大的感受是：

AI 编程不是完全不用学习编程知识了，而是可以边做边理解。

你不需要先成为程序员，才有资格开始。

但当项目变复杂以后，你一定会遇到一些 AI 也没法凭空解决的问题。

尤其是 Figma 插件这种平台型开发。

它既借用了 Figma 的能力，也受制于 Figma 的规则。

AI 能帮你写很多代码。

但如果它不了解这些规则，它也会反复犯错。

而你如果完全没有基础概念，就只能看着它在错误方向上越走越远。

所以我现在不再觉得“用 AI 编程”就等于“不需要学习”。

更准确地说：

AI 降低了开始的门槛，但越往后走，越需要一点判断力。

你不用学到多深。

但最好知道一些基础概念。

这样当 AI 卡住的时候，你至少不会两眼一抹黑。

你能给它补充上下文，能让它查官方文档，能让它逐项排查，而不是一遍遍让它“再试试”。

下一篇我可能会继续拆更具体的坑：

Figma 插件里的组件读取、组件映射、文本替换、AI 数据生成，这些功能为什么看起来简单，真正做起来却很折磨。

我是天宇，一名持续探索 AI 的 UX 设计师。

未来我会继续分享 AI 时代的 UX 设计师如何拥抱变化。

如果你也对这些话题感兴趣，欢迎关注。

未来的探索之路，我们结伴同行。