AI 助手如何以上下文为界面重构跨应用体验

设计的未来在于产品之间发生什么

想象一下，你收到朋友推荐一家餐厅的消息。你想查看它的位置，看看那天晚上是否有空，并回复一个双方都合适的时间。你在消息中搜索，打开链接，查看位置，切换到日历，返回对话，最后写下你的 回复。

每一步单独来看都很简单，但合在一起却造成了碎片化的体验。你必须将一个产品的上下文带到另一个产品中，记住自己在做什么以及接下来需要做什么。这是一种熟悉的交互方式。多年来，我们围绕单个任务设计产品，让人们自己去连接这些任务。但当 AI 能够解读意图并帮助跨产品执行时，体验开始 改变。

问题变成了如何设计界面之间发生的事情。

从应用转向 上下文

应用成为数字体验的主导模式，因为它为软件提供了清晰的结构。每个产品都有自己的界面、功能和管理信息的方式。人们在不同应用间切换以完成 任务。

问题是人们的意图很少遵循这些边界。规划一次旅行涉及对话、日历、地图、预订和支付。组织一场会议需要关于人员、空闲时间、地点和承诺的信息，这些信息可能存在于几个不同的系统中。

每个产品单独运行可能都非常完美，但整体体验仍然是碎片化的。AI 使得从另一个方向处理这些活动成为可能。助手不再要求人们识别正确的应用并浏览其功能，而是可以从他们的意图出发，确定哪些信息和功能是相关的。

Apple 在 Siri 和 Apple Intelligence 上的工作体现了这一方向。通过其 App Intents 框架，Apple 允许开发者描述可供支持的系体验使用的操作和内容。这为 Siri 和其他支持的功能提供了一种结构化的方式来发现应用程序能 做什么。

想象一下，让 Siri 查找朋友在之前的对话中推荐的餐厅，检查你周五的空闲情况，并帮助准备预订。根据可用的集成和权限，助手可以连接那些原本需要多次手动搜索才能获取的信息。应用程序仍然对其数据和功能负责，但它们的能力可以通过始于其他地方的体验来访问。

这改变了设计问题，因为挑战不再局限于帮助某人浏览应用。它还涉及在正确的上下文中，在变得 有用之际，提供正确的信息和功能。

有关其工作原理的实际解释，请参阅 Apple 关于 Apple Intelligence、Siri 和 App Intents 的开发者文档，其中描述了应用实体、架构模式和屏幕上下文如何帮助系统解读和使用应用功能。

情境是一种设计材料

情境一直是用户体验（UX）的一部分。它帮助系统理解用户想要做什么、哪些信息是相关的，以及接下来应该发生什么。它可以包括当前的对话、用户的偏好、之前的决策或正在进行任务的状态。它还可以包括约束条件，例如日历是否可用，或者某个操作是否需要权限。

当有人请求餐厅推荐时，仅凭请求本身可能不够。助手可能需要了解场合、涉及的人员、地点、可用的时间以及任何重要的偏好。其中一些信息可能已经存在。其他细节可能需要被询问。

为情境进行设计意味着决定在每个阶段哪些信息重要，以及它们应如何影响体验。这也意味着决定哪些内容应被记住，哪些应在产品之间共享，以及哪些应保持 私密。

当任务跨越时间或产品时，记忆变得尤为重要。助手可能会记得朋友推荐了某家特定餐厅，周五是首选的晚上，或者用户通常避免嘈杂的地方。但记住信息并不等同于知道该信息是否仍然相关。系统应该能够展示其打算使用的情境，特别是当该情境影响决策时。向某人显示一家餐厅是六个月前由朋友推荐的，这给了他们在助手采取行动之前确认或纠正信息的机会。记忆应有助于保持连续性，而不应将过去的行为变成未经质疑的假设。

不幸的是，情境很少是完整的。一个人可能会说，“在附近找地方吃晚饭”，而没有指定预算、菜系或确切时间。系统必须决定是否有足够的信息继续执行，还是应该提出一个问题。

