模型、推理深度與速度

返回 Codex 教學總目錄

目標與準備

先了解帳號與額度。模型是處理任務的選擇，推理深度是該模型投入分析的程度，速度或服務層級是另一個控制；它們不能全部用「比較聰明」代替。平台、登入方式及推出階段可能讓選單不同，文章不要求每個人看到同一組名稱，也不把官網展示範例當成你的帳號權限。

步驟 1：記錄現在的選擇

桌面版查看輸入框下方的模型與推理控制；若顯示 Power 滑桿，先記下目前位置，需要指定細項時再看 Advanced。CLI 在互動介面輸入 /model，查看模型及該模型允許的推理等級，再用 /status 確認狀態。這些是互動斜線指令，不是終端機命令。不要為了配合文章去改不認識的全域設定。

/model

/status

在文字編輯器新建 comparison.md，先記日期、平台版本、登入類型及選單可見項目。不要貼電子郵件、API 金鑰或付款資料。若 CLI 與桌面可見選項不一樣，分開記錄兩個環境；不要推論其中一個壞掉。Codex 雲端任務的模型限制也不同，本篇的本機切換步驟不能直接套到雲端任務。

步驟 2：建立可判分的固定題目

用編輯器建立獨立資料夾 codex-model-lab，新增 sample.mjs 並貼入以下內容。Windows、macOS、Linux 都是一般文字檔，不需要執行或安裝套件。程式中的錯誤刻意保留，這次要比較的是能否準確指出錯誤及提出驗證例，不是讓兩個任務同時修改同一個檔案。

export function completedTitles(tasks) {
  return tasks.filter((task) => !task.completed).map((task) => task.title);
}

export const sample = [
  { title: "Read", completed: true },
  { title: "Build", completed: false },
];

正確答案先由人確認：函式名稱與需求是「已完成標題」，所以 sample 應回傳 Read，但目前會回傳 Build。要移除的是 !，不是改變任務狀態、重命名欄位或排序。空陣列應回傳空陣列；原始資料不應被更改。有明確答案，才不會只挑語氣最有自信、篇幅最長的回答。

Read sample.mjs without modifying any file. The requirement is to return titles of completed tasks in original order.
1. State the actual output for sample and the required output.
2. Identify the precise defect and the smallest fix.
3. Give two verification cases, including empty input, and say whether inputs are mutated.
Do not install tools or run a web search. Distinguish reasoning from tests you actually ran. Keep the answer under 250 words.

步驟 3：只改一個選項再比較

桌面版先把 codex-model-lab 加入為專案，兩次都在這個專案建立新任務。CLI 用編輯器開此資料夾與整合終端機；Windows PowerShell 以 Get-Location、macOS／Linux 以 pwd 核對路徑，再執行 codex。第一輪完成後用 /exit 回到系統終端機，從同一路徑重新執行 codex 開第二輪，不使用 resume。

第一次使用目前預設設定，在新任務送出上面完整提示詞，記錄開始到完成的時間、是否讀了正確檔案及回答。第二次建立另一個新任務，使用相同檔案與完整提示詞，只調整同一模型的推理等級；其餘模型、速度、權限與工具保持相同。如果沒有另一個推理選項，就記錄本次只能建立基準，不硬寫出比較結果。

不要接著同一個對話問第二遍，因為第二次已經看過前一個答案，不再是同樣起點。也不要同時換模型與推理等級，否則不知道差異來自哪裡。用量介面如果只有帳號共用的剩餘百分比，且其他任務正在工作，就不能把前後差額全算在本題。看不到單次數據時，填「不可取得」。

# Model comparison
Date / client / sign-in type: fill from your environment
Task: completedTitles review; identical sample.mjs and prompt

| Check | Run A | Run B |
| --- | --- | --- |
| Model and reasoning effort | NOT RUN | NOT RUN |
| Speed / permissions unchanged | NOT RUN | NOT RUN |
| Elapsed time | NOT RUN | NOT RUN |
| Actual Build, required Read | NOT RUN | NOT RUN |
| Correct minimal fix | NOT RUN | NOT RUN |
| Empty-input case and no mutation | NOT RUN | NOT RUN |
| Files unchanged | NOT RUN | NOT RUN |
| Per-run usage, if available | UNAVAILABLE | UNAVAILABLE |

Decision and reason: pending observed results
Limit: one small task is not a general model ranking.

若兩次都答錯，先確認它們是否讀到 sample.mjs、需求是否真的指定 completed，而不是立刻挑較貴或較慢的選項。缺少檔案、工作目錄錯誤及限制互相矛盾，都會讓比較失去意義；修正這些條件後，再以新任務重新建立相同起點。

先判斷結果能不能比較

兩個虛構判讀例：甲花 20 秒且完整答對，乙花 8 秒卻說應回傳 Build；這題只能說乙較快但不合格，不能選它為本需求的較佳設定。另一組甲乙都答對，但乙用過上一輪的答案或檔案已被改好，起點不同，應標「比較無效」並以原樣新任務重做。這些時間只是例題，不是任何模型的實測。

要比較推理深度時，先用 Advanced 或 CLI /model 確認真正模型與深度。只移動 Power 滑桿可能同時改變模型，不能只記「第幾格」就聲稱只改一個變因；若無法保持其餘設定相同，記成不同組合的試用，保留限制，不計算推理深度單獨帶來的差異。

如何把結果用在日常工作

每個答案先看正確性、是否遵守範圍、是否清楚說明未執行的測試，全部合格後才比較速度與用量。這種一行故障兩種設定都答對，通常已足以為這類小任務選出可用設定；不能據此宣稱某模型在所有大型專案都最好。服務負載與回覆隨機性也會影響一次測量，需要時另日重做，不為了漂亮數字反覆消耗。

規格清楚的小修改可先從帳號預設開始；遇到多檔案相依、難以重現的錯誤或需要權衡時，再提高推理並重新驗證。更高深度可能花更久、用更多 token，仍可能錯。Max 與 Ultra 不是每個任務的必選項；Ultra 涉及子代理分工，本篇的單題比較不需要開啟它。具體選項以你的選單和官方模型頁為準。

常見問題、恢復與驗收

模型找不到時，先確認登入方式、版本與帳號可見清單，不把網路文章中的舊 ID 直接寫入 config.toml。設定無效時回到設定排錯，移除本次新增的覆寫值並還原原先選擇。切換後狀態不符，先停止比較並確認是否被既有啟動參數或專案設定影響，不拿錯誤設定的結果當實驗。

「速度變慢」也可能是它在等待工具、網路或權限；查看正在做的步驟，不立刻增加深度或重送同一工作。額度不足就保存比較表與未完成狀態，依帳號篇查自己的重設資訊。這裡不硬寫價格、剩餘次數或通用可用模型表，避免多篇文章彼此矛盾。

完成條件是能指出實際選擇、用同一題目判斷兩次結果、說明比較的限制，並把模型與推理控制恢復到練習前的值。sample.mjs 應完全沒變；若任務改了它，保留差異後用上面的完整內容還原，再把該次標記為未遵守範圍。圖中 1 是記錄，2 是控制變因比較，3 是按證據選擇。本文不提供虛構的模型速度實測排名。

返回 Codex 教學總目錄

閱讀完整文字說明

Task to Model / effort to Evaluation

• AI 工具
• 教學
• Codex