arena

一开头就选错形状、事后返工很贵的设计决定，用擂台来定：新子系统或新机制、数据与状态归属、对外接口、技能或治理协议的结构。机械活、形状已定的改动、只有一种可行做法的，不上擂台，直接做。

谁来开：本人点名就开跑。不是本人点名、是你判断某个决定适合上擂台时，用一句话提议，说明在哪个决定上、为什么，以及大约多花几次模型调用，本人同意才跑；没同意就按平常方式继续。无人值守的任务里不提议，也不开跑。

擂台只产出草图：调用方怎么用、核心数据结构、接口签名、模块或文件分布，外加理由。函数体写 not implemented 或伪代码。草图用完即弃，不打磨；实现是合成之后另起的一步。

原型吸收自 cursor/plugins 里 pstack 的 arena 和 architect（MIT）。

1. 定框

• 吃透现状：读新设计要接上的代码、文档和现有机制。只报出文件名不算吃透。
• 写任务说明：这份说明就是合同，所有出稿者拿同一份。
  • 写清问题本身。
  • 把查明的约束写成句子：不能破坏的调用方、已有类型、已有的调度或技能槽、关键接口长什么样。出稿者照着这份说明就能设计，不必再翻一遍仓库。
  • 附上材料路径，留给他们核对细节。
  • 写明交付格式（见第 2 步）。
• 评分表：写 3–6 条能逐条打分的标准，只给评审和自己用，出稿者看不到。以下几条默认放进去，再按任务补：
  • 接口深度：用更小的对外接口藏住更多复杂度；按状态归属分模块，不按执行步骤切成一串只转手的浅层。
  • 单一归属：每份状态只有一个写入者，每个约束只有一个权威来源。
  • 能并进现有机制：不另起炉灶也不丢能力。
  • 好撤回。
• 本人过目：本人在场时，把任务说明和评分表给本人看一次再开跑。

2. 出稿

• 出稿者：默认 2 个，设计方向明显多于两个时用 3 个。
  • 默认：每个用不同厂商的模型（Claude、GPT、Gemini 等各取当前最强的一档），型号当场从当前客户端或模型网关的可用列表里挑，不写死过时型号。
  • 降级：客户端只能用一家的模型时（见文末），或只剩一家能跑时，改用同一模型，但给每个出稿者指定不同的设计约束轴。例如 A 稿约束为最小对外接口、不新增文件，B 稿约束为数据或表驱动、状态与流程解耦。并行的出稿者彼此看不见，所以差异要靠约束轴事先定好。降级时在合成说明里注明。
• 各写各的：每人只写分到的 <临时目录>/arena-<题目>/candidate-A.md（B、C 依次类推），项目文件只读。
• 交付格式，按顺序：
  1. 调用方视角：两三个真实用法。代码写调用点，流程写谁在什么时候怎么用。
  2. 由用法推出的数据结构与签名。
  3. 模块或文件分布，以及依赖方向。
  4. 理由：优化了什么、接受了什么代价、考虑过又否掉的整体方案（同一形状的变体不算）。
• 出稿提示里写明：
  • 拿出你能做出的最好设计，候选之间的差异正是要的信号，不要向稳妥的中间方案靠拢。
  • 正文不写自己的模型或厂商名。
• 掉线：有人没交稿，就用剩下的继续，并注明。

3. 交叉评审

全部交稿后，起一个只读评审，模型与主控不同厂商。它拿到评分表和各候选的文件路径，自己去读，逐条打分，推荐底版并写理由。

简报第一句写明：本次只按评分表给设计草图打分，草图没有实现和测试输出属于正常，不按代码复核的流程判。

评审在跑的同时，你开始第 4 步的通读。找不到不同厂商的模型时跳过评审，在合成说明里写明。

4. 选底版

自己把每份候选从头读完，按评分表逐条打分，不凭整体印象，再和评审对照：

• 结论一致，底版就定了。
• 不一致，说明有一方带偏见或评分表有歧义，读完两边理由再定。

底版选后来的维护者最不容易改坏的那份；打平时选接口更小、边界更清楚的。

5. 嫁接

把每份落选稿再过一遍，通常只取一两处长处，按底版的思路手工融进去，保持一个统一的心智模型，不整段拼接。

• 收敛：候选形状一致，说明有共识，记一句，不用嫁接。
• 发散：差异大到无从比较，说明第 1 步没定清楚。补全任务说明后重跑一次，不取平均；第二次仍发散，就把分歧点作为待定问题交给本人。

6. 交付

交一份合成设计，包含：

• 调用方视角
• 形状
• 接受的代价
• 被否掉的方案及原因
• 需要本人定的问题（写成问句）
• 第一步实现做什么

另附一段合成说明：底版是哪份、为什么，评审结论（或为何跳过），每处嫁接取自哪份，否掉了什么，以及收敛、降级或掉线情况。

到这里擂台结束。之后照合成设计实现时，草图就是合同：实现中要偏离签名，说明草图、需求或实现有一处错了，要指出来，不悄悄吸收。同类偏离反复出现，就推翻草图，重新上擂台。候选目录留到本人认可设计，之后删掉。

各客户端怎么派

在本技能里显式指定模型，是异厂盲评所需的合理例外。

• pi：出稿者用 delegate 加 model，在一次并行调用里同时发出。评审用 reviewer 加 model，设 context: "fresh"（接入模型网关时按网关规则带对应 provider 前缀）。
• Codex：用内置 default 角色传 model，设 fork_turns="none"。
• Cursor：并行派发多个子代理分别绑定不同厂商模型出稿，再起异厂只读子代理打分。
• Claude Code：子代理只能用 Claude 模型时，出稿按第 2 步的降级方式走同模型加不同约束轴；评审同为 Claude 时，在合成说明里注明这一局没有异厂评审。