Figma插件驱动的设计系统自动化工程实践

1. 项目概述：这不是又一个“AI+设计”的概念秀，而是一套能跑通的工程闭环

“AI 设计助手：从 Figma 插件到设计系统自动生成的工程实践”——这个标题里没有虚词，每个短语都对应一个真实、可交付、可验证的技术动作。“AI 设计助手”不是指调用某个大模型API吐出几张图，而是指在设计工作流中嵌入具备上下文理解与决策能力的智能体；“Figma 插件”是落地入口，意味着它必须通过 Figma 官方 Plugin API 审核，能在真实设计师的 Sketchbook 里稳定运行；“设计系统自动生成”不是生成几套颜色变量或字体样式，而是从高保真页面稿出发，自动识别组件边界、提取原子级结构、推断语义层级、校验约束规则，并输出可被前端工程直接 consume 的 JSON Schema + TypeScript 类型定义 + Storybook 可视化文档；最后的“工程实践”三个字是全文锚点——它拒绝 PPT 架构图，只谈 CI/CD 流水线里怎么跑通 lint、怎么触发版本 bump、怎么让设计师改一个按钮圆角，前端仓库就自动同步更新所有引用处的 CSS 变量和 React 组件 props。

我带团队在某跨平台产品线实操了整整14个月，从第一个能识别按钮文字的原型插件，到最后上线支持 23 个核心业务模块的设计系统自动化流水线。过程中踩过最深的坑不是模型不准，而是 Figma 节点树解析时遇到的“不可见但占位”的 group 节点、设计师随手拖拽导致的嵌套深度爆炸、以及当 AI 推断出“这是一个搜索框”但实际代码里它叫 SearchInputV2 的命名鸿沟。这些细节不会出现在任何技术白皮书里，但它们决定了这套方案是停留在 Demo 阶段，还是真正进入产研协同主干道。如果你正在评估是否要启动类似项目，或者已经卡在“识别不准”“输出不一致”“设计师不买账”这些节点上，这篇内容就是为你写的——它不讲大模型原理，只讲怎么让 AI 在 Figma 里不掉链子，在 Git 里不冲突，在 PR 里被前端工程师点“Approve”。

2. 整体架构设计：为什么必须放弃“端到端大模型”幻想，转而构建三层协同引擎

2.1 核心矛盾：设计语言的模糊性 vs 工程系统的确定性

很多团队一上来就想用多模态大模型（比如 Qwen-VL 或 LLaVA）直接“看图识组件”，结果在内部测试中准确率卡在 68% 就再也上不去。根本原因在于：设计稿是意图表达的中间产物，而非规范本身。同一个“用户头像区域”，设计师可能画成圆形 mask + 图片叠加，也可能用 SVG clipPath 实现，还可能只是两个矩形叠在一起加阴影模拟——三者视觉效果几乎一致，但底层 DOM 结构、CSS 属性、可访问性标签完全不同。大模型擅长的是“相似性匹配”，而工程落地需要的是“结构等价性判定”。强行用一个黑盒模型覆盖全部环节，等于把语义理解、结构解析、规则校验、代码生成全压在一个模块上，一旦某环出错，整个链路就不可调试、不可回滚、不可解释。

我们最终放弃单一大模型路径，转而构建感知层-推理层-执行层三层协同架构。这不是为了炫技，而是每层解决一类明确问题，且各层输出均可验证、可替换、可灰度：

• 感知层（Perception Layer）：专注“看见什么”。不追求语义理解，只做高精度视觉结构解析。输入是 Figma 节点树（Node Tree），输出是带几何属性（x/y/width/height）、样式属性（fill、stroke、fontSize）、文本内容（characters）、嵌套关系（children）的标准化 JSON。这里我们没用任何外部模型，而是基于 Figma Plugin SDK 的figma.currentPage.selection和figma.currentPage.findAll()原生 API，配合自研的 Layout Analyzer 模块——它用改进的“最小包围矩形聚类算法”处理浮动布局，用“文本行基线对齐检测”区分标题与正文，用“阴影扩散半径阈值判别”识别卡片容器。实测下来，对主流设计稿的节点结构还原准确率达 99.2%，比调用任何视觉大模型都稳，且毫秒级响应。

