cross-critique

Cross-Critique

使用此技能在數個子代理針對同一爭議問題獨立產出提案或意見後，進行第二輪討論。與其自行綜合他們的報告，不如將每個提案傳遞給其他作者，請他們提出批評——優缺點——然後綜合由此產生的更豐富的分析。

為什麼這很重要

當你產生獨立提案（不同模型、不同角度）時，每個作者對問題都有深入的背景——通常比你更深，因為他們做了調查。如果你直接跳入綜合他們的報告，你就成了瓶頸：你只能看到你碰巧注意到的取捨。

要求作者互相批評，就像一個好的領導者在尋求建議時所做的：讓幾個觀點不同的人聚在一起，讓他們互相挑剔對方的推理，你就能得到比任何一個人——或你自己——單獨產出更完整的圖像。作者們會浮現出你或原始提案者未標記的失敗模式、隱藏假設和取捨。

何時使用

當決策存在爭議時使用 cross-critique——即獨立代理產生了真正分歧的提案，或者問題足夠主觀以至於合理的做法會不同。適合的情況：

• 架構和設計取捨。
• 審查者得出不同結論的程式碼審查。
• 針對錯誤的競爭根本原因理論。
• 沒有單一正確答案的程式碼結構或 API 形狀決策。

當提案已經高度一致，或者問題有可以直接驗證的客觀答案時，不必使用——批評會增加延遲和 token，其價值來自於解決真正的分歧。在該範圍內，請自由使用；你不需要高風險的理由，只需要值得解決的真正分歧。

先決條件：你需要先有獨立提案

此技能是第二輪。它假設你已經有 N 個獨立提案。如果你還沒有：

• 對於判斷密集型決策，使用 council 技能（針對同一問題使用不同模型的子代理）來產生它們。
• 對於調查密集型問題，透過產生並行子代理來產生它們（參見 research 技能）。
• 或者使用你已經收集的任何臨時獨立子代理提案。

關鍵是，第一輪必須是獨立的——不要讓作者在第一輪看到彼此的工作，否則你會失去使第二輪有價值的多樣性。

如何執行

1. 收集提案

收集每位作者的提案。保持簡潔——核心建議及其理由，而不是完整的對話記錄。考慮中立地標記它們（提案 A、B、C），並在可行時匿名化作者身份，以減少對聽起來最自信的模型的從眾偏誤。

2. 傳遞並要求結構化批評

重複使用第一輪的相同子代理，而不是產生新的——他們保留上下文，並且能夠從理解的角度進行批評。將其他提案（不是他們自己的）發送給每位作者，並要求他們提供：

• 對於每個替代方案：其優點（它做對了什麼，在哪裡比我的方法更強）和缺點（風險、邊緣情況、隱藏成本、錯誤假設）。
• 在看了替代方案後，他們是否會修改自己的建議——以及為什麼或為什麼不。
• 最終排名或建議，附帶信心程度。

堅持對每個替代方案同時提出優點和缺點。一個誠實的批評，承認對手的優勢，遠比反射性地捍衛自己的提案更有用。

3. 綜合

現在你自己將它們整合起來。根據證據品質而非票數來比較批評。在你的最終答案中：

• 以建議開頭。
• 指出作者們在看到彼此的工作後在哪裡趨同——第二輪的趨同是一個強烈的信號。
• 浮現針對每個選項提出的最尖銳的缺點。
• 解釋為什麼推薦的選項在決策標準下最能經受批評。
• 指出剩餘的分歧、信心程度和重要的未知因素。

最終答案模板

除非任務要求不同的格式，否則使用此結構：

## 建議
[一兩句說明決策。]

## 批評如何改變了局面
- [作者們在看到替代方案後在哪裡趨同或改變了想法]
- [提出的最強烈反對意見，以及它是否具有決定性]

## 為什麼這個選項勝出
- [基於批評的理由]

## 剩餘風險與未知
- [開放問題或注意事項]

實用提示

• 除非底層任務明確涉及進行更改，否則保持批評輪為唯讀。
• 除非使用者要求，否則不要在面向使用者的摘要中暴露內部子代理 ID。
• 如果批評內容薄弱或缺乏支持，請向同一作者發送有針對性的後續問題，而不是直接丟棄。