Gemini Map 工具上线，Google 以 @ 替代斜杠命令

Google 已在 Android 和 iOS 上推出 Gemini Map 工具，同时还进行了第二项界面调整：以 @ 菜单取代斜杠命令。

该地图功能让用户可将一个地理区域直接放入提示词，而无需用文字描述该区域。@ 的调整则将 Skills、已连接服务及其他工具整合至同一选择层。

这些更新共同指向了一种不同形态的 Gemini 应用。Google 正将提示框从空白文本栏变为用于选择上下文和功能的控制界面。

眼前的变化并不算大。用户获得了可视化的位置选择器和整合后的菜单。更大的押注在于：当人们能够准确展示助手应在哪个区域工作时，助手会变得更有用。

这给传统的文本优先聊天机器人界面带来了压力。OpenAI、Anthropic 和其他助手开发商都在扩展工具使用能力，但 Google 拥有移动端分发与地图基础设施这一独特组合。

Gemini Map 工具正在测试，这项优势能否转化为更好的提示体验。它也带来了人们熟悉的问题：可用性、位置准确性、数据处理方式，以及 Gemini 是否能可靠地根据所选上下文采取行动。

Gemini Map 工具将区域转化为提示上下文

这项新地图功能将位置从用户需要描述的内容，变成可以直接选择的内容。

移动端 Map 工具出现在 Android 和 iOS 的 Gemini 应用附件轮播栏中，与 Photos、Camera、Files、Drive、Avatar 和 Notebooks 等选项并列。

选择 Map 后，会打开以用户当前区域为中心的实时视图。界面包含一个圆形焦点区域，用于标识 Gemini 应当考虑的位置。

用户可以移动地图、放大或缩小，或搜索其他目的地。点击“探索此区域”后，提示框中会添加一个“地图区域”附件。

该附件可以与文字请求结合使用。例如，旅行者可以选择酒店周边几个街区，并要求推荐适合开会的安静餐厅。

用户还可以选择一个陌生街区，请求推荐靠近交通站点的咖啡馆。计划跑腿办事的人则可让 Gemini 找出所选区域内值得顺路前往的地点。

关键区别在于精确性。“市中心附近”这类说法可能涵盖边界不清的地理范围，而地图选择会为系统提供明确的视觉参照。

这并不能保证答案正确，但在 Gemini 开始对请求进行推理之前，它减少了一种歧义来源。

这一工作流还将区域选择与目的地搜索分开。用户无需从商家的准确名称或地址开始。

他们可以先从地理位置出发，再通过提示描述自己的意图。这种结构比传统目的地输入框更适合探索性问题。

据报道，该功能仅在移动端推出。目前 Gemini 网页界面尚无法使用 Map 选项，尽管网页版应用可在相关回答中使用位置信息。

这一差异很重要，因为该交互依赖触控操作。在旅行途中使用手机时，在地图上拖动并调整目标区域会显得自然。

它也比在应用之间复制坐标、街道名称或链接更直接。地图因此成为一种与图像或文档类似的输入对象。

Google 此前已在其他场景中将 Gemini 与地理信息连接起来。其早期推出的 Maps grounding 为开发者提供了覆盖超过 2.5 亿个地点的信息访问能力。

面向消费者的 Map 工具则在界面层面应用了同样的广义思路。它让用户在要求 Gemini 解读之前，先定义地理上下文。

不过，这一新的选择器不应与完整导航混为一谈。据报道，该界面用于准备基于位置的提示，而不是替代逐向导航。

它也并未表明每项请求都会使用实时路况、私人收藏地点或完整商家信息。这些能力取决于 Gemini 可以访问哪些服务。

更稳妥的解读应当更为有限：Google 创建了一种将所选区域直接附加到 Gemini 对话中的方式。

这一新增功能之所以重要，是因为地理提示往往难以准确表达。所选区域能为 Gemini 回答此类问题提供更清晰的边界。

它也构成了本文的核心张力。Google 可以提供异常丰富的位置上下文，但用户仍需了解哪些数据会进入对话。

Google 正围绕工具重构提示框

提示框正变为专业输入、可复用指令和已连接服务的启动器。

Map 选项是这场转变的一部分。根据最初报道，另一部分变化出现在 Google 应用 beta 17.63 版本中。

在该 beta 版本中，输入正斜杠会显示一条消息，提示斜杠现已改为 @。界面称，用户可以从同一位置访问 Skills、Connectors 等内容。

Google 不久前才将斜杠引入，用于调用 Skills。如此快速的切换表明，Google 认为统一的工具菜单比保留这种命令惯例更重要。

