Gemini 接管应用创建，Google 取消 AI Studio 移动应用

尽管此前计划在 Android 和 iOS 上推出独立的 AI Studio 应用，Gemini 正在整合 Google 两个月前宣布的一项产品。9to5Google 的报道称，这些移动应用已被取消。Google 现在计划将应用创建功能直接引入 Gemini，最终覆盖移动端和桌面端软件。

这不只是 Google 又一次取消实验项目。它推翻了公司在 I/O 2026 上的说法：当时 AI Studio 移动版被定位为一个可通过手机进行开发的专属空间。Google 现在似乎认为，应用生成应当置于用户已经在使用的助手之中。

这一决定将独立开发界面与集成式对话界面摆在了对立面。AI Studio 仍可通过网页使用，但 Gemini 的月活用户超过 9 亿。将创建能力并入这一更大的产品，可能让构建应用从一个专门目的地，变成对话中的常规环节。

9to5Google 的报道指出了哪些变化

Google 取消的是独立的移动端载体，而非让日常设备上的软件创建变得更易用这一更大方向。

在 5 月 19 日的 Google I/O 上，该公司邀请用户为 Android 和 iOS 的专属 AI Studio 应用预注册。原计划中的体验承诺，可在手机上使用完整的 Build mode。Build mode 是 AI Studio 基于提示词生成和预览应用的环境。

Google 描述了一种从离开办公桌时捕捉灵感开始的工作流。用户随后可以迭代代码、预览构建结果、改编画廊项目，并分享已上线的部署版本，之后还可在桌面端继续同一项工作。

公司最初的移动应用计划将便携性视为主要优势。手机将成为紧凑的开发界面，而不只是展示在其他地方生成的应用。

iOS 上的页面甚至暗示将在 7 月发布，而 Android 用户则可通过 Google Play 预注册。如今，这两个版本均未如最初所述面向公众推出。

根据 7 月 31 日的应用取消报道，Google 已改变这一策略。该公司正放弃专属的 AI Studio 移动客户端，并将重点转向在 Gemini 内部创建应用。

Google 的公开表述显示，用户最终将能够通过日常的 Gemini 对话创建移动端和桌面端应用。一个想法可能出现在讨论旅行、安排工作或解决实际问题时。Gemini 随后可以将这一需求转化为交互式软件。

措辞很重要，因为它描述的是一种不同的交互模式。AI Studio 要求用户带着应用想法进入开发环境；而 Gemini 则可能在用户已经说明目标时识别出软件机会。

这种区别改变了切入点。用户不再需要在开始前就认定应用是答案。Gemini 在理解底层任务后，可能提出或生成一个界面。

Google 尚未公布这一功能的详细发布时间表，也未说明哪些平台、账户类型或国家将优先获得该功能。取消计划已成定局，而替代方案仍属于未来的产品方向。

AI Studio 本身并未关闭。其网页产品仍支持应用生成、模型实验、部署以及原生 Android 开发。被取消的产品是原计划推出的独立移动客户端。

这一界限很重要。一些反应将这一决定描述为 Google 终止 AI Studio，但现有证据并不支持这一结论。Google 改变的是面向消费者的创建体验将在哪里呈现。

因此，9to5Google 的报道同时包含收缩与扩张。原本承诺推出的一对移动应用已经取消，而底层愿景如今涵盖桌面应用以及规模大得多的 Gemini 用户群。

这次转向引出了核心问题：通用助手能否为严肃的应用创建提供足够控制，还是整合会抹去 AI Studio 之所以实用的清晰边界？

Google 正以专属构建工具换取 Gemini 的覆盖范围

被取消的应用少了一个明确入口，但 Google 也获得了将应用生成能力呈现在数亿现有用户面前的机会。

Google 在 5 月表示，Gemini 在 230 个国家和地区、超过 70 种语言中拥有逾 9 亿月活用户。一年前，该公司报告的用户数为 4 亿。这些数据来自 Google，尚未经独立审计。

即便有这一限定，规模差异仍然显著。AI Studio 面向开发者、技术创作者，以及积极试验 Gemini 模型的人群；Gemini 应用则触及更广泛的受众，其中许多人可能从未访问过开发者工具。

