07 Figma插件又报错了:我怎么把满屏红字交给 AI?

前几篇文章里，我写了自己为什么开始 Vibe Coding，也写了第一次搭 Figma 插件环境、怎么拆需求、怎么和 AI 一步步共创产品，以及 Figma 插件为什么和普通小工具不一样。

这一篇想聊一个更具体，也更真实的问题：

插件报错了，怎么办？

做「灵犀表格 / Tablesense」的时候，我遇到过太多次类似场景：

插件突然打不开了。

按钮点了没反应。

表格没有生成到画布上。

AI 数据返回了，但文案没有填进去。

刚修好一个功能，另一个功能又坏了。

接入本地 Ollama 时，明明地址看起来没错，插件里就是请求失败。

一开始我看到这些问题，第一反应基本都是慌。

尤其是控制台里出现一堆红字的时候，我完全不知道它在说什么。

我只知道：又坏了。

后来我慢慢发现，对代码小白来说，修 Bug 的第一步不一定是看懂代码，而是学会把“问题现场”完整交给 AI。

01 一开始我只会说：又报错了

刚开始用 AI 写代码时，我反馈 Bug 的方式非常粗糙。

我经常会直接告诉 AI：

“又报错了，发生了xxx事情，帮我修一下。”

这种方式偶尔也能解决问题，但更多时候效果并不好。

因为 AI 不在我的电脑前。

它不知道我刚才点了哪个按钮。

不知道插件是在打开时崩了，还是点击生成时崩了。

不知道我预期它做什么。

不知道完整的控制台日志是什么。

它只能猜。

如果猜对了，运气好。

如果猜错了，就会进入很折磨的循环：

AI 说“我找到原因了”。

改一轮。

还是报错。

它又说“真正原因应该是这里”。

再改。

继续报错。

做插件那段时间，我被这种循环折磨过很多次。

后来我才意识到，很多时候不是 AI 完全没能力修，而是我给它的信息太少了。

02 先把问题说清楚，再让 AI 看日志

现在如果插件出问题，我一般不会马上让 AI 改代码。

我会先把问题描述清楚。

比如：

我刚才做了什么？

我预期插件应该发生什么？

实际发生了什么？

这个问题是刚刚改完哪个功能后出现的？

控制台里有什么报错？

不用写得很专业，但要让 AI 知道现场发生了什么。

比如，比起说：

“生成表格失败了。”

更好的描述是：

“我在插件里输入了表头和行数，然后点击生成表格。预期是在 Figma 画布中生成一张表格，但实际点击后画布没有任何变化，插件窗口也没有提示。我打开控制台后复制了日志，内容如下……”

这样 AI 至少能知道问题发生在什么操作之后。

如果是接入 AI 模型失败，也可以这样说：

“我刚才在插件里选择 Ollama，本地地址填的是 http://localhost:11434，模型名是 qwen3:8b。点击测试连接后失败。浏览器可以打开 localhost:11434，终端也能看到模型列表，但 Figma 插件里请求失败。下面是控制台日志……”

这种描述配合日志，AI 才更容易判断问题到底出在插件代码、manifest、模型接口，还是本地服务配置上。

03 Figma 插件的控制台日志怎么打开？

做 Figma 插件时，很多问题都要看控制台日志。

这个入口我当时也摸索了很久。

现在可以直接记住：

在 Figma 客户端里，右键打开菜单：

Widgets → Development → Show / Hide console

也可以用快捷键：

Windows：

Ctrl + Alt + I

Mac：

Command + Option（Alt）+ I

打开控制台以后，在控制台区域右键，可以复制全部日志。

然后把这些日志和刚才的问题描述一起发给 AI。

这里我建议尽量复制文字日志，不要只发截图。

截图有时候看不全，也不方便 AI 精确判断。

日志里会包含更完整的信息，比如报错类型、文件名、行号、调用栈、请求失败原因。

你不一定看得懂。

但 AI 看这些内容，比看一张模糊截图有用得多

04 不要一上来就让 AI 改代码

我后来养成了一个习惯：

插件报错后，先不急着让 AI 改代码。

以前我经常会直接说：

报错了，出现了xx问题，帮我修一下。

结果 AI 很容易马上开始改文件。

它看起来很积极，但有时候根因还没找准，就已经动手改了一轮。

更麻烦的是，Figma 插件里的问题不一定都在业务代码里。

有时候是 code.ts 改了，但 code.js 没重新编译。有时候是 manifest.json 里的入口或网络权限不对。有时候是 UI 和主逻辑之间的消息没传过去。有时候是 Figma 插件环境不支持某些新语法。有时候是本地 Ollama 的跨域配置没有生效。

如果 AI 没先判断问题在哪一层，就直接开始改代码，很容易越修越乱。

