1. 为什么设计稿与代码之间总有一道人工翻译的墙
做前端或者全栈的朋友大概都有过这种体验：产品经理甩过来一个设计稿链接，说“就按这个做”，然后你打开一看，图层命名全是 Frame 427、Rectangle 18、Group 233，光是理清哪个图层对应哪个组件就要花掉小半天。更别提改稿阶段，设计侧微调了一个间距、换了一个圆角，你这边得手动去代码里翻对应的样式，改完还要截图比对，来回确认。这个过程中最耗时的不是写代码本身，而是“人肉解析设计稿”这个环节。
Figma 作为目前主流的界面设计工具，本身提供了插件体系和 REST API，理论上可以让机器直接读取设计稿的结构化数据。但现实情况是，很多团队用的免费版账号在 API 调用上有额度限制，或者干脆没有开放某些接口权限。于是就有了一个很实际的需求：能不能在不购买付费套餐的前提下，让本地的 AI Agent 直接读懂 Figma 设计稿，甚至反过来修改它？
Local Figma Agent MCP 就是冲着这个场景来的。它本质上是一个运行在本地的 MCP 服务，通过 Figma 桌面端提供的插件运行环境，把设计稿的节点树、样式属性、组件信息暴露给本地的 Agent 进程。Agent 拿到这些结构化数据之后，就可以做代码生成、样式比对、批量重命名、甚至反向修改设计稿的操作。整个过程不依赖 Figma 的云端付费 API，走的是本地插件通道，所以免费账号也能跑通。
这篇文章适合三类人看：一是前端开发者，想减少设计稿到代码的手动翻译成本；二是设计系统维护者，需要批量处理图层命名和组件规范；三是对 MCP 协议和 Agent 工具链感兴趣的工程师，想了解本地 Agent 如何与设计工具打通。我会从原理、环境搭建、核心操作、踩坑经验几个维度展开，尽量把每个环节的“为什么”讲清楚，让你看完能直接上手复现。
2. Local Figma Agent MCP 到底在做什么：拆解本地插件通道的工作机制
2.1 MCP 协议在这里扮演什么角色
MCP 全称 Model Context Protocol，你可以把它理解成一套“Agent 和外部工具之间的通用插头标准”。在没有这套标准之前，Agent 想调用一个外部能力，得针对每个工具单独写适配代码，今天接 Figma 写一套，明天接数据库又写一套，维护成本很高。MCP 的思路是定义统一的通信格式：Agent 侧作为客户端，工具侧作为服务端，双方通过标准化的请求和响应来交互。
Local Figma Agent MCP 就是把这个服务端跑在本地。它启动之后会监听一个本地端口，Agent 通过这个端口发送指令，比如“获取当前选中节点的属性”“列出所有文本图层的字体信息”“把某个节点的填充色改成指定值”。服务端收到指令后，转译成 Figma 插件 API 能理解的调用，执行完再把结果回传给 Agent。整个链路都在本机完成，不经过外部服务器，所以响应速度快，也不受账号套餐的 API 额度限制。
这里有个关键点需要理解：Figma 插件 API 和 Figma REST API 是两套不同的东西。REST API 是走网络的，受套餐和权限约束；插件 API 是运行在 Figma 桌面端或浏览器端插件沙箱里的，只要插件被加载，就能访问当前文档的节点树。Local Figma Agent MCP 走的是后者，所以才能绕开付费限制。当然，这也意味着它只能操作“当前打开的那个文档”，没法在后台批量处理一堆文件，这是它的能力边界。
2.2 本地插件通道的数据流转过程
把整个数据流转拆开看，大概是这么几步。第一步，你在 Figma 桌面端加载 Local Figma Agent MCP 对应的插件，插件启动后会建立一个本地通信通道，通常是一个 WebSocket 或者本地 HTTP 服务。第二步，你在本地启动 Agent 进程，它作为 MCP 客户端去连接这个通道。第三步，Agent 发送指令，插件在 Figma 沙箱内执行对应的 API 调用，拿到节点数据。第四步，数据经过序列化后回传给 Agent，Agent 再决定下一步做什么。
这个过程中最容易被忽略的是“节点树的序列化”。Figma 的节点树可能非常深，一个页面里嵌套几十层 Group 是常事。如果一次性把整棵树拉过来，数据量会很大，Agent 处理起来也慢。所以实际使用中，通常的做法是先拉顶层节点，按需展开。比如先获取当前选中的节点，或者按名称过滤出特定类型的节点，再逐层深入。这个策略和爬虫的“按需抓取”是一个道理，避免一次性加载过多无用数据。
另一个细节是样式属性的读取。Figma 里一个矩形的填充可能来自样式库、可能来自本地样式、也可能是直接设置的色值。插件 API 能区分这些来源，但 Agent 拿到数据后需要自己判断优先级。比如做代码生成时，如果填充来自共享样式，那生成的代码应该引用对应的设计令牌，而不是硬编码色值。这个判断逻辑需要在 Agent 侧实现，MCP 服务本身只负责把原始数据吐出来。
2.3 不买付费套餐能用到什么程度
免费账号在 Figma 里的限制主要是协作人数、版本历史和部分云端 API 额度。Local Figma Agent MCP 走本地插件通道，所以协作和版本历史这些限制不影响它。它能做的事情包括：读取当前文档的完整节点树、读取和修改节点属性、创建和删除节点、批量重命名、导出节点为图片或 SVG。基本上插件 API 能做的，它都能通过 Agent 来触发。
做不到的事情也要说清楚：它没法访问你没有打开的文件，没法跨文件批量操作，没法读取团队库的完整元数据（部分库信息在插件 API 里是受限的）。所以如果你的需求是“每天晚上自动扫描团队所有设计稿并生成报告”，那这个方案不合适，还是得走云端 API。但如果你的需求是“在当前打开的设计稿里，让 Agent 帮我批量改图层名、提取样式、生成组件代码”，那它完全够用。
3. 从零搭起本地 Agent 与 Figma 的通信链路
3.1 环境准备：别急着装插件，先把这几样确认好
动手之前，先把基础环境理清楚。你需要的东西不多，但每一样都有坑。首先是 Figma 桌面端，注意是桌面端不是浏览器端。虽然浏览器端也能跑插件，但本地通信通道在桌面端更稳定，而且桌面端对本地文件系统的访问权限更宽松，后续如果要导出文件会方便很多。版本方面，建议保持最新，老版本插件 API 可能有差异。
然后是 Node.js 环境。Local Figma Agent MCP 的服务端和插件构建脚本通常依赖 Node 工具链，建议用 LTS 版本，别用太新的实验版，避免依赖包兼容问题。装完之后确认 npm 或 pnpm 能正常工作。如果你习惯用 yarn 也行，但要注意锁文件的一致性，别混用。
第三样是 Agent 运行环境。这个取决于你用哪个 Agent 框架，有的用 Python，有的用 Node。关键是确认你的 Agent 支持 MCP 客户端功能。如果不支持，就得自己写一层适配，把 MCP 的请求格式转成 Agent 能理解的工具调用格式。这一步是很多人在搭建时卡住的地方，因为文档里往往默认你已经有一个支持 MCP 的 Agent 了。
最后确认一下端口占用情况。本地 MCP 服务通常会监听一个固定端口，比如 3000 或者 8080 附近的某个值。如果这个端口被其他服务占了，启动时会报错。建议提前用命令行查一下端口占用，或者直接在配置里改成一个不常用的端口，省得后面排查。
3.2 插件侧的加载与调试：为什么你的插件面板是空的
插件加载这一步，最常见的现象是“面板打开了但一片空白”或者“提示连接失败”。先说空白的情况。这通常是因为插件的 UI 线程和主线程通信出了问题。Figma 插件分两部分：一部分是运行在沙箱里的主逻辑，能访问 Figma API；另一部分是 UI 面板，运行在 iframe 里，负责展示界面。两者通过 postMessage 通信。如果 UI 面板加载了但没收到主逻辑的数据，就会空白。
排查方法是打开 Figma 的插件开发控制台，看有没有报错。常见错误包括：UI 的 HTML 文件路径写错了、构建产物没有正确输出、或者跨域限制导致 iframe 里的脚本加载失败。如果是用构建工具打包的，确认一下输出目录和插件 manifest 里配置的路径是否一致。这个坑我踩过好几次，每次都是路径问题。
连接失败的情况，多半是本地 MCP 服务没启动，或者端口对不上。插件侧一般会有一个配置项让你填本地服务的地址和端口，确认这个配置和服务端实际监听的一致。另外注意，有些系统对本地回环地址的访问有额外限制，如果填的是 localhost 不通，可以试试换成 127.0.0.1，反过来也一样。这个细节很小，但确实会卡住人。
3.3 Agent 侧的配置：把 MCP 服务注册成可用工具
Agent 侧要做的核心事情，是把 Local Figma Agent MCP 注册成一个可调用的工具。不同 Agent 框架的注册方式不一样，但思路是相通的：你需要告诉 Agent“有一个叫 figma-local 的工具，它的能力描述是什么，怎么连接它”。能力描述很重要，它决定了 Agent 在什么情况下会主动调用这个工具。描述写得太模糊，Agent 可能该调用的时候不调用；写得太宽泛，又可能在不相关的场景下乱调用。
一个实用的做法是，在工具描述里明确列出几个典型操作，比如“读取当前选中节点的属性”“按名称查找节点”“修改节点填充色”“批量重命名图层”。这样 Agent 在遇到类似需求时，更容易匹配到这个工具。同时，在 Agent 的系统提示里也可以加一句引导，比如“当用户提到设计稿、Figma、图层、组件时，优先考虑使用 figma-local 工具”。这种引导不是必须的，但实测能明显提升调用准确率。
配置完成后，先做一个最简单的连通性测试：让 Agent 调用工具获取当前选中节点的名称。如果返回了正确的名称，说明链路通了。如果报错，根据错误信息逐段排查：是 Agent 没找到工具，还是工具连不上服务，还是服务连不上插件。分段定位比整体调试效率高得多。
4. 让 Agent 真正读懂设计稿：节点解析与语义提取的实操细节
4.1 节点树的读取策略：一次性拉取还是按需展开
前面提到过，节点树可能很深，一次性拉取不现实。实际操作用的是“分层读取”策略。第一步，获取当前页面的顶层节点列表，通常数量不多，几十个以内。第二步，根据 Agent 的任务目标，决定展开哪些子树。比如任务是“找出所有按钮组件”，那就按名称或类型过滤，只展开可能是按钮的节点。第三步，对目标节点读取详细属性，包括尺寸、位置、填充、描边、圆角、字体等。
这个策略的好处是数据量可控，Agent 的处理速度快。坏处是需要多轮交互，如果 Agent 的规划能力不强，可能会漏掉一些节点。为了减少遗漏，可以在工具侧提供一个“递归查找”的接口，让 Agent 指定一个过滤条件，服务端在 Figma 沙箱内递归遍历，只返回匹配的节点。这样把遍历逻辑放在服务端，Agent 只需要发一次请求，效率更高。
过滤条件的写法很关键。Figma 节点有 type 属性，比如 FRAME、TEXT、RECTANGLE、COMPONENT、INSTANCE 等。按 type 过滤是最常用的。另外还可以按 name 做模糊匹配，按是否可见过滤，按是否有特定插件数据过滤。组合使用这些条件，能比较精准地定位到目标节点。我一般会建议在工具描述里把这些过滤能力写清楚，方便 Agent 自己组合。
4.2 样式信息的语义化：从原始属性到设计令牌
拿到节点的原始属性只是第一步，真正有价值的是把这些属性语义化。举个例子，一个矩形的填充色是 #1A73E8，这是原始数据。但如果这个色值来自一个叫“Primary/Blue/500”的共享样式，那语义就是“主色蓝 500”。Agent 在做代码生成时，应该优先使用语义化的设计令牌，而不是硬编码色值。这样后续设计令牌变更时，代码只需要改一处。
实现这个语义化，需要在读取节点属性时，同时读取它引用的样式 ID，然后再去样式表里查这个 ID 对应的名称。Figma 插件 API 提供了获取本地样式和共享样式的方法。需要注意的是，共享样式的读取在某些权限下可能受限，如果读不到，就退而求其次用本地样式，或者直接用原始值加一个标记，提示 Agent 这里可能需要人工确认。
字体信息也是类似的处理。一个文本节点的字体可能是“Inter Regular 14px”，但设计系统里可能定义的是“Body/Regular”这样的令牌。Agent 需要根据字体名称、字重、字号去匹配设计令牌表。这个匹配逻辑可以放在 Agent 侧，也可以放在 MCP 服务侧提供一个“解析样式令牌”的工具。放在服务侧的好处是复用性强，多个 Agent 都能用；放在 Agent 侧的好处是灵活，可以根据不同项目的令牌规范调整。
4.3 组件与实例的识别：区分主组件和派生实例
Figma 里组件和实例的关系，类似于面向对象里的类和对象。主组件定义结构和默认样式，实例继承主组件但可以覆盖部分属性。Agent 在处理设计稿时，必须能区分这两者，否则生成的代码会出问题。比如一个按钮的主组件改了圆角，所有实例都会跟着变；但如果某个实例单独覆盖了圆角，那它就不受主组件影响。
读取节点时，INSTANCE 类型的节点会有一个 componentId 指向主组件。Agent 可以通过这个 ID 去获取主组件的属性，然后对比实例的覆盖属性，判断哪些是继承的、哪些是覆盖的。这个信息对代码生成很重要：继承的属性可以抽成公共样式，覆盖的属性需要单独处理。如果 Agent 不区分这些，生成的代码就会把所有属性都写死，失去组件化的意义。
另外，组件的命名规范也影响 Agent 的理解。如果主组件叫“Button/Primary/Large”，Agent 很容易推断出这是一个大号主按钮。如果叫“Frame 427”，那就只能靠属性推断，准确率会下降。所以我在实际项目中会建议设计侧尽量规范命名，这不仅对人友好，对 Agent 也友好。如果命名已经乱了，可以先让 Agent 做一轮批量重命名，把命名规范起来，再去做后续的代码生成。
5. 反向操作：让 Agent 修改设计稿的边界与注意事项
5.1 哪些修改是安全的，哪些容易出问题
让 Agent 修改设计稿，听起来很美好，但实际操作中要区分场景。安全的修改包括：批量重命名图层、统一修改填充色或描边色、调整间距和圆角、替换文本内容、显示或隐藏特定图层。这些操作的影响范围明确，出错了也容易回滚。不安全的修改包括：删除节点、改变节点层级结构、替换主组件、修改自动布局的关键参数。这些操作一旦出错，可能破坏整个设计稿的结构，恢复起来很麻烦。
我的建议是，在让 Agent 做任何修改之前，先手动保存一个版本，或者复制一份文档出来操作。Figma 的版本历史在免费版里有限制，别指望靠它回滚。复制文档是最稳妥的，改坏了直接删掉副本就行。另外，修改操作最好分批进行，改完一批检查一批，别一次性让 Agent 跑完所有修改，出了问题都不知道是哪一步导致的。
还有一个细节是自动布局。Figma 的自动布局（Auto Layout）有一套自己的约束逻辑，Agent 修改子节点尺寸或间距时，可能会触发自动布局的重新计算，导致意料之外的位移。如果设计稿大量使用自动布局，建议 Agent 在修改前先读取布局配置，修改后验证布局是否还符合预期。这个验证步骤不能省，否则改完一看全乱了。
5.2 批量重命名的实战策略
批量重命名是 Agent 修改设计稿里最高频、也最实用的操作。一个典型场景是：设计稿从其他工具导入，图层名全是默认的“Rectangle 1”“Group 2”，需要按规范重命名。Agent 可以根据节点的类型、尺寸、位置、内容来推断合理的名称。比如一个 375x812 的 Frame 可能是手机屏幕，一个包含文本且宽度较小的节点可能是按钮。
具体策略可以分几步。第一步，按类型分组，FRAME 归 FRAME，TEXT 归 TEXT，COMPONENT 归 COMPONENT。第二步，对每组内的节点，根据尺寸和位置排序，推断层级关系。第三步，结合文本内容或已有命名，生成候选名称。第四步，批量应用重命名，并输出一份变更日志，方便人工复核。这个流程里，变更日志很重要，因为 Agent 的推断不可能百分之百准确，人工复核是必要的兜底。
重命名时还要注意命名冲突。如果两个节点被推断成同一个名称，后续引用会出问题。解决办法是在名称后加序号，或者用更细粒度的特征来区分。比如两个都是按钮，一个宽度 120，一个宽度 200，可以命名为“Button/Small”和“Button/Large”。这个逻辑可以在 Agent 侧实现，也可以做成 MCP 服务的一个工具，让 Agent 调用。
5.3 修改后的验证：怎么确认 Agent 没把设计稿改坏
修改完成后的验证环节，很多人会忽略，但它恰恰是最重要的。验证分两个层面：结构验证和视觉验证。结构验证是检查节点树是否完整，有没有节点丢失，层级关系是否还正确。这个可以通过对比修改前后的节点数量和层级深度来快速判断。如果修改前有 500 个节点，修改后只剩 480 个，那肯定有问题，得排查哪里丢了。
视觉验证是导出修改后的关键页面截图，和修改前的截图做比对。如果只是重命名，视觉上应该完全一致；如果有样式修改，视觉差异应该符合预期。这个比对可以人工做，也可以让 Agent 做。Agent 做的话，需要能读取图片并做像素级或结构级比对。像素级比对对渲染差异很敏感，结构级比对更实用，比如比对两个截图的布局网格是否一致。
我自己的习惯是，每次让 Agent 做批量修改后，都会让它输出一份“修改摘要”，包括修改了哪些节点、改了什么、预期效果是什么。然后我拿着这份摘要去抽查几个关键节点，确认无误后再继续下一步。这个习惯帮我避免了好几次潜在的事故，尤其是涉及组件和自动布局的修改。
6. 踩坑记录：那些文档里不会写的实际问题
6.1 插件沙箱的权限限制与绕行思路
Figma 插件沙箱对某些 API 的调用是有限制的，比如网络请求、本地文件系统访问、部分跨文档操作。Local Figma Agent MCP 走本地通信通道，本身不涉及网络请求，所以网络限制不影响它。但文件系统访问受限会影响导出功能。如果你想让 Agent 把设计稿导出成图片或 SVG 并保存到本地，插件沙箱可能不允许直接写文件。
绕行思路是：插件侧把导出的数据通过本地通道传给 MCP 服务，由服务侧负责写文件。服务侧运行在 Node 环境里，没有沙箱限制，可以自由读写本地文件。这个分工很关键：插件负责和 Figma 交互，服务负责和本地系统交互，Agent 负责决策和调度。三层各司其职，边界清晰，出问题也容易定位是哪一层的毛病。
另一个权限限制是跨文档操作。插件只能访问当前打开的文档，没法在后台打开另一个文档并操作它。如果你的需求涉及多个文档，只能手动切换，或者用 Figma 的 REST API（但那就回到付费额度的问题了）。这个限制目前没有太好的绕行方案，只能接受。所以在规划任务时，尽量把同一文档的操作集中在一起，减少切换成本。
6.2 大文档下的性能瓶颈与优化
设计稿节点数量超过几千个时，性能问题会很明显。插件 API 的调用本身有开销，每次读取节点属性都要跨沙箱边界，累积起来很慢。如果 Agent 还在一轮轮地发请求，整体耗时可能从几秒变成几分钟。优化思路有几个：一是减少请求次数，把多个读取操作合并成一个批量请求；二是缓存已读取的节点数据，避免重复读取；三是限制遍历深度，非必要不展开深层子树。
批量请求的实现方式，是在 MCP 服务侧提供一个“批量读取”接口，接受一个节点 ID 列表，一次性返回所有节点的属性。这样 Agent 只需要发一次请求，服务侧在 Figma 沙箱内循环读取，虽然总开销差不多，但省去了多次通信的往返时间。实测下来，批量读取比逐个读取能快三到五倍，节点越多差距越明显。
缓存策略也要注意失效问题。如果 Agent 读取了节点数据，然后修改了某个节点，缓存里的数据就过期了。简单的做法是修改后清空相关节点的缓存，或者干脆每次修改后重新读取。复杂一点的做法是维护一个版本号，每次修改递增，读取时检查版本号决定是否用缓存。这个看具体场景，如果修改不频繁，简单清空就够了。
6.3 Agent 误操作后的回滚方案
Agent 误操作是难免的，关键是怎么快速回滚。前面说过，最稳妥的方式是操作前复制文档。但复制文档有个问题：复制出来的文档和原文档是独立的，Agent 操作的是副本，你确认无误后还得把改动同步回原文档。如果改动很多，同步本身也是工作量。所以这个方案适合改动量大、风险高的场景，日常小改动没必要这么重。
轻量级的回滚方案是利用 Figma 的撤销功能。插件 API 触发的修改，在 Figma 里是可以撤销的，只要在同一个会话里。所以如果 Agent 改错了，立刻在 Figma 里按撤销快捷键，通常能恢复。但要注意，撤销栈有深度限制，如果 Agent 连续做了很多步修改，可能撤不回去。所以还是建议分批操作，每批做完确认一下，确认无误再继续。
还有一个兜底方案是让 Agent 在修改前先记录原始值。比如要改一个节点的填充色，先读取当前色值存下来，修改后如果发现问题，可以用存下来的原始值改回去。这个方案需要 Agent 有“记录-修改-回滚”的完整逻辑，实现起来稍微复杂，但对关键操作很值得。我一般会在涉及组件和布局的修改上用这个方案，普通的重命名和样式微调就不必了。
7. 把 Agent 接入日常设计开发流程的几种玩法
7.1 设计稿转代码：从节点树到组件代码的映射
这是最直接的玩法。Agent 读取设计稿的节点树，识别出组件和布局，生成对应的前端代码。映射规则可以自定义，比如 FRAME 映射成 div，TEXT 映射成 span 或 p，INSTANCE 映射成组件引用。样式方面，填充色映射成 background-color，描边映射成 border，圆角映射成 border-radius，自动布局映射成 flex 或 grid。
这个过程中最麻烦的是布局推断。Figma 的自动布局和 CSS 的 flex 不是一一对应的，有些自动布局的配置在 CSS 里需要额外的处理。比如 Figma 里的“间距自动”在 CSS 里可能是 gap，也可能是 margin，取决于具体场景。Agent 需要根据节点的实际布局结果来反推最合适的 CSS 写法，而不是机械地翻译属性。这个推断逻辑需要一些启发式规则，准确率不可能百分之百，但能省掉大部分手动工作。
生成的代码质量还取决于设计稿的规范程度。如果设计稿用了规范的组件和命名，生成的代码结构会很清晰；如果全是散乱的 Frame 和 Rectangle，生成的代码就是一堆嵌套 div，可读性很差。所以这个玩法的前提是设计稿本身有一定的规范性。如果设计稿不规范，可以先做一轮规范化处理，再生成代码。
7.2 设计规范检查：让 Agent 当你的设计 lint 工具
设计稿里经常会出现不规范的地方：用了不在设计系统里的色值、字体大小不在预设范围内、间距不是 4 的倍数、组件实例被解绑了等等。这些检查人工做很费时，让 Agent 做就很合适。Agent 遍历节点树，对每个节点检查预设的规则，输出违规列表。规则可以配置，比如“所有填充色必须来自共享样式”“所有字号必须是 12/14/16/20/24 之一”“所有间距必须是 4 的倍数”。
这个玩法的价值在于，它把设计规范的执行从“事后人工检查”变成了“随时自动检查”。设计侧改完稿，跑一下 Agent，立刻知道哪里不合规，改完再跑，直到通过。这比等到开发阶段才发现问题要高效得多。而且规则可以随设计系统演进不断更新，Agent 的检查逻辑也跟着更新，保持一致性。
实现上，检查规则可以写成配置文件，Agent 读取配置后逐条执行。每条规则对应一个检查函数，输入是节点属性，输出是是否通过和违规详情。这个架构很灵活，新增规则只需要加一个函数和一条配置。我见过一些团队把这种检查集成到 CI 里，设计稿更新后自动跑，结果发到群里，效果不错。
7.3 设计稿差异比对：改版前后的自动化 diff
产品迭代时，设计稿经常改版。改版前后有哪些差异，人工比对很费眼。Agent 可以做自动化 diff：读取两个版本的节点树，按节点 ID 或名称匹配，找出新增、删除、修改的节点，输出差异报告。这个报告可以细化到属性级别，比如“按钮的主色从 #1A73E8 改成了 #1B74E9”“卡片圆角从 8px 改成了 12px”。
这个玩法的难点在于节点匹配。如果改版时节点 ID 变了，就得靠名称和位置来匹配，准确率会下降。所以最好在设计侧约定，改版时尽量保留节点 ID，或者至少保留名称。如果做不到，Agent 的 diff 结果就需要人工复核，但即便如此，也比纯人工比对快很多。
差异报告的输出格式可以很灵活，简单的就是文本列表，复杂点的可以生成 HTML 报告，带截图对比。截图对比需要导出节点图片，然后并排展示。这个在 MCP 服务侧实现比较方便，因为服务侧可以写文件，生成 HTML 报告后直接在浏览器打开看。我一般会生成一个简单的 HTML，左边是改前截图，右边是改后截图，下面列出属性差异，一目了然。
8. 关于这套方案的能力边界与后续扩展方向
用了一段时间下来，我的整体感受是：Local Figma Agent MCP 这套方案在“单文档、中等规模、规范化设计稿”的场景下表现很好，能实实在在省掉大量重复劳动。但它不是万能的，跨文档批量处理、超大文档的性能、非规范设计稿的理解准确率，这些方面还有明显的天花板。所以我的建议是，先在小范围试点，跑通一个具体场景，比如“批量重命名”或“设计规范检查”，确认效果后再逐步扩大使用范围。
扩展方向上，我觉得有几个值得探索的点。一是把 MCP 服务和 CI 流程结合，设计稿更新后自动跑检查和 diff，结果推送到协作工具。二是把 Agent 的修改能力做成“建议模式”，Agent 只输出修改建议，人工确认后再执行，降低误操作风险。三是积累一套针对自己团队设计系统的规则库和提示词模板，让 Agent 的理解准确率随着使用不断优化。这些方向都不需要额外的付费成本，靠本地工具链就能实现。
最后说一个实际体会：这套方案的价值不在于“完全替代人工”，而在于“把人工从重复劳动里解放出来”。Agent 做批量处理，人做关键决策和复核，这个分工目前是最务实的。指望 Agent 全自动搞定一切，现阶段还不现实，但让它承担百分之七八十的机械工作，完全可行。我在实际项目里就是这么用的，效率提升很明显，而且随着规则和提示词的积累，Agent 的表现会越来越好。