Google 的Gemini 应用更新也说明了为何整合符合其当前战略。该公司正将 Gemini 打造成通用的行动层，而不仅仅是一个问答聊天机器人。

在 I/O 上，Google 推出了 Gemini Spark，这是一种可在用户指示下执行后台任务的智能体。公司还扩展了文件生成、服务连接和主动协助功能。应用创建符合这一方向，因为它能将对话转化为可执行的产物。

设想一名项目经理正在规划产品发布。对话可能暴露出对状态仪表盘、风险跟踪器或反馈分类工具的需求。Gemini 可以生成该界面，而无需用户打开独立的开发产品。

教师可以要求创建一道会根据每次回答调整的课堂测验。销售经理可以请求一个连接到共享表格的移动录入表单。旅行者可以将行程讨论转化为离线清单。

在 Google 推出这项整合前，这些例子仍只是设想。但它们说明了对话上下文为何重要。在生成应用前，Gemini 可能已经了解用户的目标、限制条件、文件和偏好输出。

专属 AI Studio 应用的起点则缺少这些上下文。它可以访问项目历史，但用户仍需将现实问题转化为开发请求。Gemini 有可能消除这一步转译。

这也是 Google Workspace 集成在战略上变得有用的地方。AI Studio 已可构建与 Sheets、Drive 和文档协同工作的应用。这些连接使生成的软件能够处理人们在工作中使用的信息。

公司的开发者亮点将 AI Studio 放在更广泛的链条中。用户可以在 AI Studio 中制作原型，将项目导出至 Antigravity，并继续走向部署。

Gemini 可能成为同一链条的第一阶段。它将捕捉意图并生成初始体验。当项目变得更复杂时，AI Studio 或 Antigravity 则可提供更深入的控制。

这种结构更像漏斗，而非替代关系。Gemini 将应用创建带给庞大受众；AI Studio 负责基于浏览器的构建，而 Antigravity 支持更广泛的开发与智能体编排。

挑战在于保持清晰的交接。一个生成的应用一旦加入身份验证、数据库、权限、计费和外部服务，就会变得更难维护。用户需要能够访问代码、配置、测试和部署记录。

Google 尚未解释 Gemini 项目将如何进入这些专业工作界面，也没有说明对话上下文、生成文件、密钥或部署设置是否会随之迁移。

该公司已支持将 AI Studio 项目连同附带上下文导出至 Antigravity。若能提供从 Gemini 出发的类似桥梁，这一整合战略会更具可信度。否则，生成的应用可能沦为临时演示。

对 Google 而言，覆盖范围的理由仍然很有吸引力。建立独立的移动端用户群需要安装、引导和持续互动。Gemini 已拥有这些用户关系，并覆盖 Android、iOS、网页和桌面端。

对用户而言，整合也能减少产品混淆。Google 提供 Gemini、AI Studio、Android Studio、Firebase、Antigravity，以及多项云端开发服务。再增加一个移动应用，只会多出一道需要理解的边界。

不过，覆盖范围并不保证采用。人们打开 Gemini 往往是为了完成与软件无关的任务。Google 必须让应用生成易于发现，同时不打断日常对话或产生不需要的界面。

9to5Google 的报道反映了一次分发策略的押注。Google 正牺牲一个聚焦的产品，以便让应用创建出现在其最大的助手内部。这一取舍是否成功，取决于执行，而不只是用户规模。

真正的转向在于应用想法从何处开始

Google 最初围绕有意识地构建来设计移动版 AI Studio，而 Gemini 方案则从对话中浮现的需求开始。

旧概念遵循熟悉的开发顺序：一个人有了想法，打开 AI Studio，描述应用，审查输出结果，并分享部署版本。手机改变了设备，但没有改变基本工作流。

新概念改变的是工作流本身。用户可能先讨论问题，而不是请求软件。Gemini 则可能判断交互式应用是有用的回应。

这是本文的主要转向。Google 正从“打开一个构建工具”走向“让助手在合适时进行构建”。这将主动权从用户转向模型。

