怎样让 Codex 连续开发几天？

代码会留下，关于代码的可靠认识却会不断过期

开发越久，代码、需求、已知问题和测试结论越容易对应不上。

论文 Figure 2：右侧由系统自己观察问题、规划修改、开发和测试。

01

决定被遗忘早期需求、设计取舍和已知限制埋进历史，后续修改不知道什么不能破坏。

02

下一步没有唯一答案同一份公开产品需求文档（PRD）可以对应多条开发路线。

03

“能运行”不等于“做完”软件还需满足交互、画面、音频、流程和运行稳定性要求。

HoH 不改 Codex，也不训练模型；它改的是外层开发协议

HoH 把验证证据绑定到候选版本，跨轮状态不再只是对话摘要

一轮包含一次受控的状态提交

配置检查与实际文件隔离是两层保护

class WorkspaceAccess(str, Enum):
    READ_ONLY = "read-only"
    READ_WRITE = "read-write"

@dataclass(frozen=True)
class RoleBinding:
    role: RoleName
    workspace_access: WorkspaceAccess
    godot_mcp: GodotMCPAccess

    def __post_init__(self):
        if self.role is not RoleName.DEVELOPER:
            if self.workspace_access is WorkspaceAccess.READ_WRITE:
                raise ValueError(...)

每条验证记录说明测试了哪个版本、看到了什么

{
  "candidate_id": "loop-70-...",
  "final_status": "FAIL",
  "verified_records": [
    {
      "claim": "正常启动成功",
      "method": "runtime replay",
      "evidence": ["log", "screenshot"]
    }
  ],
  "gap_records": [
    {
      "claim": "encounter reaches combat",
      "observed": "idle / walk only",
      "impact": "完整用户路径受阻"
    }
  ]
}

内部 QA 能帮助下一轮；外部隐藏验收程序 只能在结束后结算

先看提交经过什么 judge，再看表格里的数字

提升不只来自“项目终于能启动”，内容深度和呈现也一起变化

论文 Figure 4：对 45 题做 20,000 次 bootstrap（有放回重采样）的 95% 分位数区间。

Core Mechanics：核心玩法基础玩法与玩家交互。三种 harness/model 都提高。

Content Depth：内容深度关卡、挑战、目标和进展的丰富程度；权重与艺术呈现同为 0.35。

运行门槛仍先执行如果项目无法编译或运行，四项评分再高，Overall 仍是 0。

三轮 HoH 更常把核心交互、UI 和场景细节同时补齐

论文 Figure 6：Momentum Lab、Kitchen Rush、Ant Empire。

Momentum LabOverall 34.05 → 70.61；从基础平台场景走向更完整的动量玩法。

Kitchen RushOverall 42.62 → 73.38；订单、厨房状态与管理反馈更完整。

Ant EmpireOverall 65.52 → 87.88；殖民地状态、资源与进展展示更成熟。

证据边界这些是按结果展示的作者选择案例，不能替代同题重复生成或随机抽样案例。

Repeated Vanilla 也会进步，但 HoH 每轮更有效地使用新增 token

论文 Figure 9：累计 score 与 token trajectory。

Protocol	Pass 1	Pass 2	Pass 3	Tokens@3
Vanilla / Continue	49.58	54.99	58.24	6.33M
HoH	59.71	64.84	71.52	8.41M

同预算附近的关键点HoH@2 用 5.67M tokens 得到 64.84，已经超过三轮 Vanilla 的 58.24 / 6.33M。

仍不是严格等 computeMatched pass 不等于 matched wall-clock、invocation 数或 token；论文另用 budget efficiency 辅助解释。

三项消融都降低均分，从头重建最费 token

论文 Figure 10：最终均分与累计 token。Lighthouse 是单题反例：80.90 → 81.50（去掉 Warm-Start）。

Full HoH@3 · 71.52 / 8.41M更新计划、传递 QA 记录、沿旧项目继续全部保留。

w/o Plan Update · 63.39后续轮次固定使用第一轮开发文档。

w/o Evidence Feedback · 65.23QA 仍测试，但下一轮 Planner 看不到它的记录。

w/o Warm-Start · 63.67 / 11.12M每轮从初始工作区重建，整体更费 token。

Dominance 上升与长期零分可以同时存在

Figure 5：11 个 Codex 阶段互比，Vanilla 27.33%，HoH@10 72.67%；阴影 ±1 标准误。

Figure 8 按任务类别显示均分。主表用三系统 × 四阶段，共 12 配置；同一 Vanilla 为 22%。比较池不同，不能把两值拼成准确率曲线。

总体平均上涨，不代表每个任务、每个阶段都变好

论文 Figure 11：每次开发调用的 token 分布。

单题回退Pi 的 Spire Descent 26.61 → 10.96，Pipe Crisis 53.26 → 37.65；总体均分上涨不等于每题上涨。

生成方差未知每种任务配置只跑一次有效实验，没有共同生成 seed，也没有同题重复采样。

不同 provider 不同记账缓存读入、输入和输出 token 的记账方式不同，Figure 11 适合看同一 harness/model 内部，不适合横向算单价。

局部修复通过，但玩家仍不能完成战斗和重新开局

Figure 1：前 70 轮发现 81 个问题，关闭 65、未解决 16；17 个曾关闭问题因回归重开。

准备与操作启动、进入游戏，准备三组遭遇战，再推进战斗；测试前后源码哈希一致。

观察 1有 3/5/10 个敌人，只看到待机与走路；未证明完整战斗动作。

观察 2Replay 后部署按钮无法重开；llvmpipe 软件渲染采样为 8 FPS，不能证明原生性能。

判定 · FAIL / BLOCKED必需检查未全部通过、仍有阻断项；局部启动 PASS 不能通过整轮验收。

最值得复用的是 与候选版本绑定的证据；最需要补的是重复实验与 QA 校准

实验支持完整 HoH 协议有效三种 harness/model、三套 benchmark 的总体指标均高于 Vanilla；同开发次数比较与三项消融支持跨轮记录有用。

未验证没有同题生成方差一次有效实验 无法回答稳定性；bootstrap 只重采任务。

待补实验QA 还未校准需要测 误判通过/失败率、停止条件、何时回滚，以及固定预算的分配。

作者兴趣度9.5 / 10对 Claude Code、Codex 式完整 harness 的多日自治开发非常直接。