Motiff 妙多一直坚信 AI 会重塑 UI 设计,并推出了多项业界首创的 AI 功能。大语言模型的快速进展,进一步提升了我们对于 AI 功能的想象力。 Motiff 希望 AI 功能不仅可以作为设计师的 Copilot,也能实现设计领域的 Autopilot,甚至可以生成完整的设计稿。
经过了多次的挫折和尝试,Motiff 妙多终于发布了 AI 生成 UI 功能——用户只需要输入一段设计需求,就可以获得精美的 UI 设计稿。
本文将与大家分享一下这个功能开发过程中的经历和思考。
在 AI 生成 UI 项目刚启动的时候,我们对于技术方向还有非常多的疑问。
一个核心问题在于,应该从零生成所有细节,还是利用 UI 组件进行组装?基于组件的方式理论上会更加简单,但是从设计表达力的角度考虑,我们认为让 AI 控制所有细节,才能实现最佳生成效果。这也成了我们首先尝试的方向。
乍看之下,UI 设计稿很像一张图片。测试后我们发现文生图模型也可以生成视觉效果不错的 UI 稿图片,但问题很明显:
这些问题对于专业的工具来说都是无法接受的,因此我们认为当前这个方案并不可行。
那么另外一个自然的方向,就是把 UI 作为结构化文本(网页)来生成,但同样存在明显问题。
真实的 UI 稿通常包含大量细节,意味着输出阶段需要大量 token,目前主流大模型还是容易碰到瓶颈。我们尝试过自定义 DSL 来提高表达效率,但提升也非常有限。
更为关键的问题在于,大模型生成的网页与高质量的 UI 设计之间还有明显差距,尤其对于复杂的视觉效果,大模型很难表达出设计感。
我们发现 UI 稿是一个独特的生成领域,既要在整体布局上具备严谨的逻辑结构,又要在细节处理上达到像素级的精确程度,还需要在视觉效果上体现高度的设计美感。目前的各类大模型,在这个任务上,都还难以直接生成满意的效果。我们也不得不重新审视技术方向。
仔细分析 UI 稿的内容,主要分为三个部分:
我们发现大模型在生成整体结构和内容方面已经有非常好的能力,主要欠缺的是对于 UI 细节的控制。如果不要求生成所有细节,而是使用预定义的 UI 组件库,恰好可以弥补大模型当前能力的不足。
当然也存在一些不容易处理的场景,例如一些产品卡片里 UI 元素特别密集,恨不得摆上 10 种标签,这种情况很难匹配到合适的组件。但这些场景是因为 UI 的个性化不够,才需要在有限空间内堆叠大量信息。
我们认为,随着 AI 时代软件开发成本的降低,未来的应用会更加智能和个性化,这样的场景也会越来越少。
因此我们调整了技术方向,通过一套富有表现力的 UI 组件来保证细节上的良好设计,同时让大模型专注于生成页面结构和具体内容。
确定新的方向后,我们最初认为实现起来并不复杂,只需向大模型描述页面需求和组件库,就可以生成完整页面。但是效果远不如预期。
虽然我们努力精确地描述各个 UI 组件,大模型依然很难准确挑选到适合的组件。部分原因是为了实现好的 UI 效果,我们需要提供多样化的组件,很多组件是很相似的——以列表为例,有些场景只需要展示简单的文本,其他场景则需要展示更多的图片和按钮等信息。
我们也尝试使用 Few Shots 来提升准确性,但是生成一个 UI 页面的上下文内容很多,很难在一次推理中提供大量的样例,因此提升效果依然有限。
通过以上实践我们发现,基于组件的方案虽然大大降低了复杂度,但是让大模型直接生成页面并不容易。
我们很快转向 Flow Engineering,把生成流程拆分成多个子任务,协同来完成整个功能。
例如一个拆分的方式是把流程分为两个大的步骤:
第一步“生成”的效果还可以,但是“转换”的过程非常困难,自由度非常高的页面元素难以被匹配到有限的组件中。人工定义转换规则的尝试也被我们放弃了,因为这很难扩展。我们又尝试了多个流程拆分的方案,效果依然不理想。
我们发现,核心问题还是在于,如何让大模型充分理解 UI 设计这个任务。
UI 设计作为一个非常垂直和专业的领域,现有的通用大模型存在明显的局限性。
不只是 AI 生成 UI,其他的 AI 功能也需要一个更懂 UI 的大模型。因此我们自研了国内首个 UI 行业的多模态大模型——Motiff 妙多大模型。
这是一个典型的整合专家模型,预训练好的语言模型和视觉模型被通过模态转换器连接,从而可以协同工作。然后输入大量专业数据进行训练,让模型具备 UI 领域的基本能力。
最终通过针对性优化,Motiff 妙多大模型在多个 UI 领域任务的表现上显著超越了通用大模型,例如基于 UI 页面的问答、精确描述 UI 内容乃至像素级别的元素定位都可以轻松完成。
如果对训练流程感兴趣,可以阅读《Motiff 妙多大模型:懂 UI 设计的多模态大模型》来获取更多信息。
基于 Motiff 妙多大模型,我们终于可以把 UI 组件库的表现力和大模型的生成能力有效结合起来。通过内容生成、组件匹配、图片生成等多个流程的结合,准确根据用户需求生成相应的设计稿。
在内部评测中,Motiff AI 的生成效果对比其他一些方案都有了明显的提升,并且可以有效支持多语言的生成。
Motiff 也在持续迭代流程和模型,开发了同时生成两版不同设计稿的功能,让用户能够挑选最合适的设计方案。AI 生成 UI 后,用户可以无缝衔接 Motiff 强大的专业能力,比如快速制作原型或者进一步编辑优化。
在探索的过程中 Motiff AI 团队碰到很多困难也踩了很多坑,这里简单分享一些我们对于 AI 应用开发的经验和思考。
由于技术上的不确定性,我们应当对于 AI 产品的功能形态保持足够开放的态度。例如这个项目开始的时候只有很模糊的产品方向,然后在技术探索的过程中才逐步细化产品方案。
Motiff 目前的很多工作都是在寻找 TPF(Technology-Product-Fit),这是和之前的开发经验很不一样的。并不是说过去的项目中技术不重要,只是之前的技术栈已经很成熟,比较容易判断一个需求的技术可行性和开发成本。
而 AI 模型还在快速升级迭代,我们对于底层逻辑的理解也还远远不够,因此判断技术可行性就困难了很多。
面对这些困难,我们能做的,就是小步快跑、持续迭代。相较于一个完善的产品方案,我们倾向于让功能更早落地并获取用户反馈。这样既可以减少产品侧的不确定性,也能在实际产品中更好地理解技术的边界。
提示词调优依然还是基础,只是随着模型的发展和团队经验的提升,通常可以较快地把提示词优化到合理程度。但如果要进一步提升正确率或者增加功能,提示词调优的难度会急剧上升。与之相比,我们倾向于把任务拆分得足够简单,降低单次推理的复杂度。
相比大模型推理的黑盒运行,流程拆分对于团队协作和工程化都更为友好。
很多之前的工程经验和基础设施也能方便地复用,比如各种性能监控、错误报警、限流重试等,这些对于线上的稳定运行都是非常重要的。
在系统设计中,我们强调应该依赖于稳定的抽象,而不是具体的实现。
对于 AI 应用,我们同样需要思考支撑产品的底层能力是什么。
过去一年中,大模型的上下文增加了一个数量级,成本降低了一个数量级,推理速度也快了好几倍。在这样快速的变化中,应该避免让当前的指标影响到系统架构的底层逻辑。Motiff 也有过很多教训,例如之前为了优化生成速度采用了复杂的并发流程,后来发现得不偿失。
所以我们认为,在构建系统的时候要谨慎判断哪些是长期的限制。尽量专注在核心能力的交付,其它方面可以延迟决策,在碰到瓶颈的时候再进行优化。
我们认为当前最核心的工程能力,就是让团队能够快速试错,快速迭代。因此我们投入了很多资源来完善实验平台,让团队成员都可以灵活定制新的流程和参数。各个流程的运行数据都会记录在数据库中,方便调试和评估。
之前的软件开发中,我们习惯了程序运行结果的确定性。但是在 AI 应用中,只能去适应结果的不确定性。例如我们一直希望实现完整的端对端自动化测试,但是目前发现困难重重,那也只能调整工作流程,通过每天进行一到两轮的人工评测来验证效果。
最终 AI 生成 UI 能够通过自研模型取得良好效果,与 Motiff 妙多在 UI 领域长期积累的优质数据密不可分。这些高度专业的数据无法低成本获取,需要投入大量的资源进行整理和标注。
长远来看,大模型所体现的逻辑能力会变得越来越强大,也会越来越廉价。数据作为更稀缺的资源,才是最重要的护城河。
在探索新产品时,我们都会希望轻装上阵,尽快落地。但是一项业务要保证服务品质,往往都是越做越重,AI 应用也不例外。因此如果我们着眼于长期发展,就必须尽早构建数据壁垒。
目前 AI 生成 UI 的功能只是一个开始。
Motiff 妙多一直在密切跟进 AI 基础能力的发展并持续迭代技术方案,我们也欣喜地发现最近大模型的进展带来很多新的思路。我们期望能够尽快落地更好的生成效果,让 AI 进一步改变设计的未来。