当AI成为产品不可或缺的一部分时，用户体验（UX）设计也迎来了新的变革。透明性成为了AI产品设计中至关重要的因素。

随着 AI 越来越多地融入网站和应用程序的各个体验环节，明确区分哪些功能采用了 AI 技术变得至关重要。

最初，大多数产品仅通过聊天机器人引入 AI ，需要用户主动发起交互。而现在，AI 已被整合进仪表盘、任务系统和搜索功能中——用户不再需要主动触发，AI 体验已无处不在。

当用户失去对 AI 使用场景的控制权时，就必须通过设计明确告知：哪些内容和功能由 AI 驱动。这既关乎用户对信息可信度与质量的判断，也符合欧盟《AI 法案》（2026年生效）的强制性要求——该法案规定用户与 AI 系统交互时必须获得明确提示。

此时便需要设计体系的介入：通过专门的视觉标识，系统化地区分 AI 内容/功能与非 AI 内容/功能。

Google 的 Material Design 设计体系文档

遗憾的是，目前仅有少数开源设计体系明确包含了 AI 组件与设计模式。虽然我希望更多系统能尽快跟进，但截至目前，只有 GitLab 的 Pajamas 、IBM 的 Carbon 和  Twilio 的 Paste 在设计指南中提及了 AI 相关内容。

注：我使用 Figma 的 Design Systems 插件作为 AI 组件与模式的评估基准。同时，本文未纳入仅包含 AI 聊天机器人或对话设计文档的设计体系（如 Amazon 的 Cloudscape 和 Salesforce 的 Lightning），因为这些属于相对标准化的交互模式。

下面让我们对比分析这些设计体系中的 AI 组件与模式，探索优化用户体验的可能性。

1.GitLab 的 Pajamas

2.IBM 的 Carbon

3.Twilio 的 Paste

1.GitLab 的 Pajamas

Pajamas 目前尚未提供具体的 AI 组件，但其关于人机协作的文档颇具启发性。该文档首先建议通过评估自动化实施的伦理性和收益（如区分高风险与低风险任务），来判断 AI 是否真正能为用户创造价值。

接下来，它建议要对 AI 的使用场景保持透明。Pajamas 通过其 “GitLab Duo” 做到了这一点，该功能可展示 AI 的特性、能力及局限性。

GitLab Duo 用于标识界面中用户可与 AI 交互的区域

由于” GitLab Duo “仅用于标识 AI 功能模块（不涉及 AI 生成内容），Pajamas 设计体系还建议对 AI 生成内容采用”by AI”的标注方式（如”由 AI 生成摘要”），并附加提示信息引导用户核验内容准确性。

GitLab 目前正在开发配套实践框架，虽然尚处于建设阶段，但相关成果已体现在《GitLab  AI 交互模式》文档中。其目标是发布包含完整说明文档的 AI 模式库——这正是行业迫切需要的解决方案（求求了快上线吧！）。

🔗 https://gitlab.com/groups/gitlab-org/-/epics/10334GitLab

为其 AI 用户体验模式制定了四维评估体系，用以选择合适的设计范式，具体包括：交互模式、实现路径、响应机制和任务类型。

• 交互模式：AI的侧重方向（专注/辅助/融合）
• 实现路径：AI的优化方向（任务自动化/能力增强化）
• 响应机制：AI的交互方式（主动触发/被动响应）
• 任务类型：AI的核心功能（分类/生成/预测）

例如在早期探索中，他们通过低保真原型展示了 AI 如何融入图表界面或内联说明系统。这些设计模式都清晰标注了 AI 的使用范围，以此建立用户认知并培育对 AI 系统的信任。

带有 AI 标记的简约集成图表（如预测数据等，基于 GitLab 的 AI 用户体验愿景）

AI 辅助填表的简约指引界面（基于 GitLab 的 AI 用户体验愿景）

结论

目前，GitLab 的文档仍以概念性框架为主，概述了他们对于未来 AI 用户体验的愿景。尽管如此，它提供了一个坚实的、可跨行业和产品复用的设计体系基础框架。

我期待他们能尽快发布更深入的 AI 交互模式文档。如果实现，它很可能成为其他设计系统在制定 AI 规范时的重要开源参考资源。

2.IBM 的 Carbon

在开源设计系统中，Carbon 在人工智能（ AI ）使用方面的文档最为完善。它包含一个专门针对 AI 的板块——“ Carbon for  AI ”，该板块涵盖了相关组件、模式和指南，旨在帮助用户识别 AI 生成的内容，并了解 AI 在产品中的应用方式。

“ Carbon for  AI ”建立在现有 Carbon 组件的基础之上，通过添加蓝色光晕和渐变效果来突出显示 AI 相关实例。到目前为止，已有 12 个组件推出了 AI 变体，例如模态框、数据表格和文本输入框等。

