Google 关闭 Firebase Studio，推动开发者转向其更新的 AI 工具

Google 将于 2027 年 3 月 22 日关闭 Firebase Studio，推动开发者转向较新的 AI 工具，同时保留底层 Firebase 服务的运行。Firebase Studio 的关闭迫使现有用户选择另一种开发环境，即使他们已部署的应用无需变更托管服务。Google 希望这些开发者转向 Antigravity 或 Google AI Studio。

这一区别至关重要。开发环境整合了人们编写、测试和准备发布软件所使用的工具。Firebase 的数据库、身份验证服务和托管服务则独立运行。Google 正在淘汰开发者构建应用的场所，同时保留这些应用所依赖的基础设施。

核心矛盾在于连续性。Google 将此次转变描述为更精简的产品线，但现有用户必须判断，这种精简是否会改善他们的工作方式。Firebase Studio 本身曾吸收 Google 早期的浏览器工作区 Project IDX。如今，开发者又面临一次转变，需要在浏览器原型开发、桌面开发和将代码迁往其他平台之间作出选择。

Firebase Studio 的关闭已在进行中

此次关闭是按计划逐步退出，相关限制已经生效，并非 11 月新近宣布的决定。

Google 于 2026 年 3 月 19 日宣布停止该产品。新账户注册和新工作区创建已于 2026 年 6 月 22 日结束。现有工作区仍可访问，直至最终关闭。Google 的停止服务时间表记录了这些节点，并确认已部署的 Firebase 应用之后仍将继续运行。

因此，截至 11 月 6 日，开发者仍在使用一项可承载现有项目、却不再支持通过新工作区扩展的服务。这改变了它的实际角色。它仍可用于维护当前工作，但不再为未来项目提供同样的起点。

对于管理多个应用的团队而言，这一区别带来了规划难题。现有工作暂时可以保持熟悉的方式，但新工作需要另寻归宿。除非团队主动作出决定，否则在最终期限到来前，其开发实践可能已分散在多个环境中。

因此，眼下的问题不止于应用是否仍能打开。团队需要确定未来的改动将在何处进行、由谁执行，以及这些改动如何触达用户。一个正常运行的生产应用本身无法回答这些问题。

Google 的立场也为有序过渡留出了空间。开发者无需将每个仍可运行的 Firebase 应用都视为紧急迁移任务。他们需要识别与 Firebase Studio 绑定的开发依赖，并在访问权限消失前替换这些依赖。

这一区分有助于让报道保持适当的尺度。退出会带来实际工作，但将其描述为 Firebase 的终结，会误判受影响的产品；也会在当前责任仅涉及工作区时，促使用户进行不必要的基础设施变更。

更恰当的理解是，Firebase Studio 的关闭为保留软件维护能力设定了期限。应用可以继续提供服务，但其维护者可能失去熟悉的更新路径。一旦缺陷、安全问题或业务需求要求发布新版本，这一落差便会产生实质影响。

公告的时间点还有另一层意义：这已不再只是产品路线图之争。如今评估选项的开发者，可以使用自己的项目检验替代工作流。决策所依据的，已是经过验证的连续性，而非继任产品未来或许能够提供什么的承诺。

Google 更精简的产品线为现有用户带来额外工作

Google 通过让开发者承担产品之间的过渡工作，来减少旗下产品的重叠。

整合确有合理之处。相似的工具会让人难以判断从何开始、哪个产品会获得新功能，或文档适用于何处。更清晰地区分浏览器原型开发和桌面开发，能为新用户提供更易理解的起点。

现有用户对同一决定的体验则不同。他们已经选择了起点，熟悉了界面，并围绕它组织工作。面向未来客户的更简洁选择界面，并不会自动补偿他们重建这些习惯所付出的成本。

压力最直接地落在那些工作流依赖代码周边环境的人身上。源文件代表应用本身，但工作设置还包括说明、开发命令、权限和发布实践。迁移这些职责所需的判断，远不止复制一个文件夹。

设想一个维护内部审批应用的小团队。该应用或许仍在正常服务员工。实际的迁移问题是：另一位获授权的维护者是否能够进行修改、完成验证并发布，而不依赖即将退出的工作区。

