Codex Reasoning Effort 怎么选：Medium、High 与 Xhigh

2026 年 9 月 16 日，Codex Pulse 用请求模型 gpt-6-astra 记录了三次 HTML 动画输出：medium、high、xhigh 各一次。静态分数依次是 81、90、84。在这三个输出中，请求的最高 effort 没有拿到最高分。

这个样本量不足以选出通用赢家。 它的价值更具体：effort 对照需要保留原始产物，并说明分数究竟衡量什么。

Reasoning effort 调整什么

OpenAI 为支持的模型提供 model_reasoning_effort 配置。官方配置说明 给出的一个例子是：

model_reasoning_effort = "high"

这是配置示例，不代表所有任务都应该选 high。先检查当前模型和客户端支持的选项。比较输出前，记录实际生效的设置；项目配置和命令行覆盖可能改变用户级文件里的值。

这三次究竟测了什么

任务要求生成一个自包含 HTML，用 SVG 绘制鹈鹕骑自行车的 2D 动画，直接在最终回复输出完整 HTML。Prompt 禁止调用工具、读文件、加载 skills、访问网络和写文件，由调用方保存回复。完整中文 prompt 已归档；换成英文转述就改变了测试输入。

Codex CLI 0.154.0 同时运行三个独立临时会话。命令禁用了 memories 和 multi-agent，其余用户及运行时配置仍被继承。事件日志没有记录到已完成的命令、MCP 或网页搜索调用。每档都保留首次尝试，没有修图，也没有重试后挑最好的一张。

Manifest 保存了请求设置、prompt 哈希和输出哈希。请求模型名没有经过后端快照的独立验证。

分数遗漏了什么

分数来自 @ryqdev/pelican-test@0.1.0 的静态分析，规则版本是 html-svg-heuristic-v2，需要在这套规则的范围内理解。静态分数不能证明浏览器里的每个运动部件都正确，也不能判断审美偏好，更不能推导修复生产 bug 的能力。

归档截图在 1200 × 900 的浏览器视口里拍摄，时间为 HTML 加载后 1.5 秒，运行沙箱阻断了网络请求。截图只能呈现一个瞬间，动画仍需实际观看。档案说明 记录了这些条件。

每档只有一次，90 与 84 的差距不足以证明 high 稳定优于 xhigh。这里也不做速度或费用排名：表格没有可比较的延迟测量和账单数据。

怎样为自己的任务选设置

以当前支持的设置作为基线，再选一个替代设置。给两组完全相同的任务、起始文件、指令和工具权限，运行前写清验收标准。

改代码时，分别记录测试结果、意外改动、总耗时与人工介入。做动画时，保留源文件，同时检查运动过程和静态结构。每个条件重复运行，不从最好的一次输出挑赢家。

一个实用决策规则是：只有目标结果的改善足以抵偿实际观察到的代价，才保留设置变化。代价可能是更久的等待、更多用量或更多人工检查。这些需要在自己的环境测量，三份示例无法替你给出答案。

如果两档都无法稳定完成任务，继续提高 effort 之前，先检查任务定义、上下文和工具失败。Codex 质量指南 提供了症状分类；需要一个小型视觉任务时，可以使用鹈鹕说明与示例。

这组对照的下一次更新，需要每档更多同条件重复尝试，并单独记录耗时。在此之前，81、90、84 只描述已保存的三个产物。