Nielsen Norman Group 实测新 Siri：个人上下文比智能更重要

摘要：一个有用的 AI 助手需要相关的个人上下文、使用这些上下文的能力，以及一种能帮助用户理解其局限性的体验。

Apple 或许不需要最聪明的 AI 来打造最有用的 AI 助手。智能手机已经保存了我们日常生活的大部分上下文：我们的消息、照片、联系人、位置、日程、社交媒体，以及我们全天使用的各种应用。能够访问所有这些上下文的 AI 助手，相比那些虽然高度智能但需要用户提供这些信息的助手，拥有重要优势。

Apple 新推出的 Siri AI 于 2026 年 9 月 14 日开始以英文测试版形式推出，提供了一个有用的案例研究。它的成功与失败表明，为什么个人上下文与 AI 能力在有用的 AI 个人助手设计中应当相辅相成。它们还说明了随之而来的一些用户体验挑战：当上下文在应用之间丢失时会发生什么，以及为什么用户需要准确理解 AI 代理能做什么。

个人上下文与 AI 能力相辅相成

一个有用的个人 AI 助手两者都需要：

访问相关信息的能力
利用这些信息做有用之事的能力

为了了解这两者如何协同工作，我在周末去纽约市旅行后，给旧版 Siri、Apple 新的 Siri AI 和 ChatGPT 分配了相同的日常任务：查找我的照片、查找我哥哥的餐厅推荐，并给我的伴侣起草一条消息。这些任务需要的不只是巧妙的对话。每一项都要求助手能够找到正确的信息并理解我想用它做什么，而无需让我自己收集所有内容。

每个助手在这两方面的组合各不相同。旧版 Siri 已经具备个人数据功能，包括 iOS 9 中引入的情境提醒和照片搜索，但并非真正的生成式 AI。OpenAI 的 ChatGPT 则情况相反：它是一个能力强大的对话模型，但无法直接访问这些任务所需的个人消息和照片。Siri AI 两者兼备。两个版本的 Siri 在检索上下文的方式上也有所不同。Apple 描述了 Siri AI 如何使用设备端的 Spotlight 索引，其开发者文档解释了语义索引如何使应用内容可按含义和关系进行搜索。该索引是 Siri AI 有用性的很大一部分，但模型仍需解释请求并使用索引返回的内容。我的示例展示的是两者结合的结果，而非各自贡献的单独体现。

访问个人上下文可减少用户操作

个人上下文将助手的回答建立在用户自己的信息之上；没有它，即使能力再强的模型也只能猜测或发问。AI 代理应当能够回答关于用户手机上已有信息的问题，而无需用户自己去查找并粘贴到对话中。

当我问 Siri AI：“我弟弟 Emmett 在纽约给我推荐过哪些餐厅？”时，它迅速找到了他发短信推荐的那三家早餐店。接着我问：“我去过其中任何一家吗？”它正确地回答说没有，并引用了我回复 Emmett 说我选了别处的那条短信。我可以直接询问这段对话，而无需记住答案在哪条短信里、翻找短信记录，或把它们粘贴到聊天机器人中——那样做反而会违背提问的初衷。

Siri AI lists three restaurant recommendations with short descriptions and source labels, then answers the follow-up with a Messages source label. — *Siri AI 列出了 Emmett 的推荐（左），然后引用我的回复回答了我的追问（右）。每条答案下方都显示了“信息”标签。*

另一方面，ChatGPT 搜索了我连接的工作账号，但一无所获；那些账号能提供信息，却无法提供我问题所需的上下文。只有当新增的数据源包含用户任务所需的信息时，连接更多数据源才有意义。设计的关键在于明确用户需要什么信息，以及助手如何在获得用户许可后检索到这些信息。只有当连接更多数据源有助于 AI 智能体找到相关信息时，这样做才有用。

访问权限的边界同样重要。当我问：“Peter 关于周六说了什么？”时，Siri AI 找不到他发来的关于那天的短信或邮件。它提供了我发给 Anna 的一条短信中的相关信息——关于约他一起去看 Citi Bike 比赛，但漏掉了 Peter 通过 Signal 发来的“5:30 在 Olea 见”的消息，因为 Signal（一款注重隐私的应用）默认无法被 Siri 访问。

答案本应区分 Peter 本人发来的消息和他人转述的他的计划，并说明检索了哪些数据源。否则，“我没找到”听起来就像“它不存在”。

智能体体验必须向用户展示检索了哪些数据源，并说明相关的缺口。在支持的情况下，提供授权访问其他数据源的途径；否则，帮助用户补充缺失的信息。例如，一条补救提示可以这样写：我搜索了“信息”和“邮件”，但没有找到 Peter 关于周六的计划。如果他在别处提过，请把消息粘贴在这里。用户不应该为了弄清朋友说了什么，还得先搞明白助手连接了哪些应用。

AI 能力：将上下文转化为有用的结果

仅有访问权限并不能保证得到有用的回答。AI 智能体还必须理解用户的意图，而且它的回答应当让这种理解足够透明，以便用户进行验证。

旅行结束后，我让每个 AI 助手（旧版 Siri、新版 Siri AI 和 ChatGPT）“给我看看上周末在纽约拍的照片”。旧版 Siri 显示了通用的网络图片；ChatGPT 搜索了网络并提供了新闻图片链接；Siri AI 找到了我的旅行照片。

当我把旧版 Siri 的请求改为“给我看看我在纽约的照片”时，它打开了“照片”应用，但显示的是整个相册。而 Siri AI 返回了旅行照片，尽管请求中从未提到“我的照片”——这显然是一个进步，尽管这次对比无法区分模型的贡献和检索系统的贡献。