这是一个说明性场景，而非已报道的客户案例。它表明，迁移是否成功，应通过一项常规维护任务来判断。成功导入只能证明文件已抵达；成功发布才能证明团队恢复了运营软件的能力。

不同组织面临的负担也不同。独立开发者可以通过个人试验更换工具。公司则可能需要在替代方案能供所有应用维护者使用前，协调访问权限、安装规则、文档和支持职责。

对于习惯于打开浏览器继续工作的人而言，桌面环境引入了另一套运营安排。反过来，希望直接掌控本地工具的开发者可能欢迎这种改变。两种偏好都不能证明迁移是轻而易举的。

此次转变还提出了所有权问题。如果只有最初的构建者了解新环境，应用仍然依赖于这个人。可持续的迁移应让下一位维护者拥有足够背景信息继续工作，其中包括那些从源代码中从未显而易见的决策。

将这些背景信息保存在可搜索的知识库中，有助于完成交接。相关材料包括架构决策、发布说明、已知限制，以及特殊配置选择背后的原因。

这正是 Google 的“简化”主张需要附加实际条件的地方。产品整合可以改善整体产品线，同时仍增加某位客户的工作量。两种结果可以同时成立，而迁移支持的质量决定了它们之间的冲突会有多尖锐。

对于企业采购者而言，这使过渡支持成为产品评估的一部分。开发工具的评估，应部分取决于离开它所需的工作量。此次关闭让这个通常只是理论上的问题，变成了眼前的责任。

Antigravity 和 AI Studio 分拆了 Firebase Studio 曾整合的工作

替代策略将 Firebase Studio 最初试图一并服务的开发者偏好分开处理。

Firebase Studio 于 2025 年 4 月 9 日进入预览阶段。Google 的原始工作区公告描述了一种统一体验，结合了 Project IDX、应用原型开发、编码工作区和部署选项。它明确面向两类人群：使用自然语言构建应用的人，以及带来自身技术选择的资深开发者。

这段历史使当前转变比传统编辑器替换更值得关注。Google 最初将整合视为优势。如今，其首选安排将工作分布到不同产品中，由不同环境服务于不同开发风格。

Antigravity 代表桌面方向。Google AI Studio 则代表浏览器方向，其中提示词和应用生成是体验的核心。选择关乎开发者在哪里工作，以及他们希望在多大程度上直接参与实现过程。

AI 编程代理是一种能够使用工具检查项目并执行开发任务的软件。它的作用不止于建议下一行代码。当代理成为核心时，界面还必须帮助人们指挥工作、检查变更，并判断结果是否可接受。

Google 表示，升级后的 AI Studio 体验采用了 Antigravity 代理框架的关键组件，即协调模型行动和工具的软件。其Firebase 集成可在用户批准后提供数据库和登录设置。Google 以一个共享食谱应用说明这一方式。

这个例子解释了产品逻辑。共享食谱应用需要的不只是生成的界面，还需要持久化信息和将活动与人员关联的方式。在创建体验中连接这些能力，可以缩短吸引人的原型与可用应用之间的距离。

这为整合提供了技术上的理由。如果 AI Studio 可以协调应用创建和 Firebase 集成，独立的 Firebase 品牌环境对 Google 的产品叙事就不再那么必要。基础设施可以支持应用，而无需决定开发工具的名称或界面。

不过，这不应被解读为 Firebase Studio 缺乏 AI。其发布公告早已将 AI 置于产品主张的核心。变化关乎产品组织和首选工作界面，而非从传统编码向 AI 开发的清晰过渡。

这种分拆也暴露出，将所有开发者视为单一受众的局限性。浏览器访问对某些人至关重要，对另一些人则只是附带条件。对本地工具的细致控制对某些团队有价值，对另一些团队却可能构成管理障碍。

对于考虑 Firebase Studio 替代方案的用户而言，这一区别应先于模型品牌的比较。替代方案需要契合实际维护流程。一次令人印象深刻的演示，无法证明某个团队能否复现其日常工作。

