软件技术分享

关于电子游戏的方方面面

Claude vs Codex：同一段“修 flaky 测试”提示谁更省回合

作者

省回合＝少人肉粘贴，或一次可验证完成。交互追 flake 偏 Claude Code；清单清楚出 PR 偏 Codex exec。差在闭环非品牌。

要点

  • 同一提示骨架可两边共用：任务＝修 flaky（CI 变绿不算完）＋失败用例＋复现命令＋连续 N 次全绿＋先分类再改＋禁止无证据加 timeout／删断言／无条件 retry／skip。
  • 省回合的定义（本稿）：①少“人把终端输出粘回聊天”的来回；②一次交付满足完成定义（含复跑记录）；口头“应该好了”不算。
  • 交互多轮“跑→看→改→再跑”：带终端闭环的 Claude Code／同类 Agent，通常更少人肉粘贴回合（第三方中：sdet.qa 对照、DEV 案例）。
  • 已有失败清单＋沙箱＋完成定义、要一次性可审 PR：Codex exec／非交互批量稳定化更省“开会式回合”（同 sdet.qa：Codex 适合界定清楚的批量／异步 PR）。
  • 证据强度：产品形态差异＝官方能力＋第三方综述（中高）；相对“谁更省”＝编译对照（中高）；无本室秒数／回合数字 benchmark，勿当成跑分。
  • 第三方共识：先做 repro harness，先分类，先要证据（Junction；DEV 文）。
  • 套餐是否含 Claude Code／Codex、具体按钮名＝待核。

正文

场景

CI 上有一条红一阵绿一阵的测试。你把失败日志丢进聊天，模型回“试试加长 timeout”。你本地跑两次碰巧全绿，以为修好了；合并后再红。另一条路：先写死复现命令与“连续 15 次全绿才算完”，再让 agent 自跑、自改，并贴复跑摘要。

争论“Claude 还是 Codex 更聪明”之前，先对齐省回合指什么：少来回，还是一次可验证完成。工具闭环不同，同一提示的成本差在粘贴次数与是否等异步 PR，不在口号。

可跟做步骤／可抄工作流

证据强度：提示骨架与禁令＝编译可跟做（中高）；工具选型＝第三方用例／综述（中）＋产品形态（中高）；无实验室跑分。

1. 共用提示骨架（先复制再填空）

任务：修 flaky，不是让 CI 变绿就算完。
失败测试：【文件 + 用例名】
复现命令：【精确命令】
完成定义：连续 N 次（建议 10–15）全绿才算修完；贴出每次结果摘要。
流程：
1) 先只分析：回归 vs flaky vs 基建；
2) 确认能复现再改；
3) 最小补丁；
4) 按完成定义复跑。
禁止：无证据加长 timeout；删断言；无条件 retry；skip；改生产逻辑却声称只改了测试（除非证据证明是产品 bug 并说明）。
输出：根因分类｜改动 diff 摘要｜复跑记录｜仍不确定项。

建议另备 ./scripts/repro.sh [N]：只有连续 N 次通过才退出 0。DEV 案例把“STABLE”写成可执行完成定义，比“请修复 flaky”可证伪得多。

2. 对照表：同一骨架下的回合成本

维度Claude Code／带终端闭环的 Claude AgentClaude 对话（无自跑终端）Codex CLI（交互）／codex exec（非交互）证据
典型闭环agent 自跑测→读失败→改→再跑你跑测，把输出贴回对话交互可批命令；exec 适合一次任务出改动／PR 向交付中高（产品形态）／中（第三方）
人肉粘贴回合通常更少（输出留在同一会话）往往最多（每轮依赖你粘日志）交互中等；exec 把多轮收成“提交任务→审 diff”编译对照（中高）
适合题型根因未清、需多轮追 shared state／顺序依赖已有完整日志、只需讨论假设失败清单已清且禁令／验收写死，要可审批量补丁sdet.qa／Junction／DEV（中）
“省回合”怎么省少粘贴；人盯判断点（删测？改产品？）省的是工具切换，不省粘贴省开会式来回：一次看 diff＋复跑记录定义见上，非秒数榜
风险仍可能 bump timeout／过度 mock（须写进禁止项）易在未复现时“口头修好”异步／非交互时若完成定义含糊，回来一包无效绿DEV 反例（中）

