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