非平凡产出需要多方案比选时：并行跑 N 个候选、选基准…

当一次尝试就可能把非平凡产物锁死在错误形态时，用多个模型并行出 N 份候选，交叉评审后选一份为基准并手工吸收其余候选的精华。

适用场景

解决思路

1. 启动任何候选之前先开一个 todolist，每个阶段一条：Frame、Fan out、Cross-judge、Pick、Graft、Verify。
2. Phase A（Frame）第 1 步：写明每个候选要产出的 artifact 是什么。
3. Phase A 第 2 步：推导 rubric。先说清对*这个*任务而言成功长什么样，再把它转成 3-6 条具体的、可评分的标准。rubric 是 Phase D 挑选者的工具，候选只看得到任务本身。
4. Phase A 第 3 步：挑选 runner。若存在 `~/.cursor/rules/pstack-models.mdc`，使用其中的 `arena runners`；否则默认在 `claude-opus-5-5-max`、`gpt-5.6-sol-max`、`grok-4.7-xhigh-fast` 上各起一个。当 arena 覆盖多个设计方向时多起几个；当工作偏生成而非判断敏感时，用同一模型起 N 次。
5. Phase A 第 4 步：分配输出路径。每个候选写到自己独立的位置（尽量用 git worktree，否则用 `/tmp/arena-<slug>/candidate-<n>/`），遵循 separate-before-serializing-shared-state 原则技能。
6. Phase B（Fan out）：在一条消息里同时 spawn 全部 N 个子代理，设置 `run_in_background: true`，每个都带上任务、共享 grounding 的路径、自己的输出路径，并要求同时产出 artifact 和一段简短 rationale。
7. Phase B：每个 rationale 要写明该候选考虑过哪些替代方案、否决了什么。
8. Phase B：如果某个候选没能产出，就用 N-1 继续推进，并在 synthesis record 里记下这个 dropout。
9. Phase C（Cross-judge）：等 Phase 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`。优先选与父代理不同的模型家族，在该模型上 spawn 一个 readonly 的 judge 子代理。
10. Phase C：judge 看到 rubric 和按路径标签标识的候选，逐条标准打分，推荐一个 base 并给出理由。它是与 Phase D 中父代理的阅读并行运行的，不是与候选并行；候选还在写的时候不要 spawn judge。
11. Phase D（Pick）：挑选之前把每个候选从头到尾读完。
12. Phase D：逐条标准地对每个候选打分，而不是凭整体感觉；与 cross-judge 的结论对比。对 base 的意见一致就确认选择；不一致意味着你们中有一方有偏，或者 rubric 本身有歧义——决定前把双方的理由都读完。
13. Phase D：按“未来的维护者能最容易地扩展且不破坏不变量”来选 base；当两个候选难分高下时，按 Laziness Protocol 优先选边界更干净或 API 更小的那个。
14. Phase D：在 base artifact 旁边写一份简短 synthesis note，记录选择结果和理由，包含 cross-judge 的裁决。
15. Phase E（Graft）：把每个落选候选再走一遍，找出值得移植进 base 的东西。信号通常是每个候选只有一两处，而不是大部分内容。
16. Phase E：按 redesign-from-first-principles 原则技能手工把每一处嫁接进去，不要机械粘贴。结果必须在同一个心智模型下保持连贯。
17. Phase E：记录移植了什么、来自哪个候选、否决了什么以及为什么。
18. Phase E：当 N 个候选收敛到同一种形态，这是很强的一致信号——在记录里注明收敛，直接交付共识形态，不需要任何 graft。当 N 个候选严重发散，说明 Phase A 规格不足——重新框定并重跑，而不是把分歧平均掉。
19. Phase F（Verify）：合成后的 artifact 必须像任何其他产出一样经得起同样的检验，遵循 prove-it-works 原则技能。
20. Phase F：如果验证暴露出 arena 没抓到的问题，要么是 Phase A 错了（重新框定并重跑），要么是某个候选抓到了而你漏了 graft（回到 Phase E）。不要掩盖过去。
21. 输出：一个合成后的 artifact。旁边放一份简短的 synthesis note，写明 base、graft（含来源候选）、被否决项、dropout（若有）以及验证结果。

适用边界 · 注意事项

• 任务平凡、一次尝试不可能把结果锁死在错误形态时——并行 N 份的成本远超收益。
• 无法并行 spawn 子代理、或无法为每个候选隔离独立输出路径（如 git worktree、`/tmp/arena-<slug>/candidate-<n>/`）的环境。
• 候选还在写入时就启动 judge，或让 judge 与候选并行——必须是候选全部完成后才起 judge。