读表时记住：sdet.qa 写明交互追 flake 偏 Claude Code 闭环；界定清楚的批量稳定化／异步 PR 偏 Codex。这是工作流契合，不是 SWE-bench 冠亚军声明。

3. 两条可跟做开跑协议（编译对照，非本室实测）

A. 交互追单条／一小簇 flake（偏 Claude Code）

  1. 仓库内打开 Claude Code（或文档所述同等终端 Agent）；权限保持可跑测试、改测试／相关文件需你方审批习惯。
  2. 粘贴上方骨架；把“复现命令”换成真实一行，例如 pnpm vitest run tests/flaky.spec.ts -t "saves draft"。
  3. 要求第一步只输出分类（回归／flaky／基建），附是否能在隔离命令下复现；未复现则升到整文件／整包（DEV 文的 escalation）。
  4. 你确认分类后，再允许最小补丁；完成定义未满足前不得宣称修好。
  5. 人审 diff：有无删测；有无无条件 retry；有无把 I/O 换成空 mock。

B. 清单批量稳定化（偏 Codex exec／非交互）

  1. 先准备：失败列表（文件＋用例名）、统一 repro.sh、AGENTS／提示里写死禁止项与 N 次全绿。
  2. 对单条或一小批：
codex exec --sandbox workspace-write "$(cat <<'PROMPT'
【粘贴同一提示骨架，填入本批失败列表】
只改与本批相关的测试／必要生产修复；每条附根因分类与 repro 摘要。
PROMPT
)"
  1. 回来只审三件事：diff 是否最小；复跑记录是否观察值；不确定项是否单列。
  2. 根因未清、需要你盯着 bisection 时，把该条打回协议 A，别强迫 exec “一次猜中”。

沙箱旗标与审批以现行 Codex 文档为准；入门勿默认全放行（衔接本室终端审批篇）。

4. 把“省回合”写进完成定义的一句话

可贴在提示末尾：

回合成本约束：你可自行复跑；不要让我为了同一失败日志来回粘贴。
若缺权限或缺工具，列出最小阻塞项后停止。
未达到连续 N 次全绿：状态=未完成，禁止用“看起来稳定”收束。

省回合的杠杆在完成定义＋禁止项＋可复现脚本。模型品牌换了，这三样不换，差距会小很多。

真实用户诀窍／反例

  • 诀窍：先 harness，后编辑。 DEV：无验证手段时，agent 的“修复”常是假绿。
  • 诀窍：先分类再修。 Junction：跳过分类容易改症状。
  • 诀窍：禁止项写进文件或提示。 “不要盲目加 timeout”比事后骂一句有效。
  • 诀窍：产品 bug 与测试脆皮分开收口。 真 bug 可改生产逻辑，但必须在输出里标明证据。
  • 反例：以一次绿或 CI rerun 当完成。 与 flaky 定义打架。
  • 反例：无清单就对 Codex 说“把仓库 flaky 都修了”。 范围无限，异步回来也难审。
  • 反例：在无终端闭环的纯对话里假装省回合。 粘贴成本仍在你身上。
  • 反例：用假想的“平均少 3.2 轮”做选题结论。 本稿不做这类数字。

适用边界

  • 本稿是同一提示下修 flaky 的工具闭环对照与可跟做协议，不是模型智商总榜，也不是本室 benchmark。
  • Claude 网页对话与 Claude Code、Cursor 内 Agent、Codex TUI／exec：按钮名与套餐可用性随版本变，待核。
  • 不覆盖：在 CI 里无人值守自动开 PR 的完整平台搭建（可另稿）；也不鼓励为绿而删覆盖。
  • 第三方文中的“63 条／一周”等数字属于原作者环境，不得外推为本室或读者仓库指标。

【来源与编译】