@ 符号在许多数字产品中已有明确含义。它通常表示某个人、服务、代理或资源应参与当前任务。

这种心智模型对 Gemini 很有帮助。用户可以将 Skill 或已连接应用视为明确的能力来源，而非不可见的系统设置。

更广泛的界面也在改变其术语。“Connected Apps”预计将更名为“Connectors”，而 Gems 则由 Skills 取代。

Google 将 Gemini Skills定义为可用于重复性任务和工作流的可复用自定义指令。Gemini 可以自动应用相关 Skill，用户也可以明确指定。

这一模式不同于一次性提示。Skill 会保留一种可重复的方法，在出现类似任务时再次调用。

Google 还表示，多个 Skills 可以协同工作。一个可以确立组织的写作规范，另一个则定义制作每周报告的步骤。

@ 菜单让这些可复用指令与外部服务拥有共同入口。它将提示框变成模型、已保存工作流与已连接数据之间的路由层。

Google 9 月的已连接应用扩展展示了这一雄心的规模。公司宣布在生产力、创意和生活方式类别中推出集成。

其示例涵盖项目管理、数据库组织、设计、网站构建、锻炼计划、公寓搜索、信用监测和活动发现。

用户可在设置中连接受支持的服务。随后，他们可以通过 @ 提及或直接请求，将某项服务带入对话。

新界面缩小了这些服务与 Google 自身可复用 Skills 之间的差异。二者都成为同一对话中可调用的资源。

Map 将这一资源模式扩展到了物理空间。所选区域会成为 Gemini 可与文件、照片、笔记本和已连接应用一同使用的另一种对象。

这种整合可减少界面摩擦。用户不再需要记住某项资源使用 @，而另一项使用斜杠。

但它也可能让菜单变得拥挤。单一选择器最终可能包含个人 Skills、工作场所流程、Google 服务、第三方工具和媒体输入。

因此，可发现性将与可用性同等重要。如果用户无法预测 Gemini 选择了哪项资源，整合可能会掩盖复杂性，而非消除它。

自动路由带来了相关担忧。Gemini 选择合适 Skill 的能力可以节省时间，但错误选择可能悄然改变结果。

明确的 @ 提及提供了有用的平衡。它让用户在模型解读任务前指定预期工具。

界面仍在过渡之中。Map 工具被描述为广泛可用，而斜杠命令的替代方案尚未广泛推出。

因此，用户可能会在不同账户、平台和应用版本中看到不同控件。beta 界面不应被视为一项已完成的全球迁移。

Google 的方向比其时间表更清晰。该公司希望 Gemini 提示框协调一组工具，而不只是接收自然语言文本。

Gemini Map 工具凸显 Google 的地理优势

Google 的优势不只是地图选择器本身，更在于其背后的地图系统。

竞争性助手可以接受地址、坐标、截图和与地点相关的问题。有些还能调用网页搜索或外部服务，以获取当前地点信息。

Google 处理这一问题的起点不同。它运营 Google Maps，在 Android 上分发 Gemini，并管理包含有用个人上下文的服务。

这种组合使位置成为产品整合的自然领域。它也让 Google 有机会缩短目前在聊天机器人和地图应用之间切换的工作流。

在新的消费者选择器出现之前，Google 已开始向开发者展示这一策略。其面向 Gemini API 的 Maps 工具将模型回答与当前地理空间信息连接起来。

公司表示，该开发者产品取材于超过 2.5 亿个地点。这一规模为 Gemini 回答餐厅、景点、服务和行程问题提供了坚实基础。

Google 还在持续扩展 Maps 内部的 Gemini。一条路径从导航开始，在旅途中引入对话式协助。

Gemini Map 工具则沿着相反方向发展。它从助手内部开始，将所选地理区域导入对话。

这两条路径正开始交汇。Maps 正获得更多对话能力，而 Gemini 正获得更明确的地理输入。

这种融合对“AI 助手应始终是一个独立目的地”的观念形成压力。Google 可以将 Gemini 置于基于位置的决策之前、期间和之后。

以周末规划任务为例。用户可以选择一个区域，要求提供若干选项，结合日历限制进行比较，然后继续进入导航。

Map 附件通过定义搜索区域来处理第一步。Connectors 最终可能提供可用性、预订、门票或其他任务特定信息。

Skills 则可以保留用户的重复偏好。已保存的指令可能优先考虑步行距离、较安静的场所、无障碍条件或特定的日程格式。

这种组合将使助手不只是一个地点搜索框。它将协调地理上下文、个人规则和已连接服务。

