UI Remix：通过交互式示例检索与混搭支持用户界面设计 UI Remix: Supporting UI Design Through Interactive Example Retrieval and Remixing
基于多模态检索增强生成的UI设计系统，帮助终端用户通过真实示例进行迭代式界面设计
前置知识
多模态检索增强生成（MMRAG）
MMRAG 是 Retrieval-Augmented Generation（RAG）在多模态场景下的扩展。传统 RAG 通过检索外部文本文档来增强大语言模型的生成质量，而 MMRAG 则将检索对象扩展到图像、UI 截图等视觉模态。在本系统中，用户输入自然语言查询后，系统使用视觉-语言编码器（GUIClip）将查询文本和 UI 截图映射到同一嵌入空间，通过余弦相似度检索最相关的 UI 示例，再将检索到的示例作为上下文输入多模态大语言模型（GPT-5）进行代码生成。这种范式让模型不仅能生成新内容，还能参考真实世界的设计案例。
本文的核心技术架构就是 MMRAG，理解这个范式才能明白系统如何将用户的模糊文本描述与具体的视觉 UI 设计连接起来
向量数据库与嵌入检索
向量数据库（如本文使用的 ChromaDB）是一种专门存储和检索高维向量的数据基础设施。每个数据项（如一张 UI 截图）通过编码器转换为固定维度的向量（嵌入），查询时将用户的文本查询也编码为向量，通过计算向量间的余弦相似度（cosine similarity）来衡量语义接近程度。这种方法比传统的关键词匹配更灵活，能捕捉语义层面的相似性——例如查询「现代风格的餐厅菜单」可以匹配到视觉风格相似但文字描述不同的 UI。
检索模块是本文系统的前端核心，理解向量检索才能明白系统如何从 900 张 UI 截图中快速找到最相关的示例
Diff-Patch 代码生成
Diff-Patch 是一种增量代码更新机制，源自版本控制系统（如 Git）。传统方式下，每次修改 UI 设计都需要重新生成完整的 HTML/CSS 代码，耗时超过 3 分钟。而 Diff-Patch 方式让模型只输出相对于当前代码的变更部分（即差异），然后使用 unidiff 和 difflib 库将这些差异应用到现有代码上。这类似于 Git 的 diff 功能，只记录和应用「新增了什么、删除了什么、修改了什么」，而不是每次都重写整个文件。
这是本文的关键工程优化，将修订时间从 3 分钟缩短到约 1 分钟，直接影响用户体验的流畅度
社会透明度理论（Social Transparency Theory）
社会透明度理论强调在信息系统中使他人的意图、身份和行为可见的重要性。在 AI 推荐场景下，当用户能看到推荐内容的来源信息（如评分、下载量、开发者信息），他们更容易理解推荐的背景和可信度。这种透明性帮助用户形成「传递性信任」——即「如果很多人都在使用或喜欢这个设计，那它应该是可靠的」。本文将这一理论应用于 UI 示例推荐，通过展示来源透明度线索来增强用户对 AI 推荐结果的信任。
这是本文区别于其他 UI 设计工具的核心设计理念之一，解释了为什么系统要展示评分、下载量等元数据
设计固着（Design Fixation）与设计漂移（Design Drift）
设计固着是指设计师在看到一个参考示例后，过早地锁定在某个特定方案上，难以跳出该方案的框架进行创新。设计漂移则相反，是指在探索大量示例的过程中，设计师逐渐偏离最初的设计目标，被过多的灵感分散注意力。这两种现象分别对应「太窄」和「太广」两个极端，是基于示例的设计工具需要平衡的核心张力。
理解这两个概念才能明白本文为什么要设计全局混搭和局部混搭两种互补模式
研究动机
随着 AI 工具降低了 UI 设计的技术门槛，越来越多的终端用户（如小企业主、学生、业余爱好者）开始自己设计界面。然而，这些用户面临一个核心困境：他们能够判断自己是否喜欢某个设计，却很难用语言准确描述想要的视觉效果。例如，一个餐厅老板可能知道想要「现代感的」、「用户友好的」菜单页面，但无法将这些抽象印象转化为具体的配色、布局、排版等设计决策。现有的 AI 设计工具虽然能将模糊提示转化为初始设计，但当系统生成了一个「现代」风格的界面时，终端用户缺乏设计素养去评判这个设计是否真的好，也难以信任 AI 的选择。现有的基于示例的设计工具要么提供过于宽泛的搜索空间（如 Dribbble、Behance 等设计社区平台），容易导致设计漂移；要么要求用户提供高质量的参考示例作为输入，对新手来说门槛太高，且容易导致设计固着。
本文的目标是本文旨在设计并实现一个交互式系统 UI Remix，帮助终端用户通过可追溯的真实世界 UI 示例来表达、迭代和验证他们的设计意图。具体目标包括三个层面：第一，支持用户通过自然语言描述设计需求，系统自动检索并展示相关的 UI 示例作为灵感参考；第二，提供全局混搭（Global Remix）和局部混搭（Local Remix）两种机制，让用户既能借鉴整体风格又能精细调整特定组件；第三，通过展示来源透明度线索（如评分、下载量、开发者信息），增强用户对 AI 推荐结果的信任，使设计选择更有依据。
与已有工作不同的是，本文的独特切入角度在于将「检索增强」范式从纯文本生成领域引入 UI 设计这一创意任务，并且不只是简单地检索+生成，而是构建了一个「检索-选择-混搭-迭代」的完整交互循环。与已有工作相比，本文抓住了三个被忽视的点：第一，现有系统大多将示例检索和设计生成作为独立步骤，而 UI Remix 将两者无缝集成，用户可以在浏览示例的同时直接将选中的设计元素应用到自己的作品中；第二，本文从社会透明度理论出发，认识到单纯展示视觉示例不足以建立信任，还需要展示示例的来源和质量信号；第三，本文同时提供了全局和局部两个粒度的混搭操作，让用户能够在发散探索和聚焦精修之间灵活切换，避免了设计固着和设计漂移的两极困境。
核心方法
UI Remix 的核心思路可以用一个类比来理解：想象你是一个不懂烹饪的新手，想做一道菜。你不会直接凭空想象，而是会先在美食网站上搜索菜品图片，找到几个喜欢的风格，然后参考某个菜品的摆盘、另一个菜品的配色，逐步拼凑出自己的方案。UI Remix 就是将这个过程数字化——用户先用自然语言描述设计需求，系统从一个包含约 900 张真实移动应用 UI 截图的数据库中检索相关示例，用户浏览这些示例并选择喜欢的，然后通过「混搭」操作将选中的设计元素（整体风格或特定组件）应用到自己的 UI 中。技术上，系统由三个面板组成：对话面板（用户与系统交互的主界面，支持聊天、搜索、应用三种模式）、示例画廊（展示检索到的 UI 示例及来源元数据）、可编辑画布（显示当前设计的实时预览，支持代码和视觉双视图）。整个流程基于 MMRAG 架构：检索模块使用 GUIClip 编码器将文本查询和 UI 截图映射到同一嵌入空间，通过余弦相似度检索 Top-10 结果；生成模块使用 GPT-5 模型接收用户指令、当前代码和参考截图，以 diff-patch 格式输出增量更新。
本文最本质的创新在于将 AI 在 UI 设计中的角色从「生成执行者」转变为「反思协作者」。传统的 AI 设计工具（如 GPT Canvas、Figma Make）采用一次性翻译模式：用户输入描述，AI 输出设计，用户如果不满意只能重新描述或手动修改。UI Remix 则构建了一个迭代式的协同进化循环：用户通过浏览和选择真实示例来逐步澄清自己的设计意图，系统通过检索和混搭来支持用户的探索和精修。这种设计哲学的核心区别在于——它不假设用户能在一开始就准确表达需求，而是通过交互过程帮助用户逐步发现和表达自己的偏好。用户从模糊的「我想要一个现代的餐厅菜单」开始，在浏览多个示例后逐渐意识到「原来我喜欢的是简洁的布局配上暖色调」，这种反思性澄清（reflective articulation）是纯生成工具无法提供的。同时，通过展示来源透明度线索（评分、下载量、开发者信息），系统将 AI 推荐从「黑箱输出」转变为「可追溯的设计参考」，让用户能够基于社会性证据而非主观审美来做出设计决策。
方法步骤详情
UI Remix 的完整工作流程可分为以下步骤：第一步，用户在对话面板中输入自然语言描述（如「一个中式餐厅的菜单页面」），系统调用 GPT-5 生成初始 HTML/CSS 代码并在可编辑画布中渲染预览（聊天模式）。第二步，如果用户对当前设计不满意，可以切换到搜索模式，输入新的查询（如「美食类应用的菜单设计」），系统将查询文本通过 GUIClip 编码器转换为向量表示，然后与预存的 UI 截图向量进行余弦相似度计算，检索出 Top-10 最相关的 UI 示例及其元数据（评分、下载量、分类、开发者信息），展示在示例画廊中。第三步，用户浏览示例画廊，选择一个满意的 UI 设计，切换到应用模式，输入混搭指令（如「应用这个配色方案」），系统将用户的查询、当前 UI 代码和选中的参考截图组合成结构化提示词发送给 GPT-5，模型以 diff-patch 格式输出代码变更（全局混搭）。第四步，如果用户只想修改特定组件（如按钮样式），可以在可编辑画布中点击选中该组件，系统将检索范围聚焦到该组件的变体上，用户选择喜欢的变体后通过绘画标注目标区域，系统生成仅更新该组件的代码（局部混搭）。第五步，用户可以反复迭代以上步骤，系统记录所有中间版本，支持前进后退导航。整个过程中，三种模式（聊天、搜索、应用）可以无缝切换，所有交互记录在对话面板中保持透明可追溯。
技术新颖性
与已有 UI 设计辅助系统相比，UI Remix 的技术新颖性体现在三个方面。首先，在检索能力上，系统同时支持基于文本的语义检索和基于组件的聚焦检索，且使用 GUIClip 视觉-语言模型将文本和图像映射到同一嵌入空间，而多数现有系统（如 Gallery D.C.、d.tour）仅支持关键词检索或单一模态检索。其次，在混搭机制上，UI Remix 同时提供全局混搭（整体风格迁移）和局部混搭（组件级别精修）两种粒度，这在现有系统中是独一无二的——Table 1 显示，大多数系统只支持其中一种，而 UI Remix 是唯一同时支持两种且面向终端用户的系统。第三，在生成效率上，系统采用 diff-patch 增量更新机制而非全量重新生成，这将修订时间从 3 分钟以上缩短到约 1 分钟，是一个关键的工程创新。此外，系统将社会透明度理论应用于 UI 示例推荐，通过展示来源元数据来增强信任，这在 UI 设计辅助系统中属于首创。
实验结果
本文通过用户研究（24 名参与者，受试者内设计）和技术评估两个维度验证了系统的有效性。在技术评估方面，研究团队使用 100 个自动生成的文本查询测试检索模块性能，查询类型涵盖配色主题、布局、UI 类别和 UI 组件四种。结果表明，系统在所有查询类型上的平均 Hit@5 达到 0.88，nDCG@5 达到 0.77，这意味着 88% 的查询能在前 5 个检索结果中找到至少一个被标注为相关的设计。其中配色主题和 UI 类别的检索表现最好（Hit@5 均为 0.92），而 UI 组件的检索相对较弱（Hit@5 为 0.80）。在用户研究方面，参与者使用 UI Remix（Beta）和 GPT-Canvas 基线（Alpha）分别完成一个 UI 设计任务。统计分析显示，UI Remix 在多个维度上显著优于基线：在「帮助探索更多替代设计方案」方面（p < .001, Z = 1.03）、在「愿意将系统用于其他创意任务」方面（p < .001, Z = 0.03）、在「支持我很好地实现设计目标」方面（p = .02, Z = -0.64）、在「有效迭代 UI 设计」方面（p = .04, Z = 0.67），Beta 系统均获得显著更高的评分。行为数据显示，参与者平均使用搜索模式 3.75 次、全局混搭 1.33 次、局部混搭约 3 次，21 名参与者在前 5 次操作中就至少使用了一次检索模式。访谈数据进一步揭示，9 名参与者明确表示喜欢系统的示例驱动特性，17 名参与者主动查看了来源透明度线索。值得注意的是，专家评估（UI 质量、布局质量、准确性）在两个条件间没有显著差异，这可能是因为评估聚焦于静态单屏 UI 的短期任务，示例驱动交互的收益更多体现在设计过程而非最终结果上。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| UI 检索 - 配色主题查询 | Hit@5 | 0.92 | N/A（首次评估） | N/A |
| UI 检索 - UI 类别查询 | Hit@5 | 0.92 | N/A | N/A |
| UI 检索 - 布局查询 | Hit@5 | 0.88 | N/A | N/A |
| UI 检索 - UI 组件查询 | Hit@5 | 0.80 | N/A | N/A |
| UI 检索 - 整体平均 | Hit@5 / nDCG@5 | 0.88 / 0.77 | N/A | N/A |
| 用户研究 - 设计目标达成 | 7 点 Likert 量表 | 5.92 (M), SD=0.97 | 4.79 (M), SD=1.67 | p = .02* |
| 用户研究 - 迭代有效性 | 7 点 Likert 量表 | 5.83 (M), SD=1.20 | 4.67 (M), SD=1.99 | p = .04* |
| 用户研究 - 探索替代方案 | 7 点 Likert 量表 | 6.58 (M), SD=0.78 | 4.17 (M), SD=2.01 | p < .001** |
局限与改进
本文存在以下局限性。在研究设计层面，用户研究聚焦于静态单屏 UI 的短期原型设计任务，每个任务限时 25 分钟，这种设置虽然便于控制实验变量，但无法捕捉示例驱动交互在多屏、交互式设计中的价值，也无法观察长期使用中的设计能力成长。在评估指标层面，专家评估采用粗粒度的 7 点 Likert 量表评估最终 UI 的美观度、布局质量和准确性，两个条件间未发现显著差异，这暗示示例驱动系统的主要收益可能体现在设计过程（探索、迭代、信任）而非最终产出质量上，但现有的评估框架难以量化这种过程性收益。在数据规模层面，系统的示例库仅包含约 900 张来自 196 个应用的 UI 截图，虽然覆盖了食品、旅行、生活方式、新闻、教育等类别，但与 Mobbin 等平台的数万张截图相比规模有限，可能影响检索结果的多样性和覆盖度。在技术架构层面，系统依赖 GPT-5 进行代码生成，存在 API 调用成本和延迟问题（即使优化后修订仍需约 1 分钟），且生成质量受闭源模型能力限制。此外，研究参与者以 25 岁左右、受过高等教育的年轻人为主（19 男 5 女），样本的代表性有限，不同年龄、文化背景的终端用户可能对系统有不同体验。
独立分析的弱点
从独立分析的角度，UI Remix 存在以下值得改进的弱点。首先，系统的检索依赖于文本查询与 UI 截图之间的语义匹配，但对于 UI 设计这种高度视觉化的任务，文本描述往往无法充分传达视觉意图——用户说「现代风格」可能指的是扁平化设计、极简主义、深色模式等多种可能性，而 GUIClip 的文本编码器难以消解这种歧义。改进方向是引入基于草图的检索（允许用户画出大致布局）或基于多图融合的查询（用户提供 2-3 张喜欢的 UI 作为参考）。其次，系统的来源透明度线索（评分、下载量、开发者信息）虽然被多数参与者认为有价值，但 7 名参与者表示这些元数据不影响他们的设计决策，说明当前的透明度展示方式可能过于简单——用户真正需要的可能是「为什么这个 UI 适合你当前的需求」的解释性信息，而非通用的质量指标。改进方向是引入 AI 生成的适配理由（如「这个 UI 的配色方案与你的餐厅主题匹配度为 85%」）。第三，系统的三种模式（聊天、搜索、应用）需要用户手动切换，增加了认知负担，新手可能不清楚何时应该切换到哪个模式。改进方向是引入智能模式推荐，根据用户的当前操作和上下文自动建议最合适的模式。第四，全局混搭和局部混搭的操作流程依赖用户在示例截图上绘画标注目标区域，这种交互方式对不熟悉设计工具的终端用户来说可能不够直观，改进方向是引入更自然的交互方式，如拖拽、点击选择或语音描述。
未来方向
本文提出了几个重要的未来研究方向。作者明确指出，未来可以将 UI Remix 扩展到多屏或交互式 UI 流程设计，探索示例驱动的反思如何跨连接的设计上下文延伸——例如从单个菜单页面扩展到完整的餐厅 App 流程（首页、菜单、点餐、支付）。作者还建议进行纵向研究，观察用户在更自然或协作的环境中如何使用系统，以及设计意图的表达能力如何随时间演变。此外，作者提出可以进行组件级别的消融研究（仅检索、仅混搭、组合条件），以更精确地刻画每个组件对探索、反思和意图表达的贡献。基于本文的成果，还可以延伸以下方向：第一，引入主动式代理机制（agentic mechanisms），让系统根据用户的实时操作主动推荐示例或设计方向，而非完全依赖用户发起查询；第二，探索多人协作场景，让团队成员可以共享示例库、评论设计选择、混合各自偏好的元素；第三，将系统应用于不同的设计领域（如海报设计、PPT 设计、网页设计），验证示例驱动范式的泛化能力。
复现评估
本文的代码管线已开源（https://github.com/ETH-PEACH-Lab/UI_Remix），这大大提升了可复现性。系统的技术栈相对标准化：后端使用 FastAPI，前端使用 React，检索使用 ChromaDB，嵌入使用 GUIClip，生成使用 OpenAI GPT-5 API。数据方面，系统使用了三个公开可用的数据源（Mobbin、Interaction Mining、MobileViews），但需要注意的是，Mobbin 是商业平台，其数据的获取可能需要额外授权。复现的主要成本在于 GPT-5 的 API 调用费用——每次修订约需 1 分钟的模型推理时间，如果进行大规模用户研究或批量测试，API 成本可能相当可观。此外，系统的示例库经过人工筛选了 196 个流行应用的约 900 张截图，复现者需要投入类似的数据收集和筛选工作。总体而言，对于有基本 Web 开发能力和 OpenAI API 访问权限的研究团队，复现本文系统是可行的，预计需要 1-2 个月的开发时间。
论文图表