cross-critique

交叉评议

在多个子 Agent 已针对同一个有争议的问题分别提出方案或观点后，使用此技能开展第二轮评议。不要自行综合他们的报告，而是将每个方案发给其他作者，请他们评议其优缺点，然后综合由此产生的、更丰富的分析。

为什么这很重要

当你生成独立方案（来自不同模型、不同视角）时，每位作者都会对问题形成深入理解——通常比你更深入，因为他们做了调查。如果你直接独自综合他们的报告，你就会成为瓶颈：你只能看到自己注意到的权衡。

请作者相互评议，是优秀领导者征求意见时的做法：找几位视角各异的人，听他们互相指出对方推理中的漏洞，最终你就能获得比任何一个人（包括你自己）单独分析更完整的认识。作者会发现失败模式、隐藏假设和权衡，而这些都可能被你和最初的提案者忽略。

何时使用

当决策存在争议时，使用交叉评议——也就是说，独立 Agent 提出了真正不同的方案，或问题具有足够主观性，以至于合理的处理方式各不相同。适用场景包括：

• 架构和设计权衡。
• 评审者结论不一的代码审查。
• 对 Bug 的多种根因理论。
• 没有唯一正确答案的代码结构或 API 形态决策。

如果各方案已经高度一致，或问题有客观答案、可以直接验证，就不必使用：评议会增加延迟和 Token 开销，而它的价值恰恰来自解决真正的分歧。在适用范围内，可放心使用；不需要有重大风险作为理由，只要存在值得解决的真实分歧即可。

前提：你需要先有独立方案

此技能属于第二轮。它假定你已经有 N 个独立方案。如果还没有：

• 对于需要大量判断的决策，使用 council 技能生成方案（让不同模型的子 Agent 针对同一个问题分别提出方案）。
• 对于需要大量调查的问题，通过启动并行子 Agent 生成方案（参见 research 技能）。
• 或使用你已经收集到的任意一组临时子 Agent 独立方案。

关键在于，第一轮必须彼此独立——第一轮不要让作者看到彼此的成果，否则就会失去让第二轮评议有价值的多样性。

如何操作

1. 汇总方案

收集每位作者提出的方案。保持简洁，只保留核心建议及其理由，而不是完整记录。可以用中性的标签（如“方案 A”“方案 B”“方案 C”），并在可行时匿名处理作者身份，以减少对听起来最自信的模型产生的从众偏差。

2. 分发方案并要求结构化评议

重新使用第一轮的同一批子 Agent，而不是启动新的子 Agent——他们保留了上下文，可以基于已有理解进行评议。将其他方案（不包括自己的方案）发给每位作者，并要求他们：

• 针对每个替代方案，说明其优点（正确之处、比自己的方案更强之处）和缺点（风险、边界情况、隐藏成本、错误假设）。
• 说明看过替代方案后，是否会修改自己的建议，以及原因。
• 给出最终排序或建议，并说明信心程度。

要求对每个替代方案都同时指出优点和缺点。诚恳地肯定竞争方案的长处，远比本能地为自己的方案辩护更有价值。

3. 综合

现在请自行综合。按证据质量，而不是投票数比较各项批评。在最终答复中：

• 开篇给出建议。
• 指出作者在看到彼此的工作后在哪些方面达成了一致——第二轮达成一致是一个强烈信号。
• 说明针对每个选项提出的最有力反对意见。
• 解释为什么推荐的选项在决策标准下经受住了最多批评。
• 指出仍存在哪些分歧、信心水平如何，以及有哪些重要未知因素。

最终答复模板

除非任务需要采用其他格式，否则请使用以下结构：

## Recommendation
[One or two sentences with the decision.]

## How the critiques shifted things
- [Where authors converged or changed their minds after seeing alternatives]
- [The strongest objection raised, and whether it's decisive]

## Why this option wins
- [Reason grounded in the critiques]

## Remaining risks and unknowns
- [Open question or caveat]

实用说明

• 除非底层任务明确要求进行更改，否则批评环节应保持只读。
• 除非用户提出要求，否则不要在面向用户的摘要中透露内部子 Agent ID。
• 如果某条批评内容单薄或缺乏依据，请向同一位作者提出有针对性的追问，而不是直接弃用。