当前版本并未证明完整工作流能够可靠运行。它只提供了构建该工作流所需的若干界面组件。

这一区别很重要。视觉选择的区域并不能消除幻觉、过时列表、缺失营业时间或值得怀疑的推荐。

基于位置的推荐存在许多隐藏要求。系统必须理解边界、检索相关地点、对其排序，并说明它们为何合适。

任何一个环节出错，都可能削弱答案质量。即使地图区域选得再精妙，如果 Gemini 忽略了提示词中的重要限制条件，价值也十分有限。

Google 自身深厚的地图能力，仍会改变竞争格局。竞争对手可以接入地图服务提供商，但 Google 同时掌控着助手和主要的地理信息平台。

尽管 Google 在 iOS 上缺乏 Android 级别的操作系统控制权，它仍可通过自家应用触达 iOS 用户。Map 工具同时登陆两大移动平台，扩大了此次测试的覆盖范围。

网页版可用性仍是一个显著缺口。研究旅行目的地或商业地点的桌面用户，可能更偏好更大的屏幕和键盘。

Google 最终或许会将这一选择器扩展至网页端，但据报道的发布内容并未作出这样的承诺。其缺席使当前功能仍聚焦于移动端使用场景。

因此，竞争对手面临的压力是明确的：即使并不拥有底层地图，也必须让用户同样轻松地提供位置上下文。

Google 面临的压力同样真实。它必须证明，这种整合能带来更好的结果，而不只是增加进入现有服务的路径。

更好的位置提示词，也意味着更大的隐私负担

Map 工具消除了请求中的歧义，但也让数据边界变得更加重要。

Gemini 已经通过多种方式使用位置信息。Google 表示，在获得许可时，其应用可能会使用大致位置或设备的精确位置。

在移动端，这些权限部分取决于承载 Gemini 助手功能的 Google 应用。因此，平台设置可能影响 Gemini 获得的上下文。

新的 Map 界面引入了一个更具主动性的信号：用户自行选择一个区域，并将其附加到提示词中。

相比不可见的后台推断，这种操作更容易理解。所选地图以可见形式呈现了正在共享的位置。

然而，附加阶段的可见性并不能解答所有问题。用户可能仍希望了解提示词如何被存储、处理，以及如何与其他信息结合。

Google 的 Gemini 隐私控制说明，Gemini 信息可能包括提示词、上传内容、已连接应用的数据、设备信息和位置信息。

该文档还区分了大致位置与精确位置。用户在共享敏感地理上下文前，应检查应用权限和 Gemini 活动设置。

一次地图选择可能泄露的不只是目的地。它还可能标识住址区域、工作地点、医疗机构、学校或重复出行规律。

当位置信息与电子邮件、日历、文件、照片、联系人或第三方服务的信息结合时，风险会进一步增加。每一次连接都可能让回答更有用，也更具个人属性。

Google 表示，连接受支持的应用仍受用户控制。但当助手自动组合多个来源时，这种控制就更难评估。

统一的 @ 菜单或许会有所帮助，因为它能让被选中的资源可见。用户明确调用某个连接器时，会更清楚地知道它正在参与任务。

自动选择 Skill 则不那么直观。即使用户没有直接调用，已保存的工作流也可能影响答案。

Skills 是指令而非数据来源，但它们可能影响 Gemini 请求哪些信息，或如何使用已连接的信息。因此，透明度十分重要。

值得信赖的界面应显示哪些 Skill、连接器或附件影响了回答，也应让用户能在提交前轻松移除这些元素。

Map 附件似乎在提示词输入框中提供了这种明确对象。最终界面是否会解释后续数据使用方式，则仍是另一个问题。

准确性也属于这一风险讨论的一部分。所选区域在屏幕上可能很精确，但底层解释仍可能并不完美。

边界可能横跨街区、行政区、校园或商业区域。Gemini 可能将粗略圆圈视为严格搜索半径，也可能只把它当作一般提示。

该功能的名称可能让用户期待它会执行完整的地图搜索。对于关键细节，用户应在 Google Maps 中或直接向场所核实。

营业时间、无障碍设施、预订情况、道路状况和出行时间尤其如此。这些细节可能在 Gemini 生成回答后发生变化。

助手还应区分：哪些推荐基于当前 Google Maps 信息，哪些建议来自更广泛的网页材料。界面未必总能清晰呈现这种来源信息。

第二个不确定性与发布一致性有关。据报道，Map 工具已在 Android 和 iOS 上广泛出现，但功能可用性仍可能因账号而异。

