arena

Arena

针对同一任务并行发起 N 次尝试。逐字通读每个候选结果。选出最强的作为基础版本。将其他结果中的最佳思路融入其中。验证综合后的结果。

开始

在启动任何操作之前，创建一份待办清单，每个阶段对应一项。Arena 会自主运行，清单可防止阶段悄然遗漏。

1. 定义
2. 并行发起
3. 交叉评审
4. 选择
5. 融合
6. 验证

阶段 A：定义

N 个候选者会收到相同的提示词，因此提示词就是约定。启动任何操作前，先把提示词完善。

1. 说明每个候选者要产出的内容。
2. 制定评分标准。说明此任务的成功标准，然后将其转化为 3-6 条可具体评分的标准。具体示例：添加一个 --dry-run 标志以跳过写入操作。模糊示例：代码正确。评分标准是阶段 D 中选择者的工具；候选者只能看到任务。
3. 选择运行者。默认运行者为已配置的 arena 列表（默认值为 claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast）。当 Arena 涉及多种设计方向时，增加运行者数量。如果工作侧重生成而非判断，则使用同一个模型运行 N 次。
4. 指定输出路径。每个候选者都写入自己的位置（尽可能使用 git worktree，否则使用 /tmp/arena-<slug>/candidate-<n>/）。N 个候选者写入同一路径会造成共享可变状态，违反 separate-before-serializing-shared-state 原则技能测试的要求。

阶段 B：并行发起

在一条消息中启动所有 N 个子 Agent，并设置 run_in_background: true；每个子 Agent 都要收到任务、共享依据材料的路径、各自的输出路径，以及同时产出内容和简短理由的指示。

理由是必需的。没有理由，父 Agent 就无法判断候选方案的结构是经过深思熟虑还是偶然形成的，这会降低阶段 E 融合的可靠性。每份理由都要说明候选者考虑过哪些备选方案，以及拒绝了哪些方案。

如果某个候选者未能产出结果，则继续使用 N-1 个候选者，并在综合记录中注明该候选者退出。

阶段 C：交叉评审

阶段 B 的所有候选者完成后，启动一个只读评审子 Agent，其模型系列需与父 Agent 不同。评审者会看到评分标准和按路径标签标识的候选结果，为每项标准打分，并说明推荐哪个基础版本及理由。评审应与父 Agent 在阶段 D 的阅读工作并行进行，而不是与候选者并行。若候选者仍在写入时就启动评审，评审者看到的可能是部分输出或空输出，并将其误报为退出。

阶段 D：选择基础版本

选择前，逐字通读每个候选结果。只略读 N 个候选结果，通常只会发现表面上最熟悉的那个。

逐项依据评分标准为每个候选结果打分，而不是凭整体感觉判断。与交叉评审结果进行比较。双方一致选定某个基础版本，说明选择得到了确认。若意见不一致，说明其中一方存在偏见，或评分标准不够明确。做出决定前，先阅读双方的理由。

选择一个未来维护者最容易扩展、又不破坏不变量的候选版本。若两个版本难分高下，则根据惰性原则，优先选择边界更清晰或表面积更小的版本。

在基础版本旁附上一份简短的综合说明，记录选择结果和理由，并注明交叉评审的结论。

阶段 E：嫁接

再次逐一检查每个落败的候选方案，找出值得移植到基础方案中的内容。每个候选方案通常只有一两点值得借鉴，而非大部分内容。

根据 从第一性原理重新设计 原则技能，手动融入每一项嫁接内容。不要机械地粘贴。最终结果必须在同一套思维模型下保持连贯。

记录嫁接了什么、来自哪个候选方案，以及舍弃了什么、原因是什么。舍弃说明是记录中最有价值的部分。未来的读者能从你考虑过却最终舍弃的内容中学习，而不仅仅是你保留的内容。

当 N 个候选方案收敛到同一种形态时，这是强有力的一致性信号。在记录中注明这种趋同，并采用这一共识形态。无需嫁接。当 N 个候选方案大相径庭时，说明阶段 A 的问题定义不够明确。重新梳理问题并重新运行，而不是对这些差异取平均。

阶段 F：验证

合成后的产物必须经得起与其他任何输出相同的审查，这符合 证明其有效 原则技能。经过竞技场检验并不意味着可以免于验证。

如果验证发现竞技场未能发现的问题，要么是阶段 A 有误（重新梳理问题并重新运行），要么是某个候选方案发现了问题，而你漏掉了相关嫁接内容（回到阶段 E）。不要敷衍了事。

输出

一个合成后的产物。另附一份简短的综合说明，注明基础方案、嫁接内容（及其来源候选方案）、舍弃内容、落选方案（如有）以及验证结果。