cross-critique

交叉评审

使用此技能在多个子代理就同一有争议问题独立提出提案或意见后，进行第二轮讨论。你不是自己综合他们的报告，而是将每个提案分发给其他作者，请他们进行评审——列出优缺点——然后你综合由此产生的更丰富的分析。

为什么这很重要

当你生成独立提案（不同模型、不同角度）时，每个作者对问题都有深入的背景——通常比你更深入，因为他们做了调查。如果你直接综合他们的报告，你就成了瓶颈：你只能看到你恰好注意到的权衡。

让作者们互相评审，就像一个优秀的领导者在寻求建议时所做的那样：让几个不同视角的人聚在一起，让他们互相质疑对方的推理，你就能得到一个比任何一个人——或你自己——单独得出的更完整的图景。作者们会揭示出失败模式、隐藏假设和权衡，这些连你或原始提案者都没有注意到。

何时使用

当决策存在争议时使用交叉评审——即独立代理产生了真正不同的提案，或者问题足够主观，合理的做法存在分歧。适合的场景：

• 架构和设计权衡。
• 代码审查中审查者得出不同结论。
• 针对 bug 的相互竞争的根因理论。
• 没有唯一正确答案的代码结构或 API 形状决策。

当提案已经高度一致，或者问题有可以直接验证的客观答案时，不必使用——评审会增加延迟和 token，其价值在于解决真正的分歧。在这个范围内，可以自由使用；不需要高风险的理由，只要有值得解决的实际分歧即可。

前提：首先需要独立提案

此技能是第二轮。它假设你已经有了 N 个独立提案。如果还没有：

• 对于判断密集型决策，使用 council 技能生成（模型多样化的子代理针对同一问题）。
• 对于调查密集型问题，通过生成并行子代理来生成（参见 research 技能）。
• 或者使用你已经收集的任何临时独立子代理提案。

关键是，第一轮必须是独立的——不要让作者在第一轮看到彼此的工作，否则你会失去使第二轮有价值的多样性。

如何操作

1. 收集提案

收集每个作者的提案。保持简洁——核心建议及其理由，而不是完整记录。考虑中性标记（提案 A、B、C），并在可行时匿名作者身份，以减少对听起来最自信的模型的跟风偏见。

2. 分发并要求结构化评审

重用第一轮的相同子代理，而不是生成新的——他们保留上下文，可以从理解的角度进行评审。将其他提案（不是他们自己的）发送给每个作者，并要求每个作者提供：

• 对于每个替代方案：其优点（它做对了什么，在哪些方面比我的方法更强）和缺点（风险、边缘情况、隐藏成本、错误假设）。
• 在看过替代方案后，他们是否会修改自己的建议——以及为什么或为什么不。
• 带有置信度的最终排名或建议。

坚持对每个替代方案同时列出优缺点。一个诚实的评审，承认对手的优势，远比对自己提案的防御性辩护更有用。

3. 综合

现在你自己整合起来。根据证据质量，而非投票数量比较评审。在你的最终答案中：

• 以建议开头。
• 指出作者们在看到彼此工作后在哪里达成一致——第二轮中的趋同是一个强烈信号。
• 揭示针对每个选项提出的最尖锐的缺点。
• 解释为什么推荐的选项在决策标准下最能经受住评审。
• 指出剩余的分歧、置信度和重要的未知因素。

最终答案模板

除非任务要求不同，否则使用此格式：

## 建议
[一两句话说明决策。]

## 评审如何改变了局面
- [作者们在看到替代方案后在哪里达成一致或改变想法]
- [提出的最强烈反对意见，以及它是否具有决定性]

## 为什么这个选项胜出
- [基于评审的理由]

## 剩余风险和未知因素
- [未解决的问题或注意事项]

实用说明

• 保持评审轮次为只读，除非底层任务明确涉及做出更改。
• 除非用户要求，否则不要在面向用户的摘要中暴露内部子代理 ID。
• 如果评审内容单薄或缺乏支持，向同一作者发送有针对性的后续问题，而不是丢弃它。