09 · 如何控制模型、速度、成本和质量

Codex 的模型、速度、成本和质量不是一个旋钮。你需要同时看任务复杂度、上下文质量、推理强度、登录方式、入口和验证成本。

不要把“最强模型 + 最高推理 + 最大上下文 + 加速档”当默认值。很多任务用中等配置更快、更便宜，也更容易审查。

四个旋钮

flowchart TB
    Task["任务复杂度"]
    Model["模型选择"]
    Reasoning["推理强度"]
    Speed["速度档位"]
    Context["上下文策略"]
    Result["质量 / 延迟 / 成本"]

    Task --> Model
    Task --> Reasoning
    Task --> Speed
    Task --> Context
    Model --> Result
    Reasoning --> Result
    Speed --> Result
    Context --> Result

四个旋钮分别影响：

• 模型选择：决定基础能力、可用入口和成本路径。
• 推理强度：决定花多少时间思考。
• 速度档位：决定是否为更快响应付出更多用量成本。
• 上下文策略：决定给多少材料，以及是否精准。

真正的控制不是把所有旋钮拉满，而是让它们匹配任务。

先按任务复杂度分层

低复杂度：

• 改错别字。
• 解释一段代码。
• 找文件。
• 写简短文档。
• 做格式检查。

建议：

• 低或默认推理。
• 默认上下文。
• 只给必要文件。
• 不要开高成本配置。

中复杂度：

• 修普通 bug。
• 补测试。
• 改局部组件。
• 调整文档结构。
• 做小范围迁移。

建议：

• 默认推理。
• 明确范围和验证。
• 根据失败输出迭代。
• 必要时再提高推理。

高复杂度：

• 跨模块重构。
• 架构判断。
• 安全审查。
• 复杂性能问题。
• 多系统集成。

建议：

• 先 plan，再实现。
• 使用更强模型或更高推理前，先保证上下文真实。
• 拆小任务。
• 验证和人工审查必须跟上。

推理强度怎么选

低推理适合：

• 事实明确。
• 改动很小。
• 验证直接。
• 失败成本低。

默认推理适合：

• 大多数日常开发。
• 局部 bug。
• 普通测试和文档任务。

高推理适合：

• 需求不确定。
• 需要权衡多个方案。
• 改动跨多个模块。
• 一次错误代价高。

高推理不是“更正确”的代名词。如果上下文错了，高推理只会更认真地沿错误方向前进。

速度档位怎么用

速度档位适合等待成本很高、任务很短的场景。

适合：

• 解释概念。
• 快速找文件。
• 小段代码说明。
• 简短改写。

不适合：

• 大规模改文件。
• 长时间测试构建。
• 多轮调试。
• 成本敏感的批处理。

使用前先看官方 pricing 和当前入口说明。不要把加速档写成默认配置。

上下文策略比上下文长度更重要

长上下文不是默认答案。给错材料、过期材料、无关材料，都会降低质量。

上下文优先级：

1. 当前真实文件。
2. 当前命令输出。
3. 明确报错和复现步骤。
4. 项目规则。
5. 相关官方文档。
6. 历史背景。

少而准通常比多而杂更好。

登录方式影响成本路径

ChatGPT 登录：

• 使用 ChatGPT plan、workspace 权限和 Codex credits。
• 适合 App、IDE、CLI 和 Cloud 的日常交互。
• 具体额度和功能以 pricing 和当前 workspace 为准。

API key 登录：

• 使用 OpenAI Platform API key。
• 费用走 API pricing。
• 适合程序化、本地脚本和某些自动化场景。
• 某些依赖 ChatGPT workspace 的能力可能不可用。

同一任务用不同登录方式，成本和能力边界可能不同。不要混在一起解释。

推荐决策流程

flowchart TD
    Start["任务来了"]
    Scope{"能否 30 分钟内验收?"}
    Context{"上下文是否真实充分?"}
    Risk{"失败代价高吗?"}
    Default["默认模型和默认推理"]
    Plan["先只读规划"]
    High["提高推理或模型能力"]
    Split["拆成更小任务"]

    Start --> Scope
    Scope -->|能| Context
    Scope -->|不能| Split
    Context -->|是| Risk
    Context -->|否| Plan
    Risk -->|低/中| Default
    Risk -->|高| High

先拆任务和补上下文，再调模型和推理。顺序反了，成本会上升，质量不一定上升。

不要写死的内容

教程、团队规范和 workflow 里不建议写死：

• 当前模型完整列表。
• 某个模型是否在某个入口可用。
• 具体价格和额度。
• fast mode 具体倍率。
• 某个计划的临时权益。
• 版本发布时间表。

应写成：

• 如何判断任务复杂度。
• 如何选择推理强度。
• 如何核验当前可用模型。
• 如何从 pricing 页面确认成本。
• 如何通过 changelog 判断版本变化。

模型、速度和成本控制的目标，是把钱和时间花在真正需要深度判断的任务上。