交互体验崩塌：Gemini在智能体时代的可靠性危机
作者回顾了自己准备本期视频时的亲身经历，试图使用谷歌最新升级的 Antigravity 2.0 和刚发布的 Gemini 3.5 Flash 来撰写讲稿，但最终因模型表现糟糕而放弃，转而使用GPT完成。在测试过程中，作者询问如何使用刚在IO上发布的 Gemini Spark，模型虽然进行了搜索和思考，却混淆了概念，将其指向了 Apache Spark 或 科大讯飞 的相关产品，甚至反问作者是否真的要用Apache Spark。这种对新产品名称的无知和胡言乱语，让作者意识到 Gemini 3.1 Pro 同样存在严重问题。 > “我去问Gemini...他也搜索了也思考了...你到底要用哪个呢...当时把我问傻了。”
这种体验并非单纯的吐槽，而是揭示了 智能体时代 的核心痛点。谷歌在IO上强调智能体（Agent）时代，但普通用户关心的是AI能否听懂指令、准确执行任务并减少低级错误。在聊天阶段，AI胡说八道仅引人发笑；但在智能体阶段，AI操作文件、发送邮件、删除代码或安排会议，一旦出错后果严重。因此，可靠性远比速度和价格重要。作者指出，当前系统本身不够靠谱，若再让不可靠的模型去执行真实工作，用户无法容忍。Gemini 3.5 Flash 在谷歌自家的 Harness Agent 框架上表现出的不靠谱，证明了 只追求省钱和提速毫无意义，用户宁愿花高价使用GPT或Claude，也不愿因贪便宜而遭遇频繁的错误和愤怒。
战略误判：Gemini 3.5 Flash 与 Omni 的市场错位
谷歌此次IO发布的 Gemini 3.5 Flash 主打“快”和“便宜”，但作者认为其性价比并无优势。 > “你说快不快呢确实很快便宜呢它其实没有国内的DeepSeek V4 Pro便宜也没有像什么MiniMax呀或者是其他的一些中国模型便宜”。谷歌选择先发布Flash而非Pro，可能出于三种考量：一是Pro模型不够惊艳，无法明显压制GPT、Claude或DeepSeek；二是智能体时代需要更便宜、更快的模型，无需深度思考；三是留后手等待更强模型。然而，作者认为谷歌选了一条难路，因为智能体应用的核心需求是 靠谱，而非廉价。Gemini 3.5 Flash 的缺陷在于跑题、瞎猜、硬套旧知识，导致用户不敢放心使用。
另一款发布产品 Gemini Omni 被描述为全能的世界模型，具备全模态输入输出能力，能理解物理规律并保证逻辑自洽。然而，在与字节跳动的 Seedance 2.0 对比测试中，Gemini Omni 虽然物理逻辑自洽，但缺乏表现力，用户无分享欲望。 > “结果发现什么呢Gemini Omni他输出的视频确实是物理上自洽了但是没有表现力Seedance3.0出来的东西才有表现力”。作者以iPhone击败尼康佳能为例，指出用户更看重 用户感知 和 易用性，而非纯粹的技术还原度。Gemini Omni 像尼康佳能一样追求技术内核，却忽视了用户想要“随手拍、直接发”的体验需求，导致 用户感知极差。
云端生态优势与入口战略的混乱
Gemini Spark 是作者较为期待的产品，旨在解决AI Agent在云端运行的数据与权限矛盾。本地运行Agent需巨大权限且不安全，云端运行则需解决数据上传和交互问题。谷歌凭借 Workspace 和 Google Drive 的云端优势，理论上能完美解决这一痛点，成为智能体时代的基础设施。然而，谷歌目前仅向美国地区的 Google AI Ultra 用户开放内测，Pro用户被排除在外。作者警告，鉴于底层模型 Gemini 3.5 Flash 的不靠谱，若将其用于Spark，可能导致 惨绝人寰的事故，建议用户谨慎使用。
Antigravity 2.0 试图成为谷歌的超级APP入口，类似Claude的客户端或OpenAI的Codex。但作者认为其难用并非技术不足，而是 谷歌内部入口过多，战略定位模糊。谷歌从未擅长前端体验和用户感知，其成功依赖后端算法（如搜索、Gmail反垃圾、YouTube推荐）。 > “谷歌真正强的地方是它的后端算法特别强可以提供这种别人无可替代的结果”。在智能体时代，谷歌若不能统一入口，将难以形成类似iPhone那样的用户体验闭环，导致其 宏大叙事 沦为令人厌烦的空谈，错失移动互联网时代后再次建立用户粘性的机会。
Antigravity客户端体验糟糕与内部资源倾斜不足
在Google I/O期间，作者亲自测试了Google推出的新客户端Antigravity，试图通过命令行工具（CLI）完成浏览器操作、文件处理等复杂任务，但体验极差，报错频发。无论是使用Gemini 3.5 Flash还是Gemini 3.1 Pro，效果均不理想。在尝试将原有的Gemini CLI替换为Antigravity CLI的过程中，作者经历了繁琐的安装步骤：系统提示需先卸载Gemini CLI，再安装Antigravity IDE才能生成CLI工具。这一过程不仅复杂，且最终执行任务的核心模型竟是Claude Opus，而非Google自家的Gemini系列。
“干活的是谁，是Claude Opus，这个有点让人哭笑不得啊。”
这种“挂羊头卖狗肉”的现象暴露了Antigravity作为收购产品（源自Win Server团队）在资源投入上的不足。相比Google内部的“亲儿子”项目，Antigravity缺乏足够的人力、物力及Token倾斜，导致其作为一个试图争夺用户注意力的“超级APP入口”，显得粗糙且难用。由于不敢轻易移除底层依赖的Cloud Ops 4.6，以免导致KPI和用户量下滑，Google在整合上显得三心二意，最终呈现出的产品只是一个半成品。
内部产品内耗与战略主线分散
Google面临的核心问题并非技术实力不足，而是“好牌太多，主线太散”。Google拥有搜索、YouTube、Android、Chrome、Gmail、Drive、Docs、Sheets、Google Cloud、Gemini、TPU、DeepMind等众多顶级产品，任何单一产品都足以击败市场独角兽。然而，当这些产品汇聚在一起时，却形成了严重的内部掣肘。
目前，Google内部存在多个争夺“AI入口”的产品线： 1. Android Studio：Google维护多年的IDE，仍在持续升级。 2. AI Studio：试图独立成为应用。 3. Firebase Studio：谷歌云推出的系统。 4. Gemini Code Assist：云工具。 5. Antigravity：新推出的客户端。
“你除非把他们通通都干掉，这个是可以的。如果下不了这种决心的话，Antigravity也只能是这样啊。”
这种“撒胡椒面”式的策略导致每个产品都只能分到少量资源，无法形成合力。与OpenAI通过砍掉冗余项目来聚焦不同，Google舍不得放弃任何一个入口，导致体系架构无法打破，部门利益相互冲突。正如“三个和尚没水喝”，Google拥有几十个“和尚”，却难以集中力量喝到那碗水。缺乏唯一的中心和突出点，使得Google在客户端战争中难以形成绝对优势。
TPU生态局限与发布会模式的失效
在算力层面，尽管TPU常被宣传为比英伟达显卡更便宜、更省电，但在实际大模型训练中，TPU的适配成本极高。Midjourney CEO抱怨，将算法迁移至TPU后，虽然节省了成本并实现盈利，但训练速度比同行慢了一年。这是因为TPU缺乏像英伟达那样成熟的预置工具和社区支持，小公司难以像Google或Anthropic那样投入大量工程师进行调教。
目前全球大模型训练主要依赖三种算力：
| 算力类型 | 代表产品/案例 | 特点与现状 |
|---|---|---|
| 英伟达 GPU | 绝大多数主流模型 | 工具链成熟，社区支持好，训练最简单 |
| Google TPU | Gemini, Anthropic部分模型 | 需大量适配调教，小公司难以驾驭 |
| 华为昇腾 | DeepSeek V4 Flash | 需先在英伟达训练Pro版，再蒸馏至昇腾 |
此外，传统发布会模式已失效。AI大厂不再依赖线下发布会，而是通过线上直播、博客或直接上线产品来吸引用户。OpenAI在Google I/O前发布GPT-4o和GPT-image，以及重置Codex额度，直接抢走了注意力。相比之下，Google I/O发布的众多产品（如眼镜等）因缺乏实际竞争力，难以获得长期关注。小米、百度等国内厂商的发布会也因产品力不足而显得尴尬，市场更倾向于用脚投票，选择真正好用的工具。
谷歌的出路：必须做出取舍
Google并未输在技术上，而是输在大公司病和产品决策上。它不敢牺牲任何部门利益，不敢砍掉重复产品，也不敢让某个产品成为绝对主线。若要拯救局面，Google需要发出两个关键信号：
- Workspace + Spark的成功：必须将Spark模型下放至Pro或更便宜账号，并确保在Workspace环境下不再出现幻觉（胡说八道）。目前Gemini 3.5 Flash在此环境下事故频发，需紧急修正。
- Antigravity成为默认入口：若Antigravity能整合内部资源，成为能与Claude Code和Codex竞争的超级APP，则Google在客户端仍有胜算。
“谷歌的问题不是看不到未来，它的问题是看见了太多未来，却还没有决定哪一个未来才是自己真正要压上去的。”
Google需要像微信牺牲手机QQ那样，做出痛苦的取舍，集中资源All-in某一条具体路线，而不是试图在所有领域同时保持领先。没有决断，就没有未来，这是Google当前面临的最大挑战。