这一方法建立在对话式 AI 产品中已经出现的功能之上。助手可以创建文档、电子表格、图表、交互式可视化内容以及小型代码产物。应用是这种输出模式更大规模的延伸。

Google 在 4 月为 Gemini 增加了可下载文件生成功能。用户无需离开聊天，即可请求文档、电子表格、PDF 和其他格式。该公司如今正将软件定位为对话可以产出的另一种成果。

应用不同于文件，因为它具有状态和行为。它可能接收用户输入、调用外部服务、存储信息，或随时间变化。这使生成更有价值，但也带来更多失败的可能性。

Google AI Studio 已支持基于提示词的全栈应用，这类应用结合了界面、服务器逻辑和连接的数据服务。其当前的Build mode 指南围绕 Gemini 能力、部署和服务器端密钥处理来说明应用生成。

这一网页工具提供了可见的开发控制。用户可以检查代码、调整提示词、测试行为、连接服务并管理部署。这些控制在对话与软件工程之间建立了明确的认知边界。

Gemini 的对话界面则有意降低技术门槛。这使它更易接近，但也可能隐藏影响重大的决策。生成的应用仍需要权限、数据规则、错误处理和安全边界。

Google 必须决定在聊天中呈现多少这种复杂性。配置过多会让 Gemini 像一个集成开发环境；配置过少，用户又无法判断生成的应用程序具体做了什么。

移动端和桌面端生成又增加了一层复杂性。Google 演示了在 AI Studio 中使用 Kotlin 和 Android 的现代界面框架 Jetpack Compose 创建原生 Android 应用。用户可以在基于浏览器的模拟器中预览代码，并将构建版本发送到内部测试轨道。

桌面应用开发的定义则不那么清晰。Google 尚未明确其计划通过 Gemini 支持哪些操作系统、应用框架、打包格式或分发方式。

“桌面应用”可能指可安装在 Windows 和 macOS 上的软件，也可能是针对大屏幕优化的 Web 应用。这两种承诺存在实质差异，因此 Google 需要明确这一术语的含义。

iOS 路线同样充满不确定性。AI Studio 已公布的原生开发支持聚焦于 Android。Google 没有宣布等效的、基于 Swift 的原生 iPhone 应用生成工作流。

取消 iOS 客户端并不会自动带来 iOS 开发支持。该客户端原本可让用户在 iPhone 上使用 AI Studio，但并不必然能够生成原生 iOS 软件。

这种区别很容易在新闻标题中消失。Google 表示 Gemini 最终将创建移动应用，但输出格式仍未明确。适配移动设备的 Web 应用并不等同于可直接上架应用商店的原生应用。

Google 计划的最强形态，是通过对话识别需求、生成可用界面，并让用户选择输出目标；随后在部署前提供代码与测试工具。

较弱的版本则可能只是创建仅能在 Gemini 内运行的一次性交互卡片。这类体验仍可能对用户有帮助，但无法满足人们对独立移动或桌面软件的普遍期待。

产品边界将决定谁会感受到压力。基于提示词的构建工具通过提供专用工作区、可复用项目、托管和部署来竞争。如果 Gemini 的对话式输出仍可编辑、可移植，它就能挑战这些工具。

传统开发环境面临的是另一种压力。Google 并非试图用一句提示词取代专业工程，而是在许多用户本就描述需求的地方，将早期原型设计前移。

开发者可能会从从未打开过编码工具的同事那里，收到更多半生成的项目。这可以加快需求探索，但也可能带来维护工作。生成的代码在处理敏感信息或服务真实客户前，仍需审查。

团队可以将对话式原型视为需求工件，而非成品。应保留提示词、预期行为、测试用例和源材料。一套可搜索的工程文档可以让这种交接更加顺畅。

Google 的押注是：应用创建早在某人意识到自己正在开发软件之前就已开始。Gemini 已经占据了那个更早的时刻，而 AI Studio 没有。

Gemini 应用创建仍面临控制问题

整合策略降低了摩擦，但 Google 尚未展示 Gemini 将如何处理测试、安全性、可移植性和长期维护。