因此，这一转变是明确的：Google 早先的统一工作区正让位于更细分的产品线。Google 认为这会让开发更清晰。现有用户则必须确认，由此产生的选择是否保留了他们在组合产品中所看重的灵活性。

导出代码并不能保留完整的开发工作流

最有力的迁移证据，是在目标环境中完成经过验证的维护闭环。

Google 的项目迁移指南提供了迁往其替代产品及其他环境的路径。该指南也指出了重要限制：标准导出存档不包含代理聊天历史，迁移工具也未必会更新每一项项目产物。

这些细节说明了为什么可移植性需要谨慎解读。代码可移植性意味着开发者能够取得其文件。工作流可移植性则意味着，他们迁移后仍能理解、修改、测试并发布应用。前者支持后者，但并不等同于后者已经实现。

聊天记录体现了两者的差异。一段对话可能包含某项变通方案的说明、一个被放弃的方法，或最终代码仅部分表达的需求。丢失这些记录未必会导致应用无法运行，却可能让下一次变更更难评估。

当开发者通过提示词创建了应用的重要部分时，这一点尤为相关。生成的文件展示了已有内容，而对话可能说明构建者的意图。当两者不一致时，维护人员需要足够的上下文来识别预期行为。

部署引入了另一条边界。部署是指将应用的某个版本发布到用户可访问的环境中。Google 记录了保留现有 App Hosting 地址的方法，同时也提供了会引入不同托管安排的 Cloud Run 路径。

因此，团队应区分更换开发工具与更换生产托管环境。这两项变更可以同时进行，但这会扩大需要审查的工作范围。当不相关的基础设施变更同时发生时，迁移决策会更难诊断。

凭据也值得同样关注。它们是让软件访问服务的密钥和其他机密信息。Google 的说明描述了开发者在将替代工作流连接到现有基础设施时必须承担的配置责任。

相关分析应从运营角度出发：替代方案可能能够正确打开项目，却仍缺少生产发布所需的配置。即使编辑器和智能体看起来运行正常，这种情况仍属于迁移缺口。

Google 的文档还表示，关闭后剩余的 Firebase Studio 工作区数据将被永久删除。这使得独立保存资料变得至关重要。开发者需要自行保留经过验证的记录，其中应包含维护项目所需的材料，而不能假设旧工作区会一直可用。

这些要点均不能证明迁移工具普遍失效。文档没有提供足以得出该结论的证据。相反，它指出了一些边界，说明成功传输文件不能作为连续性已得到普遍证明的依据。

公平的评估还应区分应用缺陷与迁移缺陷。原工作区中已存在的问题不应自动归咎于替代方案。同样，即使智能体最终解决了问题，新增的配置工作也不应从评估中被忽略。

有价值的比较应从头到尾跟随一项具有代表性的任务。团队能否理解需求、完成变更、验证行为，并通过新安排发布？这一结果比导入是否在没有报错的情况下完成更有分量。

竞争性编码工具让连续性成为竞争的一部分

Google 必须通过替代方案的使用体验留住开发者，因为保留 Firebase 基础设施并不能保证他们会继续忠于其编辑器。

更广泛的市场已经提供了围绕编码智能体组织的开发工具。Cursor 的智能体能力包括搜索代码库、编辑文件、运行终端命令和处理错误。其文档还介绍了通过云端智能体进行浏览器访问的功能。

这一比较表明，仅靠智能体功能无法解释 Google 的竞争地位。多款产品都可以承诺在开发任务中提供协助。真正有意义的差异体现在它们如何融入项目、呈现变更、应对中断，以及支持持续维护。

就此处审阅的证据而言，并不存在适用于所有前 Firebase Studio 用户、且已被独立确立的赢家。偏好浏览器工作并不能决定选择。偏好某个特定模型同样不能，尤其是在周边开发工作流决定该模型实际能完成什么的情况下。

对于已经使用 Google 基础设施的开发者，Google 保有一个明显优势：熟悉度。留在关联产品体系中，可能减少团队需要学习的新知识量。这是一项合理的益处，但仍需要在实际迁移结果中得到体现。

竞争环境则拥有不同的机会。被迫迁移会让用户重新审视他们此前未曾质疑的假设。一旦开发者无论如何都必须评估新的工作环境，他们便可以将 Google 的建议与其他工具进行比较。

