1. 项目背景与核心价值如果你是一名设计师或前端开发者那么Figma大概率是你日常工作中不可或缺的工具。它强大的协作和设计能力让从概念到实现的流程变得无比丝滑。但你是否也遇到过这样的场景面对一个复杂的设计稿需要手动提取颜色变量、测量间距、或者将设计稿中的文本内容批量导出给开发这些重复、琐碎的操作虽然单个看并不复杂但累积起来却极大地消耗了我们的时间和精力打断了流畅的创意和工作状态。这正是自动化工具大显身手的地方。今天要聊的这个项目虽然其最初的形态——figma-gemini-cli-extension——已经被官方归档Deprecated但它所代表的工作流优化思路和其演进后的新形态对于任何希望提升Figma使用效率的从业者来说都具有极高的参考价值。简单来说它最初是一个命令行工具旨在充当Figma和Google的Gemini AI模型之间的“桥梁”让你能用自然语言命令Figma完成一些操作比如“把选中图层的填充色导出为CSS变量”或者“为所有文本图层生成一份内容清单”。这个想法的核心价值在于“意图驱动而非操作驱动”。我们不再需要记住Figma插件商店里某个特定插件的名字和点击路径也不需要编写复杂的脚本。你只需要用最自然的方式说出你的需求剩下的交给工具去理解和执行。这极大地降低了自动化门槛让非程序员背景的设计师也能享受到脚本带来的效率红利。虽然原项目已迁移但理解其设计哲学和实现路径能帮助我们更好地拥抱其继任者并启发我们构建属于自己的自动化工作流。2. 从CLI到MCP一次架构的必然演进原figma-gemini-cli-extension被标记为“已归档”并引导用户转向新的mcp-server-guide仓库。这并非简单的项目废弃而是一次重要的架构升级。要理解这一点我们需要先拆解几个关键概念。2.1 原CLI扩展的运作模式与局限最初的CLI扩展其工作模式可以概括为“本地中转站”。它的工作流程大致如下监听指令你在终端命令行里输入一句自然语言例如figma-gemini “列出当前页面的所有组件”。请求中转CLI工具将你的指令文本连同你的Figma个人访问令牌Personal Access Token和当前打开的文件ID通常需要从Figma桌面应用或URL中获取一并发送给Google Gemini AI的API。意图解析与API调用Gemini AI理解你的自然语言指令将其“翻译”成一系列具体的Figma REST API调用。例如“列出组件”可能对应GET /v1/files/:file_id/components这个API。执行与返回CLI工具代表你使用你的令牌去调用Figma API获取结果数据。结果格式化CLI工具将API返回的原始JSON数据整理成人类可读的格式如表格、列表输出在终端里。这个模式的优势是直接、灵活但它有几个明显的痛点环境配置复杂用户需要在本机安装Node.js、配置Gemini API密钥、Figma令牌并可能面临包依赖冲突。上下文隔离它是一个独立的命令行工具与你的Figma设计环境是分离的。你需要手动获取并传递文件ID操作不够“无缝”。功能扩展性差如果想增加对新指令的支持需要直接修改这个CLI工具的代码对于普通用户来说门槛太高。协议不统一这只是Figma团队构建的其中一个集成工具。如果每个AI功能或外部服务都采用自己的CLI模式用户需要维护一堆不同的工具体验是割裂的。2.2 MCP构建统一的“技能”生态Model Context Protocol (MCP) 是这次迁移的核心。你可以把它理解为一个“标准插座”。Figma作为客户端定义了这个插座的规格任何符合规格的“电器”即MCP Server都可以即插即用。MCP Server服务端这就是新的“技能”提供者。figma-gemini-cli-extension的功能被重构并增强做成了一个标准的MCP Server。这个Server封装了与Gemini AI的交互逻辑并能提供一系列定义好的“工具”Tools或“资源”Resources比如“导出颜色”、“分析布局”、“生成文案”等。Figma AI客户端Figma软件内置的AI功能如“Make Design”侧边栏现在内置了MCP客户端的能力。它可以自动发现、连接并调用本机或远程运行的MCP Server。这样一来工作流发生了根本变化你在Figma中选中一些图层。在AI对话框中输入“将这些图层的颜色转换为Tailwind CSS配色变量。”Figma AI会将你的指令和当前设计上下文文件ID、选中图层信息发送给已连接的、专司“设计转代码”的MCP Server。该MCP Server可能集成了Gemini或其他AI模型处理请求调用必要的Figma API或进行逻辑计算生成对应的CSS代码。结果直接返回到Figma的AI对话框中供你使用。2.3 迁移的深层原因所以这次迁移远不止是换了个仓库地址。它是从“一个孤立的脚本工具”升级为“一个标准化、可扩展的AI能力平台的一部分”。对于用户而言好处是巨大的开箱即用未来这些能力可能会被直接集成到Figma中用户无需单独安装CLI。生态丰富任何开发者都可以遵循MCP协议开发自己的Server为Figma提供翻译、代码生成、内容审核、品牌检查等各式各样的AI技能。你可以在一个统一的界面里调用它们。上下文感知操作完全在设计环境中进行无需手动传递文件ID等上下文信息体验更流畅。维护升级功能更新在Server端统一进行所有用户能无缝获得改进。注意目前Figma的MCP生态仍处于早期建设阶段。mcp-server-guide仓库更像是一个官方指南和示例展示了如何构建一个MCP Server。普通用户期待的“一键安装即用”的成熟产品形态可能还需要等待Figma官方的进一步整合发布。但作为开发者或技术爱好者现在正是学习和尝试构建自定义技能的最佳时机。3. 核心功能场景与实操推演尽管原CLI工具已不再维护但通过其描述和MCP的愿景我们可以清晰地推演出它旨在解决的核心场景。理解这些场景能帮助我们在新架构下更好地构想和应用类似能力。3.1 场景一设计资产批量导出与规范化这是最经典的需求。设计师定稿了配色和文字样式开发同学等着使用。传统方式设计师手动从“样式”面板中一个个查看颜色HEX值或字体样式复制粘贴到文档中或者使用一些导出插件生成静态的CSS/JSON文件。开发再手动录入到代码里。一旦设计稿调整整个过程就要重来。AI驱动方式设计师选中所有使用了颜色样式的元素或直接对页面发起指令“导出本页所有颜色样式格式为CSS自定义属性CSS Variables并按色系分组。” MCP Server可以通过Figma API获取所有本地样式。利用AI的聚类能力自动将相近的颜色归类如主色、辅助色、成功色、错误色。生成具有语义化命名如--color-primary-500的CSS代码并附上原始的HEX值作为注释。实操心得颜色命名是设计系统落地的难点。纯靠AI生成的名字可能不符合团队规范。一个更优的实践是在指令中提供你们团队的命名规则示例例如“按照‘颜色-用途-明度’的格式导出参考primary-500, success-600。”3.2 场景二设计稿内容审查与文案处理设计稿中的文案需要经过产品、法务等多方审查或者需要批量替换为多语言版本。传统方式截图标注或使用注释工具一条条写反馈效率低下。多语言替换更是需要手动查找文本图层并修改。AI驱动方式审查指令可以是“检查当前页面所有文本标出长度超过50个字符的段落并检查是否有拼写错误。” Server会返回一个列表直接定位到具体图层。提取与替换指令为“提取本画板所有用户界面上的文案生成一个CSV文件包含图层ID、图层名称和文本内容。” 拿到CSV后交给翻译团队或AI翻译然后使用另一个指令“根据这个CSV映射文件批量更新设计稿中的文案。” MCP Server可以精准地根据图层ID进行替换。注意事项批量替换文案是高风险操作务必先在副本文件上测试。AI在理解上下文时可能出错比如误改了作为Logo一部分的文本。最佳实践是结合“选择相同文本样式”的功能先进行可视化确认。3.3 场景三布局分析与开发辅助开发同学在实现复杂设计稿时有时需要快速理解布局的嵌套关系和约束条件。传统方式手动测量间距在代码中反复调试以实现精准还原。AI驱动方式开发者在查看设计稿时可以询问“这个列表项和卡片之间的间距规律是什么” 或者“这个头部导航栏在移动端视图下的布局变化规则是怎样的” MCP Server可以分析相关元素的Frame、Auto Layout属性并生成描述性的总结甚至直接输出一段关于Flexbox或CSS Grid布局建议的伪代码。实操推演例如Server接收到关于“间距规律”的查询后其内部逻辑可能是1获取选中元素及其相邻元素的坐标和尺寸2计算水平/垂直间距3判断这些间距是否为固定值或存在某种比例关系如8pt网格系统4用自然语言报告“这些元素采用8pt网格系统垂直间距均为24pt3倍网格水平间距为16pt2倍网格。”3.4 场景四自动化文档生成为设计系统生成实时、同步的文档是一项繁重但必要的工作。AI驱动方式指令可以是“为我们的按钮组件Master Component: ‘Button/Primary’生成使用文档包括尺寸变体、状态默认、悬停、禁用、可配置属性以及代码片段。” Server会拉取该组件的所有实例、变体Variants信息分析其属性Property并组织成结构化的Markdown文档甚至可以附上截图。核心价值这确保了文档与设计稿的绝对同步任何组件更新都会在下一次生成文档时体现出来解决了设计系统文档长期滞后的痛点。4. 如何基于新架构MCP进行实践既然官方方向已转向MCP作为技术人员或乐于探索的设计师我们的实践路径也应该随之调整。以下是基于当前mcp-server-guide仓库的实践推演。4.1 环境准备与概念理解首先你需要明确自己的角色。作为使用者你的目标是未来使用Figma官方或社区发布的成熟MCP Server。目前你需要关注Figma的官方更新等待其AI功能深度集成MCP客户端。同时可以尝试运行一些开源的MCP Server示例来体验其能力。作为开发者/探索者你的目标是理解MCP协议并可能为自己或团队开发定制化的Server。这需要一些技术基础。基础环境准备Node.js 环境MCP Server 通常使用 JavaScript/TypeScript 编写需要安装 Node.js (建议 LTS 版本) 和 npm/yarn/pnpm 包管理器。Figma 访问令牌你需要一个 Figma Personal Access Token 来授权 Server 访问你的设计文件。可以在 Figma 账户设置的 “Account” 部分生成。务必妥善保管如同密码。AI 模型 API 密钥如果你想复现类似 Gemini 集成的功能需要申请相应 AI 服务如 Google AI Studio 的 Gemini或 OpenAI 的 GPT的 API 密钥。克隆示例仓库将https://github.com/figma/mcp-server-guide仓库克隆到本地这是最好的学习材料。4.2 剖析一个MCP Server的基本结构打开官方指南仓库你会看到示例 Server 的代码结构。一个最简单的 MCP Server 核心包括package.json定义项目依赖其中会包含modelcontextprotocol/sdk这个核心 SDK。server.ts或index.js主程序文件。其核心任务是实现initialize方法在连接建立时向客户端Figma AI宣告自己提供哪些“工具”Tools。每个工具都有名称、描述和参数定义。// 示例声明一个名为 extract_colors 的工具 const tools: Tool[] [ { name: extract_colors, description: 从当前Figma文件中提取所有颜色样式并生成CSS变量。, inputSchema: { type: object, properties: { format: { type: string, enum: [css, scss, tailwind], description: 输出格式 } } } } ];实现handleToolCall方法当客户端调用某个工具时执行具体的业务逻辑。这里就是集成 Figma API 和 AI 模型的地方。async function handleToolCall(request: CallToolRequest): PromiseToolResult { if (request.name extract_colors) { const fileId request.arguments?.fileId; // 上下文通常由客户端自动提供 const format request.arguments?.format || css; // 1. 使用 Figma API 获取文件样式数据 const styles await figmaApi.get(/v1/files/${fileId}/styles); // 2. (可选) 调用 AI API 对颜色进行智能分类和命名 const processedColors await aiClient.processColorStyles(styles); // 3. 根据格式生成代码 const code generateCode(processedColors, format); return { content: [{ type: text, text: code }], isError: false }; } }启动 Server使用 SDK 提供的Server类绑定标准输入输出stdio使其能够与客户端进程通信。4.3 本地运行与调试安装依赖在示例项目目录下运行npm install。配置环境变量创建.env文件填入你的FIGMA_ACCESS_TOKEN和AI_API_KEY。编译与运行如果是 TypeScript 项目先运行npm run build然后使用node dist/server.js启动 Server。它会等待客户端连接。连接测试目前你需要一个 MCP 客户端来测试。可以是用 TypeScript SDK 写一个简单的测试客户端脚本或者使用一些早期支持 MCP 的 AI 应用如 Claude Desktop在其最新版本中已支持配置本地 MCP Server。在客户端的配置中指向你本地运行的 Server 可执行文件或脚本。4.4 构建自定义技能的思路官方示例可能只提供了基础框架。你可以在此基础上发挥创意技能垂直化不一定要做大而全的“万能AI助手”。可以做一个专注于“图标管理”的Server功能包括从选中Frame中提取所有矢量图标、批量重命名、导出为SVG并打包、甚至自动上传到团队的图标CDN。集成内部系统将MCP Server作为桥梁连接Figma和你的内部系统。例如一个“发布设计评审”工具可以将当前页面截图、变更描述自动提交到内部的Jira或飞书任务一个“同步品牌资产”工具可以从内部品牌中心拉取最新的Logo和配色直接应用到Figma组件库。无AI版本并非所有工具都需要AI。很多自动化操作是确定性的。你可以构建一个纯逻辑的MCP Server例如“为所有选中图层添加‘最新’标注水印”这只需要调用Figma的API更新图层名称或添加覆盖层即可。重要提示在开发过程中务必严格遵守Figma API的速率限制并对可能修改文件内容的操作如创建、删除、修改图层实现“模拟运行”或“二次确认”机制避免因脚本错误导致设计文件损坏。5. 潜在问题、排查与未来展望在探索这项技术时你可能会遇到一些挑战。以下是一些常见问题的排查思路和对未来的思考。5.1 常见问题与排查问题Server启动失败提示权限或依赖错误。排查首先确认Node.js版本符合要求。检查package.json中的依赖是否完整安装node_modules是否存在。如果使用TypeScript确保tsconfig.json配置正确并且已成功编译dist目录有输出文件。环境变量文件.env是否在项目根目录且变量名拼写正确。问题客户端无法连接到Server或连接后看不到工具列表。排查这是MCP通信中最常见的问题。确保Server程序正在运行且没有崩溃。检查客户端配置中Server的启动命令或路径是否正确。最关键的是Server必须在initialize回调中正确返回GetToolsResult。可以在Server代码中添加详细的日志输出观察握手过程是否完成。问题调用工具时失败报错“Invalid file ID”或“Authentication error”。排查这通常是Figma API调用环节的问题。确认你的Personal Access Token是否有效且具有足够的权限需要file:read等。确认客户端如Figma AI是否正确传递了fileId参数。你可以先在Server代码中硬编码一个已知的、你有权访问的fileId进行测试以区分是参数传递问题还是令牌权限问题。问题AI模型返回的结果不符合预期或格式错误。排查AI的不确定性是天然存在的。首先检查你发送给AI模型的“提示词”Prompt是否清晰、无歧义并包含了足够的上下文如“你是一个前端专家请将颜色转换为CSS变量”。其次在Server端对AI的返回结果做一层“后处理”和“验证”至关重要。例如对于生成的代码可以用一个简单的语法校验库检查其基本格式对于提取的信息可以设置一些合理性检查如颜色值必须是6位十六进制码。5.2 安全与成本考量令牌安全Figma访问令牌是最高机密。绝对不要将其硬编码在客户端代码或公开的仓库中。Server端也应从环境变量或安全的配置服务中读取。考虑使用令牌范围限制仅授予必要权限如只读。API成本如果集成商用AI模型如GPT-4、Gemini Advanced频繁调用会产生费用。需要在Server端实现调用频率限制、缓存机制例如对同一文件同一问题的结果缓存一段时间并为用户提供用量提示。数据隐私设计文件可能包含未公开的商业信息。确保你的Server尤其是当它涉及将数据发送到外部AI API时符合公司的数据安全政策。对于敏感项目考虑使用本地部署的大模型或进行数据脱敏处理。5.3 未来展望与个人建议MCP协议为Figma的自动化生态打开了一扇新的大门。它从“一个工具”变成了“一个平台”。对于个人和团队我建议保持关注暂缓重度投入对于大多数非开发者的设计师建议保持对Figma官方AI和MCP生态进展的关注但不必急于现在就去搭建复杂的本地环境。等待官方推出更成熟、图形化的集成方案是更稳妥的选择。从小痛点开始实验对于开发者可以从解决团队内部一个非常具体、微小的痛点开始。例如写一个最简单的、不带AI的MCP Server功能就是“将选中图层的名称导出为列表”。这个过程能让你彻底弄通MCP的开发、部署和调试流程。思维转变最重要的收获不是学会了一个 deprecated 的工具而是接受了“用自然语言和意图驱动设计工具”的思维模式。即使在没有现成工具的情况下这种思维也能促使你去寻找现有的插件组合或编写脚本来解决问题。社区参与当MCP生态逐渐繁荣一定会出现像VSCode扩展市场那样的“技能市场”。积极参与社区分享你构建的Server或使用他人分享的成果将是最高效的方式。技术的迭代总是如此旧的项目被归档新的架构被推出。figma-gemini-cli-extension的使命已经完成它为我们指明了方向——让工具更智能、更人性化。而作为使用者我们的任务是将这种可能性转化为每日工作中实实在在的效率提升。从理解一个已归档项目的思想开始到在新时代的架构下找到自己的实践路径这个过程本身就是一次宝贵的学习和进化。