先把事实摆正：这次到底发生了什么

这两天最容易被转错的一句话，是“Google 把 AI Studio 从前端玩具一夜之间重构成了全栈平台”。方向大体没错，细节却需要校准。不把名字、时间线和能力边界讲清楚，后面的市场判断就很容易全错。

目前能直接从官方资料确认的事实，有五个。

  • 2026 年 3 月 12 日和 3 月 13 日更新的 Google AI Studio 文档，已经明确写到 Build mode 支持 full-stack runtime。官方描述里包括 Node.js 服务端运行时、Secrets 管理、npm 包支持、多人实时协作能力，以及通过 Firebase 自动接入 Firestore 和 Firebase Authentication。
  • 同一批文档还明确写到，Build mode 背后的核心 Agent harness 来自 Antigravity，也就是 Google 在 2025 年 11 月 20 日公开的 agentic development platform。换句话说，这不是另起炉灶，而是把 Antigravity 的核心能力往浏览器端下放。
  • 2026 年 3 月 19 日，Google 官方宣布 Firebase Studio 进入 sunset。时间线写得非常具体：2026 年 6 月 22 日停止创建新 workspace，2027 年 3 月 22 日关闭并删除剩余数据。
  • 在这份 sunset 文档里，Google 直说了自己的收敛方向：代码优先、重度 agentic workflow 归 Antigravity；浏览器里的快速全栈原型归 Google AI Studio。它甚至明确写到，已经把 Cloud Firestore 和 Firebase Authentication 直接集成进 Google AI Studio。
  • 但有些流传很广的说法，官方资料还不能完全支持。比如“AI Studio 现在支持 Next.js 一键切换”，截至 2026 年 3 月 21 日我看到的 AI Studio 文档，仍然把 React 作为默认前端，并在最佳实践里写的是 React / Angular 的前后端分工，没有公开文档把 Next.js 写成 AI Studio 的正式一等框架。

所以，原帖最需要纠正的不是方向，而是对象。真正被“推翻重构”的，不是一个孤立的 AI Studio 页面生成器，而是 Google 过去一年在 AI Studio、Firebase Studio 和 Antigravity 之间那条本来分裂的产品线。

另一个要校准的误区：它不是“绝对免费”

原帖里还有一句很容易让人误解的话，就是“免费”。这个判断只对了一半。

Google AI Studio 和 Firebase Studio 的入口确实都提供 no-cost 使用方式，但官方文档同样写得很清楚：它们都有 rate limits、workspace 限额和付费升级路径。AI Studio 的 Gemini API 有明确的免费 tier 限流；Firebase Studio 也区分无付费、Google Developer Program 标准版和高级版的 workspace 数量与 Gemini quota。只要你把应用推向 Cloud Run、Firebase App Hosting 或更高配额的 Firebase / Google Cloud 服务，付费就会开始介入。

这件事不只是一个计费细节。它意味着 Google 并不是在做“永久免费玩具”，而是在用免费入口换取更长的开发链路，再把真正的付费点放到云资源、配额、部署和更高强度生产使用上。这是典型的云厂商打法。

真正重要的变化，不是多了一个功能，而是链路被打通了

如果只盯着“现在能不能一句话生成全栈 App”，这件事会被理解得太浅。更重要的是，Google 正在把原本分散的能力，拼成一条连续链路。

  • 模型层：Gemini 本身就覆盖文本、图像、视频、语音、实时交互和工具调用。
  • 浏览器原型层：Google AI Studio 现在不再只承担提示词试验，而是开始承接全栈 Build mode。
  • 后端层：Firestore、Firebase Authentication 这些最常用的后端默认件，已经被收进提示词工作流里。
  • 部署层：AI Studio 走 Cloud Run，Firebase 走 App Hosting，底层都指向 Google Cloud。
  • 重度开发层：Antigravity 负责本地、代码优先、长任务、多代理和更高自主度的工作。

这条链一旦成立，Google 的角色就变了。它不再只是“卖模型 API 的公司”，也不只是“做一个浏览器里写页面的小工具”，而是在逼近一种 developer operating surface，也就是开发者工作面本身。

这也是为什么这次动作对市场的杀伤力，比单个新功能大得多。很多创业产品只占住了其中一层，Google 现在要占的是整条链。

把市场分成两半看，会比直接喊“Lovable 完了”更准确

今天这批 AI 开发产品，已经不适合再混成一锅粥看。更清楚的拆法，是至少分成两半。

第一半，是浏览器里从提示词出发的 app builder。这一组里，Google AI Studio、Lovable、v0、Bolt、Replit 的 prompt-first 体验，以及 Figma Make 的设计到原型能力，都在抢“最快做出可运行产品”的入口。

