模型选择
Gemini CLI 模型选择：--model、auto/pro/flash/flash-lite alias，以及按任务复杂度选择模型。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| 模型选择 | selection | 按任务选不同档位模型。 |
| 维度 | axis | 速度 / 成本 / 质量 / 复杂度。 |
| 默认 | default | 长期生效的模型。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你按任务和场景选对 Gemini 模型并配好默认。
你是 Gemini CLI 模型选择顾问。
【角色】
Gemini CLI 模型选择顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。
【输入】
- 任务类型和复杂度：___
- 对速度 / 成本 / 质量的优先级：___
- 是否多场景：___
- 套餐 / 配额情况：___
- 经验水平：___
【工作流程】
1. 按复杂度分层选模型
2. 给默认模型配置
3. 说明何时临时切换
4. 处理成本和配额
5. 给决策建议
【输出规范】
▌一、模型推荐
▌二、默认配置
▌三、临时切换时机
▌四、成本 + 决策
【硬约束】
- 简单任务不用最贵模型
- 不夸大高端模型收益
- 配额 / 价格以官方为准
- 不要替我臆测情况或编造不存在的能力，信息不全先问清
- 不确定的配置或接口一律以官方文档为准，禁止照搬过时写法
- 给的每条结论都要落到具体可照做的步骤或示例，不停留在「建议」「考虑一下」这类没法直接执行的空泛表述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 会打开模型选择对话。官方当前文档列出三类：
- Auto (Gemini 3)：在 Gemini 3 Pro / Flash 范围内自动选择。
- Auto (Gemini 2.5)：在 Gemini 2.5 Pro / Flash 范围内自动选择。
- Manual：手动选择账号可用的具体模型。
/model 和 --model 不会覆盖 subagents 使用的模型。因此你在 usage report 里看到其他模型，不一定是主会话模型选择失败，可能是 subagent 自己的配置。
模型选择会影响后续交互，但不等于固定所有内部调用。官方文档明确提醒 usage report 里可能出现其他模型，这通常来自 subagent、内部分类、补全或 fallback 链路。排查时要先区分“主会话模型”和“辅助调用模型”。
alias 思路
| alias | 适合 |
|---|---|
auto | 默认选择，交给 CLI 决定 |
pro | 复杂推理、跨文件任务 |
flash | 日常平衡任务 |
flash-lite | 简单快速任务 |
选择建议
- 不确定时先用
auto。 - 大型重构前先计划，再决定是否用更强模型。
- 频繁脚本化任务要考虑成本。
- 模型失败时不要只换模型，也要检查上下文和任务描述。
- 想固定可复现行为时，记录模型名、CLI 版本和认证方式。
任务分层
用 pro 的理由应该是任务复杂，而不是“感觉更强”。典型场景包括跨模块设计、复杂 bug 定位、架构迁移、长上下文审查。flash 更适合格式转换、摘要、简单解释、单文件小改。flash-lite 适合短平快自动化，但不适合高风险修改或需要深推理的 debug。
如果输出质量差，先查这四件事：上下文是否足够，GEMINI.md 是否清楚，工具是否有权限，验证命令是否明确。模型升级只能解决一部分问题，不能替代任务契约。
| 任务 | 推荐起点 | 备注 |
|---|---|---|
| 日常问答 / 小改 | auto | 让 CLI 按复杂度选 |
| 架构设计 / 复杂 debug | pro 或 Auto 高能力路由 | 先用 Plan mode 收敛范围 |
| 摘要 / 格式转换 | flash | 更看重速度 |
| 大批量脚本化短任务 | flash-lite | 仍要记录实际模型 |
| 团队教程 | 推荐 alias，不写死 preview 模型 | 降低过期风险 |
验收方式
切换模型后跑同一个小任务，记录响应速度、工具调用质量、是否触发 fallback。对团队教程和工作流，建议在文档里写“推荐 alias”，不要写死某个 preview 模型作为唯一入口。
如果教程需要复现结果，至少记录 CLI 版本、认证方式、选择的 alias、实际使用模型和测试日期。只写“使用 Gemini 3”不够精确。
商业教程建议给出验证命令而不是只给推荐：让读者先运行 /model 看可见列表，再运行一个小任务，最后用 /stats model 或 usage report 确认实际模型。这样账号差异不会直接变成教程失效。
常见误区
第一个误区是把 preview 模型写成默认模型。Preview 状态会变，账号可见性也会变，教程最好推荐 auto 或稳定 alias，再在备注里说明测试时具体用了哪个模型。
第二个误区是只看速度不看验证。flash 很适合短任务，但高风险代码修改仍然要看 diff、测试和回滚；pro 也不会自动保证改动正确。
第三个误区是把模型选择和生成参数混在一起。/model 解决选哪个模型，generation settings 解决同一模型内的生成行为。排错时要分开改，一次只改一个变量。
接下来去哪
模型路由
继续看 fallback、Auto routing 和最终模型排查。
Gemini 3
回看 Gemini 3、Preview、release channel 和配额提示。
Generation settings
模型选定后，再考虑 generation settings，而不是先调参数。