第一个不确定性在于产品定义。Google 描述的是一个未来方向，而非已经完成的功能。目前没有公开的发布时间、支持平台清单，也没有展示 Gemini 内移动端和桌面端生成能力的详细演示。

这一缺口很重要，因为独立应用已经具体到足以开放预注册。Google 公布了功能、展示了界面，并说明了跨设备工作流。相比之下，当前的替代方案提供的实际操作细节更少。

第二个不确定性在于用户控制。对话擅长收集意图，但无法很好地替代结构化项目管理。应用程序需要版本历史、文件、依赖项、环境变量、部署设置和可重复执行的测试。

用户还需要理解 Gemini 何时是在提议创建应用。若针对每个复杂问题都自动生成界面，会造成混乱；若等待用户明确提出请求，又会削弱应用从对话中自然产生的承诺。

Google 必须建立清晰的确认环节。Gemini 可以建议创建应用、说明它将访问什么内容，并请求用户批准生成。这将保留对话式探索，同时让用户保持控制权。

权限也需要类似处理。连接电子表格的仪表盘所需的访问权限，与本地计算器不同。能发送电子邮件或存储客户信息的应用，其风险高于交互式图表。

Google 的 Firebase 文档已提醒开发者，不要将 Gemini API 密钥放入客户端代码中。它还建议为连接的服务设置安全规则和应用检查。这些防护措施不能仅因项目由 Gemini 生成就消失。

生成的应用可能包含不安全的默认设置、不可靠的逻辑，或带有已知漏洞的依赖项。精美的界面不能证明应用是安全的。由于 Gemini 生成了看似可信的预览，用户可能会高估其质量。

因此，不应将 9to5Google 的 Google 报道视为 Gemini 能取代软件团队的证据。Google 宣布的是一种分发与界面策略，而非展示了可在移动和桌面平台上可靠完成端到端开发的能力。

可移植性带来另一项风险。用户需要知道自己是否可以导出生成的代码、部署到其他地方，并在不依赖 Gemini 的情况下继续开发。被锁在对话中的项目，对长期工作价值有限。

AI Studio 目前提供面向代码的工作流，并可连接其他 Google 开发工具。这为从原型到可维护项目创造了路径。Gemini 也需要提供一个同样清晰的出口，通向 AI Studio、Antigravity、Android Studio 或其他标准环境。

跨平台测试也会变得更加复杂。桌面应用在 Windows 和 macOS 上的行为可能不同。移动应用则必须考虑屏幕尺寸、权限、后台活动、电池使用和应用商店政策。

Google 掌控 Android 和 Google Play，这让它拥有直接的测试与分发路径。但它并不控制 Apple 的开发环境或 App Store 审核流程。跨平台主张需要的不只是生成响应式界面这一类证据。

该公司在 I/O 上的演示为 Android 设定了有用基准。AI Studio 可以生成 Kotlin 代码、在浏览器模拟器中运行、通过 Android Debug Bridge 连接，并发布到内部测试轨道。在用户将 Gemini 的输出视为可部署软件前，它应达到同等的控制水平。

对高级用户而言，还存在可发现性问题。AI Studio 在为实验设计的环境中，分开呈现模型、提示词、工具和代码。Gemini 更简化的界面可能会掩盖模型选择，或移除这些用户所需的配置选项。

整合只有在 Google 保留不同层级的控制时才能奏效。普通用户可以接受自动生成的小型应用；开发者则必须能够检查实现并修改其运行方式。

用户反应已经反映出两面性。一些人认为独立应用没有必要，因为 AI Studio 可通过移动浏览器使用；另一些人担心，将创建功能整合进 Gemini 会减少对 AI Studio 深层控制能力的访问。

在替代方案发布前，这两种观点都无法得到验证。此次取消如今减少了应用程序冗余，但也在 Google 尚未证明 Gemini 提供等效体验前，取消了一个已承诺的产品体验。

Google 的产品历史也让这种怀疑可以理解。该公司经常整合重叠服务，但用户可能会在过渡中失去既有工作流。一次被取消的预注册，使未来承诺在缺乏可用软件时更难评估。