@ 替代方案仍处于较早部署阶段。稳定版用户可能仍会看到斜杠菜单，而测试版用户则会获得整合后的选择器。

这种错峰状态可能使在线或组织内部共享的操作说明变得复杂。为某个版本记录的工作流，可能与其他人的屏幕并不一致。

Gems 向 Skills 的迁移带来了另一重过渡。现有的自定义助手正在转变为可复用的 Skills，也引发了兼容性和行为保留方面的问题。

Google 必须管理好这些变化，避免让熟悉的工作流显得不稳定。功能改名和调用符号变化，可能带来虽小却持续的学习成本。

Google 押注的是：一个统一的 @ 入口能抵消这部分成本。这一押注能否成功，取决于路由是否可预测，以及反馈是否清晰。

核心挑战并不在于 Google 能否在 Gemini 中加入更多工具，而在于用户能否理解哪个工具执行了操作、使用了哪些数据，以及如何进行纠正。

三个信号将显示 Google 的界面押注是否奏效

接下来的考验是：更简洁的工具菜单，能否带来更可靠、更易理解的操作。

第一个信号是 @ 选择器的全面推出。Google 需要将其从有限的测试版可用性扩展出去，避免 Android、iOS 和网页端的行为出现碎片化。

完整发布将强化这样一种观点：@ 是 Gemini 长期固定的工具调用语言。持续的不一致则会削弱统一界面的论点。

关键不只是这个符号本身。用户应能在受支持的设备上，看到 Skills、Connectors 和其他资源采用相同的基本组织方式。

Google 还必须解释，显式选择如何与自动路由互动。用户需要知道 Gemini 何时自行选择了某项 Skill，以及他们的 @ 提及何时覆盖了这一选择。

第二个信号是 Gemini Map 工具更广泛的可用性。网页端支持将表明，Google 将地理选择视为核心输入，而非移动端实验。

桌面端可用于旅行研究、房地产比较、物流、活动规划和基于位置的商业分析。这些任务通常受益于更大的地图。

更重要的是，Google 应说明所选边界究竟控制什么。用户需要确信 Gemini 会遵守该区域，而不会将其视为宽泛建议。

当当前 Google Maps 信息支撑某项推荐时，结果也应予以披露。清晰的依据会让该工具更易于信任和核验。

第三个信号是 Skills 与 Connectors 之间更深入的协同。当这些资源能够协作而不产生隐藏行为时，Google 的界面会更有价值。

用户可能调用一个规划 Skill，附加一个 Map Area，再调用一个预订连接器。随后，Gemini 需要在整个工作流中保留每一项限制条件。

这是一项严苛测试。系统必须维持上下文、调用正确的服务、呈现可恢复的错误，并避免采取非预期操作。

Google 先前扩展已连接服务的举措表明，它希望 Gemini 覆盖更多这类工作流。@ 菜单为不断扩大的目录提供了统一入口。

这一变化也反映了从聊天机器人走向工具型助手的更广泛趋势。模型仍居于核心位置，但有价值的工作越来越通过选定的上下文和外部系统完成。

这一转变可能惠及旅行以外的知识工作者。好的助手应让人们能够识别与每项请求相关的来源、工作流和边界。

同样的原则也适用于处理文档和个人信息。个人知识库在用户能够控制哪些上下文进入任务时，会变得更有用。

Google 的地图选择器提供了这一理念的具体版本。用户无需期待助手推断出正确地点，而是直接提供预期区域。

@ 菜单则将这一原则延伸至能力调用。用户不必完全依赖自动选择，而可以调用特定的 Skill 或连接器。

这两项变化都无法消除判断的必要性。用户仍需核验重要推荐、监控权限，并检查有哪些服务参与其中。

因此，Gemini Map 工具作为独立地图小组件的重要性，远不及它作为界面模型变化证据的重要性。

Google 正在用结构化选择替代空白提示词。文件、照片、地点、已保存指令和外部服务，都可以成为可见的组成要素。

如果这些要素始终易于理解，Gemini 就能显得更加精准，而无需更长的提示词。如果它们变得不透明，界面只会隐藏更多复杂性。

未来几个月，请关注 @ 的推广、网页地图支持和多工具透明度。这些共同将显示 Google 是否构建了连贯的助手界面。

目前，移动端用户可以直接测试这一核心前提。选择边界清晰的区域，提出带有约束的问题，并将答案与 Google Maps 对比。

这种比较揭示的不只是一个新按钮的出现。它将显示 Gemini 能否将用户选定的地理上下文转化为有用、可验证的结果。