这对产品如何组织其信息具有影响。在 Apple 的 App Intents 框架中，开发人员定义实体、参数和操作，以便支持的系统体验能够理解应用程序包含的内容及其功能如何使用。这些定义会影响系统能否识别正确的条目、解释请求并可靠地执行操作。

这些决策对交互的影响不亚于界面本身。它们决定了体验是否显得相关，用户是否理解正在发生的事情，以及系统能否在不做出关键假设的情况下采取行动。

因此，情境本身成为一种设计材料。它是使体验连贯的结构的一部分，需要被结构化、解读和主动设计，而不仅仅是收集。

UX 治理定义了边界

当助手跨产品连接信息和操作时，需要有人确定这些信息如何使用以及系统允许对其做什么。

考虑一个安排会议的助手。它找到一个可用的时间，检索参与者的联系方式，并准备邀请。它应该自动发送邀请，还是请求确认？哪个日历应被视为权威来源？如果在邀请发送之前可用性发生变化，会发生什么？

这些是用户体验治理的问题：即决定体验如何在不同产品和情境中表现的一系列共享原则和规则。治理确立了谁可以访问信息、哪些操作可以被委托、何时需要审批，以及如何识别和纠正错误。如果没有这些共享规则，跨越多个产品的体验可能会变得不一致，即使每个应用程序都按预期运行。

NIST AI 风险管理框架为思考这些责任提供了有用的基础。其四项功能——治理（Govern）、映射（Map）、测量（Measure）和管理（Manage）——提供了一种识别风险、确立问责制、评估系统行为以及随时间管理问题的方法。

模型上下文协议（Model Context Protocol，简称 MCP）是另一项相关进展。它为 AI 应用程序连接外部工具和数据源提供了标准方式。这为系统协同工作创造了机会，同时使关于访问权限、授权和责任的问题成为设计的重要组成部分。

对于设计师而言，这些问题本身就是体验的一部分。如果助手可以在不同产品间采取行动，那么这些行动的边界必须是可理解的。人们应该知道系统可以访问什么、它打算使用哪些工具，以及何时需要他们的批准。

这也意味着要使工具的使用可见。当助手搜索日历、从消息中提取信息或向其他服务发送请求时，人们应该有办法了解发生了什么以及原因。目的不是暴露每一个技术操作，而是提供足够的信息，让人们能够跟随流程并对结果保持信心。

治理不能仅由一个设计团队承担。它需要设计、产品、工程、安全、法律以及负责相关系统的团队之间的协作。NIST AI 风险管理框架手册可以帮助将这些责任转化为整个开发过程中的实际活动。

为不确定性而设计

即使是治理良好的系统也可能误解语境。助手可能会找到六个月前的餐厅推荐，并将其解释为当前的偏好。它可能会识别出消息中的日期，但误解其指的是哪个事件。信息是可用的，但其含义取决于系统可能无法完全理解的情境。

这也影响信息的呈现方式。人们需要足够的可见性来理解助手推断出了什么、它正在使用哪些细节，以及它计划做什么。他们应该能够在不重启整个任务的情况下纠正假设。

有用的设计必须考虑到这种不确定性，而不是将每一次推断都视为事实。一种实用的方法是区分用户明确提供的信息和从语境中推断出的信息。另一种方法是在确定需要多少确认时，考虑错误决策的后果。

餐厅建议可以作为选项呈现，并简要说明选择它的原因。如果尚未授权这些细节，预订应在确认前明确日期、时间和人数。冲突的日历条目可能需要提出问题，而不是自动做出选择。

同样的原则也适用于助手如何传达其计划。在执行涉及多个步骤的任务之前，它可以解释打算做什么、需要哪些信息，以及用户可能需要做出决定的地方。对于简单的请求，这可能只需要简短的说明。对于影响更大的任务，这可能意味着展示一系列操作，并在继续之前等待批准。

当任务跨产品持续进行时，规划和可见性变得尤为重要。如果助手正在寻找餐厅、检查可用性并准备预订，用户应该能够看到已完成的内容、正在进行的内容以及待决定的内容。如果没有这种可见性，即使流程成功，也会让人感到不可预测。