• 推理层（Reasoning Layer）：专注“理解为什么”。输入是感知层输出的结构化 JSON，输出是带语义标签（semanticType）、角色定义（role）、约束规则（constraints）的 Component Spec。这才是真正需要 AI 的地方，但不是端到端生成，而是作为“规则增强器”存在。我们训练了一个轻量级的 Graph Neural Network（GNN），输入是节点间的空间关系图（Spatial Graph）和样式相似性图（Style Graph），输出每个节点的候选语义类型概率分布。关键创新在于：我们不直接预测“Button”或“Card”，而是预测一组基础原子语义（如 isInteractive、hasBorder、containsText、supportsHover），再通过预置的 Design System Rule Engine 进行逻辑组合。例如：isInteractive && containsText && hasBorder == true→ 推理为 PrimaryButton；isInteractive && !containsText && hasShadow == true→ 推理为 IconButton。这样做的好处是，当设计师新增一种“带图标文字的悬浮按钮”时，只需在 Rule Engine 里加一条新规则，无需重新训练模型。

• 执行层（Execution Layer）：专注“做成什么样”。输入是推理层输出的 Component Spec，输出是可直接集成的工程资产。这里完全脱离 AI，全部由确定性代码驱动：JSON Schema 生成器根据 semanticType 映射预设字段模板；TypeScript 类型定义器按原子语义组合 interface；Storybook MDX 文件渲染器将 constraints 转为交互式控件；CSS 变量导出器按 design token 分类写入 :root。所有生成逻辑都封装为独立 npm 包，可通过 CLI 直接调用，也可嵌入 Figma 插件的onRun回调中。

提示：三层解耦的最大收益是故障隔离。某次线上发布后，前端反馈 Button 组件的 disabled 状态样式丢失。我们立刻定位到是执行层的 CSS 变量映射表漏配了--button-disabled-opacity字段，而非去怀疑 GNN 模型是否误判了按钮类型——问题修复从“可能要重训模型”压缩到“改一行配置，CI 自动发布”。

2.2 为什么 Figma 插件必须是“轻客户端+重服务”模式

Figma Plugin 的运行环境有硬性限制：内存上限 512MB，主线程执行超时 30 秒，无法访问本地文件系统，不能建立长连接。这意味着所有重计算（如 GNN 推理、复杂规则匹配）绝不能放在插件前端。但我们也没选择纯云端方案——那样会导致每次点击“生成”都要等待网络往返，设计师体验断层。

最终采用“轻客户端+重服务”混合模式：

• 插件前端只做三件事：① 获取当前选中节点的精简快照（仅保留必要属性，体积控制在 200KB 内）；② 调用本地缓存的 Rule Engine 做初步过滤（如快速排除明显非组件的装饰线条）；③ 将快照加密后发往私有推理服务。

• 私有推理服务部署在公司内网 Kubernetes 集群，GPU 资源独占，模型加载后常驻内存。收到请求后，先做一致性校验（检查节点 ID 是否在当前文档中存在），再交由 GNN 推理，最后经 Rule Engine 合并输出。平均响应时间 1.7 秒（P95 < 2.3 秒），远低于 Figma 的 30 秒超时阈值。

• 关键设计：插件前端内置“离线降级策略”。当网络异常或服务不可达时，自动切换至本地缓存的轻量规则集（约 3MB），仅支持基础组件识别（Button/Card/TextInput），但保证核心功能不中断。设计师不会看到报错弹窗，只会发现“高级组件如 DataGrid、Stepper 暂不可用”，体验平滑。

这种架构让插件体积始终控制在 1.2MB 以内（Figma 审核硬限 5MB），且通过了所有安全扫描——因为所有敏感数据（设计稿结构）在传输前已脱敏（移除所有 text.characters 原始内容，仅保留字符长度和字体族），密钥由 Figma OAuth Token 动态派生，单次有效。

3. 核心细节解析：Figma 节点树解析、语义推理、设计系统输出的实操要点

3.1 Figma 节点树解析：如何绕过 Figma 的“伪隐藏”陷阱

Figma 的节点树看似简单，实则布满陷阱。最典型的是“伪隐藏节点”：设计师为对齐参考创建的辅助线（Guides）、锁定图层（locked layers）、甚至某些插件遗留的空 group。它们在 UI 上不可见，但在figma.currentPage.findAll()返回的节点列表中真实存在，且visible属性可能为true（因为 Figma 认为“未被显式隐藏即可见”）。如果直接遍历所有节点，会拿到大量噪声，导致后续推理层输入失真。

