一个体验设计师,用 AI 给自己写了个提效工具

我常常感叹，这真是一个好的时代。

相信很多人都已经在这个被 AI 重新打开的年代里，肆意奔跑着。

得益于 AI 技术的发展和进步，每个基础的个体都仿佛开启了外挂，拥有了更多原本不属于自己的能力。不懂设计的人，可以像设计师一样做设计；不懂代码的人，可以像工程师一样搭建产品；不懂算法的人，可以借助模型理解复杂问题；不懂运营的人，也可以通过数据、内容和自动化工具，重新组织自己的工作方式。

很幸运，在我的职业生涯里，能够亲眼见证这个大时代的变化，也能在这个节点上，重新获得一种主动生长的可能。

作为一个在互联网行业里工作了十多年的体验设计师，我很少像现在这样，频繁地感到一种具体的成就感。这种成就感并不只来自效率提升，而是来自一种更深层的变化：AI 正在把原本属于组织的能力，逐渐下放给个体。过去，很多事情要依赖完整的团队分工、稳定的研发资源、漫长的沟通流程，甚至还要等待一个合适的项目时机，才有机会被推进。一个想法从出现到落地，中间隔着产品、设计、研发、排期、评审和优先级。而现在，一个人也可以在 AI 的帮助下，把代码跑起来，把工具做出来。它并不是让人突然无所不能，而是把人的能力边界向外推了一圈。

这种变化对我来说很重要。它让我重新感受到，个体并不是只能等待组织分配资源，也不必永远停在“我有一个想法”的阶段。只要问题足够具体，路径足够清晰，一个人也可以先往前走一段。

这大概就是我在这个阶段最强烈的感受：AI 放大的不是幻想，而是行动本身。

最近工作里的一件小事，这也是无论团队规模大小，产研团队几乎都会遇到一个共同问题：设计工具迁移。设计资产往往长期沉淀在某一个平台或软件里，逐渐变成团队协作中的基础设施，也变成一种沉重的负担。因为不同软件之间存在兼容性问题，很少有团队愿意轻易更换设计工具。

毕竟，软件之间的 gap，最终都会变成团队真实的迁移成本。

但对设计师来说，这件事又很难完全避免。工具会变化，团队会调整，协作方式也会不断更新。某个阶段看起来稳定的工作流，过几年之后，可能就会成为新的限制。

迁移设计工具，真正的问题并不只是“把文件搬过去”。因为文件虽然能导入，但导入之后往往并不干净。自动布局丢失、信息错位、图层重叠、莫名出现的空图层、颜色变量混乱……这些问题不会阻止文件打开，却会让后续工作变得十分痛苦。

我一直在思考，能不能通过 AI 实现两端文件的高质量迁移。

最开始，我尝试过很多思路。比如通过两侧的 MCP，让 Codex 在中间做桥接；或者试图让 AI 理解两端文件结构，再完成对象级别的转换。但结果都不算理想。跨平台迁移涉及的变量太多：文件结构、对象属性、组件逻辑、自动布局规则，都可能在转换过程中发生损耗。想一次性解决所有兼容问题，反而会让问题变得过于庞大。

于是，我开始把目标收窄。既然现阶段很难实现完全无损的迁移，那就先不要执着于“完美迁移”。

与其解决两个平台之间复杂的兼容问题，不如把问题改为解决迁移之后的文件整理。也就是说，把问题从“两端转换”，缩小成“单一平台内的清理和修复”。这个思路一变，事情的难度突然降了下来。

因为在 Figma 内部，文件已经完成了基础导入。接下来要处理的，不再是复杂的跨平台映射，而是一些更明确、更可判断的问题：

• 哪些图层是空的，可以删除？

• 哪些对象发生了重叠，需要重新整理？

• 哪些文本样式丢失了，需要统一修正？

• 哪些颜色不符合设计系统，需要替换为变量？

• 哪些自动布局被破坏了，可以尝试重新建立？

这是些很简单的问题，但问题的难点在于需要我们发现问题是什么。当你定义清楚问题之后，后面的事情才是真的简单。

解决这些问题不需要一个宏大的工具，只需要能做到：帮助设计师批量检查和处理那些原本需要设计师一点点手动修复的问题，即可。

这件事给我的启发是，AI 时代的很多问题，未必一开始就要追求完整解决。

有时候，真正有效的方式，是先换一个问题切口。

不要试图让 AI 直接替你完成整座桥的建设，而是先让它铺好脚下最难走的那一段路。

工具迁移如此，设计自动化如此，很多工作也都是如此。

当我们把一个模糊的大问题拆成足够清晰的小问题，AI 才真正有机会参与进来。它不是凭空制造奇迹，而是在清晰的规则、明确的目标和真实的工作场景里，把人的经验放大，把重复的劳动接过去。

这可能也是这个时代最有意思的地方。

它并没有让专业消失，而是迫使专业换一种方式继续生长。

工具已经发布在Figma社区，或搜索F9 Fill Cleaner,免费使用。

https://www.figma.com/community/plugin/1677600123926027773