Antigravity 中 Gemini 3.1 Pro 消失：实测 3.8 Flash 的能与不能

Antigravity 的模型选择器里，Gemini 家族只剩下一个选项了。

2026 年 10 月 13 日早晨，开发者打开 Google Antigravity 准备开始当天的开发工作时，发现模型选择器中 Gemini 家族下只剩下一项：Gemini 3.8 Flash。此前作为复杂任务首选的重型旗舰模型 Gemini 3.1 Pro 已经消失。

Antigravity 模型下拉选择器截图

这不完全出乎意料，但一个主力模型毫无预告地从选择器中消失，对于每天依赖 Antigravity 的开发者而言，立刻引出了一系列运维层面的疑问。本文梳理已确认的事实、尚未验证的猜测，以及在实际 Web 开发和 Excel 自动化项目中得到的真实体验。

一、哪些是确认的，哪些不是

当日常工具链的核心组件在无预警的情况下发生变化时，区分硬事实和社交媒体上的猜测至关重要。截至 2026 年 10 月 13 日，可以确认的信息如下：

已确认的事实：

在实际使用的 Antigravity 客户端（Google AI Pro 订阅）中，Gemini 3.1 Pro 已无法选择。Gemini 家族唯一的入口是 Gemini 3.8 Flash，覆盖 Low / Medium / High 全部思考层级。
Google AI 开发者论坛上有多位订阅用户报告，3.1 Pro 在一次平台同步后突然消失，引发了要求恢复该模型的呼声。

尚未确认的事项：

Google 并未发布官方博客或 changelog 声明 3.1 Pro 已永久退役。这究竟是有意的淘汰、临时的路由调整，还是未公布的配额分层策略，目前不清楚。
Antigravity 官方模型文档在撰写时仍列出 3.1 Pro 覆盖各订阅层级，Google Gemini API 的弃用时间表中也没有 gemini-3.1-pro-preview 的关闭日期。

这说明两种可能：要么公开文档落后于生产部署，要么 Google 正在执行分阶段的服务器端灰度推送，尚未覆盖所有账户。在做任何结论之前，建议先检查自己的选择器和账单面板，确认你的工作流是否真的受到了影响。

二、这不是孤立事件：八个月的战略轨迹

要理解 3.1 Pro 为何消失，需要回顾 Google 在 2026 年的发布节奏。这并非一夜之间的意外，而是向高效、小体积模型激进转型的结果。

发布节奏的巨大落差

今年年初以来的时间线值得关注：

2 月 19 日：Google 发布 Gemini 3.1 Pro，凭借深度分析推理、顶级的 ARC-AGI-2 表现和细致的架构规划能力获得广泛好评。
Flash 系列的密集迭代：Gemini 3.5 Flash（5 月 19 日）、3.6 Flash（2026 年仲夏）、3.7 Flash（2026 年夏末）、3.8 Flash（2026 年 9 月初）。

不到四个月，Google 推送了四个 Flash 重大架构版本，而 Pro 层级零更新。研究重心明显集中在推理优化、蒸馏和测试时计算，目标是让 Flash 快到足以在 agentic 循环中替代更重的基础模型。

更大范围的产品线精简

Antigravity 的模型选择器正在经历全面整合。模型管理控制台显示活跃的"Notice"标记，警告包括旧版 Claude 4.6 端点在内的遗留模型将于 2026 年 11 月 2 日彻底停用。

在全球数据中心维护多个数十亿参数模型意味着巨大的 GPU 集群开销。高频 agentic 循环（助手每分钟读取数十个文件、运行终端命令、检查 linter 十五次）在 3.1 Pro 这样计算密集的模型上运行，成本远高于服务蒸馏后的 3.8 Flash 检查点。

三、实测对比：3.1 Pro 与 3.8 Flash 的真实差距

在一个多门店 POS 报表工作簿的自动化项目中，同样的提示词、同样的多表结构约束、同样的数据集，两个模型的表现差异显著：

指标	Gemini 3.1 Pro	Gemini 3.8 Flash High
单步延迟	28–45 秒	3–6 秒
配额消耗	约 42%（4 轮修订）	约 11%（一次完成）
重构迭代	3 次失败（误改了正常工作的格式化例程）	1 次成功

Flash 在速度、配额效率和精准度上全面占优。但必须诚实地指出这份数据的局限：

单一样本：这是一个工程师在两个特定领域、结构良好的模块化代码库上的经验。
提示工程进步：使用 3.1 Pro 的数月里，提示技巧显著提升，学会了隔离任务并提供具体类型定义。Flash 的成功部分归功于更好的指令。
偏好与被迫的区别：

因为 Flash 在你的工作负载上表现优秀而选择它，是工程决策。因为 Google 移除了所有其他 Gemini 选项而被迫使用 Flash，是基础设施约束。

两者的区别不能被混淆。

四、Gemini 3.8 Flash 在 Web 开发中的五个实际观察