我们的解决方案是构建四维可见性判定矩阵，仅保留同时满足以下四条件的节点：

1. 显式可见性：node.visible === true
2. 非辅助元素：node.type !== 'SLICE' && node.type !== 'GUIDE' && node.type !== 'CONNECTOR'
3. 有实际渲染内容：对文本节点校验node.characters.length > 0；对图形节点校验(node.fills?.length || 0) + (node.strokes?.length || 0) > 0；对容器节点递归校验至少一个子节点满足前两条
4. 非空几何体：node.width > 1 && node.height > 1（过滤掉 1px 分割线等）

注意：第3条“有实际渲染内容”的实现有讲究。早期我们用node.visible && node.opacity > 0判断，结果发现设计师常用 opacity=0 做动画占位，这类节点必须剔除。后来改为直接检测渲染属性是否存在，更可靠。

另一个深坑是嵌套深度失控。设计师习惯用 group 套 group 实现视觉分组，一个“用户信息卡片”可能嵌套 8 层 group，而真正承载语义的 Text/Rectangle 节点藏在最底层。Figma Plugin SDK 对深层递归有限制（默认栈深度 10），暴力遍历必崩溃。我们改用迭代式广度优先遍历（BFS），并设置最大嵌套深度阈值（默认 6，可配置）。超过阈值的节点标记为isDeepNested: true，在推理层会被降权处理——它的语义权重只有普通节点的 30%，避免因结构混乱导致误判。

实操中，我们封装了cleanNodeTree()工具函数，输入原始节点数组，输出净化后的扁平化节点列表（含 parent-child 映射关系）。该函数在插件启动时预热，确保首次点击“生成”无延迟。

3.2 语义推理：GNN 模型训练与 Rule Engine 规则编排的实战技巧

我们的 GNN 模型并非从零训练，而是基于 PyTorch Geometric 框架，以 Figma 节点为图节点（Node），节点间空间关系（相邻、包含、对齐）为边（Edge），构建异构图结构。输入特征包括：

• 几何特征：[x, y, width, height, aspectRatio, area]（归一化到 0~1）
• 样式特征：[fillOpacity, strokeWeight, fontSize, fontWeight]（one-hot 编码）
• 文本特征：[charLength, isAllCaps, hasPunctuation]（仅文本节点）
• 关系特征：边类型（CONTAINS / ADJACENT / ALIGNED_LEFT / ALIGNED_TOP）

模型输出是 128 维原子语义向量，每个维度对应一个基础语义（如isInteractive:0.92,hasBorder:0.87,containsIcon:0.43）。训练数据来自 327 个真实项目的设计稿，由 5 名资深 UI 工程师人工标注——注意，他们标注的不是“这是什么组件”，而是“这个节点具备哪些原子特性”。这种标注方式成本低（每人每天可标 200+ 节点），且与下游 Rule Engine 天然契合。

Rule Engine 是纯 JSON 配置驱动，示例如下：

{ "rules": [ { "id": "primary-button", "conditions": [ {"atomic": "isInteractive", "op": ">=", "value": 0.8}, {"atomic": "containsText", "op": ">=", "value": 0.7}, {"atomic": "hasBorder", "op": ">=", "value": 0.9} ], "output": { "semanticType": "Button", "role": "primary", "constraints": { "minWidth": "120px", "padding": "0 24px", "borderRadius": "8px" } } } ] }

实操心得：规则编写有两大禁忌。第一，禁止使用绝对数值阈值。比如{"atomic": "fontSize", "op": ">=", "value": 16}—— 设计师可能用 15.8px 或 16.2px，微小浮动就会导致规则失效。正确做法是用相对排名，如{"atomic": "fontSize", "op": "isMaxInGroup", "value": true}。第二，避免规则间逻辑重叠。曾有团队写了一条isInteractive && hasShadow识别 Card，又写了一条isInteractive && hasBorder识别 Button，结果当设计师给按钮加阴影时，两个规则同时命中，输出冲突。我们强制要求所有规则 condition 数组必须满足“互斥性校验”，CI 流水线中加入规则冲突检测脚本，发现重叠即阻断发布。

3.3 设计系统输出：从 Component Spec 到可交付资产的完整链条