所以我现在会先这样说：

先不要修改代码。请先根据我描述的问题和控制台日志，分析可能原因。我不懂代码，请用清晰易懂的方式解释给我听。等我确认后，再给出修改方案。

这里我之前会把它理解成“AI 的注意力机制导致它容易没分析完就动手”。

更准确地说，应该是：当你直接要求 AI“修一下”时，它会倾向于立刻生成解决方案；如果上下文不够完整，它可能会在没有定位根因的情况下开始修改。

所以，对代码小白来说，让 AI 先解释原因很重要。

你不一定要完全听懂所有技术细节。

但至少可以知道它准备往哪个方向修。

如果它的分析明显很飘，你也可以继续追问，而不是马上让它动项目代码。

05 我会这样把 Bug 发给 AI

后来我给 AI 反馈 Bug 时，会尽量把信息说完整一点。

不用写得很专业，只要把现场讲清楚就行。

比如我不会只说：

生成表格失败了。

我会改成：

我在 Figma 插件里输入了表头和行数，然后点击“生成表格”。预期结果是：在 Figma 画布中生成一张表格。实际结果是：点击后画布没有任何变化，插件窗口也没有明显提示。我打开 Figma 控制台后，复制了完整日志，下面是日志内容：【粘贴日志】

这种描述的好处是，AI 不只是看到一段报错，而是知道：

我做了什么；

我期望发生什么；

实际发生了什么；

问题出现在哪一步；

控制台给了什么线索。

这些信息放在一起，AI 才更容易判断问题到底出在插件代码、Figma 配置、接口请求，还是本地服务环境上。

很多时候，AI 修 Bug 的效率，不是取决于你会不会写代码，而是取决于你有没有把问题现场交代清楚。

06 我后来会记录 AI 常犯的错

做 Figma 插件时间长了以后，我发现 AI 有些错误会反复出现。

于是我开始把它们记下来，就像错题本一样。

比如：

AI 有时候会直接修改 code.js，但更合理的流程应该是先修改 code.ts，再重新编译生成 code.js。

如果只改 code.js，后续再编译时可能又被覆盖。

再比如：

Figma 插件运行环境和普通浏览器不完全一样，一些新的ES语法可能不兼容。

AI 有时会按普通 Web 项目的习惯写代码，结果插件里跑不起来。

还有：

模块拆分以后，最终产物必须正确打包成 Figma 能运行的 code.js。

如果最终文件里残留 import / export 这类模块语法，插件可能直接打不开。

再比如：

接入本地 Ollama 时，不只是插件里填地址，还要注意 manifest 网络权限和 Ollama 的 OLLAMA_ORIGINS 配置。

这些东西我一开始都不懂。

但遇到一次，记下来一次。

下次再遇到类似问题，就可以直接提醒 AI：

“这是 Figma 插件项目，请注意不要直接修改 code.js。优先修改 code.ts，并确保重新编译。”

“请注意 Figma 插件环境可能不支持某些较新的 JS 语法。”

“请结合 manifest、code.ts、ui.html 的关系来判断，不要按普通网页项目处理。”

这不是什么高级技巧。

但对我这种非程序员来说，真的很有用。

你不需要一下子懂很多。

但你可以把自己被坑过的地方一点点记下来。

07 修完 Bug 后，一定要回到 Figma 里再点一遍

还有一个很重要的习惯：

AI 修完以后，不要马上继续加新功能。

一定要回到 Figma 里重新测试一遍。

插件能不能打开？

按钮能不能点？

刚才的问题是否真的解决？

原本能用的功能有没有被改坏？

做灵犀表格时，我遇到过很多次这种情况：

一个 Bug 修好了，另一个功能被改坏了。

比如修组件读取时，生成表格逻辑出了问题。

修文案替换时，AI 数据生成又受影响。

修接口请求时，原来的默认文案生成方式又异常了。

所以我后来会更谨慎一点。

每次修完，只测试当前问题还不够。

至少要把几个核心流程再跑一遍。

这一步很笨，但很有必要。

08 写在最后

这篇文章没有什么复杂技巧。

它更像是我被 Bug 折磨之后，总结出来的一套最基础动作：

先把问题说清楚；

打开 Figma 控制台；

复制完整日志；

把日志和问题一起发给 AI；

让 AI 先分析原因；

听懂大概方向后再让它修改；

修完以后回到 Figma 里重新测试；

遇到重复坑，就记到错题本里。

对代码小白来说，这已经能解决很多问题。

你不需要完全看懂每一行报错。

但你要知道去哪里找报错，怎么复制报错，怎么把问题描述清楚。

满屏红字看起来吓人。

但很多时候，它其实已经把线索给你了。

你要做的，就是把这些线索完整交给 AI。

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

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

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

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