在生产级 JavaScript、CSS 和数据库过程中使用 Gemini 3.8 Flash High 思考模式后，以下五个特征值得注意：

1. 极快的 Agent 循环响应

在 Antigravity 这样的 agentic 环境中，瓶颈通常不是打字速度，而是 agent 编辑文件、运行测试、检查 stdout、写下一个修复之间的等待。3.1 Pro 下十步 agent 循环需要 7 到 10 分钟，3.8 Flash 下同样的循环不到 90 秒完成。快速反馈让开发者保持在心流状态。

2. 高保真的上下文吸收能力

Gemini 的长上下文窗口仍然出色。在实际项目中，可以同时喂给 3.8 Flash 数据库 schema、客户端路由逻辑、Supabase 行级安全策略和整个购物车脚本，它能追踪跨文件的关系而不遗漏变量名。

3. 危险区：单体大重构陷阱

这是 3.8 Flash 最危险的失败模式。当要求它在一个提示中执行涉及多个关注点的全面重构时，它经常引入回归问题。

一个真实案例：要求 3.8 Flash "重构 app.js 中整个认证状态管理，将会话存储转为 cookie，并更新所有受保护路由监听器"。结果模型成功重构了认证监听器，但完全遗漏了购物车角标更新事件监听器，并破坏了文件下方已有的错误弹窗处理器。它"忘记"保留那些被它判定为次要的相邻函数。

解决方案是拆分任务：先让它在 auth.js 中写新的 cookie 会话助手，不碰 app.js；再让它只更新 router.js 中的路由守卫。

4. 缺乏视觉参考时审美保守

如果放任自流，3.8 Flash 产出的 Web 样式像是 2014 年的作品：灰色按钮、刺眼的 #0000ff 链接色、僵硬的 Bootstrap 式布局。但如果提供现代 UI 截图或严格的设计 token 系统（比如"暗色玻璃拟态，1px 边框微光，hsl(220, 15%, 10%) 卡片"），它将这些视觉线索转化为干净原生 CSS 的能力会大幅提升。

5. 文档和表格自动化的精准度

虽然设计直觉保守，但它对结构化文件格式（.xlsx、.docx、复杂 CSV 解析器）的程序化处理相当可靠。单元格格式化、动态公式求值、多表合并几乎零语法错误。

五、另一面：开发者社区为何拉响警报

3.8 Flash 适合有明确边界的开发风格，但其他工程师的经历截然不同。

在 Google AI 开发者论坛上，从事大型企业代码库的开发者表达了真实的焦虑。一位中型企业代码库的用户详述了 3.8 Flash 如何拖累他们的冲刺：

编造 API：Flash 幻觉出不存在的库方法
范围蔓延：要求修改一个控制器，结果改动了三个不相关的工具文件
无限推理循环：陷入重复的读取-思考循环，反复读取同一个配置文件直到用户的每小时 token 配额耗尽

他们唯一的解救方式是 git reset --hard 回滚分支并切回 3.1 Pro 保守、审慎的推理模式。而当 3.1 Pro 从选择器中消失后，他们感到被困住了。

基准测试揭示的真相

独立技术分析解释了为何这两种矛盾的体验可以同时成立：

基准错觉：3.8 Flash 在 Terminal-Bench 2.1 上获得 89.4% 的高分，但该评测套件已被现代模型普遍攻克。在测试多步故障恢复、冷门编译器错误和深层依赖树的 Terminal-Bench 4.0 上，Flash 仅得 46.8%，远落后于 Claude Opus 5（78.2%）和 GPT-5.6（74.1%）。
Agentic Harness 的威力：3.8 Flash 在 Antigravity 这类 IDE 中表现明显优于裸聊天界面。IDE 提供实时 lint 反馈、文件树检查和终端测试执行，相当于外置的前额叶皮层，补偿了 Flash 较少的内部参数量。

工作假设：Flash 在问题空间能清晰装入上下文的有界任务上表现出色。当被迫在未驯服的、紧耦合的单体代码库中导航时——每一行都依赖未文档化的遗留架构——它的表现呈指数级下降。

Terminal-Bench 与基准饱和

Terminal-Bench 是一类评测 AI 模型在真实终端环境中完成多步任务的基准，例如在沙箱里排查构建错误、修复依赖冲突、执行跨文件的代码迁移。它的评分基于任务是否被端到端解决，而非单轮问答正确率，因此更能反映 agentic 场景的实战能力。

文中提到的"基准错觉"指的是基准饱和（benchmark saturation）：当一个评测套件的题目被主流模型普遍攻克后，分数分布会集中在高区间，模型之间的区分度急剧下降。Terminal-Bench 2.1 的题目多为结构清晰、错误信息明确的常见任务，因此 3.8 Flash 能拿到 89.4%。而 4.0 版本引入了冷门编译器报错、深层依赖树和需要回滚重试的故障恢复场景，考察的是模型在信息不完整时的探索与纠错能力，这正是小模型参数量不足的短板所在。因此，阅读任何模型基准分数时，都需要确认该套件是否已经饱和，否则高分可能只说明题目太简单，而非模型真的强。

