Gemini 3 Pro 已经结束了。如果你在 2026 年 3 月 28 日 还在比较 Gemini 3.1 Pro 和 Gemini 3 Pro，直接从 gemini-3.1-pro-preview 开始就对了。Google 当前文档明确写着：gemini-3-pro-preview 已弃用，并在 2026 年 3 月 9 日 关闭；官方给出的替代就是 Gemini 3.1 Pro。真正值得关心的差异，其实没有很多旧对比页写得那么散。两者的多模态输入合同和 headline token limits 基本一致，但 Gemini 3.1 Pro 是现役分支，支持 Google Maps grounding，而且多了 gemini-3.1-pro-preview-customtools 这条给 tool-heavy agent 用的单独路径。
“证据说明：本文中的状态、能力和价格信息，均于 2026 年 3 月 28 日按 Google 当前模型页、deprecations 页和 pricing 页重新核对。
如果你只要结论
如果你的问题是“我现在到底该用哪个”，答案很简单：用 Gemini 3.1 Pro Preview，把 Gemini 3 Pro Preview 当成迁移历史。
| 你真正要做的事 | 直接从哪里开始 | 为什么 |
|---|---|---|
| 新上一个较强的 Gemini 文本项目 | gemini-3.1-pro-preview | 它是当前仍在运行的分支 |
| 迁移旧的 Gemini 3 Pro 集成 | gemini-3.1-pro-preview | Google 直接把它写成替代路径 |
| 做 coding agent 或 tool-heavy loop | gemini-3.1-pro-preview-customtools | Google 说它更擅长优先调用注册工具 |
继续把 gemini-3-pro-preview 当生产选项 | 不要这样做 | 这个分支已经停用 |
Gemini 3.1 Pro 到底改了什么
最大的变化不是跑分，而是生命周期。
Google 当前的 Gemini 3 Pro 页面开头就写了警告：gemini-3-pro-preview 已经 deprecated，并于 2026 年 3 月 9 日 shut down；开发者应迁移到 gemini-3.1-pro-preview。只要这一点成立，这篇文章的核心就不是“谁更强”，而是“迁移到当前分支时，哪些变化真的值得你重视”。
最具体的变化有三个。
第一，Gemini 3.1 Pro 是活着的分支。这意味着当前价格、当前能力表、当前接入合同，都应该从 Gemini 3.1 Pro 的官方页面读，而不是继续参考旧 Gemini 3 Pro 的缓存截图或二手卡片。
第二，Gemini 3.1 Pro 支持 Google Maps grounding。在 Gemini 3.1 Pro 当前模型页里，Google Maps grounding 是 supported；在 Gemini 3 Pro 页面里，它是 not supported。这个差异不是文案修饰。如果你的任务和地点、门店、地图数据有关，这就是实际能力边界的变化。
第三，Gemini 3.1 Pro 多了 -customtools 独立 endpoint。Google 现在把 gemini-3.1-pro-preview-customtools 单独列出来，说它更擅长优先调用开发者注册的工具，例如 view_file、search_code。同时 Google 也提醒：如果你的场景并不受益于这些工具，质量可能会有波动。Gemini 3 Pro 没有这条独立路径。
除了这些具体工作流差异，Google 对 3.1 Pro 的产品定位也更清楚：更好的 thinking、更好的 token efficiency、更 grounded、更适合 software engineering 和 agentic workflows。这个定位不能代替你自己的评测，但它明确告诉你 Google 希望新分支解决什么问题。
哪些东西没变
这一轮迁移比很多人想象中简单，一个重要原因是 Google 没有把基础合同推倒重来。
两边当前模型页都写着相同的 输入模态：text、image、video、audio、PDF；输出都是 text。两边列出的 headline token limits 也一样：1,048,576 input tokens、65,536 output tokens。Batch、caching、code execution、function calling、search grounding、structured outputs、thinking、URL context，这些高阶形态也都还在。
这意味着你不需要把它理解成“整套架构推翻重做”。对大多数团队来说，它更像是一场聚焦迁移：
- 改 model ID
- 重测关键 prompt
- 复核 grounding 和 tool-routing
- 按当前分支重新核价
但“合同看起来相似”不等于“行为完全相同”。Google 自己都在说 Gemini 3.1 Pro 提升了 thinking、token efficiency 和软件工程行为，这就意味着 prompts、tools 选择和输出风格都可能变。正确姿势不是恐慌，但也绝不是盲目字符串替换。
规格与能力差异速览
真正值得你记住的是这张表：
| 维度 | Gemini 3 Pro Preview | Gemini 3.1 Pro Preview |
|---|---|---|
| 当前状态 | 已弃用，已关闭 | 当前 preview 分支 |
| 模型 ID | gemini-3-pro-preview | gemini-3.1-pro-preview |
| 替代关系 | 只剩迁移意义 | Google 官方替代路径 |
| 输入 | Text / Image / Video / Audio / PDF | Text / Image / Video / Audio / PDF |
| 输出 | Text | Text |
| 输入上限 | 1,048,576 | 1,048,576 |
| 输出上限 | 65,536 | 65,536 |
| Search grounding | Supported | Supported |
| Google Maps grounding | Not supported | Supported |
| customtools 独立路径 | 没有 | gemini-3.1-pro-preview-customtools |
| Image generation | Not supported | Not supported |
| Live API | Not supported | Not supported |
这里最值得前置的有两点。
一是 Maps grounding。如果你做的是 location-aware 任务，这一项就足以让你停止把两者当成可互换分支。
二是 customtools 路由。对做 coding agent、repo agent、multi-step tool workflow 的团队来说，真正重要的往往不是“又多了一个抽象 benchmark 点”，而是模型到底会不会优先走你定义好的执行面。如果你的工作流依赖注册工具，下一篇最直接的延伸就是 Gemini 3.1 Pro customtools 指南。
还有一个命名陷阱需要顺手拆掉：本文里的 Gemini 3 Pro 指的是已经退场的文本模型 gemini-3-pro-preview，不是 Gemini 3 Pro Image。后者属于另一条产品线，也不是这次迁移判断的一部分。
价格与迁移影响
Google 当前 pricing 页给出的可执行答案，只应落在现役分支上。对 标准 Gemini 3.1 Pro 请求，Google 现在列的是：
- 输入：
200k以内\$2.00 / 1M，超过后\$4.00 / 1M - 输出：
200k以内\$12.00 / 1M，超过后\$18.00 / 1M - Context caching：
\$0.20 / 1M与\$0.40 / 1M，另加 storage - Search grounding：每月
5,000次免费，之后\$14 / 1,000 - Maps grounding：每月
5,000次免费，之后\$14 / 1,000
对 batch，Google 当前列的是：
- 输入：
200k以内\$1.00 / 1M，超过后\$2.00 / 1M - 输出：
200k以内\$6.00 / 1M，超过后\$9.00 / 1M
这段价格信息有两个实际意义。
第一，它告诉你未来成本应该看哪里：看 Gemini 3.1 Pro，而不是继续拿 Gemini 3 Pro 的旧截图当预算依据。分支一旦停用，旧价格就不再适合指导当前规划。
第二，它也告诉你迁移时该重测什么。如果你以前把 Gemini 3 Pro 当成长上下文 reasoning 分支，那么现在除了改 model string，还应该重点看：
- 是否经常跨过
200kprompt threshold - 哪些 tool-heavy 请求应该改走
-customtools - 哪些 grounded 请求会因为 Maps 变得更有价值
- 哪些 reasoning-heavy 请求会被 output 或 thinking cost 主导
如果你现在更需要的是接入路径而不是对比逻辑，下一步直接看 Gemini 3.1 Pro API 接入指南。如果你关心迁移后怎么控制 reasoning 成本，则更适合看 Gemini 3.1 Pro thinking level 指南。
一份足够安全的迁移清单
最稳妥的迁移心态是“聚焦”，不是“随便换一下试试”。
第一步当然是把 gemini-3-pro-preview 改成 gemini-3.1-pro-preview。但不要停在这里。官方 replacement 不等于行为百分之百相同，尤其当 Google 自己都在强调 3.1 Pro 的 better thinking、token efficiency 和更可靠的 tool usage。
真正值得跑一遍的是这六项：
- 把 model ID 改到所有环境和后台任务里
- 对核心 prompt 重新做回归
- 复核 grounding 路径，尤其是与 Maps 相关的调用
- 重测 tool-calling 行为，决定标准分支还是
-customtools更适合你的 agent - 按现行 pricing 页重算成本
- 把团队内部旧文档里的 Gemini 3 Pro 当前候选表述删掉
对大多数团队来说，这已经够了。你不需要把它上升成一场漫长的平台重构，但你确实应该停止把 Gemini 3 Pro 当成“还可以先看看”的新项目候选。
什么时候 Gemini 3.1 Pro 也不是对的答案
官方替代不代表它适合所有任务。
Google 当前页面依然写着：Gemini 3.1 Pro 不支持 image generation，也 不支持 Live API。如果你的真实工作负载是“出图”“实时语音”“最低成本高频文本流水线”，那你从一开始就不该把问题写成 Pro 对 Pro 的迁移题。
这点很重要，因为很多迁移会犯一个错：旧分支退场了，就把名字最像的新分支顶上去。更稳的做法是先确认旧分支当初解决的是不是正确任务，然后再决定现在该迁移到哪里。
FAQ
Gemini 3 Pro 现在还能用吗？
不能。Google 明确写着 gemini-3-pro-preview 已弃用，并在 2026 年 3 月 9 日 关闭。
Gemini 3 Pro 的官方替代是什么？
gemini-3.1-pro-preview。
token limits 变了吗？
没有。两边当前模型页列出的 headline limits 都是 1,048,576 input 和 65,536 output。
Gemini 3.1 Pro 最值得注意的新点是什么？
对多数开发者来说，是 Google Maps grounding 支持 和 gemini-3.1-pro-preview-customtools 独立 endpoint。
这次迁移可以当成 drop-in replacement 吗？
不能。基础合同很像，但 prompts、tools、grounding 路径和成本都应该重新验证。
这篇要不要顺便拿 Gemini 3 Pro Image 一起比？
不用。那是另一条产品线，不属于这次文本模型迁移判断。
最终结论很短：Gemini 3 Pro 已退场，Gemini 3.1 Pro 是当前分支，而今天真正有价值的比较，不是谁在一场过时的正面对打里赢了，而是迁移到现役分支时，哪些变化真的会影响你的系统。