Gemini 3.6 Flash 与 3.5 Flash-Lite 正式商用：新模型、新 API、新坑，这篇全说清楚了

Google 的 Gemini 系列又更新了，这次是 「Gemini 3.6 Flash」 和 「Gemini 3.5 Flash-Lite」，而且都是 GA（General Available）状态，可以直接上生产环境。

在这篇文章里，我把官方公告里最有价值的信息过滤、重组了一遍，不仅告诉你“新模型强在哪”，更会直接回答一个关键问题：「如果我的代码今天还在跑 Gemini 3.5 Flash，改到 3.6 Flash 到底要动哪些地方？」 以及，「3.5 Flash-Lite 到底 Lite 在哪，适合干什么？」

我们直接开始。

新模型概览：两张表看懂定位和成本

先说最务实的部分：选哪个模型，花多少钱。

「Gemini 3.6 Flash」 的目标是替代 3.5 Flash，在复杂任务（多步 agent 调用、多模态理解）上更强，同时「更便宜」——输出 token 从 3.5 Flash 的 $9.00/1M降到了$7.50/1M，输入 token 价格不变，还是 $1.50/1M。别小看这$1.5 的差距，在高并发生产环境下，月度账单差异会很明显。

「Gemini 3.5 Flash-Lite」 则是整个 3.5 家族里跑得最快、单价最低的选手——输入 $0.30/1M，输出$2.50/1M。如果你在做大批量数据清洗、文档解析、结构化抽取，这个模型的经济账非常划算。

两个模型都支持 「100 万 token 上下文窗口」、「64k 最大输出 token」、thinking 机制，以及全套内置工具——包括 Computer Use。也就是说，让模型直接操作 GUI 界面的能力，这两个新模型都原生支持。

Gemini 3.6 Flash：写代码更强了，但做 UI 风格可能退步了

3.6 Flash 不是 3.5 Flash 的简单提频，它在几个关键维度上确实有肉眼可见的变化。

多步工作流“话变少了”

实际测试中，3.6 Flash 完成同样一个多步任务（比如“查天气 → 写邮件 → 翻译成日语”），消耗的 token 更少，调用的工具次数更少，对话轮次也更少。官方文档里用了一个词叫 「“减少执行循环螺旋”」 ——这很形象。以前模型可能会在某个环节反复确认、反复重试，3.6 Flash 明显更“果断”。

这对生产环境的意义在于：「token 成本下降是明面上的，更关键的是延迟下降」。少了几个来回，用户等结果的时间就短了。

代码生成：更成熟，但有个“审美”问题

3.6 Flash 生成的代码质量更高，更接近“可直接提交 PR”的水平。具体表现在：

• 「不必要的修改更少」。以前模型改 A 的时候顺带改了 B，现在收敛多了。
• 「调试循环减少」。生成代码后自己检查、自己纠错的次数变少了。
• 「指令跟随更精准」。尤其是在诊断类任务中，不会擅自改不相干的文件。

但这里有一个有意思的 trade-off：「3.6 Flash 更喜欢“先跑一下看看”」。遇到复杂任务，它会更倾向于先执行诊断脚本、检查环境，再动手改代码。这在复杂工程场景下是加分项——少犯错。但在简单前端任务上，这个“先检查”的步骤显得多余，反而多耗了时间。

另外，官方文档里坦诚地提了一点：「人类评估者更喜欢旧版本生成的 UI 视觉效果和布局样式」。3.6 Flash 功能更稳了，但审美上可能不如 3.5 Flash 讨喜。如果你做的是前端界面生成，「建议在 system instruction 里给非常明确的设计规范」（色值、间距、字体大小、布局方式），模型是能跟上的。

多模态推理：看图、读表、转蓝图

在图表解读、视觉蓝图转换、多元素网页布局生成这类任务上，3.6 Flash 的提升是可感知的。它不是那种“benchmark 涨了 0.5%”的微调，而是实际使用中更少出现“图没看懂”的情况。

Gemini 3.5 Flash-Lite：便宜，但别把它当“低配版”

“Lite”这个后缀容易让人误解，好像它只是一个能力缩水的廉价替代品。但这次发布的 3.5 Flash-Lite，实际上是一个「定位非常精准的专用模型」。

它不是“慢速版”，而是“极速版”

