pstack /arena 实战指南并行候选、交叉评审与择优嫁接的多模型合成工作流【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/pluginspstack 插件中的arena技能pstack/skills/arena/SKILL.md提供了一套“N 路并行候选 → 交叉评审 → 择优嫁接 → 验证合成”的确定性工作流用于解决单个模型一次尝试就把错误形状锁死的问题。本文以该技能文档为骨架结合 pstack 仓库中的设计指南与系列 principle 技能完整拆解其六阶段执行协议、提示词契约设计与源码级依据读者读完可直接在自己的 Cursor 工作流中复现/arena的完整流程。Arena 在 pstack 中的定位pstack 是一套面向 Cursor 的 agent 插件围绕“设计先于编码”的理念组织了一系列按需触发的技能。在其设计指南开篇就点明了分工一次针对困难设计的尝试会把模型最先想到的形状锁死。/architect在实现前确定类型与边界/arena对同一份 brief 运行多次尝试并合并其中最好的部分/interrogate让其他模型尝试击破结果当任务是覆盖面而非设计综合时/swarm切分切片并聚合结果。README 的技能速查表中对/arena的定位是“你想要对同一件事做 N 次并行尝试然后取每个尝试的最佳部分。”并给出了直接调用的示例/arena take my prompt to the arena verbatim. i want to compare their proposals with yours.Arena 与相邻技能的本质区别在于它给每个 worker同一份设计或代码 brief而非切片随后执行“选基座 嫁接”的仪式化流程而/swarm是覆盖切片或竞速不包含选择与嫁接环节见 swarm 技能 与设计指南第 57 行的对比说明。六阶段总览arena技能在启动任何动作之前要求先打开一个 todo 清单每个阶段占一条Frame构图Fan out扇出Cross-judge交叉评审Pick选定基座Graft嫁接Verify验证整个数据流可以用设计指南中的流程图概括Phase AFrame —— 提示词即契约N 个候选会收到完全相同的提示词因此提示词本身就是候选之间的“合同”。构图阶段要做四件事明确产物声明每个候选正在产出的是什么 artifact设计草图、代码模块、命名方案、算法实现等。推导评分标准rubric先说明“对这个任务来说成功是什么样”再把它转成36 条可打分、可判定的具体标准。rubric 是 Phase D 中选择者的工具候选本身只看任务不接触 rubric——避免候选“迎合评分标准”而失去多样性。挑选选手runners优先读取~/.cursor/rules/pstack-models.mdc中的arena runners配置不存在时默认在claude-fable-5-1-thinking-max、gpt-5.6-sol-max、grok-4.6-fast-xhigh、claude-opus-5-thinking-xhigh上各派一个。当 arena 覆盖多个设计方向时增加候选数当工作是“生成密集”而非“判断敏感”时可以让同一模型跑 N 次。分配输出路径每个候选写入自己的独立位置优先 git worktree否则/tmp/arena-slug/candidate-n/。这一步背后是 principle-separate-before-serializing-shared-state 技能并发参与者如果共享可变状态竞态会间歇性出现、难以复现且调试昂贵。该 principle 给出的默认解法正是“消除共享写目标”——每个 worker 拥有自己的文件、目录或分支只在读取/汇报边界合并。两个 worker 往同一个state.json里写各自的lastX字段仍是共享写indexer-state.json加metrics-state.json则不是。Phase BFan out —— 单条消息并行扇出在一条消息里用run_in_background: true同时生成全部 N 个子 agent每个都携带任务本身共享 grounding 材料的路径自己的输出路径要求既产出 artifact也产出一段简短 rationale理由说明。每条 rationale 要写明候选考虑过哪些备选方案、拒绝了什么。这段“备选与拒绝清单”正是后续 Phase E 嫁接时判断“什么是值得移植的好主意”的输入。容错规则如果某个候选未能产出结果就以 N-1 继续并在合成记录synthesis record中注明该 dropout。Phase CCross-judge —— 独立于候选的只读裁判等 Phase B 的全部候选完成后再从~/.cursor/rules/pstack-models.mdc的arena cross-judge pool中选一个模型作为裁判没有配置时默认从claude-fable-5-1-thinking-max、gpt-5.6-sol-max、grok-4.6-fast-xhigh、claude-opus-5-thinking-xhigh中选择。关键约束优先选择与父 agent 不同模型家族的模型——模型多样性是本工作流的核心理念不同模型有不同的盲区只生成一个只读裁判子 agent它看到 rubric 和按路径标注的候选逐条打分并推荐一个基座及理由裁判与父 agent 在 Phase D 的阅读并行进行但不与候选写作并行——候选还在写的时候绝不能启动裁判。Phase DPick —— 先读完全部候选再选择选择基座的前提是把每个候选从头到尾读完。随后逐条对照 rubric 打分而不是凭整体感觉holistic feel与 cross-judge 的结果对照一致则确认选择不一致则意味着“你们之中有一方有偏见或 rubric 本身含糊”此时必须先读双方的 rationale 再作决定。选择标准未来的维护者在哪个候选上最容易扩展而不会破坏不变量就选哪个。当两个候选感觉不相上下时偏好更干净的边界或更小的 API——这正对应 principle-laziness-protocol 技能 的“最小改动解决最大问题”取向少即是多减少层与抽象删除优于添加。选择结果必须记录在基座 artifact 旁边写一份简短的合成记录synthesis note包含选择结果、理由以及 cross-judge 的裁决。Phase EGraft —— 手工嫁接绝不机械粘贴对每个落选候选再走一遍识别其中值得移植进基座的部分。信号通常是每个候选只有一两处值得移植而不是大部分内容。嫁接要手工逐项折叠依据 principle-redesign-from-first-principles 技能不要机械粘贴而要“把新需求当作第一天就存在的基础假设来重新设计”读完所有受影响文件、问自己“如果从零写起会怎么建”、并把改动传播到每个引用。嫁接后的结果必须在同一个心智模型下保持自洽。记录内容嫁接了什么、来自哪个候选、拒绝了什么、为什么拒绝。两种特殊情形收敛信号当 N 个候选收敛到同一形状时这是强烈的共识信号——在记录中注明收敛并直接采用共识形状无需嫁接发散信号当 N 个候选严重发散时说明 Phase A 的 brief 规格不足此时应该重新构图并重跑而不是对发散结果取平均。Phase FVerify —— 合成产物必须经受同等检验合成的产物要承受与其他任何输出相同的检验依据 principle-prove-it-works 技能验证真实产物本身运行功能、读取实际值、检查 diff而不是代理指标、自我汇报或“它能编译”。该 principle 给出了四步验证路径构建必要但不充分→ 运行并走真实功能路径 → 检查全链路数据流 → 集成场景做端到端通信测试并强调“脚本化检查”是最强的证明——可重跑的确定性脚本比一次性肉眼检查更强。如果验证暴露了 arena 未捕获的问题只有两种可能二者都是回溯而非掩盖Phase A 错了 → 重新构图并重跑某个候选其实抓住了这个问题但你嫁接时漏掉了 → 回到 Phase E。禁止“paper over”纸面掩盖。Outputs两份交付物arena 的最终交付物固定为两件一件合成的 artifact一份紧随其旁的简短合成记录写明基座是谁、嫁接了什么含来源候选、拒绝了什么、有无 dropout以及验证结果。这份记录让整个合成过程可审计、可追溯——评审者不必相信任何人的口头汇报。在 pstack 工作流中的实际调用方式直接调用在 Cursor 中直接输入见 README/arena take my prompt to the arena verbatim. i want to compare their proposals with yours.按任务重要程度调整候选数示例来自设计指南/arena this, 5 candidates. the cache key format is expensive to change later.经 /architect 间接触发/architect会先跑/how摸清代码、必要时跑/why理清归属与分层然后自动调用/arena产出竞争性设计草图每个草图都先写调用方用法再写类型、签名与模块图见 architect 技能。经 /poteto-mode 自动化触发pstack/skills/poteto-mode/playbooks/feature.md 规定当实现存在多个合理形态错误处理方式、抽象层、测试结构时代码委托必须走arena技能让选手们把备选方案摆上台面、由 cross-judge 把关选择——而不是用“跳过并附理由”的方式绕过。设计指南给出的选用阶梯也印证了这一点跨函数边界或移动所有权的改动由/architect触发自带/arena独立决策命名、格式、算法适合直接/arena。什么时候该用、什么时候不该用arena 不是所有改动的默认选项。设计指南给出了简洁的阶梯小的、已完成但你不确定的改动/interrogate单独足够跨函数边界或移动所有权的改动/architect自带/arena独立决策命名、格式、算法值得独立尝试直接/arena覆盖矩阵、并行检查、声明了臂的竞速/swarm难以逆转的争议设计/architect上线前再/interrogate。/poteto-mode已内置该阶梯跨边界的工作会自动触发/architect因此只有在想要比默认更多或更少审查时才需要直接调用这些技能。小结arena的核心思想可以压缩为一句话用并发换形状多样性用 rubric 换打分客观性用跨模型裁判换判断独立性用手工嫁接换结果自洽性用合成记录换过程可审计性。它与 pstack 的 principle 技能体系分离共享状态、第一性原理重构、证明它有效、懒惰协议环环相扣任何一环缺失都会退化为“几个模型各写一版然后拍脑袋挑一个”的伪并行。按照本文的六阶段协议执行你可以把一个“昂贵的、难以事后修改”的决策从一次押注变成一次受控的搜索过程。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考