第二半，是代码优先的 agent workbench。这一组里，Antigravity、Claude Code、GitHub Copilot coding agent、OpenAI Codex app，争的是“谁能承接真实工程团队的长任务、仓库协作、审查和自动化”。

这两半市场会互相渗透，但短期不会完全重合。提示词 builder 更像在争产品经理、设计师、独立开发者和轻工程团队；代码优先 agent 更像在争专业开发者和已经有 repo、CI、review 流程的团队。

Google 这次危险的地方，就在于它开始同时踩进两边。AI Studio 负责浏览器侧的 prompt-first；Antigravity 负责本地侧的 code-first；Firebase 和 Google Cloud 把这两边接起来。

如果把主要玩家放在同一张地图里，Google 的位置会更清楚

先看最像直接对手的那一组浏览器 builder。

Lovable 的强项，是把全栈 Web app、团队协作、GitHub 同步、自定义域名和企业治理做成一个相对顺滑的工作流。它不是只会吐页面代码，而是明确把自己定义成 full-stack AI development platform。这让它在“产品、设计、运营、开发一起做一个 Web 产品”这个场景里很有竞争力。

v0 的强项，则更接近 Vercel 体系本身。它能从自然语言生成 full-stack app，能直接部署到 Vercel，能衔接环境变量、域名、监控和 GitHub。对已经深度押注 Next.js 和 Vercel 的团队来说，v0 的最大价值不只是生成，而是和生产环境的距离足够短。

Bolt 的路线更轻，更强调快速生成、内置数据库或 Supabase、GitHub 和域名发布。它对独立开发者和小团队仍然很有吸引力，但它的基础设施护城河比云厂商更薄，长期更依赖体验、速度和生态合作。

Replit 是这组里最特别的一个。它并不只是浏览器 builder，而是在往完整平台走。官方文档已经把 Replit Agent 写成全栈 app 生成器，还继续往数据库、私有部署、团队权限、移动应用构建和 App Store 路线扩。它更像独立平台型选手，而不是单点提示词产品。

Figma Make 又是另一条线。它的核心壁垒不是后端，而是设计源文件本身。你可以直接把设计稿、图片和文本文件附到 prompt 里，再把功能原型或 Web app 发出去。它在“从设计语义到可交互原型”这件事上天然有起点优势，但它不是以数据库、认证和生产运维为核心卖点。

再看代码优先的一侧。

OpenAI 的 Codex app 已经把自己定义成多代理 command center，强调并行 agent、skills、automations、sandbox 和长任务管理。Claude Code 的优势是终端优先、MCP 接入外部数据源，以及 GitHub Actions 自动化。GitHub Copilot coding agent 的优势则非常现实：它离 issue、PR、review 和组织级 repo 工作流最近。

这一组产品和 Lovable、Bolt 不是一个赛道起步，但会从另一侧吃掉高价值用户。因为一旦专业开发者开始习惯把真实仓库任务交给 Codex、Claude Code 或 GitHub Copilot，他们未必还需要一个纯浏览器 builder 来做中间层。

所以，谁最先承压，谁反而没那么怕

我不认同“Lovable 们现在都要慌了”这种一刀切判断。更准确的说法是，市场会分层受压。

最先承压的，是那些核心价值仍然停留在“提示词生成一个多页 Web app”，却没有更深基础设施、协作、治理或分发护城河的产品。因为 Google 现在给出的，不只是页面生成，而是 Gemini 模型、多模态输入、Firebase 后端、Cloud Run 部署和 Antigravity 迁移通道的一揽子组合。

相对没那么怕的，有几类玩家。

  • Replit 这类完整平台型选手，护城河在运行环境、团队协作、数据库、移动端和组织管理，不只是第一版页面。
  • Vercel 这类基础设施型选手，护城河在生产部署、性能、可观测性和 Next.js 生态，不是聊天框本身。
  • Figma 这类设计源头型选手，护城河在设计资产、设计协作和设计语义，不是后端默认件。
  • GitHub、Anthropic、OpenAI 这类 code-first agent 平台，护城河在仓库工作流、自动化和长任务 supervision，不是 prompt 到 demo 的速度。

Lovable 处在中间位置，所以压力会更真实。它的机会在于继续把“跨角色协作、GitHub 双向同步、企业治理和可迁移代码所有权”做深，而不是回头和 Google 硬拼模型与云资源。

Google 这次真正强在哪里

