双 AI 终端交叉验证调试法

你正在排查线上故障或调试代码，向 AI CLI 询问一条堆栈跟踪的解释，它给出了一个自信、具体、听起来靠谱的根因分析。

然而这也正是你得到的唯一意见。

获取第二意见以往意味着在故障时呼叫同事，或者在他们调试过程中打断他们的思路。而现在，它只需要打开第二个终端，向另一个模型询问，让它评价第一个模型给出的答案。

打开两个终端——两个窗口、两个标签页，怎么都行。把不同的 AI CLI 分别跑在每个终端里：Claude Code、Codex CLI、Gemini CLI，任意组合。唯一的要求是两个会话必须相互独立、上下文完全隔离——你在第一个里说的任何内容，第二个都看不到，除非你主动把内容粘贴过去。

（如果你已经用上了 tmux，比起在窗口间 alt-tab 切换，用分屏 panes 会更舒服。一旦你经常这么做了，就值得了解，但不是起步的必备条件。）

容易做错的方式是：向第二个模型问同样的模糊问题。以下是正确做法，按步骤来：

在第一个会话里问一个具体的问题。"这是结账服务的堆栈跟踪，最可能的原因是什么？"——而不是"这东西有什么问题？"把这个答案当作草稿，而不是定论。

把真正的答案粘贴到第二个会话里，而不是转述。"这是另一个模型对这个堆栈跟踪的诊断。缺少什么？或者你在相信它之前会先查什么？"模糊的问题得到泛泛的回应；具体的论断得到具体的批评。

对分歧做判断，而不是取平均。如果两者一致，那是轻微证据，而非证明——相关联的训练数据同样会产生相关联的盲点。如果它们不一致，那恰恰告诉了你，问题或数据中的模糊点在哪里。

这就是整个技巧：两个独立的会话，加上把答案而不是问题粘贴过去的纪律。

用于难题，而非每个问题

对每个问题都交叉质问，会把本来大概率能搞定的修复的双程时间翻倍。用你的判断力来决定何时真正值得：即将上生产的修复值得这么做，语法问题不值得。那条线在前几次并不明显——在它变成习惯而非需要刻意想的规则之前，你会经历过度检查不需要检查的东西，也会漏掉确实需要检查的东西。

我把这作为一条更长的调试路径中的一个步骤来写（仅用终端调试：grep、jq、git，以及是的，还有 tmux，都以此为目标）——如果你想要完整的"何时值得麻烦"拆解：Multiple AI CLIs, One tmux Session / full pathway。

有没有人把它推到超过两个会话，或者同时交叉质问超过两个厂商的 CLI——信号在第二意见之后还能保持吗，还是只是变得嘈杂了？