用途：帮助开发者在为 Figma 做集成时，在三种架构方案之间做选择，并理解各自使用的 API、托管方式与适用场景。
主要能力：资料给出三种方案。Variant A 为 CLI 脚本，使用 REST API，适合设计令牌同步、图标导出、同步到代码，无需托管，可本地或 CI 运行，优点是零基础设施、易调试，缺点是非实时、需手动触发。Variant B 为 Webhook 服务，使用 REST API，适合文件保存后自动同步、Slack 通知、触发构建，需要服务器或无服务器托管与 HTTPS 端点，优点是实时、事件驱动，缺点是需要托管与 webhook 管理。Variant C 为 Figma 插件，使用 Plugin API，适合编辑器内的设计检查、组件生成、数据填充，运行在 Figma 桌面应用中，优点是可直接访问文档、即时反馈，缺点是仅限桌面端、沙箱受限、无服务端处理。
使用方式：资料提供决策矩阵，从实时性、基础设施、CI/CD 集成、用户交互、所用 API、是否修改文件、是否需要 Figma 应用、认证方式等维度对比。认证方面 CLI 与 Webhook 使用 PAT，Webhook 另需 passcode，插件无需认证。资料还给出混合架构思路：CLI 做定时令牌同步，Webhook 做实时通知，插件做编辑器内检查。
限制与错误处理：CLI 过慢可用 depth=1 与 /nodes；Webhook 不触发通常是缺少 HTTPS；插件沙箱限制重计算可转由 UI iframe 调用 REST API；避免过度设计，可从 CLI 起步。资料包含本地冒烟测试命令：curl -s -X POST localhost:3000/figma/webhook -H 'Content-Type: application/json' -d '{"event_type":"PING","passcode":"test-passcode"}'。具体实现细节见各 variant 参考文档。