不是"哪个模型更强"，而是"它们漏的东西不一样"。
我想搞清楚一件事
在多模型协作中，副驾驶到底是在帮忙还是在添乱？回答这个问题不能靠直觉。
我设计了三组对照实验：同一段代码，两组审查——Claude 独立一次，Claude+Qwen 协同一次。比较结果，看 Qwen 是否能稳定贡献 Claude 遗漏的东西，同时控制噪音。
实验设计
测试用例：三个不同复杂度级别的 Python 头像上传服务。代码由我自己编写，在写的时候刻意植入了我知道的 bug，涵盖了安全、并发、数据一致性、运维四个维度。
这一点需要坦白：测试用例不是从真实生产环境取样的，而是我构造的。这意味着 bug 的分布可能带有我的个人偏见。不过实验的核心问题——"两个模型的发现是否互补"——并不依赖测试用例的来源，因为实验对比的是两组审查之间的差异，而非代码本身的好坏。
两个审查通道：
| 通道 | 方式 |
|---|---|
| Claude Solo | 我独立阅读代码，列出全部发现 |
| Claude + Qwen | 我先独立分析，然后通过 ask_qwen.py -M review 调用 Qwen（qwen3.6-plus），它的回复并入我的分析，标记哪些是它独自发现的 |
控制变量：
- 两次审查使用完全相同的代码
- Qwen 使用
-M review模式（压缩输出：按严重度分段，≤200 词） - Qwen 的系统提示词定向到特定角色（SRE 视角 / 安全工程师视角）
测试用例
V1：基础版（90 行）
一个最简的 Flask 上传接口——没有中间件、没有数据库、没有异步任务。Flask dev server 兜底。
V2：生产版（220 行）
加入了 SQLAlchemy、auth 中间件、健康检查、连接池配置。模拟了一个称职工程师写的服务。
V3：复杂生产版（223 行）
在 V2 基础上进一步加入 Celery 异步任务队列、Redis 缓存层、Prometheus metrics、存储配额管理。看起来像一个真实的生产服务。
完整代码见 GitHub。
结果
| V1 (基础) | V2 (生产) | V3 (复杂生产) | |
|---|---|---|---|
| Claude Solo 发现 | 4 | 7 | 12 |
| Qwen 额外发现 | +3 | +2 | +2 |
| 协作总发现 | 7 | 9 | 14 |
| 提升幅度 | +75% | +29% | +17% |
| Qwen 噪音（无价值输出） | 0 | 0 | 0 |
Qwen 漏掉了什么 Claude 抓到的：
在 V3 中，Claude 发现了 query_avatar_from_db 是一个返回 None 的桩函数——这意味着 Redis 是唯一的数据存储，一旦重启，所有头像元数据永久丢失。这是整个实验中最致命的 bug，但 Qwen 完全没提。Qwen 的注意力集中在安全漏洞和网络层交互上（路径穿越、CDN 速率限制、polyglot 文件攻击），而 Claude 的注意力涵盖了数据层的设计缺陷。
Claude 漏掉了什么 Qwen 抓到的：
三组实验中，Qwen 持续发现了两类 Claude 容易漏的东西：
- 系统交互的边际效应 — CDN purge 同步阻塞请求路径（V2）、每次上传对用户目录做通配符 purge 导致 CDN 速率限制（V3）
- 安全纵深防御的细节 — magic bytes 校验缺失（V3）、cache-busting 参数缺失（V2）
Qwen 额外发现详览
| 测试 | Qwen 发现 | Claude 为什么漏了 |
|---|---|---|
| V1 | 磁盘无清理逻辑会满 | 注意力在代码正确性上 |
| V1 | compute_hash 二次读文件阻塞 I/O | 同上 |
| V1 | 缺少 DB 更新导致前端不知道新 URL | 注意力在 CDN purge 的单点失败上 |
| V2 | CDN purge 在请求路径中同步阻塞 | 致命漏判——注意力在"purge 有没有执行"而非"purge 在哪里执行" |
| V2 | URL 缺少 cache-busting 参数 | 对 CDN 缓存传播机制不够敏感 |
| V3 | 每次上传对整目录通配符 purge = CDN 自 Dos | 注意力在单个请求的正确性而非全局副作用 |
| V3 | 无 magic bytes 校验 = polyglot 文件可绕过 | 对文件上传安全细节的纵深防御意识不足 |
噪音控制
多模型协作的真实风险不是"副驾驶不够聪明"，而是"副驾驶话太多"。如果每次调用 Qwen 都返回 500 字客套话+免责声明+重复内容，那上下文会被迅速污染。
-M review 压缩模式在三组实验中始终将 Qwen 的输出控制在 150-200 词内，零寒暄、零免责声明、零"希望这对你有帮助"。
这比发现数字更重要——信噪比如果不守住，协作就是负收益。
坦白交代——这个实验的局限
- 测试用例是我自己写的：这不可避免地引入了我的个人偏见。我在写代码时知道的 bug，可能在分析时更容易发现。更严谨的实验应该使用第三方代码（如开源项目中的历史 bug 修复 commit）。
- 不是盲测：我在调用 Qwen 之前已经完成了自己的分析，这会影响我对 Qwen 输出的评价。更严谨的设计应该是先调 Qwen 再看代码，或者请第三方评审。
- 样本量太小：三组测试远不足以得出统计结论。这是一个定性探索，不是定量研究。
- Claude 和我不是同一个实体：我的"独立分析"本质上是人类+Claude 的混合，Qwen 的加入是在这个基础上叠加了一层。这里没有纯净的"A/B 测试"。
尽管如此，数据仍然指向一个清晰的方向
三组实验中，Qwen 每次都能额外贡献 2-3 个 Claude 没发现的问题，同时零噪音。
两个模型的注意力分布有明显的互补特征：
- Claude 的强项：数据一致性、代码逻辑正确性、框架使用方式
- Qwen 的强项：系统间的边际效应、网络安全细节、外部依赖的行为边界
如果你在做复杂系统的代码审查，让另一个模型看一眼是值得的。 它不一定会比你看得更深，但它几乎一定会看到你看不到的角度。
这套工具怎么用
qwen-proxy 提供了基础设施：
- 反代服务 (
server.py)：将 Qwen 内部 API 转译为 OpenAI 兼容协议 - CLI 工具 (
ask_qwen.py)：6 种压缩预设，控制副驾驶输出 - 决策框架 (Skill)：何时该调、何时跳过、如何后处理
# 快速协作
./venv/bin/python ask_qwen.py -M review "$(cat your_code.py)"
不只是 Qwen
这套"主模型 + 压缩副驾驶"的模式可以接入任何兼容 OpenAI API 的后端。你也可以用 Ollama 本地模型、DeepSeek、或者 Gemini。
多模型协作的价值不在于"找一个比主模型更强的模型"，而在于当两个模型足够不同时，它们漏的东西不一样。
2026 年 5 月 · GitHub · MIT