IBM Carbon 设计系统中的 AI 定制化组件清单

尽管这些 AI 定制组件采用了独特的视觉处理，但在实际使用场景中，仍难以区分当前处于激活状态的组件（因为它们看起来都像是被激活的）。

在下方表单示例中，AI 被用于自动填充大部分输入字段，因此这些字段均采用了 AI 变体样式。问题在于：即便处于默认状态，AI 变体仍会显示蓝色渐变和边框——这使得用户在视觉上难以辨别哪个组件当前真正处于可交互状态。

 AI 组件采用的蓝色渐变与边框设计，导致用户难以辨识当前处于激活状态的组件。

用户可以覆盖 AI 生成的输入内容，此时组件会自动从 AI 变体切换回默认样式。这一操作会将输入框中的” AI 标注”替换为”恢复 AI 输入”功能选项，从而让用户可以自由选择手动输入或采用 AI 自动填充的表单响应方式。

Carbon 的”恢复至 AI 输入”功能会在用户覆盖 AI 生成内容时出现

除 AI 变体外，该组件还包含一个显性的” AI 标签”，点击后可弹出浮层，详细说明当前场景中 AI 的具体功能（Carbon 将此模式称为” AI 可解释性设计”）。用户点击 AI 标签时，解释性浮层会在按钮下方弹出。

Carbon 的 AI 标签配有解释性浮窗，用户可通过该浮窗获取 AI 功能的具体使用说明。

结论

Carbon 设计体系关于 AI 模式和组件的文档完善程度令人惊喜。它不仅提供了 AI 功能的通用使用说明，还实际设计了可复用的组件和交互模式。

但由于 AI 组件的变体在实际使用中难以区分哪个组件处于激活状态，我认为存在可用性和无障碍性问题。这些 AI 变体通过色彩使用吸引了过多注意力，并且看起来与Carbon 的焦点状态相似（这可能会影响依赖焦点状态的视力障碍用户）。

Carbon 系统中 AI 变体组件与文本框焦点状态的对比问题

3.Twilio 的 Paste 设计系统

最后，Paste 在其”体验”板块下专门设有”AI”分区。该分区既包含 AI 在用户体验中的应用指南，也提供了一些可直接调用的组件资源。

在设计 AI 功能时，Paste 建议允许用户将 AI 生成结果与其当前体验进行对比，并处理潜在的错误和风险。为降低这些错误的影响，Paste 主张应赋予用户以下能力：审核和撤销输出结果、控制数据来源，以及向 AI 系统提供反馈

Paste 同时建议，在设计新的 AI 功能时，开发者应当自问：”如果这个功能实现相同效果但不使用 AI，我会如何设计？”用户使用产品并非只是为了与AI 交互——他们的根本目的是尽可能高效地完成任务并达成目标。

Paste 提供的 AI UI 工具包包含5个核心组件：AI 图标、标识徽章、功能按钮、进度指示条以及骨架加载动画。该工具包还包含专为 AI 聊天体验设计的特定组件，例如AI 聊天记录界面。

Paste 文档中最具实用价值的是其提供的示例说明，主要包括三大类：功能标识指引、生成式功能实现以及智能对话界面设计。

在功能标识方面，Paste 建议采用带有 AI 图标的装饰性徽章来标注使用 AI 技术的功能，例如 AI 推荐或预测功能。这类标识组件虽然不具备交互功能，但其按钮式设计会营造出可点击的视觉暗示。

Paste 的 AI 功能标识示例（徽章+ AI 图标）

生成式功能会为用户提供提示，帮助他们使用该 AI 功能，例如 “总结数据” 或 “推荐下一步操作”。当你选择生成式功能时，其下方会弹出一个窗口，向用户提供使用说明以及该功能所采用的 AI 模型信息。

Paste 的生成功能包含一个带有弹出框的按钮，用于指导用户与人工智能进行交互。

最后，该对话相当典型地体现了当今常见 AI 聊天机器人的特点，其中还包含对其会话原则的引用，以塑造该 AI 的个性特征。

Paste 平台的 AI 聊天机器人界面设计，包含空白初始状态及输入框下方的引导提示语

Paste 平台即将为加载模式推出另一种设计范式，不过我们还需拭目以待。该模式将赋予用户控制和预判 AI 输出的能力——包括停止输出功能，并能根据 AI 生成耗时动态调整界面状态。

结论

我很高兴看到既有一些文档资料，又有我们可以参考的实际案例。虽然其中一个案例是聊天机器人，但这个 AI  UI工具包中的其他组件展示了在界面中展示 AI 使用情况时如何做到透明化。

Paste 正在就其 AI  UI工具包征求反馈意见——他们在 Github 上有一个公开的讨论区，你可以在那里提交需求。