原生组件是体验底线而非天花板:AI 时代的设计策略
Native is a floor, not a ceiling
在 AI 能低成本生成精美界面的当下,原生组件的价值已从“美观”转向“真实感”与“系统同步能力”。通过对比 iOS 26 Liquid Glass 更新中 Flutter 等跨平台框架的滞后现象,以及多项 AI 生成界面研究,发现 AI 往往只能模仿旧版视觉样式,难以复现原生控件随系统演进的行为逻辑、无障碍支持及动态反馈机制。
研究表明,用户虽难察觉细微差异,但在对比场景下对 iPhone 上的原生应用有显著偏好(86% vs 7%)。然而,单纯依赖原生组件可能导致界面同质化(即“原生 slop”)。因此,最佳实践是将导航、控件等系统级元素严格保留为原生实现,以确保行为一致性和可访问性;同时将品牌创意资源集中在内容、排版和独特交互时刻上。这种分层策略既避免了因重绘控件带来的维护负担和体验割裂,又能在遵循平台规范的基础上建立独特的品牌识别度。
译文尚不完整,完整内容请切换到原文。
中文翻译暂缓,已收到 5 批翻译结果,待整合校验。当前显示部分译文,页面每 30 秒检查一次进度。
有了 AI,精致的视觉效果不再需要成本。原生带来的是无法被绘制出来的东西,它随系统而动,领先于模仿它的对象一步。

一个 AI 助手帮我写了这篇文章。想法、经验和最终编辑都是 我的。
2025 年 6 月,Apple 推出了 Liquid Glass,即 iOS 26 的新材质。在 其关于 UIKit 的 WWDC 会议中,该公司直言不讳:“只要你使用新 SDK 重新编译,你的应用就会获得这种新外观。”栏、工作表、弹出窗口和控件:来自系统框架的大部分组件立即发生了变化,无需设计师介入。
自行绘制控件的应用什么也没得到。第二天,Flutter 团队在 GitHub 上回应称,目前不会在其模拟 iOS 的 Cupertino 库中开发 Apple 的新设计。其文档将自行绘制控件列为一种优势:Flutter 应用“在所有版本的操作系统上看起来和感觉都一样,即使操作系统更改了其控件的实现”。当 iOS 26 于 2025 年 9 月 15 日发布时,这种稳定性的承诺变成了明显的滞后。该团队随后已将库移出核心框架以加快进度,并表示正在致力于 Liquid Glass 的工作,但截至 2026 年 11 月 5 日,该问题仍然 未解决。

出于同样的原因,我长期与这种选择打交道。自行绘制控件意味着在系统的每个版本上都拥有自己的渲染权。代价是每次变更时的滞后。只要精致的视觉效果需要付出努力,这个代价就值得支付:正是这种努力让应用脱颖而出。
AI 改变了这笔账。现在,精致的视觉效果只需一个提示词,生成的界面在视觉外观和布局上趋于一致。我曾在其他地方写过为什么最终所有东西看起来都相似,人们称之为 slop;在那里我将表面质量称为底线,而 AI 现在将其交给每个人。原生是另一种底线,是图像无法给予你的那种。原生组件不会让应用变得美丽。它们防止应用看起来虚假,并且随系统而动。
AI 绘制了原生的 图片
自十月以来,我一直在要求几个 AI 模型设计应用屏幕,用于一项即将发表的研究。它们在特定条件下模仿系统,且仅模仿可见的部分。
第一个条件是命名设备。如果不说明是哪款手机就要求制作移动应用,你会得到一个既不完全遵循 iPhone 也不完全遵循 Android 的通用屏幕。写上“iPhone”,开关确实具有 iOS 开关的形状。加上遵循平台当前约定的指令,它们会修正更多有名称的东西:开关的绿色、返回箭头。但在 iOS 26 发布一年后,它们绘制的 iOS 仍然主要是旧版本。悬浮标签栏和脱离边缘的工作表,即 iOS 26 的设计,只有在收到该指令时才会出现,而且 很少见。

我的解释:AI 从已有的事物中学习,而旧版 iOS 多年来一直充斥着网络内容。与此同时,系统每年都在变化,有时是微小的变化,有时则是巨大的变化。在 iOS 上,原生应用通过重新编译来跟进;而模仿品则停留在被复制的那一天。这就像仿冒品抄袭去年的时装系列,而时装屋早已转向下一个 系列。

今年春天发表的一项研究指出了同样的方向。研究人员让三个 AI 设计工具生成了 138 个移动屏幕,且未提及 iOS 或 Android。他们写道,这些模型已经学会了“当代移动界面的视觉语法”:导航惯例几乎总是存在的。但用他们的话说,这种成功“似乎是由模式驱动而非原则驱动的”,并且他们报告了视觉可用性与功能可用性之间的显著差距:帮助、错误预防和错误恢复往往 缺失。
图片没有展示的 内容
模仿本身已经很多了。但底线主要是行为。随处可用的返回手势。人人都能识别的分享面板。在 iOS 26 上,从打开它的按钮生长出来的确认框。从底部升起并通过滑动关闭的面板。截图最多只能展示其 表象。