因此，重要的竞争问题是通过连续性实现留存。如果 Google 的替代方案既能保留应用，又能让后续工作更轻松，整合就可能巩固其地位。如果开发者不得不反复重建工作流，迁移就会成为竞争对手的机会。

这也改变了应如何看待生产力主张。一个能够快速生成初始实现的智能体，仍可能带来审查或修复工作。相关结果应包括达到获准发布所需的投入。

对于需要长期维护的业务应用而言，可预测的交接可能比令人惊叹的生成演示更重要。团队需要知道发生了什么变更、为何变更，以及必要时如何回退。即使智能体完成了大部分实现，这些要求依然存在。

比较还应纳入不依赖 AI 辅助的工作。开发者仍需要有办法检查文件、理解故障，并在智能体误解需求时继续推进。围绕委派组织的界面，仍应支持直接调查。

因此，应通过同一项应用开发与维护任务来评估 Firebase Studio 的替代方案。否则，用户可能会将熟悉工具积累的问题，与替代方案精心挑选的演示进行比较。这种比较偏向新鲜感，却无法证明运营层面的改进。

Google 的决定并不能证明云端开发环境已经过时。它表明 Google 选择将开发产品集中于何处。浏览器访问的持续重要性，与这个特定工作区的命运仍是两回事。

最终，竞争压力只有在改善迁移后保留内容的前提下才会使用户受益。更多智能体功能只有在减少维护真实软件所需工作量时才有意义。当开发者必须反复重建这些智能体所需的上下文时，它们的重要性就会降低。

关注迁移可靠性、工作流覆盖度与重复发布

下一项有价值的证据将来自普通项目离开 Firebase Studio 后能否持续成功运行。

未来几个月，第一个信号是迁移可靠性。关注是否会出现更清晰的受支持项目类型文档、已解决的转换问题，以及可重复执行的迁移流程。这些方面的改进将加强 Google 关于整合能够实现可控过渡的论点。

此类证据的质量十分重要。一次成功演示只能证明一个选定项目完成了迁移。更广泛的信心需要覆盖不同工作模式的案例，其中包括在初始创建后发生重大变化的项目。普通配置反复出现问题，将削弱简化的论点。

第二个信号是工作流覆盖度。关注面向浏览器的用户能否保留托管工作区对他们具有价值的工作方式。同时也要关注桌面用户能否恢复项目配置和开发实践，而不必反复即兴拼凑替代方案。

这一信号检验了核心的产品分工。如果这些目标产品能清晰服务于不同需求，Google 的产品阵容在实践中就会更容易理解。如果用户仍不断在工具之间切换，以找回原有工作流中缺失的部分，那么所宣称的清晰度就不那么有说服力。

第三个信号是迁移后的重复发布。导入成功只是早期里程碑。持续维护则提供了更有力的证据，表明开发者已恢复对应用的控制，并能够响应新的需求。

最具说明力的案例会描述实际变更、所执行的验证以及最终发布的结果。反复出现的配置修复或缺失的项目上下文报告，将指向相反的结论。无论是宣传性的应用数量，还是孤立的投诉，都无法单独确立整体结果。

这些信号也为分析设定了合理界限。Google 公布的退役时间表说明了哪些内容将关闭。其产品公告说明了它打算让开发者使用什么。两类来源都不能独立证明每位客户迁移需要花费多少时间。

目前，Firebase Studio 关闭带来了一项明确义务，但负担并不均衡。Google 已确定后续产品，并保留了底层 Firebase 服务。开发者仍必须验证，所选环境是否保留了维护其已构建内容的能力。

应将剩余访问期视为建立这种连续性的时间。选择一项有代表性的应用变更，并在目标环境中完整跟进，从理解需求到发布结果。保存另一位维护人员所需的项目决策和配置知识。根据已完成的工作来评估替代方案，包括审查和修复所投入的工作量。Google 更新的 AI 工具应以此为依据，与其他选择一并接受评估。在旧工作区消失之前，团队中的其他人能否不依赖你们正在离开的环境，自信地维护并发布该应用？