3.5 Flash-Lite 是整个 3.5 系列里吞吐量最高的模型。如果你有「海量 PDF 需要解析、大量 JSON 需要抽取、或者每天几百万条日志需要分类」，这个模型的性价比远高于通用模型。

它的推理能力比上一代 Flash-Lite 有明显提升，官方数据是：

• HLE 推理任务从 11.0% 提升到 18.0%
• CharXIV 多模态基准从 63.7% 提升到 74.5%

这些数字意味着什么？意味着以前需要用 2.5 Flash 才能处理的任务，现在用 Lite 就能扛住一部分了。

工具调用可靠性提升

如果你用 Lite 做 「subagent（子代理）编排」——也就是让模型自己决定调用什么工具、以什么顺序调用——会发现它比前代更稳定。官方文档特别提到：「如果 Lite 做复杂多步任务时中途“罢工”或提前终止工具调用，可以尝试把 thinking_level 从默认的 minimal 调到 medium 或 high」。这个调节方式在代码迁移部分会详细讲。

多轮对话里“人设”更稳了

做 chatbot 的同学会关心这一点：3.5 Flash-Lite 在多轮对话中的指令跟随能力和角色一致性，比 3.1 Flash-Lite 强。这意味着它不容易“聊着聊着忘记自己是谁”或者“反复确认同一个信息”。

⚠️ 这次升级最大的坑：三个 API 参数被废弃了

我估计很多人会在这块卡住。「Gemini 3.6 Flash 和 3.5 Flash-Lite 开始，temperature、top_p、top_k 这三个采样参数被正式废弃。」 目前的 API 还会忽略它们（不报错），但官方明确说：「未来版本会直接返回 HTTP 400 错误」。

这意味着你现在就得把代码里这三个参数删掉，而不是等着报错再修。

# ❌ 这些参数不要再传了
generation_config = {
    "temperature": 0.7,
    "top_p": 0.9,
    "top_k": 40,
}

「替代方案」：如果你需要控制输出格式或确定性，用 system_instruction 写明确规则，或者使用结构化输出（Structured Outputs）。

另一个重大变化是：「请求末尾不能以 model 角色的 turn 结尾」。以前有些开发者会手动预填一段模型回复（比如“翻译结果：”），让模型接着这个开头继续生成。现在这个做法被禁用了，API 会返回 400 错误。

// ❌ 错误示例：contents 数组最后一条是 model 角色
{
  "contents": [
    {"role": "user", "parts": [{"text": "翻译 'Hello' 到中文"}]},
    {"role": "model", "parts": [{"text": "翻译结果："}]}
  ]
}

「正确做法」：用 system_instruction 指定输出格式，或者在 Interactions API 里利用服务端管理对话历史。

# ✅ 推荐做法
interaction = client.interactions.create(
    model="gemini-3.6-flash",
    input="翻译 'Hello' 到中文",
    system_instruction="只输出翻译结果，不要加任何解释。",
)

还有一个细节：「thinking_budget 参数被替换成了 thinking_level 字符串枚举」，可选值 "minimal"、"medium"、"high"。这个改动其实更直观了，你不需要再算“给多少 token 用于思考”，直接告诉模型“你想多深”就行。

迁移清单：从旧模型切到新模型，我建议按这个顺序做

从 3.5 Flash 或 3 Pro 迁移到 3.6 Flash

1. 「改 model ID」：把代码里的模型名换成 gemini-3.6-flash。
2. 「删采样参数」：移除 temperature、top_p、top_k。如果原先用了 thinking_budget，换成 thinking_level="medium" 或 "high"。candidate_count 也不再支持，一并移除。
3. 「检查多轮对话逻辑」：如果你手工维护了 contents 数组，确认最后一条非空消息是 user 角色。如果之前依赖“预填 model 回复”来限定输出，改用 system_instruction 或结构化输出。
4. 「函数调用（Function Calling）格式检查」：

   • 如果使用 Interactions API（推荐），多模态内容要放在 response payload 里。
   • 如果还在用 generateContent API，确保所有 FunctionResponse 包含 call_id 和 name。
   • 遇到 Malformed_Function_Call 错误时，检查 pre-tool text 格式，参考官方 workaround。
