每個開發者在首次為AI應用程式建立時，都會遇到一個特定的時刻
不是那個有趣的時刻。不是那個模型做出令人印象深刻的事情而你感覺自己像個天才的時刻。是另一個時刻。凌晨1點那個時刻，你盯著客戶端程式碼，突然發現你的Gemini API金鑰就那裡，以明文形式存在，即將被打包進一個JavaScript檔案，任何有瀏覽器和十分鐘時間的人都能打開並閱讀。
當我正在開發 Sambhav 時，這一刻發生在我身邊——Sambhav 是一個透過 Whisper 進行實時語音轉文本、履歷分析以及透過 Gemini 提供個人化指導的 AI 職業平台。這個應用程式使用 Next.js 15 作為前端，與 Flask 後端溝通，下方是 Supabase，還有很多需要在不同時刻觸及大型語言模型的組件。
我最自豪的功能：一個實時模擬面試模式，用戶可以自然地說話，獲得他們的回答被譯錄，並讓 Gemini 即時評估他們。它感覺很完善。它運作良好。
它底下的架構是一個即將發生的負擔。
實際的問題
我所陷入的模式是：需要低延遲的 Gemini 呼叫都放在客戶端。像是實時字幕反饋這類，如果增加伺服器迴圈會讓體驗感覺到延遲和失敗。但從客戶端呼叫 Gemini 意味著 API 金鑰必須放在客戶端能夠存取的地方。
開發者通常會選擇的解決方案，各有各的壞處。
你可以將金鑰放在環境變數中，並希望你的打包工具不會洩露它 — 它確實有時候會，而且是以難以審計的方式。你可以透過自己的後端代理所有內容 — 這可行，但現在你在兩個服務之間維護會話狀態，而你的 Flask 伺服器除了轉發請求和增加延遲外什麼也不做。你可以使用短期有效的令牌 — 但那樣你就要建構一個令牌生成和刷新系統，這本身就是一個專案。
更深層次的問題在於，這些方法都無法解決配額問題。就算你隱藏了你的 API 金鑰，有動機的使用者仍然可以捕捉到有效的認證 token 並重放它。不是為了盜取金鑰 — 只是想耗盡你的計費配額。對於個人專案或程式設計競賽的示範來說，這是一個令人煩惱的邊緣情況。對於任何有真實使用者的生產環境來說，這是一個真正的威脅。
我最終選擇實現代理方法，因為這是最有辯護力的，但它增加了意義重大的延遲，並使會話管理顯著變得複雜。Flask後端必須同時維持Whisper會話狀態、Gemini上下文和身份驗證層。當出現問題——而演示中總會出現問題——從來都無法明確是哪一層失敗了。
Firebase AI Logic 实際上改變了什麼
Firebase AI Logic 並非新事物 — 但 Google 在 I/O 大會上推出的內容使其成為一個與六個月前截然不同的工具，而兩項特定功能的組合正確地解決了上述問題.
第一項是 僅限範本模式。這裡的架構很簡單：您的 Gemini 提示 — 系統指令、模型配置、工具定義 — 存放在 Firebase 的伺服器上，而不是在您的客戶端程式中。您的客戶端參考一個模板 ID。就這樣。當一個請求進來時，Firebase 執行伺服器端的模板。如果有人拦截客戶端請求並嘗試注入自訂系統提示，框架會忽略它。沒有從客戶端程式到提示操作的途徑。
對於像Sambhav的採訪模式，這意味著評估標準——定義了Gemini如何評分候選人答案的提示——應該存放在屬於它的伺服器上，而不是打包到前端。客戶端只需發送文字記錄，然後獲得結構化的回應。
第二點是應用檢查重放保護，使用一次性令牌。。從本月開始，Firebase AI Logic 的 App Check tokens 僅限單次使用。一旦使用過一次，就會失效。攻擊者即使截獲了有效的 token，也無法重放它來發起額外的 Gemini 呼叫。我之前描述的那種配額耗盡攻擊——即使 API key 非常隱蔽，技術上仍然可行的那種——現在在基礎設施層面已經被封閉。
延遲的取捨是實際且值得認可的：每個請求產生一個新的令牌會增加一個網路迴圈。對於每幾秒就呼叫一次Gemini的實時轉文本功能，這個成本會累積起來。在啟用延遲敏感路徑之前，值得為此進行分析。
混合推論部分
我認為有一則公告沒有得到足夠的報導，因為它聽起來像是效能優化，實際上卻是一項架構上的決策.
Firebase 現在支援跨 iOS、Android（搭配 Gemma 4）以及即將很快正式發布的 Chrome 網頁版進行混合推論。當可以在設備上本地運行時，模型就會在設備上運行，否則會回退到雲端 Gemini。
這件事的關鍵不僅僅在於「更快、更便宜」，更在於韌性。Sambhav 是為了競賽週的條件而建造的，這意味著要在會議的無線網路下運作。會議的無線網路非常不友善。面試模式有時會在會話中間卡住，因為一個 Gemini 呼叫超時了，這在有人試圖展示產品的最後一刻摧毀了整個體驗。
混合推論是指流程中的輕量級部分——文字轉換清理、基本回應格式化、簡單分類——無論網絡狀況如何都可以在本地運行。較重的推理仍然交由雲端處理。當網絡不通時，應用程式仍然可以運作。
對於實施這個方案的人來說，實際的問題在於：你無法從裝置上的 Gemma 4 模型獲得完整的 Gemini 品質。能力差距是實實在在的，你需要設計你的功能，讓本地路徑能夠產生一個和藹的降級體驗，而不是一個崩潰的體驗。這是一個設計問題，不僅僅是一個配置問題。
這在實際上意味著什麼
Firebase AI Logic GA 不是頭條新聞。它不會成為潮流。但對於任何已經發布或嘗試在客戶應用程式中發布 AI 功能的開發者來說，當他們遇到「API 金鑰放在哪裡以及如何保護我的配額」的壁壘時——這才是來自 I/O 的真正重要的宣布。
模板模式、應用程式檢查重播保護和混合推論的組合意味著我為 Sambhav 搭建的安全和韌性架構——代理伺服器、會話狀態管理、手動金鑰處理——現已成為 Firebase SDK 的一個優質功能。你不必自行建立基礎設施。你只需要進行設定。
我會密切關注的生產前問題：範本模式與重放保護解決了問題的不同部分，並具有不同的延遲特徵。不要在默認情況下將兩者都啟用。先分析延遲敏感路徑，了解迴圈成本落在何處，並在可接受的妥協方案上做出有意識的決策。
過去需要後端專案的保安架構，現在則包含在三個 Firebase 設定選項中。這在實際發布上是一個有意義的轉變。