arena

Arena

让同一个任务并行跑 N 次。把每个候选从头读到尾。挑最强的当基底。把其他候选里最好的想法嫁接进去。验证综合后的结果。

开始

启动任何东西之前，先开一个 todolist，每个阶段一条。

定题
扇出
交叉评判
选基底
嫁接
验证

阶段 A：定题

N 个候选会收到同一份提示词，所以提示词就是契约。

写明每个候选要产出什么。
定出评分标准。先说清这个任务做成是什么样，再把它变成 3 到 6 条可以具体打分的标准。评分标准是阶段 D 挑选时用的工具。候选只看得到任务。
选 runner（各自独立出方案的模型）。用 ~/.cursor/rules/pstack-models.mdc 里的 arena runners 这一行。如果没有这条 rule 或没有这一行，默认 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 次。
分配输出路径。按 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-max、gpt-5.6-sol-max、grok-4.7-xhigh-fast 里选。尽量选和父模型不同族的。在这个模型上开一个只读的评判子代理。它看得到评分标准，看到的候选只有路径标签，逐条打分，并推荐一个基底、给出理由。它和阶段 D 里父代理的阅读同时进行，不和候选同时跑。候选还在写的时候，不要开评判。

阶段 D：选基底

挑之前，把每个候选从头读到尾。

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

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

在基底产物旁边写一段简短的综合说明，记下选了哪个、为什么，并写上交叉评判的 verdict（结论）。

阶段 E：嫁接

把每个落选候选再过一遍，找出值得移到基底里的东西。通常每个候选只有一两处，不是大部分。

按 redesign-from-first-principles 原则 skill，每一处都亲手融进去。不要机械地粘贴。结果必须仍然能用同一个心智模型讲通。

记下嫁接了什么、来自哪个候选，拒掉了什么、为什么。

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

阶段 F：验证

按 prove-it-works 原则 skill，综合后的产物要经得起和其他任何产出一样的检查。

如果验证发现了 arena 没抓到的问题，要么是阶段 A 定错了（重新定题再跑），要么是某个候选其实抓到了、你漏了嫁接（回到阶段 E）。不要糊弄过去。

产出

一份综合后的产物。旁边一段简短的综合说明，写明基底、嫁接了什么（以及来自哪个候选）、拒掉了什么、掉队的候选（如果有），以及验证结果。