用Claude和GPT-4o（原GPT-5.

单模型 Review 最致命的问题就是“认同偏差”：如果你写了一段逻辑有漏洞但看起来很流畅的代码，模型很容易顺着你的思路点头，最后给个 LGTM（Looks Good To Me），结果 Bug 直接带到生产环境。我最近尝试把 herdr 结合两个不同阵营的顶尖模型搭了一个对抗环境，让它们互相找茬，效果出奇地好。

基本的逻辑是：一个模型负责提交代码或初步审查，另一个模型扮演“恶意审计员”，专门寻找边界 case、内存泄漏或逻辑漏洞。

实操部署方案

这套工作流的核心是利用 herdr 作为中转调度。我配置的链路是：代码 → Claude 3.5 Sonnet (初步审查) → GPT-4o (对抗质疑) → Claude 3.5 Sonnet (最终修正)。

如果你想尝试，可以参考这个简易的配置逻辑（以伪代码形式表示其调度流程）：

pipeline:
  - stage: primary_review
    model: claude-3-5-sonnet
    prompt: "Analyze the following code for functional correctness and efficiency."
  - stage: adversarial_challenge
    model: gpt-4o
    prompt: "You are a cynical senior engineer. Find 3 critical flaws or edge cases in the previous review's conclusion. Do not agree unless the code is mathematically perfect."
  - stage: final_resolution
    model: claude-3-5-sonnet
    prompt: "Compare the original code and the adversarial critique. Fix the bugs and provide the final optimized version."

实测对比：单模型 vs 对抗模式

我拿一个复杂的异步并发处理函数做了测试，涉及到了死锁风险和竞态条件。

• 单模型 Review (Claude 3.5)： 响应时间约 1.8 秒。结论是“代码逻辑清晰，符合规范”，完全没发现潜在的死锁风险。
• 对抗模式 (Claude → GPT-4o → Claude)： 总响应时间拉长到了 5.2 秒。但在第二步中，GPT-4o 直接指出了在极端高并发下，锁的释放顺序会导致死锁。最终 Claude 在第三步给出了修正后的代码。

从结果来看，这种模式的“捕捉率”明显更高，虽然牺牲了响应速度和 Token 成本。

几个关键的坑点

1. 提示词的“攻击性”： 如果给 GPT-4o 的 Prompt 太温和，它依然会倾向于礼貌地同意对方。必须在指令中明确要求它“扮演愤青”或“刻意寻找漏洞”，否则对抗强度不够。
2. 上下文漂移： 当代码行数超过 300 行时，第三步的模型有时会忘记第一步的原始需求，导致修正后的代码虽然没 Bug，但功能跑偏了。建议在 final_resolution 阶段重新喂入原始的需求文档。
3. Token 消耗： 这种模式基本是 3 倍的 Token 消耗。对于小型项目没问题，但如果是整个仓库的 CI/CD 挂载，成本会飙升得很快。

能力维度分析

• Claude 3.5 Sonnet： 逻辑严密，代码风格优雅，适合做最后的整合和代码重构。
• GPT-4o： 发散思维强，对某些边缘场景的敏感度高于 Claude，非常适合扮演那个“挑刺”的人。
• herdr： 解决了多模型切换的工程化问题，不需要自己写复杂的 API 胶水代码。

说实话，现在的 AI Review 还是不能完全信任。但通过这种“左右互搏”的机制，起码能过滤掉 80% 的低级错误，比盯着屏幕干看要高效得多。如果你在做大模型的实战部署，建议把这种对抗机制引入到你的 AI Agent 工作流中。