arena

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Arena

Fan out N parallel attempts at the same task. Read every candidate end to end. Pick the strongest as the base. Graft the best ideas from the others into it. Verify the synthesized result.

针对同一任务并行发起 N 次尝试。完整阅读每个候选方案。选出最强的一个作为基础方案。将其他方案中的最佳思路移植其中。验证综合后的结果。

Start

开始

Open a todolist with one entry per phase before launching anything.

Frame
Fan out
Cross-judge
Pick
Graft
Verify

在启动任何操作前，先打开一个 todolist，每个阶段各建立一个条目。

框定
并行展开
交叉评审
选定
融合
验证

Phase A: Frame

阶段 A：框定

The N candidates will receive the same prompt, so the prompt is the contract.

State the artifact each candidate is producing.
Derive the rubric. State what success looks like for this task, then turn it into 3-6 concrete gradeable criteria. The rubric is the picker's tool in Phase D. Candidates only see the task.
Pick the runners. Use the
```
arena runners
```
line in
```
~/.cursor/rules/pstack-models.mdc
```
. If the rule or that line is missing, default to one each on
```
claude-opus-5-5-max
```
,
```
gpt-5.6-sol-max
```
,
```
grok-4.7-xhigh-fast
```
. An
```
auto
```
or
```
inherit-parent
```
entry in this line or the cross-judge line means the parent model, so omit
```
model
```
for it. If the Task tool rejects a configured entry, run that seat on its family's default and say so. Families go by prefix:
```
claude-*
```
,
```
gpt-*
```
, and
```
grok-*
```
. With no family match, use
```
claude-opus-5-5-max
```
. If it rejects a default, use the closest valid slug of the same family from its error message. Spawn more when the arena covers multiple design directions. Same model N times when the work is generation-bound rather than judgment-sensitive.
Assign output paths. Each candidate writes to its own location (a git worktree where possible, otherwise
```
/tmp/arena-<slug>/candidate-<n>/
```
), per the separate-before-serializing-shared-state principle skill.

N 个候选方案将收到相同的 prompt，因此 prompt 就是约束契约。

明确每个候选方案要产出的产物。
制定评分标准。先说明这项任务的成功标准，再将其转化为 3-6 项具体、可评分的标准。该评分标准是阶段 D 中选择方案的依据。候选方案只会看到任务本身。
选择执行模型。使用
```
~/.cursor/rules/pstack-models.mdc
```
中的
```
arena runners
```
行。如果该规则或这一行不存在，默认在
```
claude-opus-5-5-max
```
、
```
gpt-5.6-sol-max
```
、
```
grok-4.7-xhigh-fast
```
上各使用一个。如果这一行或交叉评审行中的
```
auto
```
或
```
inherit-parent
```
条目表示父模型，则不要为它指定
```
model
```
。如果 Task 工具拒绝某个已配置的条目，则让该席位改用其所属系列的默认模型运行，并说明这一情况。模型系列按前缀区分：
```
claude-*
```
、
```
gpt-*
```
和
```
grok-*
```
。如果找不到匹配的系列，则使用
```
claude-opus-5-5-max
```
。如果默认模型也被拒绝，则使用错误消息中同一系列最接近的有效 slug。如果 arena 涵盖多个设计方向，则增加候选方案数量。当工作更受生成能力约束而非评审判断影响时，可以使用同一模型运行 N 次。
分配输出路径。每个候选方案都应写入自己的位置（尽可能使用 git worktree，否则使用
```
/tmp/arena-<slug>/candidate-<n>/
```
），遵循 separate-before-serializing-shared-state 原则 skill。

Phase B: Fan out

阶段 B：并行展开

Spawn all N subagents in one message with

run_in_background: true

, each with the task, the path to the shared grounding, its own output path, and instructions to produce both the artifact and a short rationale.

Each rationale names the alternatives the candidate considered and what it rejected.

If a candidate fails to produce output, proceed with N-1 and note the dropout in the synthesis record.

在同一条消息中启动全部 N 个 subagent，并设置

run_in_background: true

。为每个 subagent 提供任务、共享 grounding 资料的路径、独立的输出路径，以及同时产出产物和简短理由说明的指示。

每份理由说明都应列出候选方案考虑过的替代方案，以及拒绝了哪些方案。

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

Phase C: Cross-judge

阶段 C：交叉评审

After all Phase B candidates complete, choose one model from the

arena cross-judge pool

line in

~/.cursor/rules/pstack-models.mdc

. If the rule or that line is missing, choose from

claude-opus-5-5-max