对于设计师来说，实际问题很直接。系统知道什么？这些信息来自哪里？它做出了哪些假设？它下一步计划做什么？犯错的成本有多高？用户能否理解并纠正结果？

这些问题有助于团队为整个旅程进行设计，包括系统无法自信地继续前进的时刻，而不是将不确定性视为边缘情况。它们还使体验在出现问题时更易于理解和恢复。

产品团队不再拥有完整的体验

当任务跨越多个产品时，没有一个单一的界面必然包含完整的体验。用户可能在对话中开始，使用日历中的信息，依赖推荐服务，并通过另一个产品完成操作。

每个产品仍然有其角色。它的价值也取决于它在更广泛旅程中的参与程度。这改变了产品团队需要提出的问题。他们需要了解其产品提供了哪些信息，其他系统可以请求哪些操作，以及这些操作如何融入可能始于别处的任务中。

这在产品和用户之间创造了一种不同的关系，因为产品可以在用户完全未访问其界面的情况下促成成功的结果。

对产品团队而言，这意味着应用会话和屏幕时间是价值的非完整衡量标准。一项服务可能通过助手帮助某人完成预订，即使用户从未打开其主屏幕。这并不会降低界面设计的重要性，而是改变了围绕它的工作范围。

这也意味着团队需要考虑其产品如何向自身界面之外的系统传达进度和责任。如果一个操作由一个产品启动并由另一个产品完成，过渡不应让用户困惑于发生了什么或谁对结果负责。

即使体验的各个部分属于不同的团队，体验也需要保持连贯。这需要就每个产品能做什么、其操作如何报告，以及当下一步无法完成时会发生什么达成共同预期。

设计师接下来应关注什么

设计师可以从映射任务所需的上下文开始。这包括系统需要的信息、信息的来源、信息随时间的变化方式，以及涉及哪些产品。他们还需要定义当上下文缺失、不完整或模糊时系统应如何表现。

Microsoft’s Guidelines for Human-AI Interaction 为这项工作提供了有用的基础。在这些原则之上，我们可以识别出一套用于设计代理体验和流程的反复出现的模式，无论其具体 领域如何。

规划与可见性

团队需要决定助手何时应解释其预期步骤、何时应显示进度，以及人们如何理解跨多个产品的任务状态。详细程度应根据任务的复杂性和后果而定。人们需要足够的可见性来了解系统计划做什么、已完成什么，以及哪些内容仍需要他们的关注。

记忆呈现

设计师应考虑系统如何利用过去的对话、偏好和决策来影响当前体验。人们需要了解哪些信息正在影响推荐或操作，并在这些信息过时或不再相关时进行纠正。目标是提供连续性，同时避免将过去的行为变成未经质疑的假设。

工具使用披露

当助手使用外部工具或跨产品访问信息时，人们应该能够了解它访问了什么以及采取了哪些行动。团队需要区分建议、尝试的操作和已完成的结果。这使得系统的行为更易于理解，并帮助人们知道何时需要进行干预。

多步工作流跟踪

跨越多个产品的任务应该感觉像是一段连续的旅程，而不是一系列脱节的操作。设计师可以映射其阶段、阶段间传递的信息以及需要用户参与的决策。人们应该能够看到已完成的内容、正在进行的内容以及剩余待办事项，而无需自己重建整个过程。

恢复路由

并非每个任务都会按计划进行。助手可能会遇到缺失信息、操作失败或无法自信做出的决策。设计师需要定义系统在这些情况下的响应方式，无论是通过提问、返回早期步骤、提出替代方案，还是将控制权交还给用户。恢复过程应保持已建立的上下文，并帮助人们继续操作而无需从头 开始。

自主性

团队还需要决定赋予系统多少自主权。自主性不是在完全手动体验和独立执行所有操作的助手之间二选一，而是一个光谱。

助手可能会在不采取任何行动的情况下推荐一家餐厅、准备一份预订供审查，或在获得必要权限后完成预订。适当的级别取决于任务、用户的偏好、可用信息的可靠性以及犯错的 后果。