推理层输出的 Component Spec 是一个结构严谨的 JSON 对象，示例如下：

{ "id": "btn-primary-001", "name": "Primary Button", "semanticType": "Button", "role": "primary", "constraints": { "minWidth": "120px", "padding": "0 24px", "borderRadius": "8px", "states": ["default", "hover", "disabled"] }, "tokens": { "color": {"background": "blue-600", "text": "white", "border": "blue-700"}, "spacing": {"padding": "0 24px"}, "radius": {"border": "8px"} }, "props": [ {"name": "children", "type": "ReactNode", "required": true}, {"name": "onClick", "type": "() => void", "required": false}, {"name": "disabled", "type": "boolean", "required": false} ] }

执行层据此生成四类资产：

1. JSON Schema：用于校验设计系统文档完整性。Schema 自动生成器按semanticType映射模板，如 Button 模板固定包含constraints.states和props字段，缺失即报错。

2. TypeScript 类型定义：types/Button.ts文件，内容为：

   export interface PrimaryButtonProps { children: ReactNode; onClick?: () => void; disabled?: boolean; }

3. Storybook MDX 文档：stories/Button.stories.mdx，自动渲染交互式控件，constraints.states转为 Canvas Controls，tokens.color转为 Theme Selector。

4. CSS 变量文件：tokens/button.css，内容为：

   :root { --button-primary-bg: #2563eb; --button-primary-text: #ffffff; --button-primary-border: #1d4ed8; --button-primary-padding: 0 24px; --button-primary-radius: 8px; }

关键细节：CSS 变量命名必须与设计系统 token 命名空间强绑定。我们约定所有变量前缀为--{system}-{category}-{token}，如--core-color-blue-600。这样前端工程师在 CSS 中写background: var(--button-primary-bg)时，编辑器能自动提示，且构建工具（如 PostCSS）可精准替换为最终值，避免硬编码。

注意：Token 同步是高频痛点。设计师在 Figma 中修改blue-600值，必须实时同步到前端 token 文件。我们没用第三方同步工具，而是让插件在生成时，自动读取 Figma 变量（Figma Variables API），对比本地tokens/core.json，生成差异 patch 并提交 PR。PR 描述自动生成：“Sync Figma variables: blue-600 from #3b82f6 to #2563eb”，前端工程师一眼可知变更影响。

4. 实操过程：从插件开发、模型训练到 CI/CD 流水线落地的全流程记录

4.1 Figma 插件开发：如何通过官方审核并保障长期稳定性

Figma 插件审核最常被拒的原因不是功能缺陷，而是权限滥用和用户体验违规。我们踩过的坑与应对方案如下：

• 权限最小化原则：插件 manifest.json 中只申请必需权限。例如，不需要访问所有页面，就只申请"api": ["figma.currentPage"]；不需要读取字体，就不申请"font"权限。曾因误加"fileSystem"权限被拒，Figma 明确表示 Plugin 不得访问本地磁盘。

• UI 符合设计规范：Figma 强制要求插件 UI 使用其官方 UI Kit（Figma UI Kit for Plugins）。我们用 Figma 官方提供的 React 组件库（@figma/ui），所有按钮、输入框、模态框均严格遵循其尺寸、间距、动效。特别注意：禁用任何自定义滚动条、禁用position: fixed、禁用transform: scale()——这些都会导致审核失败。

• 错误处理无弹窗：Figma 禁止插件主动弹出浏览器 alert 或自定义 modal。所有错误必须内嵌在插件面板中，用figma.notify()显示轻量提示（如figma.notify('生成失败：请检查网络连接', {timeout: 3000})），且提供明确操作指引（如“点击重试”按钮）。

插件发布后，稳定性保障靠三件事：

1. 版本语义化：插件版本号与设计系统版本号绑定，如v2.3.1对应DesignSystem@2.3.0。Figma 控制台可配置自动更新策略，我们设为“仅补丁更新自动安装（x.x.1→x.x.2），次要更新需手动确认（x.2.x→x.3.x）”，避免破坏性变更影响设计师工作流。

2. 运行时健康检查：插件启动时，自动调用figma.clientStorage.getAsync('health')检查上次运行状态。若发现异常退出（如未完成生成流程），则在面板顶部显示黄色警示条：“检测到上次异常，已恢复缓存状态”，并提供“清除缓存”按钮。

3. 日志脱敏上传：开启可选日志上报（需用户授权），但所有日志在上传前经过去标识化处理：移除节点 ID、文档 ID、用户 ID，仅保留操作类型（generate_start）、耗时（duration_ms: 1742）、错误码（error_code: NODE_PARSE_FAILED）。日志用于优化性能，绝不用于追踪用户行为。

4.2 GNN 模型训练：数据采集、标注、验证的工业级实践

模型效果不取决于参数量，而取决于数据质量闭环。我们的数据管道如下：

• 数据采集：每周从设计系统仓库拉取最新 Figma 文件（.fig），用自研 CLI 工具figma-extractor解析出所有页面的节点树快照，保存为snapshot_20240520.json。工具自动过滤掉草稿页（page.name.includes('draft')）、演示页（page.name.includes('demo')），确保数据纯净。

• 标注流程：标注任务发布到内部标注平台，5 名标注员组成小组。每人每天标注上限 200 节点，超量自动锁止。标注界面强制要求：① 必须选择至少 3 个原子语义；② 若节点为文本，必须填写charLength和isAllCaps；③ 所有选择需点击“确认”按钮才生效，防止误触。

• 验证机制：每批标注数据（1000 节点）进入训练前，先由 QA 团队抽样 10% 进行交叉验证。若同一节点 3 人标注结果差异 >2 个原子语义，则整批数据返工。实测标注一致性达 94.7%（Cohen's Kappa = 0.89），远高于行业平均 72%。

训练过程采用两阶段策略：

• 第一阶段（冷启动）：用 5000 个标注样本训练初始模型，学习基础空间关系。此时准确率约 76%，但能稳定识别 Button/Card/TextInput。

• 第二阶段（在线学习）：插件上线后，收集设计师点击“生成”但人工修正的案例（需用户授权）。每周汇总 200~300 个修正样本，加入训练集微调模型。微调时冻结底层 GNN 层，只训练顶层分类头，避免灾难性遗忘。14 个月累计微调 22 次，最终原子语义预测准确率提升至 91.3%（P95）。

实操心得：不要迷信“标注越多越好”。我们发现，当标注样本超过 8000 个后，准确率提升趋缓，但标注成本指数上升。真正有效的提升来自高质量难例挖掘。例如，专门收集“设计师认为是按钮但模型判为文本”的 200 个案例，针对性优化isInteractive特征提取逻辑，一次微调就让该类错误下降 63%。

4.3 CI/CD 流水线：如何让设计系统变更自动触发前端构建与发布

设计系统自动化的核心价值，是让“设计变更”成为前端工程的第一类事件。我们的 CI/CD 流水线完全打通 Figma、Git、NPM、Storybook：

1. 触发源：Figma 插件生成设计系统资产后，自动调用 GitHub REST API 创建 PR，目标分支为design-system/main。PR 标题格式为[DS-AUTO] Update Button tokens and types，描述中嵌入变更摘要（diff 链接、影响范围）。

2. CI 流程（GitHub Actions）：

   • lint：校验 JSON Schema 是否符合规范，TypeScript 类型是否可编译
   • test：运行 Storybook Chromatic 视觉回归测试，比对新旧组件渲染差异
   • build：打包@company/design-systemnpm 包，生成 ESM/CJS 两种格式
   • publish：若 PR 合并到main，自动发布新版本（如v3.2.1），并打 Git Tag

3. 前端联动：前端仓库配置 Dependabot，监控@company/design-system版本。新版本发布后，自动创建升级 PR，其中包含：①package.json版本更新；②yarn.lock锁定；③ 自动修复脚本（如将className="btn-primary"替换为<Button variant="primary">）。

关键设计：版本兼容性保障。我们约定：

• 补丁版本（x.x.1→x.x.2）：仅允许 token 值变更、文档更新，API 不变
• 次要版本（x.2.x→x.3.x）：允许新增组件、新增 props，但不得删除或修改现有 API
• 主要版本（2.x.x→3.x.x）：允许破坏性变更，但必须提供 codemod 脚本自动迁移

这样，前端工程师看到v3.2.1的升级 PR，可放心合并；看到v3.3.0，则知道需人工检查新增功能；看到v4.0.0，则运行npx @company/codemod@4.0.0即可完成 90% 迁移。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “为什么我的按钮总被识别成文本？”——解析深度不足的典型表现

现象：设计师选中一个按钮，插件生成结果却是{"semanticType": "Text", "role": "heading"}。

排查路径：

1. 检查节点层级：在 Figma 中右键节点 → “Show Layers Panel”，确认该按钮是否被包裹在过多 group 中。若嵌套 >4 层，GNN 的空间关系建模会失真。
2. 查看节点属性：选中节点，打开右侧面板，检查Fills是否为空（设计师可能只加了 Stroke 未加 Fill，导致hasFill: false，模型降低isInteractive权重）。
3. 验证文本特征：若按钮内含文字，检查characters是否被插件截断（我们默认截断超长文本，仅保留前 50 字符）。可在插件设置中关闭截断，但会增加传输体积。

解决方案：

• 在 Rule Engine 中为按钮添加兜底规则：{"atomic": "hasStroke", "op": ">=", "value": 0.9} && {"atomic": "width", "op": ">", "value": 80}→ 强制识别为 Interactive 元素。
• 教育设计师：在 Figma 中为按钮添加Fill（即使透明），并控制嵌套深度。

5.2 “生成的 Storybook 文档里，状态控件不生效！”——CSS 变量作用域错误

现象：Storybook 中点击 “Hover” 状态，按钮样式无变化。

根因：CSS 变量未在 Storybook Canvas 的全局作用域注入。我们生成的tokens/button.css默认写入:root，但 Storybook 的 Canvas 是 iframe，:root不继承。

修复步骤：

1. 修改执行层代码，在生成 CSS 文件时，额外输出tokens/button-iframe.css，内容为：

   .sb-show-main iframe { --button-primary-bg: #2563eb; /* ... 其他变量 */ }

2. 在 Storybook 的preview.js中引入该文件：

   import '../dist/tokens/button-iframe.css';

3. 重启 Storybook。

注意：此问题在本地开发时不易复现（因 Storybook 开发服务器特殊处理），必须在build-storybook后的静态产物中验证。

5.3 “设计师说‘生成太慢了’，但后台日志显示 1.2 秒！”——Figma 渲染阻塞真相

现象：插件面板显示“生成中...”，但实际等待 5 秒以上，后台日志却显示推理服务返回仅 1.2 秒。

真相：Figma Plugin 的 UI 渲染是单线程的。当插件 JavaScript 执行大量 DOM 操作（如动态渲染 50 个组件预览图）时，会阻塞主线程，导致 UI “假死”。

解决方案：

• 所有 UI 渲染采用requestIdleCallback分片处理：

  const renderChunks = chunkArray(components, 5); // 每次渲染 5 个 renderChunks.forEach((chunk, index) => { requestIdleCallback(() => { renderPreview(chunk); }, { timeout: 1000 }); });

• 预览图使用 SVG 而非 Canvas，SVG 渲染性能高 3 倍，且支持 CSS 变量。

5.4 “为什么 Token 同步 PR 总是冲突？”——Git 合并策略优化

现象：多个设计师同时修改不同 token，各自生成 PR，合并时tokens/core.json频繁冲突。

根因：所有 token 存储在一个 JSON 文件，Git 无法智能合并对象属性。

优化方案：

• 将tokens/core.json拆分为tokens/color.json、tokens/spacing.json、tokens/radius.json等按类别分离的文件。
• 插件生成时，只修改对应类别文件（如修改蓝色值，只更新color.json）。
• CI 流水线增加json-merge步骤，合并 PR 时自动合并同类别文件，冲突率下降 89%。

我在实际使用中发现，这套方案最大的价值不在技术多炫酷，而在于把设计系统的维护成本从“月级”压缩到“小时级”。以前设计师提一个新组件需求，要走评审、切图、前端开发、联调、回归测试，平均耗时 17 天；现在她画完稿，点一下插件，2 秒后 Storybook 里就能看到可交互的组件，前端工程师当天就能接入。这背后没有魔法，只有一层层扎实的工程选择：放弃大模型幻觉，拥抱确定性规则；接受 Figma 的限制，把它变成优势；把每一次“失败”都变成数据飞轮的燃料。如果你也正站在设计与工程的裂缝上，不妨从清理一个 Figma 节点树开始——真正的自动化，永远始于对细节的敬畏。