把 AI 界面转成可维护的 Figma 组件库

这是一段没人会拍进视频里的艰苦过程。演示在截图出现时就结束了，但真正的工作往往要再过一周左右才算完成——最终交付的是一个 Figma 文件，而且即使你不在场，其他人也必须能够打开并使用它。

这一阶段也占了大约 40% 的工作量。大多数 AI 辅助设计正是在这里悄无声息地失败了——不是因为界面做得不好，而是因为其中没有任何元素是可定位、可引用的。

导入会毁掉命名

把生成的 markup 导入 Figma 后，所有内容都会变成一层套一层的 frame，而且名称毫无意义。结构保留下来了，语义却消失了。

这时，人们本能地会从画布上的内容开始组件化——在界面里找到一个按钮，把它做成组件，然后继续处理下一个。千万别这么做。那棵节点树只是渲染产生的 artefact。基于它构建组件库，就会把其中所有偶然因素一并继承下来：用于包裹内容的 div 被提升成组件、布局容器被固化进 master、同一个元素仅仅因为出现在三个不同界面里，就被建模成三种不同形式。

源 markup 才是规范。它知道每个东西究竟是什么。因此，第一步应该是读取源 markup，整理出一份记录，明确应该存在哪些元素，以及它们分别应该叫什么；接着依据这份记录重命名，最后再进行组件化。先重命名，再组件化。在这个阶段，把这两步的顺序颠倒，付出的代价会超过其他任何流程顺序错误。

先建组件库，再处理界面

master 应该在一个干净的组件库区域中创建，而不是从界面内部直接提取。

两种方式的差别，会直接体现在组件最终包含的内容上。从界面中提取出来的 master 会把周围环境也一起带进去——原本属于界面的 padding wrapper、用于演示的标签，或者仅仅为了让元素在深色画布上清晰可见而添加的背景。这些东西随后会进入每一个 instance。六个月后，就会有人追问：为什么每张卡片都多出了 8 像素莫名其妙的 padding？

结构相同的元素应该归入同一个 variant set，而不是保留为彼此独立的组件。一个按钮被导入成五个毫无关联的组件，而不是一个 variant set，这是我在这里遇到的最常见问题。它必须在这个阶段修好，因为后续所有内容都会引用它。

颜色、字体、层级和效果，都要在 master 上完成绑定；然后再单独处理那些位于组件之外的散落图层。

有两条规则听起来理所当然，却经常被违反。第一，绑定只能修改样式属性，绝不能干扰尺寸、位置、布局行为或 constraints。第二，不要自动吸附到最接近的值。一个声称能修复所有问题的检查器，其实是在主动替你猜测；而猜测并选用视觉上最接近的值，正是一个设计系统在无人察觉的情况下获得未经任何人决定的语义的方式。用检查器发现问题，但具体如何修复，要由你自己决定。

替换操作会吞掉真实内容

当界面图层被替换为 instance 时，其中的 overrides 承载着真实文案——真实姓名、真实价格，以及某个人实际写下的文本。

如果不加留意地批量执行替换，所有真实内容都会被 master 中的占位内容覆盖，而且往往要查看后面的界面时才会发现。这是整个阶段中代价最高的小错误，因为破坏是无声的、分散的，而且只有当你碰巧查看到正确的界面时才能发现。

所以，每次都要先选择一个具有代表性的界面，在替换前后亲眼检查，然后再处理其余界面，无一例外。当批量操作按钮就在眼前，而且 Agent 听起来信心十足时，先做试点似乎是在浪费时间——但这种信心本身就是危险信号，因为无论它正确生成了一个结果，还是错误生成了一百个结果，它汇报时的自信程度都完全相同。

MCP 的价值所在

有些组件结构复杂到无法通过脚本化构建准确塑形——例如嵌套 variants、相互影响的 states，以及需要判断哪些内容应该放在组件内部、哪些不应该放进去的结构。

这正是通过 Agent 连接直接操控 Figma 能够体现价值的地方：使用真实 states 构建组件，再把它替换进各个界面。由人来决定组件的形态，由工具完成重复劳动。

但它做不到的是看见结果。它只能报告指令已经执行，却无法判断界面看起来是否正确。因此，工作循环仍然不变：它负责构建，你负责查看，然后它再继续重复执行。

在宣布所有工作完成之前，切换不同主题，并与此前已经确认通过的版本进行比较。

如果 Figma 是错的，而源文件是对的，说明绑定有误——修复绑定。如果两者都是错的，说明问题出在更上游的系统本身，应该在那里修复，再把变更同步下来。绝不能只修补 Figma 文件，因为这样就会产生两个相互矛盾的事实来源；而在有人重建这个文件之前，Figma 文件都会在每次争论中占据上风。

实话实说，它能带来什么

如果处理得当，这套方法可以减少大约 70%～80% 的手工收尾工作。不是 100%。过程中一定会出错，也一定会有一轮需要你亲手修正。任何承诺只需单击一次就能获得完美文件的人，都没有真正交付过这样的项目。

但减少项目中 70%～80% 最乏味的工作，已经是一个实实在在的成果。它决定了这套工作流究竟会止步于一张漂亮的截图，还是能够真正完成交付。

它解决不了什么

它无法决定哪些内容应该成为组件。你需要根据某个元素未来是否会重复出现来作出判断，但在做决定时，通常还没有足够证据能证明它究竟会不会重复。面对不熟悉的产品类型，我现在依然会判断失误。

另外，在开发者真正打开文件之前，说“可以交付”比说“开发者可以立即开工”更稳妥。我已经学会只说前一种。

在一个真实项目中记录完整流程

我用一个项目完整记录了从头到尾的全过程——需求简报、结构与流程、生成界面、锁定 token system、包含真实组件和 variables 的 Figma 文件、可点击 prototype，以及开发者交付，其中也包括过程中发生的各种问题：

Claude AI UI/UX：从需求简报到 Figma 的完整工作流——在一个真实项目中走完同一条路径，从需求简报一直到 Figma 交付。

如果你找到了能在批量替换过程中可靠保留真实内容的方法，我很想听听。这个问题现在依然会耗费我不少时间。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。