5. 「前端 UI 场景」：如果发现生成效果“变丑了”，在 system instruction 里嵌入具体的设计 token（颜色、间距、字体），不要只写“Make it beautiful”。

从 2.5 Flash 或 3.1 Flash-Lite 迁移到 3.5 Flash-Lite

1. 「改 model ID」：gemini-3.5-flash-lite。
2. 「思考级别设置」：

   • 批量抽取、分类、路由：保持默认 minimal。
   • 带工具调用的 subagent、多步推理：显式设置 thinking_level="medium" 或 "high"，否则模型可能在第一步就“觉得自己做完了”。
3. 采样参数和函数调用的迁移规则与 3.6 Flash 完全一致，可复用上面的步骤。

实际场景怎么选模型？一张决策表

关于 Antigravity 的彩蛋

还有一个值得一提的细节：「Gemini 3.6 Flash 现在是 Antigravity 代理的默认模型」。Antigravity 是 Gemini Managed Agents 里的一个预置 agent，可以自主执行多步任务（比如“读取 Hacker News 头条，生成摘要，存成 PDF”）。官方在 API 里新增了一个字段，允许你手动指定 environment 类型。

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="读取 Hacker News，总结前 10 条新闻，保存为 PDF。",
    environment="remote",
)

如果你在用 Antigravity，这次升级不需要你做任何迁移工作——默认就切到新模型了。但如果你想回退或指定其他模型，需要关注官方后续的配置文档。

实用摘要 / 操作清单

• ✅ 「模型 ID 必须改」：gemini-3.6-flash 或 gemini-3.5-flash-lite。
• ✅ 「立即移除」：temperature、top_p、top_k、candidate_count。
• ✅ 「替换」：thinking_budget → thinking_level（minimal / medium / high）。
• ✅ 「检查多轮对话」：禁止以 model 角色 turn 结尾，改用 system_instruction。
• ✅ 「函数调用」：确认 call_id 和 name 字段存在（generateContent API）。
• ✅ 「UI 生成场景」：在 system instruction 里给明确设计规范，弥补 3.6 Flash 样式短板。
• ✅ 「高吞吐任务」：3.5 Flash-Lite 默认 minimal 思考级别，复杂 subagent 手动调高。

一页速览

FAQ

「Q1：我可以同时用 3.6 Flash 和 3.5 Flash-Lite 吗？」
可以。两个模型独立计费、独立配额，按场景混合使用是最经济的方式。

「Q2：temperature 被废弃后，怎么控制随机性？」
用 system_instruction 写清楚输出规范，或者使用结构化输出（Structured Outputs）约束格式。如果两个都不够，考虑在 prompt 里显式写“每次输出必须一致”这类指令。

「Q3：我还在用 generateContent API，必须切到 Interactions API 吗？」
不强制，但官方推荐用 Interactions API，因为它自动管理对话上下文，且对 model 角色 turn 的限制更自然。继续用 generateContent 也可以，但要自己处理好上述校验规则。

「Q4：3.6 Flash 的 Computer Use 支持是 beta 还是 GA？」
目前 Computer Use 作为内置工具已支持，但具体可用性取决于该功能的发布状态，建议查阅 Computer Use 独立文档确认当前阶段。

「Q5：3.5 Flash-Lite 的 thinking_level 设成 high 会变慢很多吗？」
会。high 级别增加内部推理 token 数，延迟和成本都会上升。只在确实需要多步推理的场景使用，批量抽取场景保持默认 minimal 即可。

「Q6：我的旧代码删了 sampling 参数后，结果质量下降了怎么办？」
检查 system_instruction 是否足够具体。旧模型依赖 temperature 等参数“软化”输出，新模型更依赖指令本身的清晰度。把 prompt 写得更细，通常能弥补参数移除带来的变化。

「Q7：这两个模型支持中文吗？」
支持，Gemini 系列一直原生支持多语言，包括中文输入和输出。

这次升级的核心信息就这些。结论很简单：「3.6 Flash 可以放心上生产，但记得动代码删参数；3.5 Flash-Lite 是批量处理的好生意，但别低估复杂任务下的思考级别配置成本。」 迁移没有想象中复杂，一个下午基本能搞定。如果在实际迁移中遇到 Malformed_Function_Call 或者格式校验问题，优先检查 pre-tool text 的格式——那是新模型上最容易卡住的地方。