gpt-5.6-sol-max

grok-4.7-xhigh-fast

. Prefer a different model family from the parent's. Spawn one readonly judge subagent on that model. It sees the rubric and the candidates by path label, scores each criterion, and recommends a base with rationale. It runs in parallel with the parent's reading in Phase D, not with the candidates themselves. Don't spawn the judge while candidates are still writing.

阶段 B 的所有候选方案完成后，从

~/.cursor/rules/pstack-models.mdc

中的

arena cross-judge pool

行选择一个模型。如果该规则或这一行不存在，则从

claude-opus-5-5-max

、

gpt-5.6-sol-max

、

grok-4.7-xhigh-fast

中选择。优先选择与父模型所属系列不同的模型。

使用该模型启动一个只读评审 subagent。向它提供评分标准，并通过路径标签标识各个候选方案；让它逐项评分，并说明理由，推荐一个基础方案。

该评审应与父 Agent 在阶段 D 中的阅读并行运行，而不是与候选方案同时运行。候选方案仍在写入时，不要启动评审。

Phase D: Pick a base

阶段 D：选定基础方案

Read every candidate end to end before picking.

Score each candidate against the rubric criterion by criterion, not on holistic feel. Compare against the cross-judge. Agreement on the base confirms the pick. Disagreement means one of you is biased or the rubric was ambiguous. Read both rationales before deciding.

Pick the base on which candidate a future maintainer can extend most easily without breaking invariants. Prefer the cleaner boundary or smaller API when two feel tied, per the Laziness Protocol.

Record the pick and the reason in a short synthesis note alongside the base artifact, including the cross-judge's verdict.

选择之前，完整阅读每个候选方案。

依据评分标准逐项对每个候选方案进行评分，而不是凭整体感觉判断。将你的结果与交叉评审结果进行比较。双方对基础方案的选择一致，即可确认该选择；如果不一致，则说明双方中有一方存在偏见，或评分标准存在歧义。做出决定前，先阅读双方的理由说明。

选择这样的基础方案：未来的维护者最容易在其上扩展，同时不会破坏不变量。当两个方案感觉相当时，按照 Laziness Protocol，优先选择边界更清晰或 API 更小的方案。

在基础产物旁写一份简短的综合记录，记录选定结果和原因，并包含交叉评审的结论。

Phase E: Graft

阶段 E：融合

Walk each losing candidate once more and identify what is worth porting into the base. The signal is usually one or two things per candidate, not most of it.

Fold each graft in by hand, per the redesign-from-first-principles principle skill. Don't paste mechanically. The result has to remain coherent under one mental model.

Record what was grafted, from which candidate, and what was rejected and why.

When N candidates converge on the same shape, that is a strong agreement signal. Note the convergence in the record and ship the consensus shape. No graft is needed. When N candidates wildly diverge, Phase A was under-specified. Reframe and re-run rather than averaging the divergence.

再次逐一审阅每个落选方案，识别值得移植到基础方案中的内容。通常每个候选方案只有一两处值得移植，而不是其大部分内容。

每次移植都要手动融入，遵循 redesign-from-first-principles 原则 skill。不要机械粘贴。最终结果必须在统一的思维模型下保持连贯。

记录移植了什么、来自哪个候选方案，以及拒绝了什么及原因。

当 N 个候选方案收敛到相同形态时，这是很强的一致性信号。在记录中注明这种收敛，并交付共识形态，无需再进行移植。当 N 个候选方案差异巨大时，说明阶段 A 描述不足。应重新框定并重跑，而不是对差异取平均。

Phase F: Verify

阶段 F：验证

The synthesized artifact has to hold up under the same scrutiny as any other output, per the prove-it-works principle skill.

If verification surfaces a problem the arena did not catch, either Phase A was wrong (re-frame and re-run) or one candidate caught it and you missed the graft (go back to Phase E). Don't paper over.

综合后的产物必须像其他任何输出一样经得起同等严格的检验，遵循 prove-it-works 原则 skill。

如果验证发现了 Arena 未捕捉到的问题，要么阶段 A 有误，需要重新框定并重跑；要么某个候选方案发现了问题，而你漏掉了相应的移植，需要返回阶段 E。不要掩盖问题。

Outputs

输出

One synthesized artifact. One short synthesis note alongside, naming the base, the grafts (with source candidate), the rejections, the dropouts if any, and the verification result.

一份综合产物。旁边附一份简短的综合说明，注明基础方案、各次移植的内容及其来源候选方案、拒绝的内容及原因、任何未产出的候选方案，以及验证结果。