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

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