Flux Art先辨认这次操作改变了什么
按钮原本已经改好文案和颜色，换成另一种组件或状态后却变样，先确认是切换变体、通过 Instance menu 替换实例，还是从 Assets 面板拖拽替换。不同操作路径不能混为一谈。Flux Art 是多模型 AI 视觉创作与生产平台，可参与品牌视觉候选制作；本文讨论外部 Figma 设计文件的组件关系，不把实例覆盖管理说成平台或图像模型功能。
保留替换前的实例和批准值
在诊断副本中操作，保留替换前实例、批准文案及需要保护的颜色或其他属性。写下原组件、目标组件、所选变体和替换方式，避免只留一张截图后无法追溯对象身份。不要先 Reset all，也不要先把实例分离成普通对象来遮住问题；这些操作会改变排查条件。若原始值或目标组件版本不清楚，应标未知并补证，不凭视觉相似判断它们来自同一组件。
默认值、覆盖值和目标默认值分三列
覆盖指实例相对于主组件作出的修改。核对时分别记录原主组件的默认值、当前实例的修改值、目标组件或变体的默认值，不要把这三者当成同一份颜色表。组件之间本来就不同的状态设计，可能与某次局部修改发生冲突。下表用于保存判断所需的证据，未修改的属性也应与真正的覆盖区分，避免把正常默认值变化误报为数据丢失。
| 核对项 | 应保留的记录 | 判断边界 |
|---|---|---|
| 原组件身份 | 组件与变体名称及版本 | 外观相似不是同一来源 |
| 原默认值 | 修改前对应属性 | 不能以当前覆盖值代替 |
| 实例覆盖 | 文案、填充及其他实际修改 | 未改属性另记 |
| 目标默认值 | 目标变体原始属性 | 不能预设与原状态一致 |
| 替换路径 | 菜单或Assets拖拽等实际操作 | 不同路径不混用保留预期 |
| 逐状态结果 | 保留、重设或待处理 | 一帧截图不是全状态验收 |
图层名称与文本层级需要对应
Figma 文档说明，替换实例或选择变体时会尝试保留覆盖，其中会检查图层名称是否匹配；文字保留还会考虑文本层级是否相近。因此先定位对应的文本层，不要只比较最外层按钮的名字。为接收者整理清晰且可识别的层级，但不要为了让某次替换暂时通过，就无依据地批量重命名共享组件。任何结构调整都应在副本验证，并由组件维护者确认其影响。
变体切换还要回看修改前的属性
切换变体时，文档还要求核对被修改属性在两个变体中原本是否一致。假设两个状态最初都用颜色甲，实例被改成颜色乙；另一个目标状态原本用颜色丙，这两条切换路径就不能预设有相同保留结果。这个例子不是真实软件测试，也不指定项目应使用哪种颜色。先查原始设计意图，再判断目标应继续沿用覆盖还是恢复其状态色，不能把所有状态强行染成一种颜色。
从 Assets 拖拽替换不要套用菜单预期
官方替换说明将 Assets 面板配合修饰键拖拽的路径单独列出，并说明这一方式只保留文本覆盖，其他覆盖不会应用到新组件。若上次操作走的是这条路径，就不能要求已修改的填充色也按 Instance menu 的预期继承。应在副本中选择与需求匹配的操作，再逐项确认结果；不提供一个跨所有嵌套结构、系统和版本都相同的快捷键配方，实际操作以当前文档与对象关系为准。
修复只针对已经定位的属性
确认原因后，可针对需要的属性重新批准设置，或在确实需要恢复默认时使用相应属性重置。不要把重置全部当作无损修复，因为已经批准的其他修改也可能被清除。推送到主组件会影响其他实例，不能为了修一个按钮就擅自修改共享设计来源。若问题来自组件结构而非某个实例值，应交由维护者处理，保留变更范围和受影响页面清单。
逐状态检查，而不只看替换后一帧
把项目实际使用的主次类型、默认状态和交互状态列成检查清单，每次切换后分别核对文案、图标、颜色和需要保留的其他属性。文字没有丢不代表全部样式都保留，颜色相同也不代表实例关系仍正确。重新打开文件并让接收者在副本中执行约定替换，保存操作路径和结果；未测试的状态标待处理，不能用一个正常截图证明组件库整体无问题。
资料与交付分工
覆盖保留与重置依据 https://help.figma.com/hc/en-us/articles/360039150733-Apply-changes-to-instances ，替换方式依据 https://help.figma.com/hc/en-us/articles/360039150413-Swap-components-and-instances 。本文未执行 Figma 实测，也不承诺特定账号拥有全部功能，权限与可用性按当前产品说明核对。视觉候选可从 https://flux-art.net/zh/ai-image 开始；组件规范、批准属性与接收端编辑验收单独交付。