---
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="/docs/gemini-cli/official/02-context-config/26-system-prompt" />
  <Card title="Model routing" description="需要按场景切模型时，继续看模型路由和 fallback。" href="/docs/gemini-cli/official/05-models-runtime/52-model-routing" />
  <Card title="Quota and pricing" description="参数可能影响消耗，回看 quota、token 和成本边界。" href="/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)
