如何正确使用 GPT 模型的推理强度
目前我每个月买的是 200 美元的 ChatGPT Pro 套餐，在 Codex 里两三天就把一周额度消耗得差不多了，根本不够用，因此这个使用强度下，除了关注哪个模型更强，还得考虑另一个问题：我目前的使用方式对不对？同一个模型，每次任务到底应该给它多少推理预算？
这就涉及 Reasoning Effort，也就是推理强度。我原本想给日常任务分配几个档位，后来又让 AI 分析了本地 Codex 会话记录，并围绕自己的工作讨论模型选型，希望能解决这个问题：怎样判断下一步值得投入多少计算资源？
先看看自己到底把额度用在哪里
这次分析检查了本地 4,771 条会话索引，重点统计约近 30 天内的 443 个主会话和 1,191 个子 Agent 会话。主会话里包含自动化和恢复任务。
按标题、项目和有限请求文本初筛，产品开发与技术调试约占主会话的 24%，审查评估与证据分析约占 16%；学习资料、AI 工具与本机工作流、内容创作与知识整理，各占一成左右。
这个分布比较符合我实际的使用情况：既让 Codex 做跨模块开发和复杂判断，也让它处理资料提取、格式整理、打开网页这样的明确小事。即使某个项目整体难，其实也并不意味着里面每一步都难，也有很多是非常简单的小任务。
用量部分，有几条信息值得单独拿出来分析下
- 输入 Token 约 97.42% 命中缓存，但单次调用输入中位数仍有 13.2 万 Token。 高缓存命中率降低了单位成本，长上下文仍然值得管理。仅凭这个数字，还不能判断是规则、历史对话还是工具结果占得最多。
- 最重的 20 个主会话，占主会话记录用量约 56%。 比起给所有任务统一降档，先检查这些长任务的范围和迭代过程更有针对性。
- 子 Agent 占记录总用量约 26%。
- 141 个主执行轮次用了 Luna / Max。 报告抽查到一个只采集到打开、关闭网页请求的会话，也用了这个配置。这是值得降档的候选。
另一个发现是，记录中的主执行轮次多数已经在用 Medium，其中 Sol / Medium 有 1,468 个轮次，Terra / Medium 却只有 1 个。看来问题并不只是“总把推理强度开得太高”，还包括日常工作有没有必要一直用成本较高的模型。
报告按 2026 年 9 月 9 日的 Standard 公开费率，对已知模型的日志用量做了一次估算：Sol 约占成本权重的 83%，Luna 约占 1%。官方费率与额度说明
推理强度控制的是什么
把 Reasoning Effort 理解成“思考时间”比较直观，但容易让人误以为可以精确指定模型想几秒。它更接近一种推理预算偏好：引导模型在当前任务上投入多少思考。实际用了多少资源，还取决于模型和问题本身。
在同一个模型下调高推理强度，没有更换模型；更多的推理投入，可能让它在复杂问题上表现得更好。模型也会根据任务难度调整实际投入，所以开了高档，不等于每个简单问题都会把预算用满。
还有一个容易忽略的地方：屏幕上看到的回答长度，不能代表全部消耗。模型可能在给出很短的结论之前使用了较多推理 Token，也可以在工具调用之间继续推理。
对于 Coding Agent，这个区别尤其有用。一次“帮我修一下”的请求，背后可能包含读代码、分析依赖、修改文件、执行测试，再根据报错继续修正。我们看到的是一个任务，模型和工具可能已经往返了很多轮。
先搞清楚自己用的是哪些档位
不同模型、客户端和版本支持的档位不完全一样，不能把某个界面的选项当成所有 GPT 模型的统一标准。下面按当前 Codex 文档中的选项理解；使用 API 时，还需要检查具体模型支持哪些参数值。
| 档位 | 怎么理解 |
|---|---|
| Low / Light | 较轻的推理投入，优先处理边界清楚、需要快速完成的任务 |
| Medium | 在速度和分析深度之间取平衡，可以作为日常任务的起点 |
| High | 给复杂分析、排查和多步判断更多推理投入 |
| XHigh / Extra High | 进一步增加投入，用于较难、能够接受更长等待的任务 |
| Max | 为最困难的单个任务投入更多推理资源 |
| Ultra | 还会使用子 Agent 并行处理任务的不同部分，涉及任务调度 |
Max 和 Ultra 值得单独区分。一个核心算法很难，但分析步骤高度依赖前面的结果，可能更适合增加单任务推理投入。一次仓库审查能拆成几个相对独立的模块，则有并行分析的空间。任务能否拆开，是考虑 Ultra 时需要额外判断的问题。官方模型与档位说明
这也意味着，“全仓库分析就开 Ultra”仍然太粗糙。先确定要找什么问题、哪些模块值得看、最后如何合并结论，才能判断并行工作有没有意义。
选型先看什么：五条比推荐表更通用的原则
讨论里出现过一些很明确的建议：MR Review 不要用 Medium，Web3D 默认 High，技术方案直接 Max。它们容易记，但把一个工作类别直接对应到档位，忽略了当前到底在做什么判断。
同样是 Review，修改几处文案和改变事件系统的生命周期，难度与遗漏后果差别很大。同样是需求澄清，把已知材料整理成问题清单，和决定一个平台要不要做，也不是同一件事。“Medium 生产、High 创造、Max 决策”无法覆盖这些差别。
下面是结合日志、官方说明和这些讨论整理的判断原则。它们是我的选型方法，不是官方规定，也不是经过实验拟合出来的评分模型。
1. 先确定什么叫合格，再优化总成本
在质量、风险和交付时间满足要求的前提下，寻找完成任务总成本更低的配置。 这是我更愿意采用的目标。总成本要同时看模型用量、等待时间和人工返工；各项未必要折算成一个精确数字，但不能只统计其中最方便的一项。
“MR 已看完”“页面能运行”“方案写了十页”都不够。Review 要检查哪些行为、页面要在哪些设备和状态下验收、方案要解释哪些约束，需要提前说清楚。否则，降低档位后表面上完成得更快，可能只是少检查了一部分问题。
对于陌生或重要的任务，可以先用较强模型建立候选结果，再用代码、测试、原始资料或人工评审确认质量基线，然后比较更便宜的配置。强模型的答案也需要验证，不能直接当标准答案。对于步骤明确、容易检查的小任务，则没有必要每次先跑一遍最强模型。
官方模型选择指南也采用先达到准确性目标、再优化成本和延迟的顺序。它支持的是这种评估方法，不能直接证明某个模型适合我的所有工作。官方模型选择原则
2. 区分缺信息、缺标准和缺推理
“不确定性高”还需要继续拆开。需求讨论没有用户材料，首先需要访谈或查资料；网页看起来不对，却没有参考样例和视觉标准，首先需要明确偏好；数据齐全，几个方案却在兼容性、性能和开发成本之间互相冲突，才是值得增加推理投入的情况。
这三类问题往往混在一个任务里。要先找当前的主要阻塞：更多思考能否减少它，还是必须从外部获得新证据。
比如性能优化缺少测量结果，先做 profiling；视觉复刻缺少截图，先实际渲染并对照；产品方向不确定，先做能够检验需求的小实验。提高推理强度可以帮助设计这些验证，却不能替代验证结果。任务重要，也不能让模型凭空知道用户真正需要什么。
3. 模型看能力适配，推理强度看当前推断的难度
选择模型时，先看它能否处理所需输入、使用必要工具，以及是否在相近任务上达到过要求。视觉任务需要实际的图像输入与检查流程；复杂代码任务需要正确理解相关代码和约束。通过提高 effort，不能让一个不支持图像输入的模型看到截图，也不能弥补它没有读取的关键文件。
选定候选模型以后，再看这一步要连接多少相互依赖的事实、排除多少竞争解释、权衡多少冲突条件。步骤已经明确，可以从较低档位执行；证据已经足够，但因果链解释不通、反例未被处理，才有理由尝试更高档位。
具体操作时，如果模型已经理解单项事实，却在组合推断中漏掉条件，可以尝试同一模型提高一档；如果它反复误解核心概念，或无法处理必要输入，就应该考虑换模型或调整工具流程，不必把当前模型一路加到 Max 才换。这些只是下一步实验的依据，最终仍要看同一项验收有没有改善。
因此，模型和 effort 要一起比较。较强模型的 Medium 与较便宜模型的 High，谁更合适不能靠档位名称判断；不同模型之间也没有通用的等价换算。官方档位说明
上下文长、验证轮次多，也不能直接当成深度推理的理由。十万 Token 可能只是重复背景；反复调整动画可能是在寻找审美偏好。要看其中有多少相关信息必须同时理解，以及每轮到底在解决什么新问题。
4. 看错误后果，也看错误能否被发现和撤销
失败成本高，值得投入更多资源，但资源未必要全部加在推理上。还可以用来补回归测试、做独立审查、验证回滚方案。
一个本地原型出错，能够立即看出来并撤销，就适合较低成本地探索。一个权限边界或数据迁移方案出错，可能到上线后才暴露，就需要更保守的起点和独立验证。难发现、难撤销的错误，比单纯“任务规模大”更值得提高关注。
这也是 Review 比一般生成任务更难验收的原因之一：生成了一段代码，可以运行已知用例；回答“没有发现问题”，却不能证明检查范围内不存在问题。对于事件泄漏、并发和权限相关的 MR，可以把 Sol / High 或 Astra / Medium 作为更保守的候选，但仍要追踪调用链、构造反例，并由相应负责人复核。不能把“用了 High”当成审查质量证明。
5. 比较下一份投入能带来的增益，并设置停止条件
决定继续升级之前，先说清希望新增什么结果：找到尚未解释的根因、处理一个明确反例，还是补齐某项方案取舍。如果再多分析一轮只是让报告更长，就没有证明额外投入值得。
我准备采用一个简单规则：同一问题连续两次尝试仍未解决，就检查阻塞和已有证据，再决定补材料、换方法、换模型或提高 effort。“两次”只是防止无休止重试的起点，不必让高风险任务先失败两次才升级。
反过来，如果配置已通过同一套验收，也没有留下值得继续处理的问题，就应该收口。质量还未达标，但剩余预算无法支持可靠完成时，要缩小交付范围或明确待解决项，不能靠降低验收标准制造“完成”。
这几条原则落到每次操作，就是先确定本轮交付和验收，再判断主要阻塞，选择有能力处理它的模型及起步档位，最后根据结果调整。真正需要额外计算的理由，应该能用一句具体的话说明，而不是“这个任务听起来很高级”。
放到我的九类日常工作里
下表里的 Luna、Terra、Sol 指 GPT-5.6 系列，Astra 指 GPT-6 Astra。这里给的是候选起点，适合拿来试用和调整，不是任务与模型的固定绑定。资料提取、格式转换和明确工具操作，仍可以先尝试 Luna / Low。
| 工作 | 普通阶段的候选起点 | 值得提高投入的具体部分 |
|---|---|---|
| Review 组员的 MR | 范围明确、低风险的小改动可试 Terra / Medium；一般功能审查可试 Sol / Medium | 改变生命周期、并发、权限或跨模块契约时，考虑 Sol / High 或 Astra / Medium，并补针对性验证 |
| Web3D 开发 | 已有结构内的交互、相机参数和普通功能，可试 Terra / Medium 或 Sol / Medium | 数学推导、渲染状态与性能瓶颈相互影响时，考虑 Sol / High 或 Astra / Medium；实际运行测量不能省 |
| Vibe Coding 一个想法 | 可撤销的小原型从 Terra / Medium 起步，复杂实现用 Sol / Medium | 想法得到初步验证，需要决定难回退的数据模型或系统边界时，再投入更强分析 |
| 生成信息可视化网页 | 数据和版式明确时可试 Terra / Medium；需要组织信息和交互时可试 Sol / Medium | 指标口径、视觉编码与阅读目标存在冲突时，再提高模型或档位；用原始数据和渲染结果核验 |
| 生成 ScrollyTelling 网页 | 内容已有依据、章节和动画模式清楚时，可试 Sol / Medium | 叙事顺序、滚动状态、动画时序和性能互相制约时，可试 Sol / High 或 Astra / Medium |
| 项目初期需求澄清 | 整理材料与缺失问题可试 Terra / Medium；分析需求冲突用 Sol / Medium | 需要决定产品边界且选择难回退时，可试 Astra / Medium / High；未知用户需求仍要向外求证 |
| 项目初期技术方案设计 | 已知模式和约束内的方案可试 Sol / Medium | 多系统约束冲突、迁移兼容或关键架构取舍，可试 Astra / Medium / High；仍有明确难点再试 Max |
| 写博客 | 事实和观点已有来源，主要做组织与改写时，可试 Terra / Medium | 多来源观点冲突、因果论证和原创判断，可试 Sol / Medium / High；风格偏差先用样例与反馈校准 |
| 写技术方案文档 | 整理已经确定的方案可试 Terra / Medium | 写作过程中还需要完成设计或证明一致性时，交给 Sol / Medium，难点再升级；文档长度不决定档位 |
这些候选符合官方模型定位的大致方向，但具体表格是我的判断。尤其是 Terra / Medium，历史中只有一个主执行轮次，让它做日常主力仍需要验证。官方模型选择说明
按当前标准费率，同样的输入、缓存输入和输出 Token 组成下，Terra 的成本约为 Sol 的 50%–60%，Luna 约为 5%–6%。换模型以后，用量和返工次数也会变化，不能据此承诺整项任务等比例省钱。官方费率说明
复杂任务可以分阶段，但不要机械降档
全程开最高档很省心，问题是不同阶段未必需要同样的推理投入。以系统重构为例，确定模块边界和兼容策略时，需要权衡很多问题；按照明确方案批量调整调用点时，判断空间就小得多。
规划阶段可以先用 Sol / Medium；复杂的跨系统问题，再考虑 Astra / Medium，遇到明确难点后提高推理强度。这个阶段应该留下可执行的方案：改哪些模块、保持哪些行为、怎样验证，以及哪些问题还没有确定。只有“大致拆成三层”这样的概念，下一阶段仍然需要重新理解和设计，降档的基础就不存在。
执行阶段，如果方案和验收条件已经清楚，可以尝试用 Terra / Medium 处理常规实现，复杂模块继续用 Sol。这里说的切换，是在明确阶段调整模型，不需要为了分流再额外创建一组 Agent。过程中出现反例，或者发现原方案依赖一个错误假设，就回到分析阶段。
收尾也要区分工作性质。更新文档、整理已经明确的测试命令，通常不需要很高的推理强度。但检查一次重构有没有遗漏兼容行为、判断测试是否覆盖了原来的 Bug，仍然可能需要更深分析。阶段切换提供了重新选型的机会，并不意味着必须逐级降档。
会话分析还让我更在意阶段结束后的上下文。只有当旧历史大部分已经无关时，才考虑用简短交接开启新任务：写清目标、关键事实、文件位置、已经验证的内容和下一步。每次追问都重开会话，又会重复加载资料，也未必更省。
“全面优化”“完美复刻”“持续打磨”这样的要求，也应该补上本轮验收范围和迭代上限。否则模型即使便宜，任务仍可能运行很久。对子 Agent 同样如此：让它负责一个独立问题，给有限输入和明确产出，避免几个 Agent 各自把整段背景重新分析一遍。
我的默认配置会怎么调整
原先设想过 70% Medium、20% High、8% Max、2% Ultra 这样的比例，后续讨论又给出了另一组比例。这些数字都缺少任务质量的对照依据，不适合当成配额。档位占比应该是任务分配后的统计结果。
接下来准备试一周：熟悉、容易验证的日常工作先用 Terra / Medium，明确小任务用 Luna / Low，复杂开发用 Sol / Medium。陌生、难验证或错误后果较重的任务，用更强的候选配置建立质量基线。High 用来解决具体难点，XHigh 和 Max 不常驻，Ultra 只在任务值得并行拆分时使用。
按报告建议，先选 20 个真实新任务：8 个资料或工具小任务、8 个普通开发任务、4 个复杂分析任务。记录起步配置、最终配置、是否通过验收、返工次数、总耗时，以及能获取的用量数据。遇到问题时记录升级原因，不为了做对照重复执行部署或其他外部写操作。
这 20 个任务不同，不能直接比较它们各自的 Token 数来给模型排名。试用先检查这套分配能否工作；需要比较两个配置时，再选少量能够安全重放的代表任务，保持材料和验收标准一致。Review 可以用已知缺陷检查遗漏，视觉任务要对照实际画面，不能只让模型评价自己的结果。样本仍然有限，也要记录验收后才发现的遗漏。
这轮会话分析没有证明换配置以后能省多少。先完成这 20 个任务，确认更低的调用成本有没有被返工抵消，再决定长期默认。以后模型名称和档位还会变，交付标准、错误后果和验证证据，仍然可以作为下一次选型的依据。
文中产品行为核对于 2026 年 9 月 9 日；档位名称、模型支持范围和额度规则可能调整，以当前客户端及官方文档为准。