如何测试 OpenAI Codex：建立可复现的 Benchmark

Codex Pulse 保存了两组不同实验：2026 年 9 月 15 日的 12 次静态 SVG 输出，以及 9 月 16 日的 3 次 HTML 动画输出。两组测试回答的问题不同。把它们放进同一张排行榜，会掩盖 prompt、指令和评分方式的变化。

有用的 Codex benchmark，要从一个能对照原始输出检查的问题开始。 画图时，可以问自行车是否正常渲染；改代码时，可以问失败的测试是否通过，以及其他行为是否受损。好看的图与可用的代码修改，各自需要对应的证据。

先选要检验的结果

从实际工作里选一项任务，规模小到可以从已知起点重复运行。

公开 benchmark 可以提供排查方向。要决定某个设置是否适合自己的工作，来自自身工作流的任务更有针对性。代价是维护：起始状态必须稳定，检查也需要继续代表真实需求。

在运行前写清验收标准

代码任务至少写清三件事：什么行为要改变、什么行为必须保留、哪些检查能证明完成。保留隔离的起始 checkout，让每次尝试面对同一道题。

可以从这样的任务描述开始：

修复给定的失败案例。保留已有对外行为，执行指定检查，并报告尚未完成的工作。

把“失败案例”和“指定检查”替换成实际输入与命令。这段描述是测试输入；它不能保证 agent 一定执行。评分必须看实际发生的行为，也要记录漏掉的检查。

视觉任务则应把可观察标准与审美偏好分开。在鹈鹕 benchmark 中，可以检查鸟是否可辨认、自行车的车轮与车架是否连接、骑手是否合理地接触自行车。要求动画时，还要观看运动过程，不能只看静态截图。

固定可比较的运行条件

记录完整 prompt、请求的模型、reasoning effort、客户端版本、起始 revision、生效指令和可用工具。使用新会话；对比两个设置时，只改变一个条件。

配置本身也要核对。OpenAI 文档说明了用户级与项目级配置，命令行覆盖可以具有更高优先级。因此，一个文件中的值可能与实际运行设置不同。具体规则见官方配置说明。

失败和不好看的输出也要保存。追加纠正、催促继续，都应记录。首次回复与经过多轮修正得到的产物，要用不同标签标明。

给每次尝试留一张记录卡

Run ID 与 UTC 日期：
完整 prompt 或 prompt 文件哈希：
请求模型与 reasoning effort：
客户端版本与配置差异：
起始 revision 或输入文件：
验收检查与实际结果：
原始输出或 patch：
总耗时与已知中断：
实际工具调用：
重试与人工追加指令：
已知限制：

客户端显示的模型标签记录了请求，不能独立鉴定后端实际快照。公开分享前，移除凭据和私有材料。

预算允许时，每个条件重复数次，并在看到结果前确定尝试次数。小批次有助于找到可复现的失败模式；对于总体排名，它的证据很弱，尤其当任务本身很窄时。

怎样使用 Codex Pulse 的现有材料

9 月 15 日档案 保存了静态鹈鹕 SVG prompt 的 12 次尝试：两个请求模型、两档 effort、每个组合三次。全部产生 SVG。运行时仍有工具和指令，部分尝试调用了工具。这组材料没有可匹配的更早基线，无法建立“降级”结论。

9 月 16 日档案 保存了另一个 HTML 动画 prompt 的三次首次输出。静态分数描述的是产物在特定启发式规则下的表现，不能代表整体编程能力，也不能独立证明视觉正确。

先从图库和测试说明 看具体输出，再从自己的工作里挑一项有验收检查的任务。如果你担心近期表现变化，可以先用质量排查指南。下一份值得保存的证据，是同一任务在明确条件下的重复运行。