arena

Arena

针对同一项任务并行尝试 N 种方案。逐字阅读每个候选结果。选出最强的方案作为基础。将其他方案中的最佳创意融入其中。验证综合后的结果。

开始

启动任何操作前，先创建一个待办列表，为每个阶段列出一项任务。

1. 制定框架
2. 并行尝试
3. 交叉评审
4. 选定方案
5. 融合改进
6. 验证

阶段 A：制定框架

N 个候选方案会收到相同的提示词，因此提示词就是约定。

1. 说明每个候选方案要产出的内容。
2. 推导评分标准。说明这项任务的成功标准，然后将其转化为 3-6 条可具体评分的标准。评分标准是阶段 D 中筛选者使用的工具。候选方案只能看到任务本身。
3. 选择运行模型。使用 ~/.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。如果默认模型也被拒绝，则根据错误消息使用该系列中最接近的有效模型标识。 当 Arena 涉及多个设计方向时，增加候选数量。如果任务受生成能力而非判断能力影响，则重复使用同一模型 N 次。
4. 分配输出路径。每个候选方案都写入自己的位置（尽可能使用 Git 工作树，否则使用 /tmp/arena-<slug>/candidate-<n>/），遵循 先分离，再串行化共享状态 原则技能。

阶段 B：并行尝试

在一条消息中启动所有 N 个子 Agent，并设置 run_in_background: true。为每个子 Agent 提供任务、共享依据的路径、自身输出路径，并要求其产出成果和简短的理由说明。

每份理由说明都要列出候选方案考虑过的备选方案，以及舍弃它们的原因。

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

阶段 C：交叉评审

阶段 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 中选择。优先选择与父模型不同系列的模型。启动一个只读评审子 Agent。它会看到评分标准和按路径标签标识的候选方案，对每项标准逐一评分，并说明建议选哪项作为基础及其理由。评审子 Agent 应与父模型在阶段 D 的阅读工作并行运行，而不是与候选方案同时运行。候选方案尚在写入时，不要启动评审子 Agent。

阶段 D：选定基础方案

逐字阅读每个候选结果后再做选择。

按照评分标准逐项评估每个候选方案，而不是凭整体印象。与交叉评审结果进行比较。双方对基础方案达成一致即可确认选择。如有分歧，说明你们中有一方存在偏见，或者评分标准不够明确。做出决定前，阅读双方的理由说明。

选择未来维护者最容易在不破坏不变量的前提下继续扩展的候选方案作为基础。若两个方案难分高下，则优先选择边界更清晰或 API 更小的方案，遵循懒惰原则。

在基础成果旁附上一份简短的综合说明，记录选择及其原因，并注明交叉评审的结论。

阶段 E：移植

再逐一检查每个落选候选方案，找出值得移植到基底中的内容。每个候选方案通常只有一两项值得移植，而不是大部分内容。

按照从第一性原理重新设计原则技能，手动整合每项移植内容。不要机械地复制粘贴。结果必须在同一套思维模型下保持连贯。

记录移植了哪些内容、来自哪个候选方案，以及拒绝了哪些内容及其原因。

当 N 个候选方案趋于相同形态时，这是强烈的一致性信号。请在记录中注明这种趋同，并采用共识形态。无需移植。当 N 个候选方案大相径庭时，说明阶段 A 的要求不够明确。重新梳理要求并重跑，而不是对不同方案取平均。

阶段 F：验证

合成后的产物必须经得起与其他任何输出相同的审查，遵循证明其有效原则技能。

如果验证发现了竞技场未能发现的问题，要么是阶段 A 有误（重新梳理要求并重跑），要么是某个候选方案发现了问题，而你漏掉了相应的移植内容（返回阶段 E）。不要敷衍了事。

输出

一份合成产物，以及一份简短的综合说明，列明基底、移植内容（及其来源候选方案）、拒绝项、弃选项（如有）和验证结果。