Old Siri shows generic New York images; ChatGPT lists links to news photo galleries; Siri AI shows the author’s trip photos. — *当被要求查看上周末在纽约拍的照片时，旧版 Siri（左）显示了通用的网络图片，ChatGPT（中）提供了新闻图片链接，而 Siri AI（右）找到了我的照片。*

这种差异也体现在消息起草任务中。当我要求“把 Emmett 推荐的餐厅清单发给 Anna”时，Siri AI 为我的伴侣准备了正确的清单。旧版 Siri 选择了不同的联系人，并把消息正文写成了对请求的字面复述。两者都显示了草稿并请求确认。

Old Siri prepares a message to the wrong contact containing the request itself; Siri AI prepares the restaurant list for Anna. Both show Cancel and Send controls. — *两个版本的 Siri 都允许我在发送前检查消息。旧版 Siri（左）的收件人和内容都不对；Siri AI（right）准备了正确的草稿。*

确认在助手通常能正确理解请求时也很有价值，尤其是当执行错误动作（即把消息发给错误的人）的代价很高时。

当请求含糊不清时，一个简短的澄清问题会带来一些摩擦，但可以避免得到一个远为无用的答案，而后者最终可能让用户付出大得多的代价。

我向 Siri AI 提出：“在 Google Maps 中规划从 Emmett 的地址到 Dimes 的路线。”Dimes 是一家靠近 Dimes Square 的餐厅，而 Siri AI 选择了街区 Dimes Square。识别出一个看似合理的地名还不够。当备选项会导致不同动作时，智能体应在行动前询问：“你指的是餐厅 Dimes，还是街区 Dimes Square？”

在整个任务中保持上下文

找到正确的信息只是任务的一部分。助手还必须将用户的要求带入执行这些要求的应用中。

同一个路线请求以第二种方式失败了。Siri AI 询问我是否指从 Emmett 的地址出发，我很乐意确认。随后它打开 Google Maps，规划的却是从我当前位置（北卡罗来纳州达勒姆）出发的路线。

Siri AI asks whether the route should start from Emmett’s address, with private contact details obscured; Google Maps then labels the origin Your location and the destination Dimes Square. — *Siri AI 询问路线是否应从 Emmett 的地址出发（左），但 Google Maps 打开后以“你的位置”为起点、以 Dimes Square 为终点（右）。*

除了终点错误，路线的起点也是错的。在交互的某一步中确认过的细节必须延续到最终执行的动作中。从用户的角度看，尽管进行了澄清对话、应用也成功启动，任务仍然失败了。

设计多步骤智能体工作流时，要评估整个任务，包括目标应用中显示的内容。对于路线规划，这意味着检查起点和终点，而不仅仅是助手是否找到了联系人或打开了地图。要给用户提供在开始导航前检查和修正路线的方法。如果用户仍需自行发现并修正错误路线，打开正确的应用帮助不大。

帮助用户建立准确的心智模型

能力更强的助手仍需要帮助人们发现现在可以向它提出哪些请求。此前的 NN/G 智能助手研究发现，高频用户只依赖一小批简单任务，并警告说，习惯了功能有限的助手的人可能不会发现改进。

推荐的示例请求有助于用户发现新功能，但前提是这些请求指向的是助手确实能搜索的数据。“问问朋友推荐了哪些餐厅”如果该对话在 Messages 中就是好建议，如果在 Signal 中则是误导。每个建议都应配有一种在数据实际无法访问时的补救方式。

呈现方式也会影响用户的预期。Siri AI 的界面很简洁，文字回答简短而实用，尽管它的语音可以很有表现力。这种克制对 Siri 很有好处，因为它把重点放在回答问题和完成任务上。更丰富的个性可能会暗示出助手无法可靠提供的理解程度。尽管如此，设计师应该测试用户从其呈现方式中推断出什么，而不是仅仅假设更安静的身份就能让预期保持现实。

进度反馈也会影响用户对助手工作方式的理解。在起草消息时，Siri AI 显示了搜索联系人和搜索邮件，但也显示了搜索网站，却没有解释原因。一个与用户对助手应当如何工作的心理模型不符的步骤，会引发疑问和怀疑，而不是建立信心。

Siri AI displays a spinner and the activity label Searching websites. — *在起草消息时，Siri AI 显示了搜索网站，却没有解释该搜索与请求之间的关系。*

进度标签显示了活动，但透明并不等于可解释。该标签可能无法帮助用户理解正在发生什么。当某个来源的相关性不明确时，要解释它，并展示答案的来源。界面本应解释搜索网站如何服务于我起草个人消息的请求。

结论

一个有用的助手需要的不只是设备上某处的信息。它需要一种检索相关上下文的方法、解读这些上下文的能力，以及一种在最终操作中保留用户意图的交互。Siri 的例子说明了为什么这些要求是相互关联的。

在设计 AI 助手时，先考虑用户应当能够自然地询问哪些内容，然后构建支持这些请求所需的访问、检索和交互。让限制可见，并给用户提供纠正错误的方法。一次有能力的对话应当带来有用的结果，包括当任务在另一个应用中继续进行时。

关于这些示例

我在一台 iPhone 14 上使用旧版 Siri，在一台运行 iOS 27 的 iPhone 18 Pro 上使用 Siri AI 和 ChatGPT Plus（使用 GPT-5.6 Sol，high effort）。ChatGPT 的记忆功能已关闭，并连接了工作 Gmail 和 Slack。独立请求会从全新状态开始；餐厅的后续请求延续了前一个请求。ChatGPT 的照片请求是口述到其文本框中的；后续请求使用了语音模式。大多数请求运行了一到两次。设备、输入方式、模型和检索系统上的差异，使得这是一次动手探索，而不是对其贡献的受控比较。