arena

Arena

启动任何东西之前，先开一个 todolist，每个阶段一条（定题、扇出、交叉评判、选基底、嫁接、验证）。

阶段 A：定题

每个候选拿到的是同一份提示词，所以提示词就是契约。

写明每个候选要产出什么。
定出评分标准，3 到 6 条可以具体打分的标准，说清这个任务做成是什么样。它是阶段 D 挑选时用的工具。候选只看得到任务。
选 runner（各自独立出方案的模型）。用 ~/.cursor/rules/pstack-models.mdc 里的 arena runners 这一行。如果没有这条 rule 或没有这一行，默认 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast 各一个。这一行或交叉评判那一行里写 auto 或 inherit-parent 的条目，指的是父模型，这时省略 model。如果 Task 工具拒绝某个配置的条目，这个席位改用同一模型族的默认值，并说明这件事。模型族按前缀分：claude-* 和 grok-*。哪个族都对不上时，用 claude-opus-5-5-xhigh。如果连默认值也被拒，从报错信息里挑同一族里最接近的有效 slug。arena 要覆盖好几个设计方向时，多开几个 runner。工作主要受生成量限制、不太考验判断时，用同一个模型跑 N 次。
按 separate-before-serializing-shared-state 原则 skill，每个候选写到自己的位置（能用 git worktree 就用，否则用 /tmp/arena-<slug>/candidate-<n>/）。

阶段 B：扇出

在一条消息里用 run_in_background: true 一次开出全部 N 个子代理。每个子代理拿到任务、共享的背景材料路径、自己的输出路径，以及要求它产出产物和一段简短 rationale 的指示。rationale 要写出它考虑过哪些备选、拒掉了什么。

如果某个候选没有产出，就用剩下的 N-1 个继续，并记下谁掉队了。

阶段 C：交叉评判

阶段 B 的候选全部完成后，从 ~/.cursor/rules/pstack-models.mdc 的 arena cross-judge pool 这一行里选一个模型。如果没有这条 rule 或没有这一行，就从 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast 里选。尽量选和父模型不同族的。在这个模型上开一个只读的评判子代理。它看得到评分标准，看到的候选只有路径标签，逐条打分，并推荐一个基底、给出理由。它和你在阶段 D 里的阅读同时进行。候选还在写的时候，不要开它。

阶段 D：选基底

挑之前，把每个候选从头读到尾。按评分标准一条一条给每个候选打分，不要凭整体感觉，再跟交叉评判的结果对照。基底选得一样，就确认这个选择。选得不一样，说明你们当中有一方有偏向，或者评分标准有歧义。两边的 rationale 都读完再决定。

基底要选将来维护的人最容易扩展、又不会破坏 invariant 的那个。两个难分高下时，按 Laziness Protocol，选边界更干净或 API 更小的。

阶段 E：嫁接

把每个落选候选再过一遍，找出值得移到基底里的东西，通常每个候选只有一两处，不是大部分。按 redesign-from-first-principles 原则 skill，每一处都亲手融进去，让结果仍然能用同一个心智模型讲通。不要机械地粘贴。

如果候选收敛到同一个形态，这是很强的一致。写明这一点，然后交付这个共识形态，不需要嫁接。如果分歧很大，说明阶段 A 没定清楚。重新定题再跑一遍，不要把分歧取个平均。

阶段 F：验证

按 prove-it-works 原则 skill，像检查其他任何产出一样检查综合后的产物。如果验证发现了 arena 没抓到的问题，要么是阶段 A 定错了（重新定题再跑），要么是某个候选其实抓到了、你漏了嫁接（回到阶段 E）。不要糊弄过去。

产出

一份综合后的产物，旁边一段简短的综合说明，写明基底和理由、交叉评判的 verdict（结论）、每一处嫁接以及它来自哪个候选、拒掉了什么和为什么、有没有收敛或掉队，以及验证结果。