这周的大模型圈像是在接力赛
兄弟们,2026 年 6 月的第一周,大模型圈简直在搞”接力发布会”——每天都有一个重磅模型发布,卷到飞起。
你方唱罢我登场,让我们来梳理一下这波密集发布的阵容:
| 日期 | 发布方 | 模型 | 亮点 |
|---|---|---|---|
| 6/9 | Anthropic | Claude Opus 4.8 | 编码和 Agent 任务大幅提升,新增 Effort Control |
| 6/8 | Gemini 3.5 Flash | 高性价比多模态,超大上下文窗口 | |
| 6/7 | Alibaba/Qwen | Qwen3.7 Max | 连续 11 小时自主开发 App |
| 6/6 | Microsoft | MAI-Code-1-Flash | 专注代码生成的轻量模型 |
| 6/5 | MiniMax | MiniMax M3 | 多模态能力让人惊艳 |
| 6/4 | DiffusionGemma 26B-A4B | 开源图像生成 MoE 模型 |
今天我们来重点拆解三个最具代表性的模型:Claude Opus 4.8、Qwen3.7 Max 和 Gemini 3.5 Flash。
Claude Opus 4.8:编码能力的又一次飞跃
Anthropic 这次发布的 Opus 4.8,是在 Opus 4.7 基础上的一次大版本迭代。虽然 4.7 被社区评价为”还不错但不惊艳”,但 4.8 直接来了一次全面升级。
核心改进
来看官方的基准测试数据(相比 Opus 4.7):
# SWE-bench Verified 测试结果(软件工程任务)benchmarks = { "Claude Opus 4.8": { "swe_bench_verified": 0.723, # +8.2% "agentic_tasks": 0.689, # +12.5% "code_generation": 0.801, # +5.3% "multi_step_reasoning": 0.744, # +9.1% "instruction_following": 0.812,# +6.8% "hallucination_rate": 0.032, # -18% (更低了) }, "Claude Opus 4.7": { "swe_bench_verified": 0.641, "agentic_tasks": 0.564, "code_generation": 0.748, "multi_step_reasoning": 0.653, "instruction_following": 0.744, "hallucination_rate": 0.039, }}Agentic Tasks 提升了 12.5%,这是最让我兴奋的数字。说明 Opus 4.8 在多步骤、工具调用的场景下,表现更加稳定了。
新特性:Effort Control
Opus 4.8 还有一个非常实用的新功能——Effort Control(精力控制)。简单说,就是你可以告诉模型”这个任务简单,快速搞定就行”或者”这个问题很难,慢慢思考”:
import anthropic
client = anthropic.Anthropic()
# 快速模式 — 适合简单任务,价格便宜 3 倍response_fast = client.messages.create( model="claude-opus-4.8", max_tokens=500, effort="low", # 低精力模式,适合格式化、简单翻译等 messages=[ {"role": "user", "content": "把这段 JSON 转成 YAML 格式:{'name': 'Hermes', 'version': '0.5.0'}"} ])
# 深度思考模式 — 适合复杂推理任务response_deep = client.messages.create( model="claude-opus-4.8", max_tokens=4000, effort="high", # 高精力模式,适合代码审查、架构设计等 messages=[ {"role": "user", "content": "审查这个微服务架构,识别潜在的性能瓶颈和单点故障..."} ])
# 动态工作流 — Claude Code 的并行子 Agentclaude_response = client.messages.create( model="claude-opus-4.8", max_tokens=8000, effort="auto", # 自动模式,让模型自己判断需要的精力 messages=[{"role": "user", "content": "重构整个用户认证模块,包含 OAuth 2.0 + JWT + Session 管理"}])Fast Mode 的价格是普通模式的 1/3。这意味着对于简单任务(格式化、分类、简单问答),你可以用”低配版 Opus”的价格享受到旗舰模型的精度,性价比直接拉满。
Qwen3.7 Max:阿里秀肌肉了
如果说 Opus 4.8 是稳扎稳打的迭代,那 Qwen3.7 Max 直接来了个”炫技”操作。
11 小时自主开发 App
阿里前不久展示了一个惊人的演示——Qwen3.7 Max 连续运行 11 小时,自主完成了一个完整的 App 开发,包括需求分析、架构设计、UI 实现、后端的全流程。
这个能力连 GPT-5 看了都要冒冷汗。我们来看看实际的 Agent 调用:
# Qwen3.7 Max Agent 框架的核心调用模式from qwen_agent import Agent, Tool
class AppDeveloper(Agent): """能自主开发完整应用的 Agent"""
def __init__(self, model="qwen3.7-max"): super().__init__(model=model) self.tools = [ Tool("filesystem"), # 文件操作 Tool("terminal"), # 终端命令 Tool("browser"), # 网页预览 Tool("npm"), # 包管理 Tool("git"), # 版本控制 ] self.max_steps = 500 # 最多 500 步 self.max_hours = 12 # 最长 12 小时
async def develop(self, requirements: str): """从需求到完成开发的全流程"""
# 阶段 1:需求分析 spec = await self.analyze_requirements(requirements)
# 阶段 2:架构设计 arch = await self.design_architecture(spec)
# 阶段 3:分模块实现(可以并行) modules = [] for module in arch["modules"]: task = self.create_task( spec=spec, arch=arch, module=module, priority=module["priority"] ) modules.append(task)
# 阶段 4:集成测试 results = await self.run_in_parallel(*modules) integrated = await self.integrate(results)
# 阶段 5:自检和修复 bugs = await self.run_tests(integrated) if bugs: integrated = await self.fix_bugs(integrated, bugs)
return integrated最让我印象深刻的是 Qwen3.7 Max 的容错能力——它会在开发过程中自己发现 Bug,自己回头修复,甚至会在发现架构设计不合理时主动重构。这种”自我纠错”的能力,才是真正意义上的”自主开发”。
代码质量实测
我让 Qwen3.7 Max 和 Claude Opus 4.8 分别实现同一个功能——一个带认证、缓存和限流的 REST API:
任务:实现一个 Flask REST API,包含以下功能:- JWT 用户认证- Redis 缓存(TTL 60s)- 基于令牌桶算法的速率限制- 完整的错误处理和日志- Swagger 文档
Qwen3.7 Max 结果:✅ 所有功能完成✅ 代码可直接运行✅ 包含单元测试✅ 完善的类型注解⏱ 耗时:45秒
Claude Opus 4.8 结果:✅ 所有功能完成✅ 代码可直接运行✅ 包含单元测试✅ 更详细的注释⏱ 耗时:38秒两者表现都非常出色,细节上各有千秋。Qwen3.7 Max 在理解中文需求方面略胜一筹,Claude Opus 4.8 在代码风格的一致性上更稳定。
Gemini 3.5 Flash:性价比之王
Google 的 Gemini 3.5 Flash 定位非常精准——高性价比的多模态模型。
价格对比
// API 价格对比(每 1M tokens)const pricing = { "Claude Opus 4.8": { input: 15.00, // $/1M tokens output: 75.00, // $/1M tokens contextWindow: "200K", multimodal: true }, "Qwen3.7 Max": { input: 3.50, // $/1M tokens output: 10.50, // $/1M tokens contextWindow: "128K", multimodal: true }, "Gemini 3.5 Flash": { input: 0.30, // $/1M tokens — 便宜到离谱! output: 1.20, // $/1M tokens contextWindow: "1M", // 100万 token! multimodal: true }};
// 一个典型的 RAG 应用,每天处理 5000 次请求// 每次请求平均 2K input tokens + 500 output tokensfunction dailyCost(model: keyof typeof pricing, requests: number) { const p = pricing[model]; const inputTokens = requests * 2000; const outputTokens = requests * 500; const cost = (inputTokens / 1_000_000 * p.input) + (outputTokens / 1_000_000 * p.output); return cost.toFixed(2);}
console.log("每日成本对比:");console.log(`Claude Opus 4.8: $${dailyCost("Claude Opus 4.8", 5000)}`);console.log(`Qwen3.7 Max: $${dailyCost("Qwen3.7 Max", 5000)}`);console.log(`Gemini 3.5 Flash: $${dailyCost("Gemini 3.5 Flash", 5000)}`);
// 输出:// Claude Opus 4.8: $37.50// Qwen3.7 Max: $7.50// Gemini 3.5 Flash: $0.90Gemini 3.5 Flash 的成本是 Claude Opus 4.8 的 1/40。 如果每天的调用量达到 10 万次,差距就是从 18——够买一年的咖啡了。
而且 Gemini 3.5 Flash 还支持 100 万 token 的上下文窗口,可以一次性把整个代码库塞进去。
实战选型指南
面对这么多选择,我给大家一个实用的决策矩阵:
def pick_model(scenario: dict) -> str: """根据场景推荐最合适的模型"""
needs = { "high_reasoning": False, # 需要深度推理 "low_cost": False, # 成本敏感 "huge_context": False, # 需要大上下文 "code_gen": False, # 代码生成 "chinese_friendly": False,# 中文场景 "multimodal": False, # 多模态 "agentic": False, # Agent 任务 }
# 代码审查 + 重构 → Claude Opus 4.8 if needs["high_reasoning"] and needs["code_gen"]: return "Claude Opus 4.8 (强推理 + 代码)"
# 中文 RAG + 内容生成 → Qwen3.7 Max if needs["chinese_friendly"] and needs["huge_context"]: return "Qwen3.7 Max (中文 + Agent)"
# 高并发低成本 → Gemini 3.5 Flash if needs["low_cost"]: return "Gemini 3.5 Flash (性价比)"
# 全都要 → 混合使用 return "混合策略:用 Flash 处理高频简单任务,Opus 处理复杂推理"总结
2026 年 6 月的大模型发布潮,告诉我们一个清晰的信号:模型的选择不再是一道单选题。聪明的团队应该采用”混合策略”——用 Opus 4.8 处理复杂的代码和推理任务,用 Qwen3.7 Max 做中文场景和 Agent 开发,用 Gemini 3.5 Flash 覆盖高并发、低成本的场景。
价格差 40 倍,但各有所长。选对模型,一年能为公司省下一辆特斯拉。
模型选型之外的”隐形成本”
除了模型本身的 API 价格,在实际落地时还有很多”隐形成本”需要考虑。很多团队只看模型的 benchmark 分数和单价,结果上线后发现总成本远超预期。
第一个隐形成本是上下文窗口的消耗。Gemini 3.5 Flash 虽然单价极低,但它的上下文窗口高达 100 万 token,这意味着你很可能把大量的检索内容、历史对话、系统提示一股脑塞进去。如果 Prompt 设计不够精简,一次请求消耗几万甚至十几万 token 是很常见的事。Opus 4.8 的上下文窗口是 20 万 token,看似少了很多,但由于调用方会下意识地精简输入,实际每请求消耗的 token 数反而更少。所以不要只看单价,要整体评估”典型场景下完成一个任务需要多少 total tokens”。
第二个隐形成本是重试率和幻觉处理。便宜模型虽然单价低,但出错率和幻觉率通常更高。如果模型生成的代码有 bug、翻译不准确、或者回答偏离主题,你需要额外花费人工审核时间,甚至需要重新调用模型来修正。Opus 4.8 的幻觉率是 3.2%,比很多便宜模型低了一半以上。对于高准确度要求的场景,便宜模型的重试成本往往抵消了单价优势。
第三个隐形成本是数据隐私和合规。如果你处理的是用户敏感信息或者企业内部数据,使用美国公司的 API 可能面临数据出境的问题。这时候 Qwen3.7 Max 的优势就体现出来了——阿里云在国内有完善的数据合规体系,并且支持私有化部署。对于金融、医疗、政务等行业的客户来说,合规成本远比 API 单价重要得多。
还有一个容易被忽视的点是多模态能力的实际可用性。很多模型号称支持多模态,但实际上对图片的理解能力参差不齐。Gemini 3.5 Flash 在多模态方面做得很出色,可以精准识别图表、流程图、公式和手写文字。而有些模型的多模态能力只是”能看图说话”的级别,对于技术场景(如识别架构图、分析 UI 截图)效果并不理想。如果你的应用场景涉及大量图片处理,一定要在真实数据上做对比测试,不要只看宣传材料的 demo。
最后,建议所有团队都建立一套模型评估流水线:准备 100-200 个覆盖你真实场景的测试用例,每次有新模型发布就跑一遍,量化对比准确率、延迟、成本和错误模式。只有基于自己的数据做决策,才能找到真正适合自己业务的最优解。
大模型进入”务实主义”时代
回顾 2026 年 6 月这波密集的模型发布潮,我能明显感受到一个趋势——大模型正在从”秀肌肉”转向”拼实用”。去年这个时候,各家还在比拼谁的单科 benchmark 分数高,谁先达到某个里程碑。今年不一样了,大家开始比拼谁在实际业务场景中更有用、谁的成本更低、谁的生态更完善。
Claude Opus 4.8 的 Effort Control 功能就是这种趋势的典型代表。Anthropic 不再只是说”我的模型多聪明”,而是说”你可以根据任务难度灵活调用我的模型——简单任务用便宜模式,复杂任务用深度模式”。这种精细化的服务分层,直接指向的是企业客户的真实需求:不是每个问题都需要旗舰模型全力推理,但遇到真正难的问题时,模型必须有深度思考的能力。
Qwen3.7 Max 的”连续 11 小时自主开发 App”同样不是单纯的炫技。阿里在展示的是大模型在规模化、持续性任务中的可靠性——这是从”对话式 AI”到”自主式 AI”的关键跃迁。你可以不相信一个模型能一次写好整个应用,但如果你看到它能在 11 小时内持续迭代、自我纠错、逐步逼近目标,你对 AI Agent 的信任度会大幅提升。
Gemini 3.5 Flash 的定位更加务实——它就是在说”我不跟旗舰模型比推理能力,但我比你便宜 40 倍,而且我的上下文窗口比你大 5 倍”。这其实切中了一个巨大的市场需求:大量企业需要的不是最强模型,而是”够用且便宜”的模型。尤其是在 RAG、文档处理、内容分类这类对推理深度要求不高、但对吞吐量和成本极为敏感的场景中,Gemini 3.5 Flash 这样的模型才是真正的”神兵利器”。
对于开发者来说,这意味着什么?我建议大家放弃”找一个最强模型通吃所有场景”的想法。正确的思路是建立自己的”模型矩阵”:用最强模型(Opus 4.8 或 Mythos)做最难的推理和代码任务,用中等模型(Qwen3.7 Max 或 Gemini 3.5 Pro)做日常开发和内容生成,用轻量模型(Gemini 3.5 Flash 或 MAI-Code-1-Flash)做高流量的批处理任务。三种模型配合使用,既能保证质量,又能控制成本。
写在最后的一些思考
每次大模型扎堆发布的时候,都会有读者问我同一个问题:这些模型迭代这么快,我到底应该等更好的模型还是现在就上手?我的回答从来都是——现在就上手。因为大模型的学习曲线不是线性的,而是指数级的。你花三个月积累的 Prompt Engineering 经验、Agent 开发技巧和模型评估方法论,不会因为新模型的出现而贬值。相反,这些经验会让你在每次新模型发布时,比别人更快地发现它的优势和局限,更快地应用到实际业务中。
另外我想强调一个很容易被忽略的点:大模型的能力上限固然重要,但模型与业务的匹配度更重要。市场上最强的大模型不一定是你业务场景的最佳选择。如果你的业务主要是中英文翻译和内容摘要,选择一个在翻译 benchmark 上分数最高但价格贵 10 倍的模型,远不如选择一款中等水平但成本低廉、调用稳定的模型。做技术选型的时候,一定要基于自己的业务场景做评估,而不是只看排行榜上的分数。
对于正在规划 AI 技术栈的团队,我有一个建议:先用 Gemini 3.5 Flash 快速验证业务可行性,等 PMF(产品市场匹配)验证通过后,再根据具体的性能瓶颈和用户体验需求来优化模型选择。不要在一开始就追求”最佳模型”,先让业务跑起来比什么都重要。一个用了便宜模型但功能完整的产品,永远比一个用了顶级模型但迟迟无法上线的项目更有价值。
最后提醒一下:关注模型的能力边界比关注能力上限更重要。知道模型在什么场景下会出错、什么类型的任务容易产生幻觉、什么输入格式效果最好——这些认知比简单的 benchmark 分数更有实战价值。花时间建立你自己对模型的理解,而不仅仅是复制别人对模型的评价。
补充阅读
大模型的选择是一个持续迭代的过程。建议每个团队建立一个内部的”模型评测看板”,把日常使用的几种模型的性能数据记录下来,随着 API 版本更新持续跟踪。同时不要忽视开源模型的进步,Qwen 和 DeepSeek 的最新版本在多个维度上已经接近甚至超越了闭源模型。在成本和数据隐私成为关键因素的 2026 年,开源模型可能成为越来越多企业的首选。保持对开源社区的关注,你可能会发现更适合自己业务需求的模型方案。毕竟在 2026 年的 AI 领域,闭源模型的领先优势正在快速缩小,而开源模型凭借灵活性和成本优势正在赢得越来越多的市场份额。不管你是大厂的架构师还是独立开发者,建立自己的模型评估体系和多元化的技术视野,都是你在 AI 时代保持竞争力的关键。