> ## Documentation Index
> Fetch the complete documentation index at: https://api.xcompute.us/llms.txt
> Use this file to discover all available pages before exploring further.
# 大模型使用与评估：闭源模型篇
> 从推理、Coding、多模态、长上下文、创意写作和服务稳定性角度整理主流闭源模型体验。
闭源模型市场存在一种循环：厂商每隔一段时间发布新旗舰，并宣称在某个基准或任务上达到 SOTA。SOTA 是 State of the Art 的缩写，表示特定任务当前公开的最高水平，但最新、最大或榜单最高的模型不一定最适合实际业务。
本文体验截至 **2026 年 1 月 4 日**，并于 **2026 年 5 月 11 日**补充更新。内容包含主观判断，请结合模型版本、渠道质量、系统提示词和自己的业务评估集判断。
了解 DeepSeek、Qwen、GLM、Kimi、MiniMax、MiMo、Gemma 等开源系列。
## 主流厂商
| 公司或机构 | 模型系列 | 主要优势 |
| --------- | ------ | ----------------------- |
| OpenAI | GPT | 精确执行、推理、后端与复杂逻辑 |
| Google | Gemini | 多模态、世界知识、创意与前端 |
| Anthropic | Claude | 工程规划、Coding Agent、综合稳定性 |
| xAI | Grok | 大参数、创意表达、实时信息与宽松风格 |
| 阿里巴巴 | Qwen | 指令遵循、模型矩阵、国内企业接入 |
| 字节跳动 | Doubao | 多模态产品、国内可用性、C 端体验 |
## 评估闭源模型时看什么
闭源模型无法检查权重、训练数据和完整架构，因此评估更依赖可观测行为：
| 维度 | 观察重点 |
| ----- | ---------------------- |
| 任务完成度 | 是否真正解决问题，而不是只生成看似合理的答案 |
| 指令遵循 | 是否服从范围、格式和实现方案约束 |
| 工程能力 | 是否理解代码边界、测试方式和回滚风险 |
| 注意力 | 长上下文中是否遗漏关键约束或修改无关文件 |
| 多模态 | 图片、视频、OCR、GUI 定位和跨模态推理 |
| 输出效率 | 完成同一任务使用的输出 Token 和总耗时 |
| 服务质量 | 延迟、断流、限流、降级和高峰期稳定性 |
| 总成本 | API 价格、缓存、重试、人工返工和故障成本 |
## OpenAI GPT：冷静、简洁、执行明确
进入 GPT-5 世代后，GPT 系列明显减少解释性文字。优点是输出 Token 更少、完成速度更可控，也更接近“按要求执行”的工程工具；缺点是聊天和创意写作中的情绪表达较弱，描述性文字有时过于简略。
GPT 更像偏后端和复杂逻辑的工程师：擅长定位明确问题、修改 Bug、处理约束较多的任务。面对新项目或需要探索方案的任务，通用 GPT 往往比 Codex 特化版本更愿意展开分析；Codex 则更强调按已有计划精确实施。
### GPT-5.2 世代
| 模型 | 模型 ID | 上下文 | 最大输出 | 体验备注 |
| ----------------- | --------------------- | ---: | ---: | --------------------- |
| GPT-5.2 Thinking | `gpt-5.2` | 400K | 128K | 支持调节 reasoning，适合高难推理 |
| GPT-5.2 Pro | `gpt-5.2-pro` | 400K | 128K | 强调企业级准确性和高推理强度 |
| GPT-5.2 Chat | `gpt-5.2-chat-latest` | 128K | 16K | 延迟较低，复杂任务能力相对有限 |
| GPT-5.2 Base | `gpt-5.2` | 400K | 128K | 通用旗舰，默认中等推理强度 |
| GPT-5.2-Codex | `gpt-5.2-codex` | 400K | 128K | 代理式编码，支持视觉和上下文压缩 |
| GPT-5.1-Codex-Max | `gpt-5.1-codex-max` | 400K | 128K | 面向长时间、项目级编码任务 |
### 2026 年 5 月更新
当前主力进入 GPT-5.4 和 GPT-5.5，推理速度有所提高，表达也比 GPT-5 初期自然。编程领域中，GPT 与 Claude 的优势并不相同：
* GPT 更擅长解决边界清晰的特定问题，并遵循调用方给定的实施计划。
* Claude 更擅长先建立工程方案，再持续推进跨文件任务。
* 修复明确 Bug、后端逻辑和复杂约束时，可以优先测试 GPT。
* 新建大型模块或需要模型主导规划时，应同时测试 GPT 通用版和 Claude。
Codex 不是所有编码任务的默认最优解。任务范围不清晰、需要广泛探索时，通用 GPT 可能比 Codex 变体更有效。
**主要风险**：指定旗舰模型时推理仍可能较慢；网页端自动路由可能发生能力降级；创意表达和前端审美不是稳定优势。
## Google Gemini：多模态与世界知识
Gemini 依托 Google 的数据、DeepMind 研究和 TPU 基础设施，在多模态、世界知识和推理速度上长期具有特色。它更像知识面广、表达细腻的综合创作者，适合创意写作、视觉理解和前端原型。
Gemini 3 Pro 在多模态和前端生成上表现突出；Gemini 3 Flash 则以更低延迟覆盖大量日常任务，部分 Coding 和 Agent 场景的实际体验甚至可能优于 Pro。
### 主要型号
| 模型 | 模型 ID | 上下文 | 最大输出 | 体验备注 |
| --------------------- | ----------------------- | --: | ---: | ----------------------- |
| Gemini 3 Pro | `gemini-3-pro` | 1M | 64K | 多模态、前端和深度推理强，长上下文稳定性需验证 |
| Gemini 3 Flash | `gemini-3-flash` | 1M | 64K | 速度快，适合 Agent 和常规开发任务 |
| Gemini 2.5 Pro | `gemini-2.5-pro` | 2M | 64K | 长文本和世界知识突出，实际召回需实测 |
| Gemini 2.5 Flash | `gemini-2.5-flash` | 1M | 64K | 高吞吐均衡版本 |
| Gemini 2.5 Flash-Lite | `gemini-2.5-flash-lite` | 1M | 64K | 低延迟、低成本的大上下文模型 |
### 2026 年 5 月更新
更新后的主力包括 `gemini-3.1-pro-preview`、`gemini-3-flash-preview` 和 `gemini-3.1-flash-lite`。这一阶段的主要体验是：硬推理、视觉能力和世界知识仍然很强，但幻觉、注意力漂移和长上下文退化变得更值得警惕。
**适合场景**：图片和文档理解、创意写作、前端原型、知识型问答、低延迟多模态 Agent。
**主要风险**：大型代码仓库中可能扩大修改范围、遗漏工程约束或错误改动文件。不要因为标称 1M 或 2M 上下文，就假设模型能稳定利用全部内容。
## Anthropic Claude：均衡的 Coding Agent
Claude 从早期强调自然表达和创意写作，逐步发展为重视长上下文、STEM 和 Coding Agent 的模型系列。它的核心优势是工程规划：能先理解项目结构、拆分任务，再跨文件推进实现。
Claude 4.5 在前后端综合开发中较均衡，特别适合让模型承担较多规划工作的 Vibe Coding。它并不总在公开榜单中领先，但工程体验、工具使用和方案完整性长期具有竞争力。
### Claude 4.5 世代
| 模型 | 模型 ID | 上下文 | 最大输出 | 体验备注 |
| ----------------- | ---------------------------- | --------: | ---: | ----------------------- |
| Claude 4.5 Opus | `claude-4-5-opus-20251124` | 200K | 64K | 支持 effort，适合高难编码与科研任务 |
| Claude 4.5 Sonnet | `claude-4-5-sonnet-20250929` | 200K / 1M | 64K | 面向复杂 Agent 和项目级代码 |
| Claude 4.5 Haiku | `claude-4-5-haiku-20251014` | 200K | 64K | 低延迟版本，需要与同价位 Flash 模型比较 |
1M 上下文通常取决于官方产品、订阅和渠道，第三方渠道常见限制仍为 200K。接入前应检查实际渠道能力。
### 2026 年 5 月更新
更新时的主要版本包括 Claude Sonnet 4.7、Claude Opus 4.7 和 Claude Mythos。4.7 系列的部分使用反馈集中在表达生硬、注意力漂移和过度坚持自身方案。
这也是 Claude 最大的优点与缺点：工程规划能力强，但可能不完全遵循调用方已经确定的实现路径。
**适合场景**：大型仓库探索、工程规划、跨文件修改、前后端一体化和复杂 Agent。
**主要风险**：服务可用性和渠道稳定性需要单独评估；严格执行既定方案时，应明确禁止扩大范围，并要求先确认计划。
## xAI Grok：大参数、创意与实时信息
Grok 依赖大规模算力和 X 平台数据，在创意表达、实时搜索、网络语境和角色化写作方面具有明显特色。相比标准的“helpful assistant”风格，Grok 的表达更直接，也更接近网络对话。
| 模型 | 模型 ID | 上下文 | 最大输出 | 体验备注 |
| ---------------- | ------------------ | ---: | -----: | -------------------- |
| Grok 4 Heavy | `grok-4-heavy` | 256K | 8K-16K | 多智能体并行推理，推理强度高 |
| Grok 4.1 | `grok-4.1` | 256K | 16K | 强调低幻觉和自然表达，适合创意写作 |
| Grok 4 | `grok-4` | 256K | 8K | 支持多模态推理与实时 X 搜索 |
| Grok 4.1 Fast | `grok-4.1-fast` | 2M | 16K | 超长上下文和低延迟版本 |
| Grok 4 Fast | `grok-4-fast` | 2M | 30K | 可切换推理，适合低延迟任务 |
| Grok Code Fast 1 | `grok-code-fast-1` | 256K | 16K | 速度快，常作为低成本 Coding 选项 |
Grok 的内容边界通常比其他商业模型宽松，但业务仍需遵守当地法律、平台规则和内容安全要求。宽松不等于可以忽略合规、隐私和滥用风险。
### 2026 年 5 月更新
Grok 4.3 的实际提升有限，团队和算力策略变化也增加了后续路线的不确定性。选择 Grok 时，不应只看模型规模，还要验证 API 稳定性、产品持续性和具体任务质量。
**适合场景**：创意写作、角色表达、实时信息、X 平台语境和低审查强度的合规任务。
**主要风险**：Coding 综合能力不是稳定领先项；超长上下文标称值不等于有效注意力；内容输出需要业务侧安全策略。
## Qwen 与 Doubao：能力路线和产品路线
阿里和字节代表两种不同路线。Qwen 强调模型矩阵、指令遵循和开发者生态；豆包更强调多模态产品、国内 C 端体验和完整应用入口。
### 闭源 Qwen
Qwen 的优势是指令遵循、型号丰富、国内服务稳定性和企业接入便利。它的不足是部分版本输出风格较模板化，思考模式可能消耗大量 Token，甚至指令模型也可能产生过长推理内容。
| 模型 | 模型 ID | 上下文 | 最大输出 | 体验备注 |
| ----------------- | ------------------- | ---: | ---: | ----------------- |
| Qwen3-Max | `qwen3-max` | 256K | 64K | 闭源旗舰，思考模式输出上限较低 |
| Qwen-Plus | `qwen-plus` | 1M | 32K | 适合复杂任务和长文本 |
| Qwen-Flash | `qwen-flash` | 1M | 32K | 低延迟、高吞吐版本 |
| Qwen3-VL-Plus | `qwen3-vl-plus` | 256K | 32K | 高分辨率视觉与复杂多模态理解 |
| Qwen3-VL-Flash | `qwen3-vl-flash` | 256K | 32K | 高性价比视觉推理 |
| Qwen-Long | `qwen-long` | 10M | 32K | 超长文本模型，有效召回需要业务实测 |
| Qwen3-Coder-Plus | `qwen3-coder-plus` | 1M | 64K | 复杂编码和大上下文工程任务 |
| Qwen3-Coder-Flash | `qwen3-coder-flash` | 1M | 64K | 低延迟代码任务 |
2026 年 5 月的主力更新为 `qwen-3.6-plus` 和 `qwen-3.6-max-preview`，均为闭源多模态模型。Qwen 3.6 Plus 综合表现较均衡，代码能力可用；Max 版本仍应通过真实任务确认其价格是否带来相应收益。
**适合场景**：国内企业应用、结构化输出、复杂指令、视觉理解、需要稳定云服务的 Coding 与 Agent。
### Doubao
豆包底层模型的开源程度较低，但产品、搜索、多模态和国内 C 端体验较完整。对于普通用户，它通常比单纯 API 更容易上手；对于开发者，则需要结合火山引擎、Coze 和具体多模态能力判断。
| 模型 | 模型 ID | 上下文 | 最大输出 | 体验备注 |
| ------------------ | --------------------------------- | ---: | ---: | ------------- |
| Doubao Seed 1.8 | `doubao-seed-1-8-251215` | 256K | 32K | 深度思考、多模态与工具调用 |
| Doubao Seed Code | `doubao-seed-code-preview-251028` | 256K | 32K | 编码特化并支持多模态理解 |
| Doubao Seed Lite | `doubao-seed-1-6-lite-251015` | 256K | 32K | 效率和推理能力均衡 |
| Doubao Seed Flash | `doubao-seed-1-6-flash-250828` | 256K | 32K | 高频多模态与视觉定位 |
| Doubao Seed Vision | `doubao-seed-1-6-vision-250815` | 256K | 32K | GUI 与复杂视觉理解 |
2026 年 5 月的最新版本包括 `doubao-seed-2.0-pro` 和 `doubao-seed-2.0-lite-260428`，均为闭源多模态模型。Seed 2.0 已具备较强综合能力，但事实幻觉仍需要业务侧校验。
关于未正式公开模型能力的传闻只能作为观察线索，不能作为采购或上线依据。应以正式模型文档、可调用版本和自己的盲测结果为准。
**适合场景**：国内多模态应用、GUI 理解、内容产品、搜索和依赖字节生态的平台集成。
## 场景化选择
| 场景 | 建议优先测试 | 原因 |
| --------------- | --------------------------------- | ------------------------------ |
| 后端与复杂逻辑 | GPT、Claude | 精确执行与工程规划互补 |
| 大型 Coding Agent | Claude、GPT | Claude 规划强，GPT 约束执行强 |
| 前端原型与视觉创作 | Gemini、Claude | Gemini 审美和多模态突出，Claude 工程完整性更好 |
| 创意写作 | Gemini、Grok | 世界知识、语言风格和情绪表达更自然 |
| 国内企业应用 | Qwen、Doubao | 国内服务、合规、生态和接入便利 |
| 低延迟批量任务 | Gemini Flash、Qwen Flash、Grok Fast | 高吞吐和较低延迟 |
| 超长上下文 | Gemini、Qwen Long、Grok Fast | 标称窗口大，但必须测试有效召回 |
| 高风险事实任务 | 至少双模型交叉验证 | 所有闭源模型都会产生幻觉 |
## 实际评估方法
从真实代码、工单、研究问题和内容任务中建立评估集。每个场景至少包含正常案例、边界案例和历史失败案例。
隐藏模型名称，让评审只看输出和任务结果，减少品牌与榜单带来的预期偏差。
记录 Token、延迟、重试、断流和人工修复时间。便宜但需要频繁返工的模型可能更贵。
检查模型在系统提示词、用户要求、工具返回和仓库规则冲突时是否遵守正确优先级。
Preview、latest 和自动路由模型可能静默更新。生产系统应定期重跑关键评估集。
## 总结
闭源模型的优势不断循环：GPT 在精确执行和复杂逻辑上领先，Claude 提供成熟的工程规划，Gemini 强调多模态和世界知识，Grok 依靠大参数与独特表达，Qwen 提供国内企业需要的模型矩阵，豆包则把多模态能力做进完整产品。
不要把“最新旗舰”直接等同于“最适合”。有效的模型选择应落在具体任务、渠道稳定性、可接受成本和可验证结果上。