核心问题
让单一模型规划复杂任务（迁移、重构、切换），你会得到一个流利、自信、但可能完全错误的答案。
昂贵的失败几乎从不是语法错误。它们是读起来很好但错了的计划：错误的抽象、遗漏的爆炸半径、会 brick state 的迁移步骤。你三小时后才发现，不是在审查时。
解决方案：多模型共识
不是更大的模型。让模型故意分歧，然后强迫它们解决。
核心机制
/claude-delegator:consensus 运行：
- GPT（通过 Codex）
- Gemini
- Claude
每个独立评审同一产物。独立性是字面上的：每轮新线程、单次调用、无共享提供商记忆。一个模型走错 tangent 不能拖另外两个下水——分歧保持诚实。
专家角色交叉
五个专家档案：
- Architect
- Plan Reviewer
- Scope Analyst
- Code Reviewer
- Security Analyst
最大信号来自轴交叉：Gemini 上的 Security Analyst + GPT 上的 Architect，比同一模型审两次争论的东西完全不同。
共识循环
- 三方独立评审
- Claude 分类每个反对意见（接受/驳回/延期）
- 修订产物
- 发送新版本出去
- 最多 5 轮，直到三方签字
- 签不了就如实报告未解决分歧，不假装同意
两个配套工具
code-intelligence
语言无关 Skill，解决 Agent 抓文本 grep 时该问语言服务器的问题：
搜索优先级：
- LSP（符号）
- rg/ripgrep（精确文本）
- 嵌入/语义 grep（模糊发现）
- 硬性规则：任何替换必须在回复第一行披露
terraform-skill
接近 2000 GitHub stars。路由 Terraform/OpenTofu 请求到真实故障模式：
- identity churn
- blast radius
- state corruption
Terraform-LS 感知：知道语言服务器没有 rename provider，所以运行安全的手动引用工作流而非盲目 find-replace。
关键设计决策
输入独立性
每轮发送评审者的只有产物文本 + 有限轮次元数据。评审者永远看不到：
- 我的分类
- 我的运行裁决
- 我之前怎么框定问题
我的判断在他们报告后应用，不是烘焙进他们收到的输入。
适用边界
| 场景 | 推荐工具 |
|---|---|
| 快速查找 | ask-gpt / ask-gemini / ask-both（单次） |
| 必须正确 | consensus（多轮） |
越松散模糊的输入，收敛轮次越多。计划收敛最快。
资源
- agent-plugins: https://github.com/antonbabenko/agent-plugins
- claude-delegator: https://github.com/antonbabenko/claude-delegator
- terraform-skill: https://github.com/antonbabenko/terraform-skill
核心 takeaway
停止接受单一模型的第一个自信计划。让它们争论，只在它们停止争论时才行动。
最便宜的审查是执行前发生的审查。