---
title: "Generation settings"
description: "Gemini CLI generation settings：模型生成引數、temperature、thinking budget 等配置應該怎麼理解和使用。"
verifiedAt: "2026-05-09"
---

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

> [!WARNING]
> **不要一上來調引數**：新手優先把任務說明、上下文和驗證做好。引數是後手，不是第一解法。

## 什麼時候需要調

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

## 什麼時候不該調

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

## 推薦順序

```text
先明确任务
再补上下文
再写项目规则
再固定验证命令
最后才调 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：

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

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

## 引數決策表

| 現象 | 先檢查 | 再考慮 |
| --- | --- | --- |
| 輸出太發散 | prompt 是否明確、上下文是否足夠 | 降低 temperature |
| 輸出太短 | 是否要求了結構和細節 | 調整輸出長度相關引數 |
| 推理不夠深入 | 任務是否需要計劃和驗證 | thinking budget |
| 同任務結果不穩定 | 輸入是否固定、規則是否寫入檔案 | 低溫 alias |
| API 報引數錯誤 | 最近新增的欄位是否合法 | 回退 alias / override |

引數只能影響生成傾向，不能替代事實來源、專案上下文和測試。程式碼任務裡，穩定性更多來自固定輸入、明確驗收和小步 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` 欄位。

## 接下來去哪

<Cards>
  <Card title="System prompt override" description="繼續看什麼時候才需要替換系統指令，而不是調引數。" href="/zh-Hant/docs/gemini-cli/official/02-context-config/26-system-prompt" />
  <Card title="Model routing" description="需要按場景切模型時，繼續看模型路由和 fallback。" href="/zh-Hant/docs/gemini-cli/official/05-models-runtime/52-model-routing" />
  <Card title="Quota and pricing" description="引數可能影響消耗，回看 quota、token 和成本邊界。" href="/zh-Hant/docs/gemini-cli/official/00-getting-started/06-quota-and-pricing" />
</Cards>

## 官方來源

- [Gemini CLI generation settings](https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/generation-settings.md)
