模型、推理深度与速度

返回 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