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 的 agent capabilities 包括搜尋程式碼庫、編輯檔案、執行終端機指令及處理錯誤。其文件亦描述了透過雲端代理存取瀏覽器的方式。

這個比較顯示，單靠代理功能不足以解釋 Google 的競爭位置。多個產品都可以承諾在各種開發工作中提供協助。真正有意義的差異，在於它們如何配合專案、呈現變更、處理中斷，以及支援持續維護。

在此審視的證據中，並沒有為每一位前 Firebase Studio 用戶獨立確立一個勝出者。偏好在瀏覽器工作並不能決定選擇；偏好某個特定模型亦不能，尤其當周邊的開發工作流程決定該模型實際可完成甚麼。

對於已使用 Google 基建的開發人員而言，Google 仍有一項明顯優勢：熟悉感。留在相關產品之中，或可減少團隊需要學習的新知識。這是合理的好處，但仍須在實際遷移結果中體現。

競爭環境則有不同的切入機會。被迫轉換，會帶來一個時刻，讓用戶重新考慮他們原本未曾質疑的假設。一旦開發人員無論如何都要評估新的工作環境，他們便可將 Google 的建議與其他工具比較。

因此，重要的競爭問題是透過延續性保留用戶。如果 Google 的替代方案能保留應用程式，並令後續工作更容易，整合便可鞏固其地位。如果開發人員反覆重建工作流程，遷移便會成為競爭對手的機會。

這亦改變了閱讀生產力宣稱的方式。能快速產生初步實作的代理，仍可能帶來審核或修復工作。相關結果包括為達成獲接受發布所需的投入。

對於持續維護的商業應用程式而言，可預測的交接或許比令人印象深刻的生成示範更重要。團隊需要知道改變了甚麼、為何改變，以及必要時如何還原。即使代理完成了大部分實作，這些要求仍然存在。

比較亦應考慮在沒有 AI 協助下進行的工作。開發人員仍需要檢查檔案、理解故障，以及在代理誤解要求時繼續工作的途徑。以委派為核心的介面，仍應支援直接調查。

因此，應以相同的應用程式及維護工作評估 Firebase Studio 替代方案。否則，用戶或會把熟悉工具長期累積的問題，與替代方案精心挑選的示範作比較。這種比較偏袒新鮮感，卻無法證明營運上的改善。

Google 的決定並不證明雲端開發環境已經過時。它顯示的是 Google 選擇將開發產品集中在哪裏。瀏覽器存取持續的重要性，仍與這個特定工作區的命運分開。

競爭壓力最終只有在改善遷移後仍能保留的事物時，才會讓用戶受惠。更多代理功能若能減少維護真實軟件的工作量，便有意義；若開發人員必須反覆重建這些代理所需的脈絡，其意義便較小。

留意遷移可靠性、工作流程覆蓋範圍及重複發布

下一項有用證據，將來自一般專案離開 Firebase Studio 後仍能成功持續運作。

未來數月，第一個訊號是遷移可靠性。留意是否出現更清晰的支援專案類型文件、已解決的轉換問題，以及可重複執行的轉移流程。這方面的改善，會加強 Google 關於整合可帶來可管理過渡的論點。

這些證據的質素很重要。成功的示範證明某個挑選出的專案已完成遷移。更廣泛的信心，需要涵蓋不同工作模式的例子，包括在初始建立後有大幅修改的專案。若一般設定反覆出現問題，便會削弱簡化的論點。

第二個訊號是工作流程覆蓋範圍。留意以瀏覽器為主的用戶能否保留令託管工作區對他們有價值的工作內容。同時亦留意桌面用戶能否毋須反覆即興尋找替代方案，便恢復其專案設定及開發實務。

這個訊號測試的是核心產品分工。若這些目的地能清楚滿足不同需要，Google 的產品陣容便更容易在實際使用中理解。若用戶持續在不同工具之間切換，以找回昔日工作流程中缺失的部分，所聲稱的清晰度便較欠說服力。

第三個訊號是遷移後的重複發布。匯入成功只是早期里程碑。持續維護提供更有力的證據，顯示開發人員已重新掌控其應用程式，並可回應新需求。

最具啟示性的例子，將會說明實際變更、所進行的驗證，以及最終發布結果。反覆修復設定或缺失專案脈絡的報告，則會指向相反方向。宣傳性的應用程式數字或個別投訴，均不能單獨確立整體結果。

這些訊號亦為分析訂立合理界線。Google 已公布的停用時間表，確立將會關閉甚麼；其產品公告，確立其希望開發人員使用甚麼。兩類來源均不能獨立證明每位客戶遷移所需花費的時間。

目前而言，Firebase Studio 關閉帶來明確責任，但負擔並不平均。Google 已識別後繼產品，並保留底層 Firebase 服務。開發人員仍必須驗證所選環境是否保留維護其已建立內容的能力。

應把餘下的存取期視為建立這種延續性的時間。選擇一項具代表性的應用程式變更，並在目的地環境中完整跟進，由理解要求到發布結果。保存另一位維護人員所需的專案決策及設定知識。透過已完成的工作評估替代方案，包括審核及修復所花費的工作量。Google 較新的 AI 工具應按此基礎與其他選項一併評估。在舊工作區消失前，團隊中另一位成員能否毋須依賴正要離開的環境，仍有信心維護及發布該應用程式？