用Claude写代码、让Codex补全、找Gemini查资料——这套 workflow 我用了很久，但有个 bug 一直没修：某个模型给出一个看起来很稳的答案，我照做了，上线后才发现漏想了一层边界情况。
问题不在模型够不够强。问题在于我只问了一个模型。
后来我开始把同一个问题丢给两个模型，各自独立回答，再对比它们的结论。奇怪的是，决策质量确实提升了——不是因为某个模型更聪明，而是它们的分歧本身就有信息价值。
但手动操作太折磨了：复制问题、粘贴上下文、等两份长回答、在脑子里做 diff、再把其中一份贴回去追问、继续等。状态好的时候能走完一轮，多数时候直接跳过。
所以我做了 WhaleCouncil，一个把这套流程自动化的 CLI 工具。
核心机制分三轮。第一轮，两个模型各自独立作答，互相看不到对方的回答——这很关键，如果模型 B 先读了 A 的答案，会产生锚定效应，最后变成礼貌性附和，而非独立判断。
第二轮，双方看到彼此的初稿，被要求回应：你是否改变立场？还有哪些分歧？为什么？
第三轮由一个裁判模型（默认用你本地已有的 Claude）做结构化解构：共识点在哪、真正的分歧点在哪、什么事实能终结争议、下一步该做什么。
作者举了个具体例子：问"session 存储该用 Redis 还是 Postgres"。
第一轮，两个 Claude 实例都默认选 Redis，理由也类似——高频访问、短 TTL、原生 EXPIRE 比 Postgres 的定时清理任务更可靠。但细看有微妙差异：一个建议"先用 Postgres 表简化部署，必要时再迁"，另一个明确反对这种"为了省组件而硬塞 Postgres"的做法。同样的技术事实，优先级判断相反。
更隐蔽的分歧在 Postgres 方案的设计细节：一个推荐分区表加定期删旧分区，另一个推荐 UNLOGGED TABLE——但 UNLOGGED 在崩溃时会丢数据，这和他们"选 Postgres 是为了持久性"的共同前提直接矛盾。
第二轮的修正很有意思。推荐 UNLOGGED TABLE 的那个实例主动认错："看到对方回答后，我更新立场——UNLOGGED TABLE 会丢掉崩溃耐久性，这 undermine 了选 Postgres 的全部理由。"另一个则软化了"默认 Redis"的绝对语气，补充了一个前置问题："你已经在跑 Redis 了吗？如果没有，专门为 session 引入它可能是过早优化。"
最终裁判模型的总结：双方共识是"如果技术栈里已有 Redis，session 存 Redis 是合理默认"；共同修正了 UNLOGGED TABLE 的失误；遗留分歧是 greenfield 场景下的默认选择——这个需要结合团队运维能力和现有组件情况 case by case 判断。
这个工具的设计假设挺值得玩味：单个模型的置信度输出是噪声，两个独立信号的交叉比对才能暴露盲区。不是追求"更正确的答案"，而是把不确定性显式化——你知道哪里还有争议，哪里已经被双方共同证伪。
作者没说的是，这套机制对什么类型的问题最有效。从例子推测，架构选型、技术权衡类问题可能收益最大——这类问题没有唯一正解，但不同方案的隐性 trade-off 容易被单一视角掩盖。而事实检索类问题，比如"Python 3.12 什么时候发布"，双人辩论的价值就有限。
另一个没展开的问题是成本。两轮 Claude 调用加一轮裁判，是 3 倍 token 消耗。作者显然觉得这笔开销值得，但规模化使用时的预算控制策略，工具本身似乎没有内置。
WhaleCouncil 目前以 CLI 形态存在，面向的显然是每天和模型打交道的开发者。它的产品逻辑很清晰：把"多模型交叉验证"从意志力消耗型任务，变成可一键执行的流程。这个定位本身也说明了一件事——AI 辅助工作的下一个优化方向，可能不是更强的单点模型，而是更好的模型协作机制。
热门跟贴