谨慎的解读应当是有限的：Google 认为，对话式应用创建的战略价值高于独立的 AI Studio 移动客户端。这个决定是否有利于构建者，取决于导出、测试、平台支持和可靠性。

Google、开发者与竞争对手接下来必须证明什么

三个信号将显示 Google 是否找到了更好的应用创建路径，还是只是在替代方案尚未准备就绪前取消了一款产品。

第一个信号是可用的 Gemini 应用生成预览。Google 需要展示一段完整对话如何变成可编辑的应用。演示应包括生成的行为、权限、测试和导出路径。

基础的交互卡片会削弱这一更大的主张。若项目能够连同其上下文完整地进入 AI Studio 或 Antigravity，则能支持 Google 的整合战略。

第二个信号是精确的平台定义。Google 必须解释移动和桌面应用具体意味着什么。开发者需要知道 Gemini 生成的是原生代码、跨平台软件包、渐进式 Web 应用，还是仅限于 Gemini 内部的体验。

原生 Android 支持将建立在 Google 已宣布的能力之上。原生 iOS、Windows 或 macOS 输出则需要新的工具链和分发工作流。每个目标都会带来不同的技术与政策要求。

第三个信号是竞争性构建工具如何回应。专注于提示词生成应用的服务可以强调可预测的编辑、部署、集成和代码所有权。它们也可以让跨平台支持比 Google 日益增多的产品集合更容易理解。

如果竞争对手改善从自然语言原型到可维护代码的交接，Google 的分发优势未必能够决定市场。只要能提供更清晰的控制，用户往往愿意接受额外使用一个应用。

Google 还需要明确 AI Studio 的持续角色。保持 Web 工具可用还不够。公司应说明哪些工作从 Gemini 开始、哪些会进入 AI Studio，以及哪些属于 Antigravity 或 Android Studio。

这张路线图将帮助普通创作者和专业团队。没有它，这个产品家族可能会让人感觉像是针对同一个问题给出的多个重叠答案。

对开发者而言，近期应对应当务实。不要围绕一项尚未发布的 Gemini 功能重新设计工作流。当 AI Studio 现有 Web 工具能满足项目需求时，继续使用它们。

与此同时，应留意那些在工程团队之外开始的项目。同事可能很快会带着在普通 Gemini 对话中生成的原型出现。团队应决定这些工件如何进入审查、测试、安全评估与所有权流程。

企业买家应关注治理，而非演示速度。他们需要记录，显示生成的应用访问了哪些数据、部署了哪些代码，以及每项权限由谁批准。

知识工作者应关注 Gemini 在未被要求时提出应用建议的频率。有用的建议可以把重复任务转化为小型、个性化工具；糟糕的建议则可能让对话更难导航。

核心竞争仍然是专用构建工具与整合型助手之间的较量。AI Studio 提供意图、结构和可见的控制；Gemini 提供上下文、分发能力以及更低的启动门槛。

Google 已选择整合型助手作为面向消费者的主要路径。但它尚未证明，这条路径能在原型变得重要之后保留所需的控制能力。

这让被取消的应用成为一次异常具有启示性的产品决策。Google 并非因为手机不适合创作而放弃移动端开发；它认为，相较于打造独立入口，将创作能力置于 Gemini 内部更有价值。

未来几个月应会揭示这一判断是否成立。更详尽的 Gemini 预览将强化这一判断；模糊的演示、受限的导出能力，或继续对平台支持保持沉默，则会削弱它。

9to5Google 对 Google 的报道标志着一款已公布产品的终结，但并不意味着 Google 放弃了移动端开发的雄心。它让 Gemini 承担起更重的责任：在不隐藏关键选择的前提下，连接对话、代码与部署。

用户现在该怎么做？继续使用现有工具进行开发，并依据导出的代码而非精致的预览来评判 Gemini 未来的应用创建能力。应当追问：对话结束后，项目是否仍然可编辑、可测试且可移植。开发者还应在将生成的软件接入真实数据之前，要求明确的权限边界。如果 Google 能交付这些要素，取消独立应用将显得是一次聚焦式整合；如果做不到，这一决定则会像是披着更宏大承诺外衣的过早退却。