Generation settings

Generation settings 控制模型生成行為。官方 docs 把它作為模型配置的一部分，用來微調 temperature、thinking budget 等引數。

什麼時候需要調

• 同類任務輸出風格不穩定。
• 需要更保守或更發散。
• 長任務需要控制推理預算。
• 團隊要固定生成行為。
• 不同 agent 或不同任務需要不同模型引數。

什麼時候不該調

• 問題其實是上下文不足。
• GEMINI.md 沒寫清規則。
• prompt 太模糊。
• 沒有驗證命令。

推薦順序

先明确任务
再补上下文
再写项目规则
再固定验证命令
最后才调 generation settings

配置機制

Gemini CLI 的高階模型配置位於 modelConfigs。它有兩個核心概念：

• customAliases：給一組模型引數起別名，可以 extends 另一個 alias。
• overrides：按執行上下文注入引數，例如匹配某個 model 或某個 overrideScope。

常見引數會直接傳給 Gemini SDK 的 GenerateContentConfig，例如 temperature、topP、maxOutputTokens、thinkingConfig.thinkingBudget。官方也明確提醒：這是高階功能，錯誤引數組合可能直接導致 API runtime error。

這裡的關鍵風險是“最小校驗”。Gemini CLI 不會替你判斷某個 provider、某個模型、某個日期是否支援所有欄位；它會把配置傳給模型供應商。教程裡給引數示例時，必須把驗證命令和回退方式寫出來，不能只說“把 thinking budget 調高”。

典型模板

保守、可復現的程式碼審查場景，可以定義低溫 alias：

{
  "modelConfigs": {
    "customAliases": {
      "precise-review": {
        "extends": "chat-base",
        "modelConfig": {
          "generateContentConfig": {
            "temperature": 0.0,
            "topP": 1.0
          }
        }
      }
    }
  }
}

如果只想讓某個 agent 使用更高 thinking budget，用 overrides 匹配 overrideScope，不要改全域性預設值。全域性調參會影響所有任務，排錯成本最高。

引數決策表

引數只能影響生成傾向，不能替代事實來源、專案上下文和測試。程式碼任務裡，穩定性更多來自固定輸入、明確驗收和小步 diff，而不是把引數調成某個“萬能值”。

生產專案建議至少保留一個低風險 alias，例如 precise-review 或 docs-polish，只覆蓋少量引數。不要把所有任務都改成同一套高 thinking、高輸出長度配置；這會增加消耗，也會讓簡單任務變慢。

解析順序

Gemini CLI 會先解析 alias：父 alias 先合併，子 alias 覆蓋父級。然後應用 overrides：更具體的匹配優先；具體程度相同則按定義順序處理，後面的覆蓋前面的。

這意味著配置要從“寬預設”到“窄覆蓋”組織。不要為同一 agent 寫多條含義相近的 override，否則後續維護者很難判斷哪個最終生效。

排錯時按這個順序反推：當前 model 是什麼、命中了哪個 alias、有哪些 overrides 匹配、最後一條同等具體度 override 是否覆蓋了前面的值。不要靠肉眼只看 settings 頂層欄位。

驗收方式

每改一個 alias 或 override，只用一個小任務驗證：同一 prompt 連續執行兩次，看輸出穩定性、長度和推理行為是否符合預期。出現 API 引數錯誤時，不要改 prompt 規避，先回退最近新增的 generateContentConfig 欄位。

接下來去哪

官方來源

• Gemini CLI generation settings