模型選擇
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，而不是先調引數。