Figma 把 AI Agent 放进画布：一份 Markdown，开始“会画图”的技能时代

最反直觉的事实是：让 AI 真正参与设计，不是更大的模型，而是一份写得足够“死板”的 Markdown。Figma 在这场对谈中展示了它的第一方 MCP Server 与 Skills 机制，如何让 AI Agent 直接“落笔”到画布上，设计与代码的边界正在被重新定义。

真正的转折点：AI 不再“建议设计”，而是直接改画布

过去一年，AI 在设计里的角色大多停留在“给建议”“生成灵感”。但 Amy 和 TJ 一上来就点破了一个变化：Figma 的 MCP server 让 agent 可以通过 use Figma 这个工具，直接写入画布。

这不是插件，也不是脚本，而是第一方能力。换句话说，AI 不再是站在你身后的“顾问”，而是被正式允许坐到设计桌前。对设计师来说，这个变化的冲击在于：你不只是和 AI 聊天，而是在和一个能真实修改设计产出的 Agent 协作。

这也是为什么他们不断强调一个词——workflow。Skill 不是炫技，而是嵌进真实工作流的能力单元。

什么是 Skill？答案反而“老派”：一份严格的 Markdown

TJ 给出的解释几乎有点反高潮：Skill 通常从一个 Markdown 文件开始，里面写满了指令。

不是自然语言随便聊，而是“严格指南”。你告诉 Agent：你是谁、你能做什么、你不能做什么、输出必须长什么样。听起来很传统，甚至有点像早期规则引擎。

但关键恰恰在这里。Skill 的本质，是把“设计与开发的意图”显性化、结构化。AI 不擅长猜你的真实目的，但它非常擅长执行被清楚写下来的规则。

TJ 的判断很直白：理解 Skill 最好的方式不是看文档，而是亲手改一份 Markdown，看 before / after 的输出差异。Skill 不是魔法，是可以被不断打磨的工艺品。

从 localhost 到 Figma：代码优先设计者的真实痛点

最有价值的部分，来自 TJ 自己做的一个 Skill：把本地运行的代码原型（localhost）抽象进 Figma 画布。

这击中了一个长期被忽视的群体——code-first 的设计师和前端。现实中，很多高保真交互最早诞生在代码里，而不是设计稿里。问题是：这些成果很难回流到设计系统。

TJ 的 Skill 做的事情并不玄学：读取正在运行的原型，理解结构，再在 Figma 中生成对应的画布元素。Amy 的反馈点出了核心价值：这不是单向转换，而是“目的与意图”的对齐——设计师和开发者终于在同一个抽象层上对话。

这也解释了为什么他们反复讨论 tweak 输出：Skill 的好坏，不在于第一次跑通，而在于你是否愿意为真实使用场景持续调教它。

发布到社区之前，他们在优化什么？

在 Cursor 里运行 Skill、回到 Figma 看 agent output，再回头改 Markdown——这个循环本身就是示范。

Amy 关注的是：哪些结果“看起来像机器做的”，哪些已经接近人类设计师的判断。TJ 则更在意可维护性：如果别人 fork 这个 Skill，能不能快速理解并修改？

他们达成的共识很克制：这只是一个很好的 first pass。但也正因为如此，才值得发布到 Figma Skills 社区，作为一个可以被共同演化的起点。

Skill 的未来，不是完美，而是可协作。

总结

这场对谈真正的启示是：AI 设计的下一步，不在模型参数，而在“意图接口”。Skill 用一份 Markdown，把设计与开发的隐性判断变成显性规则，让 Agent 真正参与生产。

如果你是设计师，可以从一个微小但真实的痛点开始，写下你希望 AI 严格遵守的规则；如果你是开发者，这是把代码成果带回设计系统的现实路径。接下来值得思考的是：当越来越多 Skill 被共享，设计语言本身，会不会开始像代码一样被版本化？

关键词： Figma， AI Agent， Skill， MCP Server， Cursor

事实核查备注： 需核查：Amy 的全名与职务表述；TJ Petri 的公司 South 的准确定位；Figma MCP server 是否为第一方工具的官方说法；use Figma 是否为工具正式名称；视频发布时间与链接有效性