昨天刷掘金热榜，看到一篇「用Claude Code搭了4个AI的团队协作开发」，热度直接冲到1300+。评论区炸了，都在问：这玩意儿真能用？其他模型行不行？
作为一个搞了半年 AI Agent 开发的独立开发者，我手痒了。
与其看别人吹，不如自己跑一遍。 我拿了同一道实际开发任务，丢给 5 个主流大模型，看看谁能真正"写出能跑的代码"。
测试任务：不是刷题，是真实需求
我没用那种 LeetCode 算法题来测——那玩意儿模型都刷烂了，测不出真实水平。
我的测试任务是一个真实业务场景：
写一个 Node.js 中间件，实现 API 请求的速率限制（Rate Limiter），要求：
- 滑动窗口算法（不是简单的固定窗口）
- 支持按 IP 和按 API Key 两种维度限流
- Redis 存储（分布式场景）
- 超限后返回标准的 429 + Retry-After 头
- 包含单元测试
这个需求不算特别难，但足够考验模型的工程化能力——不是能写算法就行，得考虑错误处理、边界情况、代码组织。
参赛选手 🏁
| 模型 | 厂商 | 定位 |
|---|---|---|
| Claude Opus 4.6 | Anthropic | 当前最强编码 |
| GPT-5.1 | OpenAI | 最新旗舰 |
| Minimax M2.5 | MiniMax | 国产新锐 |
| DeepSeek V3.2 | DeepSeek | 开源之光 |
| GLM-5 | 智谱 | 国产全能 |
为了公平，我用的都是同一个 API 格式调用，提示词完全相同，temperature 都设 0。
调用代码长这样：
import openai
client = openai.OpenAI(
api_key="your-key",
base_url="https://api.ofox.ai/v1" # 聚合API，一个key调所有模型
)
response = client.chat.completions.create(
model="anthropic/claude-opus-4.6", # 换模型只改这一行
messages=[{"role": "user", "content": prompt}],
temperature=0
)
对，没看错，换模型只需要改 model 参数，base_url 和 key 都不用动。我用的是 ofox.ai，国内直连不用梯子，而且所有模型都走 OpenAI 格式，代码只用写一套。之前想同时测 5 个模型得注册 5 家 API 配 5 套 SDK，光环境就折腾一下午 😭
测试结果：有人惊艳，有人翻车
🥇 Claude Opus 4.6 — 工程化天花板
不愧是热榜那篇文章用的模型。Opus 一次生成了完整的项目结构：
├── src/
│ ├── rateLimiter.js # 核心中间件
│ ├── slidingWindow.js # 滑动窗口算法
│ └── redisStore.js # Redis 存储层
├── tests/
│ ├── rateLimiter.test.js # 中间件测试
│ └── slidingWindow.test.js # 算法测试
└── package.json
亮点：
- 自动把算法和存储层解耦了，不是一坨全塞在一个文件里
- Redis 连接失败有优雅降级（fallback 到内存限流）
- 测试覆盖了分布式竞争条件（race condition）
- Retry-After 计算精确到毫秒
能直接跑，0 报错。 我 review 了一遍，说实话比我自己写的还规范... 😤
🥈 GPT-5.1 — 稳，但保守
GPT-5.1 给的方案也能跑，代码质量中上。但有个明显特点：太保守了。
- 没有做 Redis 降级，连接失败直接 throw
- 所有逻辑塞在一个文件里，300 行的大单体
- 测试只覆盖了正常路径，没测边界
感觉像一个经验丰富但赶 deadline 的程序员写的——能用，但 code review 的时候你会提一堆 comment 🤣
🥉 Minimax M2.5 — 有惊喜
热榜另一篇说 Minimax 对标 Opus 4.6，我带着怀疑测的。
结果它直接给了 TypeScript 版本（虽然我没要求），代码结构清晰，还加了详细的 JSDoc 注释。滑动窗口用的 Redis Sorted Set，时间复杂度比 Opus 的方案还优。
但也有问题：
- 测试文件 2 个语法错误（少了 await）
- Redis Key 没设 TTL，跑久了内存泄漏
思路在靠近头部模型，但工程化细节差距还是明显的。
第4名：DeepSeek V3.2 — 得催
DeepSeek 的问题不是写不好，是你得催它。第一轮只给核心算法，没测试，没错误处理。追问了 3 轮才拿到完整代码。
代码本身质量还行，但在 Agent 协作场景这是致命的——你总不能让 AI 团队里有个成员每次都得催三遍才干活吧 😅
第5名：GLM-5 — 有想法，跑不起来
GLM-5 最有"创意"——考虑了限流规则的动态配置（从 Redis 读取阈值），这个设计思路我是没想到的。
但：跑不起来。
用了一个不存在的 npm 包名，滑动窗口时间戳有 off-by-one 错误。修了两处之后才能跑。
数据汇总
| 模型 | 一次通过 | 代码分层 | 测试覆盖 | 工程化 | 综合 |
|---|---|---|---|---|---|
| Claude Opus 4.6 | ✅ | ✅ | 全面 | ⭐⭐⭐⭐⭐ | 95 |
| GPT-5.1 | ✅ | ❌ | 基础 | ⭐⭐⭐⭐ | 82 |
| Minimax M2.5 | ❌(2个bug) | ✅ | 中等 | ⭐⭐⭐⭐ | 78 |
| DeepSeek V3.2 | ❌(需追问) | ✅ | 基础 | ⭐⭐⭐ | 70 |
| GLM-5 | ❌(跑不起来) | ✅ | 有但报错 | ⭐⭐⭐ | 62 |
几个感悟
1. "能写代码"和"能工程化"是两回事
5 个模型都会写滑动窗口算法，但真正考虑了错误处理、代码分层、测试覆盖的只有 Opus。这也解释了热榜那篇为什么用 Claude Code 搭 AI 团队——你需要的不是会写代码的 AI，是会做工程的 AI。
2. 国产模型进步真的快
Minimax 用 Sorted Set 实现滑动窗口的思路让我眼前一亮，核心算法甚至比 GPT-5.1 更优。GLM-5 考虑动态配置也是加分项。差的主要是细节打磨。
3. 搞 Agent 开发，统一 API 是刚需
这次如果挨个注册 5 家 API、配 5 套 SDK，光环境就得折腾一天。用聚合 API 的好处是换 model 参数就切模型，5 个模型用同一套代码测，省了大量时间。
Claude和GPT选哪个？我的建议是别选，都用。不同任务不同模型，这才是 AI Agent 时代的正确姿势。
4. 为什么 AI 团队需要"一次通过"
看完测试结果再回头看热榜那篇——在 Agent 协作场景，一次通过率直接决定团队效率。如果每个 AI 成员的产出都需要人工 debug，那"AI 团队"和"AI 拖油瓶"就没区别了。
你在搞 AI Agent 开发吗？用的什么大模型API？评论区聊聊 👇
本文测试基于 2026年2月各模型最新版本，更新很快，结论仅供参考。
