GPT-5 的 Reasoning Effort 与 Verbosity 应如何组合？

作者：袖梨 2026-09-13

GPT-5 的 Reasoning Effort 与 Verbosity 应分两步组合：先根据任务的不确定性、复杂度和失败代价选择足够的 Reasoning Effort，确保模型有能力得到正确结果；再根据受众、输出格式和阅读成本选择 Verbosity，决定最终答案展开到什么程度。不要因为想要短答案就降低推理，也不要因为需要详细教程就盲目提高推理强度。

一个实用默认是 medium effort + medium verbosity。机械且可自动验证的任务可以降为 low + low；复杂分析但只需结论时使用 high + low；面向初学者的常规教程可以使用 medium + high；只有同时需要困难推理和完整审计轨迹时，才使用 high + high。

第一步：先确定 Reasoning Effort

Reasoning Effort 回答的是“模型需要投入多少推理才能可靠完成任务”。判断依据包括：

问题是否有多个相互依赖的步骤；
是否需要跨文件、跨系统或跨证据推断；
错误结果是否会造成数据、安全或生产风险；
是否有明确测试可以快速发现错误；
是否需要比较多个方案并解释取舍。

低复杂度、低风险、可自动验收的任务从 low 开始；常规开发从 medium 开始；复杂调试、安全分析和高风险决策从 high 开始。xhigh 或 max 只在模型支持且评测证明有额外收益时使用。

第二步：再确定 Verbosity

Verbosity 回答的是“接收者需要看到多少细节才能使用结果”。判断依据包括：

输出给机器、专家还是初学者；
是否需要记录决策依据；
是否需要示例、边界条件和替代方案；
是否受固定格式或篇幅约束；
阅读时间是否是主要成本。

机器消费和高频状态报告通常用 low；团队协作与常规解释用 medium；教学、审计记录和完整迁移指南用 high。

决策顺序为什么不能反过来

如果先因为“只要一句话”把 effort 设为 low，复杂问题可能得到简短但错误的答案。正确做法是 high effort + low verbosity：保留深入推理，只压缩交付形式。

反过来，如果因为“需要一篇长教程”把 effort 设为 high，简单事实可能消耗无必要的推理。medium 或 low effort + high verbosity 已经可以把确定内容展开成完整说明。

快速决策表

任务	Effort 起点	Verbosity 起点	理由
机械代码修改	low	low	路径短、测试明确
常规功能实现	medium	medium	需要规划与交接
复杂故障结论	high	low	推理困难、交付简洁
代码审查	medium 或 high	low 或 medium	问题优先、证据必要
初学者教程	medium	high	问题常规、解释完整
安全审计报告	high	high	推理和记录都重要
机器 JSON 输出	按任务	low	结构固定、减少冗余

配方一：机械编码任务

model_reasoning_effort = "low"
model_verbosity = "low"

适用于字段重命名、格式整理、运行已知命令、更新固定版本号和补充已有模式的测试。提示中应明确目标文件、变换规则和验证命令。

如果改动触发跨模块错误，先升 effort 到 medium，不必立即提高 verbosity。调试需要更多推理，输出仍可保持简洁。

配方二：日常开发

model_reasoning_effort = "medium"
model_verbosity = "medium"

适用于常规功能、局部重构和一般缺陷修复。模型有足够空间理解代码和运行工具，最终回答提供改动摘要、关键决定与验证结果。

这是建立团队基线的好组合。后续根据任务数据分别调节两个轴，不要一开始就使用最高档。

配方三：复杂问题的执行摘要

model_reasoning_effort = "high"
model_verbosity = "low"

适用于复杂故障、风险评估、管理层摘要和 CI 中的高质量结论。模型可以深入分析，但输出只保留根因、影响、建议与验证。

低 Verbosity 不能省略关键证据。提示应指定必需字段，例如“结论、证据、风险、下一步”。

配方四：教学型说明

model_reasoning_effort = "medium"
model_verbosity = "high"

适用于 API 教程、入门指南、内部培训和已知方案的详细交接。任务不一定困难，但受众需要背景、示例、错误处理和完整步骤。

如果内容涉及复杂安全推理，再把 effort 提高到 high；不要把 high verbosity 误认为已经提升了分析能力。

配方五：完整技术审计

model_reasoning_effort = "high"
model_verbosity = "high"

适用于架构决策记录、安全审计、事故复盘和高风险迁移。模型需要深入处理证据，读者也需要看到假设、取舍、残余风险和验证方法。

该组合成本较高，应提供明确范围和停止条件，避免报告无限扩展。

代码审查如何组合

普通差异审查可从 medium effort + low verbosity 开始，只输出按严重度排序的问题和文件位置。跨模块、安全敏感或并发变更可升到 high effort，Verbosity 仍可保持 medium 或 low。

审查的关键是发现真实缺陷，不是生成长篇总结。若没有问题，低 verbosity 能减少噪声；若发现复杂漏洞，再提高局部解释详细度。

