這是一份提交給Google I/O 2026寫作挑戰
我記錄Google I/O的方式就像我記錄任何會議的方式一樣——瘋狂地、亂序地，還有許多問號。
以下不是摘要。摘要會將所有事物平等化處理，而本周宣布的並非所有事物都同等重要。這更像是地圖指南：我所注意到的事、我所測試的事、令我困惑的事，以及我認為實際值得你花時間的事。
我會盡可能具體說明。我猜測的部分，我會說明。
資訊窗是實在的。推理並非自動更好。
Gemini 的 200 萬 token 上下文視窗不是一個行銷數字。我給它喂了一個完整的生產代碼庫 — 大約有 18 萬 token 的實際可執行代碼，不是一個示範專案 — 它沒有當機。它載入。它回答了我沒有提到的關於檔案的問題.
這是問題所在：寬大的上下文和良好的推理不是同一回事。
我請它找出間歇性錯誤的來源。它給了我一個自信、詳細、結構上令人信服的回答。但回答是錯的。不是稍微錯誤——而是完全虛構的。它編造了一個競態條件，這個競態條件與症狀描述匹配得如此之好，我花了40分鐘來驗證它，才接受那個競態條件並不存在。
實際的錯誤是在我沒有明確提及的一個檔案中缺少await。
長的上下文讓虛擬幻覺更難捕捉，不是更少發生。模型有更多材料來構建一個聽起來合理的錯誤答案。在你把整個單體倉庫丟入提示之前，記住這一點.
實用提示： 使用長文本上下文來進行檢索式問題的回答（例如「這個程式碼庫有使用 X 的情況嗎？」），而不是用於除錯或推理任務。前者效果很好。後者是一個信心陷阱.
機器人從示範玩具變成了我實際部署的東西
自從「AI 機器人」這個詞進入炒作週期以來，我就對它持懷疑態度。我看到的大多數實現只是帶有市場營銷層面的 API 調用鏈。
本年度I/O的Gemini代理示範在實質上有所不同：錯誤恢復。
我過去觀看的代理示範都順利失敗 — 它們會停止、報告錯誤、等待人類。這些則會迴避。不總是正確，但它們會迴避。被指派從格式錯誤的JSON終端點擷取數據的代理沒有退出 — 它嘗試了備用方案，記錄了原因，並使用部分數據繼續。
那是讓代理在生產中實際有用的行為。不是完美執行。优雅降級.
我還沒在我的自己的基礎設施上運行。我正在觀看的會話是Google AI的新功能流動從五月十九日。我會在本週在一個真實任務上測試後更新這個。
Google AI Studio: 開發者關係團隊沒有足夠討論的工具
大家都覆蓋了 Gemini API 功能。幾乎沒有人覆蓋 AI Studio 本身的品質改善。
會議持續性。 這就是改變了我工作方式的其中一個。AI Studio 現在能在不同的對話回合之間保持上下文，讓人感覺它有狀態——你可以離開一個會話，回來後，問一個與原本任務輻不輻相關的問題，再回到原本的任務，它還是知道你在建立什麼。我不知道這是上下文管理的技巧，還是會話架構中更深层的东西。我知道的是，我不再需要每次切換分頁時，都把我的組件規格貼回對話中。
並列差異檢視. 當你要求它修改程式碼時，現在會顯示變更內容，而不僅僅是完整重寫。後見之明顯而易見的功能。在此之前非常罕見.
直接API導出。 你可以選擇任何成功的 Studio 會話，並以一擊將其導出為 curl 命令、Python 程式片段或 Node.js 呼叫。聽起來很小。從每個「這在 Studio 中有效，現在該如何在我的應用程式中重現它」的工作流程中刪除了約 15 分鐘。
Firebase 安全規則 + Gemini：我最密切關注的宣布
Firebase 安全規則是初級開發者犯昂貴錯誤的地方，而高級開發者仍然必須謹慎。規則語法很具體，失敗模式是那些不會自報家門的安全漏洞，而且反饋迴路很糟糕——你寫下規則，部署後，幾個月後才發現有一條路徑權限過高。
Google 宣布了 Gemini 整合功能，可以分析你的規則對你的數據模型，並標記不匹配。
我還沒測試過。我想測試一下。我的猶豫在於「AI 會讀取你的安全規則」可能意味著兩種意思：
- 它會對已知的反模式進行模式檢查（有用，但有限）
- 它實際上理解你的模式與你的規則之間的關係，並標示出用戶可能讀取他人數據的具體路徑（非常實用，難以構建） 我將在下周一個項目中找出答案，這兩個月來規則一直讓我擔憂.
沒有人指出的事情：Google正押注於API層
以產品人的角度而非開發者角度閱讀I/O發布會，某事變得清晰：Google並未嘗試贏得UI層。Gemini的主要目標不是與ChatGPT競爭消費者心智份額。目標是API和基礎設施層——這是您構建的所有產品的基礎部分。
AI Studio, Firebase 整合, Vertex AI 更新, Android Studio 中的 Gemini API — 這些都是針對正在建立 其他東西 且需要 AI 基礎設施在其之下的開發者。
這對Google來說很聰明，但如果你是建立AI原生工具的初創公司，會稍微不舒服。基礎設施提供者和應用層正在越來越接近.
並不是說這不好。只是在做架構決策時值得知道.
我實際上這週要使用的東西
根據我實現的可能性排序：
- AI Studio 具備會話持續性 — 取代我目前的工 作流程，在每個新對話中貼上上下文
- 長文本代碼審查 — 特別針對檢索問題，而非推理。"找出所有我們在非同步函數中未處理錯誤情況的地方。"
- Firebase 規則分析 — 一個真正的專案，一套讓我感到緊張的規則
- Gemini 1.5 Pro API — 我有一個文件處理任務，幾乎剛好超過了1M token限制。2M會讓我有更多空間。 我暫時先不處理代理相關的事。不是因為它不有趣 — 是因為我想要使用的代理架構還不存在於我的技術堆栈中。這是我的問題，不是Google的問題.
老實說的總結
Google I/O 2026 是一個實質開發者會議，其中包含一些真正有用的宣布，但被大量基礎設施噪音掩蓋，這些噪音只有在您在規模上運行時才重要.
有用的內容：AI Studio 改進、代理錯誤恢復的實際行為、如果 Firebase 規則分析與示範所暗示的深度一樣深入。
我六個月後會回頭檢查的事項：推理任務的2M token上下文窗口（我預期模型品質會提升，不僅僅是窗口大小），以及任何涉及在設備上的Gemini Nano——理論上很有趣，而我因為「在設備上的AI」宣稱被騙過太多次，所以會等實際的延遲數據。
如果你想親自觀看會議：Google I/O會議探索器 有所有東西。如果你是開發者且沒有六小時，Gemini API 會議和 Google AI 新聞發布會是你可以開始看的兩個。
我會在測試完 Firebase 規則整合後更新這篇帖子。可能是星期四。
如果你在會議中發現了我不注意到的內容，請在評論中分享——我特別好奇是否有人測試了非 Pixel 硬體上的 on-device Gemini 功能。