为自主性进行设计意味着使从推荐到准备再到行动的过渡变得可理解。人们应该能够委托常规步骤，同时保留对他们重要的决策的控制权。他们还应该能够改变主意、中断流程，或在系统达到极限时接管 操作。

测试

测试应跨越产品跟随任务进行。团队不应单独评估每个界面，而应审视从初始请求到最终结果的完整旅程。他们可以测试当信息不可用、系统做出错误假设、操作失败或用户改变主意时会发生什么。这有助于揭示各产品之间可能存在的差距，而这些差距在单独测试每个界面时可能并不明显。

协作

设计这些体验需要跨产品边界的协作。设计师需要与工程师和其他团队合作，了解系统功能、数据访问权限和限制，然后将这些约束转化为人们能够理解并信任的体验。

目标是让产品之间的连接感觉连贯一致，同时保持底层操作的可见性、可理解性，并确保用户对其拥有控制权。

超越界面

餐厅示例始于一个简单的推荐。完成任务所需的信息、决策和操作分布在多个产品中。随着 AI 系统能够处理更多此类连接，体验将取决于上下文如何在步骤之间传递。

设计挑战在于使这一过程有用、易于理解，并尊重系统之间的边界。人们需要知道助手记住了什么、它计划如何继续、使用了哪些工具，以及当任务无法按预期完成时会发生什么。他们还需要控制委托的程度，并在必要时介入的能力。

界面仍然是人们查看、引导和纠正正在发生的事情的地方。但更多的体验是由围绕界面的上下文、系统做出的决策以及决定其能做什么的规则所塑造的。

为这一未来进行设计意味着超越单个屏幕，考虑产品之间的关系。这意味着从一开始就将上下文、记忆、规划、权限、恢复和治理视为体验的一部分。

设计的未来在于产品之间发生的事情。

参考文献

1. Apple Developer Documentation. Apple Intelligence and Siri AI. 关于向 Siri 和 Apple Intelligence 暴露应用内容和操作、可转移实体、模式及屏幕上下文的技术指导。
2. Apple Developer Documentation. Getting started with the App Intents framework. 介绍如何通过系统体验使应用操作和内容在应用外可用。
3. Apple Developer Documentation. Providing contextual cues to Apple Intelligence and Siri. 关于将应用实体与屏幕内容关联，以便 Siri 解释上下文引用的指南。
4. Techstrong AI article on the MCP AI governance gap. 该文章强调了企业在将 AI 系统与工具和组织数据连接时需要解决的问题。
5. National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0). 一个用于管理 AI 风险和支持可信 AI 系统的自愿框架。
6. 美国国家标准与技术研究院 (NIST)。 NIST AI RMF 手册。与框架的治理、映射、测量和管理功能相一致的实用建议。
7. Amershi, S. 等人 (2019)。人机交互指南。 2019 年 CHI 计算机系统中的人因会议论文集。
8. 微软研究院以及微软的智能体 UX 设计 。

来自 AI × 品味

一个探讨 AI 时代品味经济学的月度系列：

• AI 让每个人都成为创作者，而非设计师
  AI 如何让生成变得丰富，从而使设计判断力和品味成为新的竞争优势。
• 低品味的组织成本
  薄弱的设计判断力如何在产品、团队和组织中产生复合效应。
• 品味无法被委派
  为什么 AI 可以生成无限的可能性，但决定什么应该存在仍然是根本的人类任务。
• 为代理而设计
  为什么 AI 正在改变谁先阅读，以及当我们针对中介而非 人进行优化时会发生什么。
• 当画布开始行动时，谁真正掌控局面？
  智能界面如何改变设计师的控制范围，从交互到能动性、编排和注意力。
• AI 时代的注意力经济学。当机器开始关注时，什么值得我们的 关注？
• 语境是新的界面。设计的未来在于产品之间发生的 事情

语境是新的界面最初发表于 Medium 上的 UX Collective，人们通过突出显示和回复该故事来继续对话。