---
title: "09 · 如何控制模型、速度、成本和質量"
description: "按任務複雜度選擇模型、推理強度、速度檔位和上下文策略，避免把高成本配置當預設值。"
canonical: "https://xiangyugongzuoliu.com/openai-codex-model-cost-speed"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

Codex 的模型、速度、成本和質量不是一個旋鈕。你需要同時看任務複雜度、上下文質量、推理強度、登入方式、入口和驗證成本。

不要把“最強模型 + 最高推理 + 最大上下文 + 加速檔”當預設值。很多工用中等配置更快、更便宜，也更容易審查。

> [!IMPORTANT]
> 模型列表、價格、額度、fast mode 消耗和可用入口都會變化。教程裡不要寫死數字；具體以官方 Models、Pricing、Changelog 和當前客戶端為準。

<Cards>
  <Card title="Models" href="https://developers.openai.com/codex/models">
    檢視當前 Codex 支援的模型和入口說明。
  </Card>
  <Card title="Pricing" href="https://developers.openai.com/codex/pricing">
    檢視當前計劃、credits、API key 和 usage 說明。
  </Card>
  <Card title="Changelog" href="https://developers.openai.com/codex/changelog">
    核驗模型可用性、入口變化和版本更新。
  </Card>
</Cards>

## 四個旋鈕

```mermaid
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 的能力可能不可用。

同一任務用不同登入方式，成本和能力邊界可能不同。不要混在一起解釋。

## 推薦決策流程

```mermaid
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 判斷版本變化。

模型、速度和成本控制的目標，是把錢和時間花在真正需要深度判斷的任務上。
