一、脑洞的由来
前阵子跟同事吃饭，他说现在靠各家的免费额度做代码审查，能省则省。
我听了不以为然——薅羊毛不是问题，问题是审完了谁说了算。
Agent 审出一份报告很容易，几分钟的事。但两份报告冲突了怎么办？A 说"这里有 bug"，B 说"没问题"，你听谁的？
我当时也没答案。直到冒出一个念头：
让几个 Agent 互相对质，谁能拿出证据说服对方，谁就是对的那方。
跟"打架打到一方服了"是同一个道理——不是看谁嗓门大，是看谁有道理。说服了，说明赢的一方确实拿出了证据。
这个念头我当时觉得"想多了"。直到这次实战，才发现真的能缓解 LLM 幻觉。
二、单 LLM 为什么不行
这半年我大量用 AI 帮我校对和改后端代码，有几个 bug 是单 LLM 审代码漏看的，印象很深：
- Token 硬编码在源码里 —— Claude Code 第一次审代码漏报了，workbuddy 审出来了
- 7 个 GORM Model 的软删变硬删 —— workbuddy 的报告里只列了 4 个，真实代码里是 7 个，Claude Code 翻代码验证时才补齐
- 3 个 Goroutine 共享 bool 变量无锁 —— Claude Code 没看到，workbuddy 一眼看穿
但换一组代码，结论又不一样。这次实验里，workbuddy 出了 14 个 bug，qoder 出了 8 个——两家找到的集合并不重合。workbuddy 漏掉的部分，qoder 可能找到了；qoder 漏报较多的部分，workbuddy 反而看得更细。
三个工具，同一份代码，结果各不相同。没有谁是绝对可靠的，这正是需要"互喷辩论"的原因。
问题在哪？
LLM 写代码有"幻觉"，找 bug 也有同样的毛病。 一个 LLM 看一份几万行的代码，注意力是有限的——看完前面忘了后面，看到局部忘了整体。它给出来的审查报告，本质上是"它当时想到了什么"，不是"代码里真有什么"。
所以问题不是"用哪个 LLM"，是怎么让多个 LLM 互相制衡。
三、工具选型：免费方案里活下来 2 家
理想方案是 Claude 官方的 Agent SDK——进程内双 Agent 实例，轻量，上下文快照方便。但它必须开通 Claude Pro/Max 付费订阅，免费账号不支持。更悲剧的是想掏钱都不给用。
只能转国产免费工具。我对比了 3 家：
| 工具 | 模型 | 结果 | 备注 |
|---|---|---|---|
| workbuddy | auto（DeepSeek V4 Pro / GLM5 / Kimi 2.7） | ✅ 跑通 | 282 积分/次，每天送 150 |
| qoder | qwen3.7-max | ✅ 跑通 | 19 积分/次，每天送 200，相当大方 |
| zcode | glm-5.2 / glm5-turbo | ❌ 失败 | 把当天 glm-5.2 额度用完也没分析完；换 turbo 上下文不够，压缩也失败 |
zcode 第一个出局。本轮就 2 个工具活下来：workbuddy（auto）和 qoder（qwen3.7-max）。
四、核心方法论：让 AI 互喷，不是让 AI 投票
这个想法听起来朴素，但要工程化必须解决 3 个问题：
- 怎么让 LLM 真的"对比方案"——不能只是把多份报告堆在一起
- 怎么逼"一方说服另一方"——不是"投票"，必须有反驳/论证机制
- 怎么挑出"赢的一方"——人类是最终裁决者，不是 LLM 自己挑
最终我定下来的流程，核心设计有三点：
设计点 1：Claude Code 不是"整合"，是"分别辩论 + 共同认同"
最容易踩的坑是让 Claude Code 当"裁判"——把 workbuddy 和 qoder 的报告合并一下，挑哪个对哪个错。
真实做法是"分别辩论"：Claude Code 跟 workbuddy 一对一逐条辩论，每条 bug 都要拿到证据（代码位置 + 反例），拿不出证据就反驳掉；再跟 qoder 一对一逐条辩论，形成另一份共识。只有两家 + Claude Code 三方共同认同的 bug，才进最终报告。
设计点 2：Claude Code 必须翻真实代码，不能"想"
我不让自己整合，因为我得读 Go 源码验证每条 bug 的真实性。
这一关 Claude Code（配合 minimax-m3）比 workbuddy/qoder 都强——它能直接 grep 后端代码，验证"这个 bug 是不是真的"、"修复方案可不可行"。workbuddy 和 qoder 只能"想"，Claude Code 能"翻"。
设计点 3：二次复核，逼出"反驳"
最怕的流程是：辩论完直接定稿，没有"事后诸葛亮"环节。
必须把 fix-plan 回传给 workbuddy 和 qoder，让它们带着辩论时的记忆，再看一次最终结论。这一步是整个流程里ROI 最高的 5 分钟。
完整流程图
workbuddy 出报告 ─┐ ├─→ Claude Code 复盘（读 backend 真实代码，跟各家分别辩论） qoder 出报告 ────┘ ↓ 共同认同的结论 ┌───── fix-plan（每家一份） ─────┐ ↓ ↓ workbuddy 二次复核 qoder 二次复核 ↓ ↓ └─────→ Claude Code 出最终整改报告 ↓ 总结后生成文档，让 AI 分析，确定解决方案正确性 ↓ 用户拿整改报告，开新窗口实施代码
五、实战记录：三轮迭代的完整产出
不喜欢写"按 P0/P1/P2 排序"的静态数据表。按时间顺序看每一轮出了什么，你就知道"互喷说服"这套方法到底在每个阶段起了什么作用。
第一轮：2 个工具出报告
| 工具 | 用时 | 产出 | 状态 |
|---|---|---|---|
| workbuddy | 几分钟 | 14 个 bug 报告 | ✅ 跑通 |
| qoder | 几分钟 | 8 个 bug 报告 | ✅ 跑通（漏报较多） |
第一轮的产物：2 份原始报告，合计 22 个 bug（去重后）。
这一轮"互喷"还没发生——2 个工具是独立的，各自出报告，谁也不服谁。
第二轮：Claude Code 跟 2 家分别辩论 + 翻代码
workbuddy 和 qoder 给的报告，Claude Code 不盲信。它做了这几件事：
- 把 22 个 bug 拆给 4 个 agent 并行处理
- 每个 agent 亲自去 backend/ 真实代码里 grep + Read
- 跟 workbuddy 一对一逐条辩论：每条 bug 都要拿到证据，拿不出就反驳
- 跟 qoder 一对一逐条辩论：同样标准
- 两家 + Claude Code 三方共同认同的 bug 才进 fix-plan
结果：
| 判定 | 数量 | 含义 |
|---|---|---|
| ✅ 三方共同认同 | 18 | 真 bug，需要修 |
| 🟡 部分认同 | 5 | 部分对，部分需要纠正 |
| ❌ Claude Code 反驳 | 3 | 报告误读源码，不修 |
最精彩的一幕：workbuddy 报告里的 7 个 GORM Model 软删变硬删问题，只列了 4 个。Claude Code 翻代码时从真实代码里补齐到 7 个。workbuddy 一开始坚持"只看到 4 个"，Claude Code 把 7 段真实代码贴过去，workbuddy 才服。
这就是"辩论"的价值——不是简单相信 report，是真去翻代码 + 用证据说服对方。
注意：Claude Code 这一轮用了约 1 小时（还没到辩论的下一阶段，只是在读报告 + 翻代码验证）。中间还跑崩过一次——输入 prompt 太大，上下文窗口装不下。我没继续硬磕，而是让 Claude Code 把踩坑教训总结成了一个 skill（external-audit-fix），以后直接复用。
第三轮：workbuddy + qoder 二次复核 fix-plan
这才是"互喷"的事后诸葛亮环节。两份 fix-plan 被回传给 workbuddy 和 qoder，让它们带着辩论时的记忆，再看一次最终结论。
workbuddy 的复核：14 项完全同意，3 项有补充，其中 2 项真有价值：
atomic.Value替代RWMutex（读多写少场景更优）- HMAC 中间件前必加
MaxBytesReader(1MB)（防 OOM 攻击）
qoder 的复核：8/8 全部一致，0 实质补充（但补了一个 GORM v2 Save 行为描述修正）。
这一轮是整个流程的"金矿"——没有 workbuddy 的复核，Claude Code 自己在辩论时也看不出那 2 项。
最终实施：19 分钟跑完 7 个 PR
整改报告：external-audits/20260619/rectification-report.md（9 节 600+ 行，按 PR-1~PR-7 排序，每项含 diff / 验证 / 回滚 / 风险预案）
| 指标 | 数值 |
|---|---|
| Commit 数 | 7 |
| 改动文件 | 34 |
| 新增行 | +947 |
| 删除行 | -175 |
| 编译 | 后端 15s + 前端 5s，均通过 |
| 测试 | 9 个 timeout race test + 全部 backend 单测通过 |
六、复盘：这次实验最值得记住的事
1. 省时间的工具和花时间的工具，缺一不可
workbuddy 几分钟出报告，qoder 几分钟出报告，Claude Code 复盘 1 小时。
表面上 Claude Code 慢得离谱。但没有 Claude Code 去翻真实代码 + 校对，workbuddy 和 qoder 的报告就只是"看起来对"。
Claude Code 慢，但它把 18 个 confirmed、5 个 partial、3 个 refuted 给钉死了。workbuddy 报告里漏列的 3 个 Model，就是 Claude Code 翻代码时补齐的。
2. 互喷机制 = "让 A 反驳 B 的整合结果"
整个流程的灵魂不是"多 LLM 出报告"，是**"Claude Code 跟各家分别辩论，共同认同才定稿"**。
"用证据说服对方"的瞬间，才是 LLM 协作真正的金矿。workbuddy 二次复核时挑出的 2 项补充（atomic.Value 替代 RWMutex、HMAC 必须加 MaxBytesReader），如果不让 workbuddy 复核，Claude Code 自己在辩论时也看不出。
LLM 之间的"辩论 + 复核"是这次实验真正的金矿。
3. 经验必须沉淀成工具
跑完后，Claude Code 顺带给自己总结了几条踩坑教训：
- 单 agent 任务输入 token 不要超过 8k
- stall 一次就改 prompt，不要傻等
- findings 字段要精简，别塞 200 字段进上下文
- 方案 agent 一个看一组，别塞全量 findings
我看完眼睛一亮——这不就是多 LLM 协作最该记住的踩坑教训吗？
索性以这 4 条为核心，加上整套方法论，生成了一个 Claude Code skill——external-audit-fix。下次再做这种多 LLM 对比，直接说"用 external-audit-fix 跑"，整套流程自动跑，不用每次都重头踩坑。
"代码能复用，经验也得能复用"——LLM 协作流程尤其需要 skill 化。
写在最后
整个实验做完，最大的感慨是：
LLM 协作不是"让多个 AI 投票"，而是"让它们互喷，用证据说服对方"。
单 LLM 永远有盲区。但让多个 LLM 互喷 + 用证据说服对方，反而能逼出"哪条 bug 是真的"、"哪条方案更好"。
同事那句"薅羊毛做代码审查"点醒了我——薅羊毛没问题，但得有个"辩论 + 共同认同"机制。互喷 + 说服，就是给 LLM 协作加裁判的最低成本方案。
人类的角色是最后的整合者 + 实施者，不是被 LLM 替代的"工具人"。
如果你也在用 LLM 做代码审查，建议试试这套流程：2 家出报告 + Claude Code 复盘辩论 + 二次复核。最大的成本不是 token，是第一次跑会 stall 得很惨——但写进 skill 后，第二次就会更流畅和高效。
