arena | 同題競賽與方案合成
本頁以 pstack-claude 0.9.126 為基準。arena 讓多個候選處理同一份任務，選出一個基底，再有選擇地合成其他候選的優點。
定位與適用情境
適合一開始選錯形狀就會增加維護成本的產物，例如替通知系統設計重試策略。輸入是相同的投遞需求與現況說明。每個候選都要提出完整方案，而不是一人寫重試、一人寫記錄、一人寫測試。
這是同題競賽，不是 swarm 常見的切片分工。arena 的終點是一個合成產物。swarm 可分配不同覆蓋區域，也可競速，但不必進行「選基底再移植」的設計合成。
準備
- 準備所有候選共用的任務敘述、資料流與行為限制。
- 定義 3 至 6 項可評分規準 (Rubric)，例如重複投遞安全性、錯誤隔離、介面大小與可測性。原文讓候選只看任務，由選擇者與評審使用規準。
- 為每個候選安排獨立輸出位置。寫程式時優先使用 Git 工作樹 (Worktree)，不要共寫同一分支或檔案。
- 確認可用模型與派工工具。模型別名和平台實際支援的名稱不一定相同。
操作步驟
- 界定任務並派出候選。 先列 Frame、Fan out、Cross-judge、Pick、Graft、Verify 階段，再讓候選以相同輸入獨立工作。各自交付產物、考慮過的替代方案及拒絕理由。
- 等候候選完成再交叉評審。 選不同於主代理模型家族的唯讀評審，以候選路徑標籤逐項評分。候選還在寫入時不啟動評審。沒有可用的不同家族時，記錄略過評審。
- 完整讀取並選基底。 主代理讀完每份產物，逐項評分後對照評審意見。若分歧，先讀理由，不以票數取代判斷。接近時偏向較清楚邊界與較小公開介面。
- 移植必要優點。 再讀落選方案，通常只移入少數值得保留的部分。例如選集中式重試排程為基底，但採用另一候選的冪等鍵設計。不要把不同心智模型機械拼接。
- 驗證合成產物。 執行重複投遞與失敗重試的實際檢查。若候選高度收斂，記錄共識即可，不強迫移植。若差異大到無法比較，先重寫任務再競賽。
可直接使用的提示詞
可在 Claude Code 使用 /pstack:arena，或在 Codex 插件選單插入 $pstack:arena。以下文字是可直接貼入的需求，不是跨平台共通的 slash 指令。
用 pstack:arena 比較通知服務重試策略，只產出設計，不改正式程式。
每個候選都處理同一題，讀取 src/notifications/ 與現有投遞測試。
需求是投遞失敗可重試、重複工作不得造成重複通知、單一通道失敗不得阻塞其他通道。
為選擇者建立 3 至 6 項具體規準，候選只取得共同任務。
各候選使用獨立輸出位置，交付介面草圖與替代方案理由。
讀完全部候選後選基底，再說明每個移植點、捨棄理由與驗證方式。
若無跨家族評審或多代理工具，明列缺口，不冒稱已做獨立評審。預期結果與驗收
- 最終只有一套一致的通知重試設計，不是並排的候選摘要。
- 合成說明包含基底、逐項選擇理由、評審結論或略過原因、移植來源、拒絕項目與驗證結果。
- 中途退出的候選有被記錄。缺產物不能被當成支持某方案的票。
- 驗證針對合成後的版本，不是只引用各候選自稱通過的結果。
限制與權限
Claude Code 的原文流程依賴 Agent 與背景派工。Codex 對應為 spawn_agent。未開啟多代理能力時只能標明序列替代，不能把同一代理的多次嘗試說成獨立模型共識。
模型遭拒與執行緒容量不足是不同問題。容量不足不應靠更換模型無限重試。候選退出可繼續比較剩餘產物，但要交代比較範圍縮小。
候選輸出、測試與移植仍受指定目錄及修改權限限制。arena 不授權建立提交、推送、刪除既有產物或部署。