Apple 在其指南的品牌页面中说明了这一点:当你使用人们已经熟悉的组件时,体验会感觉“立即可靠且熟悉”。一个熟悉的控件会做你期望它做的 事情。
1998 年,针对桌面软件,John Satzinger 和 Lorne Olfman 展示了从一个应用程序到另一个应用程序发生变化的命令会使用户采取更多操作,而不同的视觉外观往往会让他们更准确。重要的是行动方式保持 不变。
这就像语言的语法:每个人都共享同一种语法,没人称之为垃圾内容(slop)。垃圾内容是那种你已经读过一百遍的陈词滥调。
UIKit controls also come with built-in accessibility, and system components with text that scales to the size the user picked and a layout that flips for Arabic or Hebrew. On Android, the Compose documentation says that “most accessibility support is provided with little or no additional work” by its components, Material included. A control redrawn by hand has to rebuild all of that, and nothing guarantees it will: Kate Owens, at Deque, describes a custom slider that VoiceOver “skipped over entirely and never focused”.
Louie Mantia 是前 Apple 图标设计师,也是 Liquid Glass 的尖锐批评者,他在 2025 年这样评价图标:“每个人都可以看起来体面,但实际上并不体面。”生成的模型可以绘制一个看起来像 iOS 警告框的界面,却并未说明应该使用真正的 iOS 警告框。然而,无论多么忠实地手工重建,它只给了应用一个地板的图像。
越多应用基于生成的模型构建,就有越多应用看起来是原生的,但实际上并非原生。这就是为什么在我看来,今天原生开发比昨天更重要。风险在于被复制的模型:当 AI 编写原生项目的代码时,它可以调用真正的组件。它也可能产生原生垃圾代码:所有真正的组件都保持默认设置,周围没有任何品牌元素。它能运行并遵循系统规范,但看起来和其他每个应用都一样。
在 iPhone 上,差异显而易见
你可能认为用户看不到这些。我找到的唯一一项将原生应用与其跨平台版本进行对比的受控实验表明,一旦能够比较,用户在 iPhone 上确实能看出差异。
2014 年,Esteban Angulo 和 Xavier Ferré 让三十七人测试同一应用的两个版本,其中十四人在 iPhone 上进行测试。一个是原生版本,另一个是使用跨平台工具 Titanium 构建的版本。当被问及哪个版本最符合他们心中手机应用的样子时,iPhone 用户以 86% 对 7% 的比例选择了原生版本。在 Android 上,差距要小得多:52% 对 39%。
在 iPhone 上,七位先尝试跨平台版本的人认为它是典型的 iOS 风格;而在七位先尝试原生版本后再尝试跨平台版本的人中,只有四人这么认为。这种差距主要通过对比显现。但跨平台版本也显示了原生组件,且由不同的团队设计:该研究无法确定是什么造成了差异。它也没有说明这在评分或销售额上的价值,而一项针对近 12,000 个 Android 应用的研究得出结论,原生应用和混合应用(封装在原生外壳中的 Web 应用)在评分上表现同样出色。
上限在别处
原生开发解决的是虚假问题,而非相似性问题。从其他应用中脱颖而出仍然是品牌的责任,而基础体验并不能阻止这一点。2019 年,Android 开发者 Reza Bigdeli 在 UX Collective 上回应了那些认为标准组件“廉价”的设计师。他的建议是:遵循平台指南,并将创造力留给 Web。我在基础体验方面认同他;至于其他方面,应用可以在不脱离其平台惯例的情况下拥有强烈的身份标识。
Apple 本身并不推崇单一风格。2023 年,其设计大奖同时表彰了 Flighty 和 Duolingo。Flighty 获得了交互类别奖项,该类别奖励那些 “完美契合其平台” 的界面。其创始人 Ryan Jones 希望这款应用运行得如此顺畅,以至于感觉 “几乎平淡得显而易见”。另一方面,Duolingo 是一个高度风格化的界面,但 Apple 仍然称赞其具有 “一流的设计”和“易于遵循的用户界面”。

对于 Apple 而言,“即使是高度风格化的界面,只要保持熟悉的行为和模式,也可以是平易近人的。”WWDC26 的一场演讲将应用描述为两个层次:栏和控制组件依赖人们已经知道的内容,内容承载品牌,而整体建立在 “平台熟悉度的基线” 之上。这一界限是生成的模型图无法 展示的。
精力应该花在哪里
来自系统的部分:导航、返回、分享、确认、工作表、控制组件、文本大小。默认情况下不要重新绘制它们:Apple 建议将自定义工作保留在具有 “最大影响” 的地方,并警告说手工重制的实用工具控制组件可能会让应用看起来不够原生,甚至显得过时。通过名称指定它们,以免有人将其重建为一张 图片。
来自品牌的部分:内容、标题的排版(这也应遵循用户选择的字号)、插图、文案的语气、应用带来惊喜的时刻。这就是身份预算花费的地方。Apple 甚至 警告不要过度使用品牌元素:到处使用的品牌色会稀释其 影响力。
当模型图来自 AI 时,在提示词中指明设备及其当前规范,然后首先审查这种划分。任何看起来像系统控制组件的东西至少应该表现得像系统控制组件,最稳妥的做法是让它就是系统控制组件。其余部分可以随心所欲:那就是一个应用不再看起来像其他应用的 地方。
封面图片:Apple 针对 iOS 27 的设计套件,即每个应用都会获得的系统组件。图片:Apple Developer。
Mathieu Poli 是 GoodBarber 的前端工程负责人,撰写关于前端工程、产品设计和 AI 的文章。
原作者保留版权;来源:UX Collective。本站维护者确认获准转载,非公共领域或开放许可证声明。 原文来源(转载授权由站点维护者确认) · 中文译文由 CxHub 客户体验社区生成,并非官方译文。
来源:UX Collective · uxdesign.cc