模型选择

Gemini CLI 支持通过 /model 交互选择模型，也支持通过 --model / -m 在启动时指定模型。官方建议大多数用户优先使用 Auto，让 CLI 按任务复杂度选择模型。

/model 和 --model 控制主会话模型，不保证覆盖 subagent 使用的模型。看到 usage report 里有其他模型时，先看是否是 subagent 或内部工具调用。

gemini --model pro
gemini -m flash -p "summarize README.md"

/model 选项

运行 /model 会打开模型选择对话。官方当前文档列出三类：

/model 和 --model 不会覆盖 subagents 使用的模型。因此你在 usage report 里看到其他模型，不一定是主会话模型选择失败，可能是 subagent 自己的配置。

模型选择会影响后续交互，但不等于固定所有内部调用。官方文档明确提醒 usage report 里可能出现其他模型，这通常来自 subagent、内部分类、补全或 fallback 链路。排查时要先区分“主会话模型”和“辅助调用模型”。

用 pro 的理由应该是任务复杂，而不是“感觉更强”。典型场景包括跨模块设计、复杂 bug 定位、架构迁移、长上下文审查。flash 更适合格式转换、摘要、简单解释、单文件小改。flash-lite 适合短平快自动化，但不适合高风险修改或需要深推理的 debug。

如果输出质量差，先查这四件事：上下文是否足够，GEMINI.md 是否清楚，工具是否有权限，验证命令是否明确。模型升级只能解决一部分问题，不能替代任务契约。

切换模型后跑同一个小任务，记录响应速度、工具调用质量、是否触发 fallback。对团队教程和工作流，建议在文档里写“推荐 alias”，不要写死某个 preview 模型作为唯一入口。

如果教程需要复现结果，至少记录 CLI 版本、认证方式、选择的 alias、实际使用模型和测试日期。只写“使用 Gemini 3”不够精确。

商业教程建议给出验证命令而不是只给推荐：让读者先运行 /model 看可见列表，再运行一个小任务，最后用 /stats model 或 usage report 确认实际模型。这样账号差异不会直接变成教程失效。

第一个误区是把 preview 模型写成默认模型。Preview 状态会变，账号可见性也会变，教程最好推荐 auto 或稳定 alias，再在备注里说明测试时具体用了哪个模型。

第二个误区是只看速度不看验证。flash 很适合短任务，但高风险代码修改仍然要看 diff、测试和回滚；pro 也不会自动保证改动正确。

第三个误区是把模型选择和生成参数混在一起。/model 解决选哪个模型，generation settings 解决同一模型内的生成行为。排错时要分开改，一次只改一个变量。