调试如何组合

根因未知时使用 high effort + medium verbosity，要求模型列出假设、证据和区分实验。根因确认后，修复实现可以降为 medium effort + low verbosity。

如果调试记录要交给其他团队或用于事故复盘，保持 high effort，并将最终报告的 verbosity 提高。执行阶段和交付阶段可以使用不同组合。

API 与机器输出如何组合

结构化 JSON、分类结果和工具参数通常要求 low verbosity，但 effort 应由任务复杂度决定。一个复杂合规判断可以 high effort + low verbosity，最终只返回固定 schema。

不要依赖 Verbosity 保证 JSON 合法。应使用结构化输出或 schema 约束；verbosity 只影响展开倾向。

创作和内容任务如何组合

内容篇幅主要由 verbosity、明确字数和结构要求决定。需要简单扩写时，low 或 medium effort 已足够；需要复杂论证、跨资料综合或正策分析时，再提高 effort。

高 verbosity 容易产生重复。提示应说明目标读者、章节、禁用套话和最大长度，并通过编辑验收而不是只看字数。

Reasoning Summary 是第三个独立设置

Reasoning Effort 控制推理投入，Verbosity 控制最终回答，Reasoning Summary 控制推理摘要的呈现。详细摘要不等于高 verbosity，也不等于内部推理更强。

评测 Effort 与 Verbosity 组合时，应固定 summary 设置，否则可见文本变化会混入第三个变量。

输出上限也不是 Verbosity

Verbosity 是风格倾向，输出 token 上限是硬约束。设置 high verbosity 但输出上限很低，可能造成截断；设置 low verbosity 但提示要求完整代码，实际输出仍可能较长。

对关键任务，应同时检查输出上限、结构化格式和截断状态。不要把“回答突然结束”误判为 low verbosity。

如何处理“答案正确但太长”

保持 effort 不变，先降低 verbosity，或在提示中限定交付结构：

只输出：
1. 根因
2. 修改位置
3. 验证结果
每项最多三句。

如果直接降低 effort，可能损害复杂问题的正确性，而不是只减少文字。

如何处理“答案详细但不准确”

提高 verbosity 没有作用。应检查任务信息是否完整、模型是否合适、effort 是否足够，以及有没有运行验证。必要时从 low 升到 medium 或 high，并补充日志、代码和验收标准。

如何处理“答案正确但解释不足”

保持 effort，提升 verbosity，或明确要求解释关键决策与边界。这样不会无谓改变推理变量，便于判断改进来自输出控制。

如何处理“响应太慢”

先拆分耗时来源：内部推理、可见生成、工具执行或网络等待。若 reasoning token 占比高且质量收益有限，降低 effort；若回答展开过多，降低 verbosity；若工具慢，优化命令或环境。

两个参数同时降低虽然可能更快，却无法定位主要瓶颈。

如何进行两阶段评测

第一阶段选择 Effort：

固定模型、verbosity=medium、提示和环境。
比较 low、medium、high 的任务通过率。
选择达到质量门槛的最低 effort。

第二阶段选择 Verbosity：

固定第一阶段选出的 effort。
比较 low、medium、high verbosity。
测量可读性、格式合规和人工处理时间。
选择满组教付要求的最低详细度。

评测指标

指标	主要用于调节
任务通过率、缺陷率	Reasoning Effort
复杂约束覆盖	Reasoning Effort
回答长度、阅读时间	Verbosity
解释完整性	Verbosity
reasoning token	Effort 影响更直接
可见输出 token	Verbosity 影响更直接
总完成成本	两个轴与工具共同影响

用 Profile 保存常见配方

重复工作流可以建立独立配置：

# ~/.codex/review.config.toml
model_reasoning_effort = "high"
model_verbosity = "low"

# ~/.codex/tutorial.config.toml
model_reasoning_effort = "medium"
model_verbosity = "high"

使用 profile 前确认当前模型支持所选 effort。模型切换后需要重新验证。

常见错误

用 high verbosity 代替 high effort

这只会增加解释，不保证复杂推理正确。

用 low effort 获得短答案

复杂任务应该高推理配低详细度。

所有任务使用 high + high

简单任务会产生额外延迟和阅读成本，且不保证更准确。

同时改两个参数后得出结论

无法判断差异来自推理还是表达。评测时一次只改一轴。

从回答长度判断 effort

短回答可能经过深度推理，长回答也可能只是浅层展开。应查看配置与运行状态。

结论

GPT-5 的 Reasoning Effort 与 Verbosity 应按“先正确、后表达”的顺序组合。先依据任务复杂度、风险和验收难度选择足够的 effort，再依据受众、格式和阅读成本选择 verbosity。medium + medium 是通用基线，low + low 适合机械任务，high + low 适合复杂但简洁的交付，medium + high 适合教学，high + high 适合完整审计。调优时固定一个轴再改变另一个，并分别用任务质量与阅读效率验证，不能把输出篇幅当成推理深度。