把所有玩家都放在一张图里之后，Google 的强点会变得非常集中。

  • 第一，它有自己的模型层，还是多模态模型层。这意味着图像、语音、视频、实时交互、搜索、地图、工具调用，都可以原生长进 builder。
  • 第二，它有自己的后端默认件。Firestore 和 Firebase Authentication 不是外挂，而是第一方集成。
  • 第三，它有自己的部署与云资源承接面。用户从 demo 走向线上，不需要跳到完全陌生的基础设施世界。
  • 第四，它有浏览器端和本地端两套界面。AI Studio 管提示词原型，Antigravity 管代码优先和重任务。
  • 第五，它有足够强的生态补位能力。即使某个产品名字被砍掉，底层 Firebase、Google Cloud、Gemini 这些资产都还在。

很多创业公司的问题，不是某一个功能比 Google 差，而是它们只能占一层。Google 真正危险，是它正在跨层。

但 Google 也不是无敌，它有三块明显短板

第一块短板，是产品线命名和迁移历史太乱。AI Studio、Firebase Studio、Project IDX、Antigravity，这些名字在一年内轮换得太快，足够让很多开发者和团队失去耐心。产品能力可以快速叠代，信任感却不行。

第二块短板，是配额、地域和可用性问题。官方文档已经写得很清楚，免费 tier 本来就有限流；再叠加不同国家和账号状态的限制，实际体验并不会像营销话术那样稳定。评论区里关于额度下降、入口不稳定和地域访问问题的抱怨，并不是个例。

第三块短板，是浏览器 builder 到真实生产系统之间，仍然有不少脏活累活没有消失。Secrets、权限、计费、OAuth、日志、错误恢复、数据迁移、团队协作，这些问题 Google 现在提供的是“更短的路”，不是“问题已经不存在”。

这三块短板决定了一件事：Google 会迅速吃掉一部分轻量建站和内部工具需求，但要真正吞掉专业团队市场，仍然要靠工作流稳定性和组织级治理，而不是靠一次刷屏。

我对 Google 下一步动作的五个判断

下面这部分是我的判断，不是官方已经确认的 roadmap。

  • 第一，Google 会优先把 Firebase Studio 到 AI Studio 的迁移链路补齐。现在官方文档已经写明“迁移到 AI Studio 即将推出”，这件事大概率会在 2026 年上半年尽快落地，因为它直接关系到用户资产能不能平滑转移。
  • 第二，AI Studio 和 Antigravity 会出现更强的项目级互通。浏览器里起原型，本地里接重构和发布，这条 handoff 现在已经有了方向，但体验还不够顺。Google 一定会把这条路磨平。
  • 第三，部署路径会继续统一。今天 AI Studio 强调 Cloud Run，Firebase 强调 App Hosting。接下来更合理的动作，是把“原型、预览、发布、监控、扩容”串成一套更统一的默认流程。
  • 第四，第一方连接器会继续扩。Google 已经在 AI Studio 文档里把地图、搜索、实时 API 写成能力入口；再往前走，Drive、Sheets、Workspace 数据、身份体系和更多 Firebase 服务，都是自然延伸。
  • 第五，免费入口会保留，但生产能力会更明确地往计费和组织版能力收束。Google 不太可能无限养一个高成本的全栈 builder，它更可能用免费体验拉新，再把 serious usage 导向 Cloud Billing、Google Developer Program 和更高阶配额。

接下来真正要看的，不是谁更会生成页面，而是谁能承接开发全生命周期

从 2024 年到 2025 年，市场最热的故事是“谁能几分钟做出一个像样 demo”。到了 2026 年，判断标准已经开始变了。真正能拉开差距的，不再只是首屏生成速度，而是后面的整条生命周期能不能接得住。

  • 需求和设计怎么进系统。
  • 代码和后端怎么一起生成和维护。
  • 数据、认证和密钥怎么管理。
  • 部署、监控和回滚怎么完成。
  • 团队如何协作、审查和接管。
  • 图片、设计稿、文档、浏览器操作这些多模态上下文，能不能成为默认输入。

谁能把这六件事连成一条顺滑路径，谁就更像下一代开发平台。谁只能把其中一段做成很炫的演示，谁就会越来越像一个会被并入大平台的功能层。

最后的判断

这次事件的真正结论，不是“Lovable 明天就完了”，也不是“Google 突然造出了一个无敌产品”。

更准确的结论是：Google 已经不满足于卖模型和 API 了，它正在把模型、浏览器原型、Firebase 后端、本地 IDE 和云部署收成一个统一叙事。只要这条链路继续顺下去，市场竞争就会从“谁更会写网页”升级成“谁更像开发者的总工作面”。

在这个新牌桌上，最危险的不是单点能力稍弱，而是没有自己的位置。没有基础设施、没有分发、没有团队工作流、没有多模态入口，只剩一句“我也能从提示词生成一个全栈 App”的产品，接下来会最难受。

Google 这次不是把桌子掀了。它更像是把桌子搬到了自己家里。