devils-advocate

Devil's Advocate Protocol

预先承诺的对抗式推理，旨在防止过早定论并暴露盲点。

何时应用

在以下情况下启用此协议：

• 在不同架构方案之间做选择
• 选择库、框架或工具
• 规划实现策略
• 在多个方案中推荐一个
• 用户询问“我应该……吗？”“……的最佳方式是什么？”“应该选哪种方案？”
• 在 architect、Plan 或 blueprint 工作流中
• 做出答案并不显而易见的权衡决策

何时跳过

以下情况下不要应用：

• 执行已决定的实现
• 只有一条显而易见的路径（没有真正的替代方案）
• 用户已明确选择方案（“使用 X 来完成 Y”）
• 任务属于机械性或流程性工作，而非决策
• 影响微乎其微的琐碎选择

协议

步骤 1：明确要做的决定

在推荐方案之前，明确说明：

• 正在做什么决定
• 你倾向于采用什么方案
• 你为何倾向于它

步骤 2：以最有力的论据为反方辩护

提出反对你倾向方案的最有力论据：

• 可能会出什么问题？
• 你做了哪些可能并不成立的假设？
• 聪明的批评者会怎么说？
• 机会成本是什么？
• 在什么情况下，这个方案会失败？

要求：

• 切实地提出反对意见，不要流于形式
• 针对你论点最有力的版本进行反驳
• 至少指出一个不易察觉的失败模式

步骤 3：辩护或转向

完成对抗性审视后：

• 解释为何尽管存在反对意见，该方案仍可能是正确的
• 哪些条件使它成为合适的选择？
• 要满足什么条件，替代方案才会胜出？
• 或者：承认这些反对意见改变了你的建议

步骤 4：校准信心后给出结论

最终建议应包括：

• 明确的建议及其理由
• 必须成立的关键假设
• 哪些情况会使这一选择失效
• 需要关注的监测信号

输出格式

## Decision: [What's being decided]

### Initial Inclination
[Approach] because [reasons]

### Adversarial Challenge
**Against this approach:**
- [Strong objection 1]
- [Strong objection 2]
- [Non-obvious failure mode]

**What I might be wrong about:**
- [Assumption that could be false]

### Resolution
[Why it's still correct OR why I'm changing recommendation]

### Recommendation: [Final choice]
- **Key assumptions:** [What must be true]
- **Watch for:** [Signals this was wrong]

与其他工具的关系

• reasoning-verifier：对已完成推理进行事后验证——包含一个迭代关卡，会反复运行，直至不再存在严重或重大缺漏（最多 3 轮）
• devils-advocate：在推理定型之前进行预先承诺挑战
• 两者结合使用：规划时使用 devils-advocate，执行后使用 reasoning-verifier
• 如需逐步建立信心：先运行一次 devils-advocate，再将输出交给 reasoning-verifier，通过循环弥补缺漏

基本原则

LLM 会过早确定答案，再倒推理由。本协议通过在解决方案定型之前强制探索各种可能性，打断这一模式。