六、开发者的生存手册

无论 Google 明天恢复 3.1 Pro 还是永久退役它，以下清单建议立即在 Antigravity 工作流中实施：

1. 记录你的环境：今天打开模型选择器，截取带时间戳的截图，显示活跃模型列表和账户订阅方案。

2. 执行原子化 Git 提交：不要让 agent 在脏工作树上无人监督地运行。每次重要提示前先提交：git commit -m "feat: stable state before cart refactor"。如果 Flash 跑偏，三秒内回滚。

3. 在提示中强制执行硬性负面约束：明确告诉模型哪些不要碰。例如："在 js/cart.js 的 calculateTotal() 中实现新的折扣计算。约束：不要修改任何数据库 schema 或迁移脚本。不要触碰已有的 CSS 类或 HTML 结构。不要引入任何新的外部库。"

4. 配置多模型策略：不要独家依赖单一 AI 模型家族。在工作区配置备用提供商（如 GPT-5.6 或 Sonnet）。用 3.8 Flash 处理 90% 的快速代码生成和测试循环，在需要从零设计复杂数据库架构时切换到更重的推理模型。

5. 在自己的代码上做基准测试：从实际代码库中挑出五个常见任务（bug 修复、重构、单元测试、数据库迁移、文档编写）让 Flash 跑一遍。你自己的仓库是唯一有意义的基准。

一个开放问题

对所有使用 Google Antigravity 和 Gemini 家族的开发者：你最近一次真正需要 3.1 Pro 或 Opus 这样的重型旗舰模型是什么时候？那个任务如果拆成更小、边界更清晰的提示，3.8 Flash 能不能胜任？你的选择器里 3.1 Pro 也消失了吗？

背景补充

什么是蒸馏模型

文中反复提到 Flash 系列是"蒸馏后的检查点"，这里补充一下背景。知识蒸馏（Knowledge Distillation）是一种模型压缩技术：先训练一个参数规模大、推理能力强的"教师模型"（如 3.1 Pro），再让一个参数更少、推理更快的"学生模型"（如 3.8 Flash）去模仿教师模型的输出分布——不仅是最终答案，还包括 token 级别的概率分布（logits）或中间推理链。这样学生模型能在参数量远低于教师的情况下保留大部分任务能力。

对 Google 而言，蒸馏的商业价值在于：Flash 级别的模型单次推理所需的 GPU 显存和算力显著更低，在 agentic 循环这种"每分钟调用数十次"的高频场景下，单位任务的成本可能相差一个数量级。这也解释了为何 Flash 在四个月内连推四个版本，而 Pro 层级停更——优化蒸馏损失函数和测试时计算策略，比继续扩大教师模型规模的投资回报率更高。代价是学生模型在训练数据分布之外的"长尾"任务上更容易失败，这与后文 3.8 Flash 在单体代码库中的表现相符。

如何看待单一样本的经验数据

文中明确标注了这份对比数据的三个局限，这里再展开一下为什么这一点在模型选型中尤为重要。单个工程师、两个项目、结构化良好的代码库，这三者共同构成了一个便利样本（convenience sample）——它反映的是"在特定条件下 Flash 表现如何"，而不是"Flash 普遍比 Pro 强"。

更关键的是混杂变量（confounding variable）：随着时间推移，使用者的提示工程能力在提升，所以在 3.8 Flash 上取得更好结果，可能部分归因于提示质量本身，而非模型能力差异。要剥离这个变量，理想做法是在同一时间点、用同一套提示分别跑两个模型，但 3.1 Pro 已被移除，这个对照实验现在无法执行——这本身就是模型被动下架带来的测量损失。

因此，文中的表格应被读作"一位开发者的方向性证据"，而不是可用于团队决策的基准。真正有决策价值的，是第六节建议的"在自己的代码库上做基准测试"：因为只有你自己的仓库承载了你真正关心的任务分布。

多模型策略与供应商锁定

文中的第 4 条建议涉及一个更宏观的工程原则：**供应商锁定（vendor lock-in）**的反制。当你的整个开发流都建立在某一家厂商的某个特定模型上时，厂商的一次服务器端配置变更（如本次 3.1 Pro 下架）就能直接改变你的生产力与成本结构，而你没有任何议价或缓冲空间。

实践层面的多模型策略通常包含三层：第一层是接口抽象，把"调用哪个模型"从业务代码中抽离到一个可配置的适配层，切换模型时只改配置不改逻辑；第二层是能力分工，把高频、边界清晰的任务（代码补全、单元测试生成、格式转换）交给快而便宜的模型，把低频、高风险的任务（架构设计、复杂重构规划）交给重型模型；第三层是持续验证，定期用同一组任务对比不同模型的输出，而不是等厂商下架后被动迁移。这样即便某个模型突然消失，影响也被限制在适配层的一行配置里，而非整个工作流的重建。