模型選擇

Gemini CLI 支援透過 /model 互動選擇模型，也支援透過 --model / -m 在啟動時指定模型。官方建議大多數使用者優先使用 Auto，讓 CLI 按任務複雜度選擇模型。

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 思路

選擇建議

• 不確定時先用 auto。
• 大型重構前先計劃，再決定是否用更強模型。
• 頻繁指令碼化任務要考慮成本。
• 模型失敗時不要只換模型，也要檢查上下文和任務描述。
• 想固定可復現行為時，記錄模型名、CLI 版本和認證方式。

任務分層

用 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 解決同一模型內的生成行為。排錯時要分開改，一次只改一個變數。

接下來去哪

官方來源

• Gemini CLI model selection
• Gemini CLI CLI reference