用途
Pstack Arena 用于 Pstack 设计或产物的对决（bakeoff）、盲评、基础方案选择，以及嫁接有用的替代方案。它把一次多方案比较组织成六个阶段，并在启动前先打开一个待办清单，每个阶段一条：Frame、Fan out、Cross-judge、Pick、Graft、Verify。
主要能力
- Frame（框定）：每个候选方案获得相同提示词，提示词即契约。需要说明每个候选产出的产物，并推导出评分标准——3 到 6 条具体、可评分的成功标准，作为 Phase D 选择者的工具。候选方案只看到任务。通过 /pstack-swarm 选择运行者：默认两个，在宿主支持时使用不同模型；当竞技场覆盖多个设计方向时可增加运行者；当工作偏向生成而非判断时，可对同一模型使用 N 次。通过 /pstack-swarm 为每个子代理选择模型和投入程度。给每个候选自己的输出位置（尽可能用 git worktree，否则用 /tmp/arena-<slug>/candidate-<n>/），遵循 /pstack-principle-separate-before-serializing-shared-state。完成条件是：产物、评分标准、运行者以及每个候选一个输出位置都已命名。
- Fan out（并行生成）：通过 /pstack-swarm 一次性在后台生成全部 N 个子代理，每个都带有任务、共享依据的路径、自己的输出路径，以及生成产物和简短理由的指令，理由需说明考虑过哪些替代方案、拒绝了什么。如果某个候选没有产出，则以 N-1 继续并记录掉队。完成条件是每个候选都写入了产物和理由，或被标记为掉队。
- Cross-judge（交叉评审）：在 Phase B 所有候选完成后，通过 /pstack-swarm 的跨厂商评审路线生成一个只读评审子代理，优先选择与父级不同的模型家族。它看到评分标准和按路径标签标识的候选，逐条打分并推荐一个基础方案及理由。它与你在 Phase D 的阅读并行运行。不要在候选仍在写入时生成它。完成条件是评审返回逐条评分和推荐基础方案。
- Pick（选基础）：选择前从头到尾阅读每个候选。按评分标准逐条打分，而不是凭整体感觉，并与交叉评审比较。对基础方案的一致确认即确认选择。分歧意味着其中一方有偏见或评分标准含糊。决定前阅读双方理由。选择未来维护者最容易扩展且不破坏不变量的基础方案。当两个感觉打平时，优先选择边界更清晰或 API 更小的方案，遵循 /pstack-principle-laziness-protocol。完成条件是选定一个基础方案，并比较你的评分与评审的评分。
- Graft（嫁接）：再次逐一查看每个落选候选，找出值得移植到基础方案中的内容，通常每个候选一两处，而不是大部分。手工折叠每处嫁接，遵循 /pstack-principle-redesign-from-first-principles，使结果在一个心智模型下保持连贯。不要机械粘贴。如果候选收敛到一种形态，那是强烈一致，记录并交付共识形态，无需嫁接。如果它们严重分歧，说明 Phase A 规格不足，应重新框定并重跑，而不是对分歧取平均。完成条件是每个落选候选都已查看，每处嫁接或拒绝都有理由。
- Verify（验证）：像验证任何其他输出一样验证合成产物，遵循 /pstack-principle-prove-it-works。如果验证发现竞技场遗漏的问题，要么 Phase A 有误（重新框定并重跑），要么某个候选发现了而你漏掉了嫁接（回到 Phase E）。不要掩盖问题。完成条件是合成产物通过验证。
使用方式
按六个阶段顺序执行，启动前先建立每个阶段一条的待办清单。通过 /pstack-swarm 选择运行者、生成子代理和评审子代理。每个候选使用独立输出位置。人工阅读与交叉评审并行进行，最终手工嫁接并验证。
适用场景
适用于需要在多个设计或产物方案之间做盲评、选出基础方案并吸收有用替代方案的场景。
限制
资料未提供关于收费、价格、平台支持范围或具体效果的信息。