过去一年大模型领域最让开发者焦虑的一件事不是某个模型又发布了新版本而是“能力飞升”的速度已经快到来不及建立稳定认知。一年前让模型在一个比较长的项目里定位问题、修改代码、生成测试用例还需要反复拆解任务、做大量提示词工程而现在主流模型已经能在百万级上下文里直接阅读仓库内容支持图片、语音、视频等多种输入并且会调用工具完成多步操作。很多团队的工作方式正在从“人指挥模型写单点代码”切换到“人定义目标模型执行工程任务”。本文要讨论的是过去一年里 OpenAI GPT 系列、Google Gemini 系列、Anthropic Claude 系列这三个最具代表性的模型家族在能力上到底发生了哪些实质变化。我更想强调的是这些变化不是简单的“分数更高了”“回答更像人话了”而是上下文、多模态、推理、工具调用、成本效率五个维度同时发生了系统性升级。对普通开发者来说更值得关注的不是“谁排第一”而是如何建立一套适合自己的模型评估与选型流程避免每次版本更新都推倒重来。1. 为什么值得回顾这三大模型在过去一年里全球开发者几乎都在同一个问题上反复纠结到底应该用哪个模型上个月刚接入的模型这个月出了新版本是否值得切换切换之后提示词要不要改、输出格式会不会变、成本会增加多少这些问题的根源在于模型能力在快速变化但很多团队缺少一个“可复用的评估方法”。多数人选择模型的方式仍然停留在“看榜单、刷帖子、自己跑几个案例”这在小规模试错时没问题一旦进入生产环境就会出现效果不稳定、成本失控、模型版本升级后行为漂移等风险。之所以选择 OpenAI GPT 系列、Google Gemini 系列、Anthropic Claude 系列作为观察对象是因为它们代表了三种有明显差异的技术路线GPT 系列更强调通用对话、指令遵循和生态工具链的完整性Gemini 系列从设计之初就强调原生多模态和超长上下文Claude 系列在代码生成、长文本理解和安全对齐上有比较突出的口碑。三家在过去一年里都有密集的版本迭代正好可以作为观察大模型能力演进的最佳样本。通过回顾这几个模型家族的变化我们能看到的不只是“模型变强了”还能看到一个更重要的趋势模型的竞争已经不再局限于单点能力而是演变为上下文、多模态、推理、工具调用、成本效率的综合工程竞争。2. 一年前的锚点当时的模型到底缺什么要理解“飞跃”先得回头看一年前模型的真实状态。以那个节点为参考当时主流模型的能力和今天相比存在几个明显短板。第一上下文窗口虽然已经比早期模型大很多但“长上下文”仍然不是可以放心使用的功能。开发者传入较长文档时模型经常出现遗漏中间信息、记忆早期内容却忘记最近内容的问题。所谓“长上下文”更多是“能接收长文本”而不是“能准确理解长文本”。第二多模态能力普遍停留在“能看懂图片”的层面。模型可以识别图片里的文字和常见物体但对复杂图表、界面截图、PDF 版面这些真实业务场景中的输入识别准确率并不理想。开发者往往需要先把图片转成文字再交给模型处理流程非常别扭。第三逻辑推理是明显的短板。遇到数学题、逻辑题、复杂代码调试时模型容易一本正经地给出错误答案。开发者不得不把任务拆得非常小让模型一步步生成再由人来拼接结果。第四工具调用虽然有雏形但远没有达到稳定可用的程度。插件、函数调用经常出现参数格式错误、选择工具错误、执行多步任务时中断等问题。想要做一个真正自动化的 Agent 应用工程成本非常高。这些短板意味着一年前的“模型替代人工”更多停留在简单任务层面。写个独立函数、生成一段文案、做一次翻译这些场景确实不错但涉及完整业务链路、多轮交互、复杂推理仍然需要大量人工兜底。3. 一年间能力飞跃的核心维度把这一年里三大模型的变化放到一起看能力的提升不是某个单点的刷新而是下面五个维度的同步演进。理解这五个维度比记住某个版本的参数要重要得多。3.1 上下文窗口从“能接收长文本”到“能处理长文本”上下文窗口是这一年变化最直观的维度。半年多前128K 上下文已经被当作“长上下文”来宣传而一年后百万级上下文已经成为头部模型的常见配置。但这里真正值得关注的不是数字变大而是使用模式变了。过去开发者拿到一个大型代码库需要先做检索、切片、摘要再把关键片段喂给模型现在模型可以直接接收整个中型仓库的内容然后在里面定位问题、理解模块关系、生成修改方案。这种变化带来的新问题也很明显上下文越长模型的注意力越分散越可能出现“看到了但没用上”的情况。因此“上下文工程”正在取代“提示词工程”成为新的关键技能。所谓上下文工程就是决定给模型喂什么、不喂什么、按什么顺序喂、如何压缩无关内容让有限的长上下文能力发挥出真正的效果。3.2 多模态从“能看图”到“默认能力”三大模型在一年间都完成了多模态能力的升级。尤其是 Gemini 系列从一开始就把多模态作为底层能力设计GPT 系列和 Claude 系列也陆续补齐了视觉输入支持。这带来的实际变化是模型不再只是“文本生成器”而是可以同时理解文字、图像、音频、视频的统一入口。开发者可以把一张界面设计稿、一段录屏、一份带格式的 PDF 直接交给模型让它完成分析、转换或代码生成。但多模态能力越强越要警惕“输入幻觉”。模型虽然能识别图像内容但对图像中数字的精确读取、对复杂表格的结构理解、对不同语言混合文本的识别仍然会有不稳定表现。生产环境中多模态输入通常需要配合预处理、后校验和人机协同而不能盲目相信模型的“看图”结果。3.3 逻辑推理从“快思考”到“慢思考”一年间最重大的变化之一是推理模型被大规模引入。之前主流的对话模型追求“快速给出答案”面对复杂问题时往往依赖语言模式直接生成结果而推理模型会在给出答案之前先生成内部推理过程尝试多种解法再做最终判断。这种“慢思考”能力对数学、科学问题、复杂代码调试、策略规划等任务有非常明显的提升。GPT 系列的 o 系列逐步铺开Gemini 系列也在推理能力上做了针对优化Claude 系列则在代码相关的推理任务上表现突出。对开发者来说这意味着任务路由变得更重要了。简单的文本处理、翻译、格式转换用快速模型成本更低、响应更快而涉及复杂逻辑、代码重构、多步规划则需要切换到推理模型。一个成熟的应用往往会同时接入两类模型根据任务难度动态路由。3.4 代码生成从“写函数”到“改工程”一年前代码生成的主流用法是“给一个需求让模型写一个函数或一个类”。一年后头部模型已经可以在大型代码仓库中完成更复杂的工程任务定位 bug、理解调用链、修改多个文件、补充测试用例甚至生成提交说明。这个变化的背后是三个能力的叠加更长的上下文输入、更强的指令遵循、更稳定的代码结构生成。不过代码能力提升并不意味着“可以完全相信模型生成的代码”。在实际工程中模型对历史代码风格理解不足、对第三方库版本不熟悉、对编译环境无感知都可能导致生成代码在逻辑上正确但无法直接运行。更合理的用法是让模型基于项目上下文生成“初版方案”再由开发者在编译和测试环境中验证。这里的核心价值不是替代开发者而是把重复性、模板化的编码工作大量压缩。3.5 工具调用与 Agent 化从问答走向执行过去一年工具调用Function Calling / Tool Use逐渐成为大模型的标准能力。模型不再局限于“你说一句我答一句”而是可以在对话过程中自主决定调用哪些外部工具查数据库、请求 API、执行代码、读取文件再根据工具返回结果继续推进任务。这是 Agent 应用能够落地的基础。三大模型在这一年里都在工具调用的稳定性、参数生成准确率、多轮工具调用链路上下足了功夫。早期工具调用经常失败现在主流模型已经能在清晰定义好工具边界的情况下稳定完成“规划-调用-观察-再规划”的执行循环。但这里也有一个容易被忽略的问题模型调用工具越顺畅越容易让人放松对权限和安全的警惕。工具调用能力相当于把模型从“建议者”变成了“执行者”一旦权限控制不严模型可能执行危险操作。因此Agent 化应用对权限隔离、操作审计、人工确认机制的要求比传统应用高得多。4. 能力飞跃对开发者工作流的实际影响模型能力变了开发者的工作方式必然要跟着变。最明显的趋势是从“提示词工程”向“上下文工程”和“任务编排”迁移。以前的提示词工程核心是“怎么把需求描述清楚”。大家研究各种角色设定、few-shot 示例、格式要求目的是让模型输出更符合预期。现在模型的理解能力大幅提升普通的描述已经不太会成为瓶颈真正的难点变成了“怎么把正确的上下文送给模型”代码库太大怎么压缩多轮对话里哪些历史信息要保留不同业务数据如何组织。第二个变化是从“单次问答”走向“多步任务”。以前一个完整体验的流程是开发者写提示词 - 模型返回结果 - 开发者检查 - 再写下一个提示词。现在模型可以自己拆解任务、调用工具、根据中间结果调整计划开发者只需要定义目标、约束和验收条件。但这并不意味着开发者的工作变少了而是工作内容变成了“定义边界”和“处理异常”。第三个变化是模型选型从“选一个最优”变成“建一套路由”。随着快速模型和推理模型分化同一家公司内部也会有多个模型版本不同模型在不同任务上的性价比差异非常大。成熟的团队开始建立自己的模型路由规则比如简单问答、摘要、格式转换 - 快速模型代码审查、复杂调试、数学推理 - 推理模型涉及图片和文档识别 - 多模态模型需要联网查询和业务系统交互 - 工具调用能力强的模型。这套路由规则不是固定的需要结合每个模型版本的能力变化持续调整。这正好引出一个重要问题如何科学地评估模型能力的年度变化而不是凭感觉选型。5. 构建一套可感知的模型能力评测基线如果你所在团队正在接大模型 API或者正在纠结要不要升级到新版本我的建议很直接不要只看官网榜单也不要只问别人“哪个模型好用”而是建立一套自己的评测基线。所谓评测基线就是用一组覆盖你真实业务场景的任务让不同模型在相同输入下跑一遍再按统一标准打分。这套基线不需要特别复杂但必须能回答一个问题新模型上线后到底哪些任务变好了哪些任务变差了。下面给出一套最小可用的评测方案整个过程只包含三个部分评测任务集、评测脚本、评分标准。5.1 第一步准备评测任务集先从实际业务中收集 20 到 50 条任务覆盖你要用的核心能力比如代码生成、日志分析、SQL 编写、文档理解、结构化输出等。每条任务需要包含任务描述模型需要完成的输入期望结果用于人工判断或自动校验的关键检查点难度标签简单、中等、困难方便后续分析。下面是一个 JSON 评测集的示例按“任务”组织{ tasks: [ { id: code-generate-001, type: code_generation, difficulty: medium, prompt: 请为 UserMapper 接口生成一个根据 email 查询用户的方法返回 OptionalUser。数据库字段为 email使用 MyBatis 注解方式。, checkpoints: [ 方法返回类型包含 Optional, SQL 使用了 #{email} 参数占位, 没有使用 SELECT * ] }, { id: sql-rewrite-002, type: sql, difficulty: hard, prompt: 下面这条 SQL 在数据量大时很慢请优化SELECT * FROM orders WHERE user_id ? AND created_at ?, checkpoints: [ 建议添加联合索引, 避免 SELECT *, 考虑分页或范围查询 ] }, { id: json-output-003, type: format, difficulty: easy, prompt: 请把下面这段非结构化文本解析为 JSON包含 name、price、stock 三个字段商品名叫无线鼠标价格 99 元库存还有 15 件。, checkpoints: [ 输出是合法 JSON, 包含 name 字段且值为无线鼠标, price 为数值类型 99, stock 为数值类型 15 ] } ] }任务不需要很多但要有区分度。如果全部是简单任务新老模型差距不明显如果全部是困难任务又很难稳定复现。建议简单、中等、困难各占三分之一。5.2 第二步编写批量评测脚本评测脚本的作用是读取评测集调用不同模型接口把结果保存到文件供后续打分。下面是一个 Python 脚本示例演示了如何同时对三家模型发起调用。# 文件路径eval_models.py import json import os import time # 生产环境建议使用对应官方 SDK from openai import OpenAI from anthropic import Anthropic # 注意Gemini SDK 的模块名可能随官方版本变化以官方文档为准 # from google import genai def call_openai(prompt, modelgpt-4o-mini): client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content def call_claude(prompt, modelclaude-3-5-sonnet-latest): client Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) resp client.messages.create( modelmodel, max_tokens2000, messages[{role: user, content: prompt}], temperature0.2, ) return resp.content[0].text # Gemini 依官方 SDK 接入思路类似构造 client - 传入 prompt - 返回文本 # def call_gemini(prompt, modelgemini-2.5-pro-latest): # ... def run_eval(tasks, model_name, call_fn, output_path): results [] for task in tasks: start time.time() try: answer call_fn(task[prompt]) status ok except Exception as e: answer str(e) status error cost_time round(time.time() - start, 2) results.append({ task_id: task[id], model: model_name, status: status, answer: answer, time: cost_time, }) with open(output_path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(f评测完成结果已保存到 {output_path}) if __name__ __main__: with open(eval_tasks.json, r, encodingutf-8) as f: tasks json.load(f)[tasks] run_eval(tasks, openai, call_openai, result_openai.json) run_eval(tasks, claude, call_claude, result_claude.json) # run_eval(tasks, gemini, call_gemini, result_gemini.json)这段脚本的重点不是代码本身而是方法论每次评测都锁定同一组任务、同一个温度参数、同样的输出要求只有模型变量在变化。这样得到的对比结果才有参考价值。5.3 第三步定义评分标准并人工复核脚本跑完之后机器只能帮你保存原始输出最终打分还是需要人来完成。评分标准建议分两层结果是否可用输出是否符合要求、能否直接使用结果是否优质逻辑是否清晰、是否有遗漏、是否存在隐藏风险。如果任务集很大可以先做自动校验。比如 JSON 输出可以直接用json.loads校验代码生成可以用编译或单元测试校验。但对于开放性问题自动校验很难覆盖建议抽检或全部人工打分把每条任务的得分填到表格里。下面是一个简单的打分维度参考任务类型自动校验点人工校验点代码生成能否编译、单测是否通过命名、边界处理、性能隐患SQL 生成能否执行、结果是否正确索引使用、查询语义是否一致JSON 输出能否解析、字段是否齐全业务含义是否正确、类型是否合理开放问答无答案完整度、逻辑一致性、引用准确性评测完成后的结论不是“A 模型比 B 模型强”而是“在哪些任务类型上A 模型比上一版本更好在哪些场景下B 模型的成本换来的增益并不明显”。这份结论才是模型选型和升级决策的依据。6. 三大模型 API 接入的最小示例评测脚本本质上就是一组 API 调用。很多开发者第一次接触模型 API 时最容易在环境配置上花掉一整天。下面以 Python 语言为例给出三个模型家族的接入思路重点是体会它们的调用差异。6.1 安装依赖与设置环境变量无论使用哪家模型都需要先安装对应 SDK。这里用虚拟环境隔离依赖。python -m venv venv source venv/bin/activate pip install openai anthropic # 如果使用 Gemini按官方文档安装对应 SDK # pip install google-generativeai export OPENAI_API_KEYyour_openai_api_key export ANTHROPIC_API_KEYyour_anthropic_api_key # export GEMINI_API_KEYyour_gemini_api_key需要说明的是密钥要保存在环境变量或机密管理服务中不要硬编码到代码仓库里。这里展示的环境变量方式适合本地开发和测试。6.2 OpenAI 接入示例OpenAI 的接口风格比较统一对话补全使用chat.completions.create。新版本模型已经支持结构化输出、工具调用等能力但在最简场景下只需要传model、messages和temperature。# 文件路径openai_demo.py from openai import OpenAI import os client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一名熟悉 Spring Boot 的 Java 工程师。}, {role: user, content: 请用 Java 写一个简单的 RateLimiter 工具类。} ], temperature0.2, ) print(resp.choices[0].message.content)代码本身很简单但要注意两点第一temperature对代码生成任务建议调低因为代码生成更看重确定性第二生产环境需要处理接口超时、重试和限流不能只是发起请求。6.3 Anthropic Claude 接入示例Claude 的 messages API 在请求结构上与 OpenAI 不同系统提示词也独立放在system参数中。这个结构差异不算大但一旦在代码里写死切换模型时就要特别注意。# 文件路径claude_demo.py import anthropic import os client anthropic.Anthropic(api_keyos.getenv(ANTHROPIC_API_KEY)) resp client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens2000, system你是一名熟悉 Java 并发编程的工程师。, messages[ {role: user, content: 请用 Java 写一个简单的 RateLimiter 工具类。} ], temperature0.2, ) print(resp.content[0].text)Claude 的max_tokens参数是必填项不像部分接口有默认值这一点在封装通用调用层时容易踩坑。另外响应中的content是一个列表需要根据类型取出文本而不是直接访问一个字符串字段。6.4 Google Gemini 接入示例Gemini 系列的接入方式在不同时期变化较大具体 SDK 名称、类名、参数都以官方文档为准。下面只给出一个示意用于展示整体结构不建议直接复制到生产环境。# 文件路径gemini_demo.py # 注意此处仅为示意实际 SDK 接口请以官方文档为准 # from google import genai # from google.genai import types # import os # client genai.Client(api_keyos.getenv(GEMINI_API_KEY)) # resp client.models.generate_content( # modelgemini-2.5-pro-latest, # contents请用 Java 写一个简单的 RateLimiter 工具类。, # ) # print(resp.text)为什么不把完整的 Gemini 示例写死因为这一年来 Gemini 的 SDK 更新非常频繁模型名也在不断调整网上很多旧示例已经无法运行。更稳妥的方式是接入前先查看官方文档中对应日期的 SDK 版本和模型列表而不是依赖一篇博客里的代码。6.5 统一封装一层调用接口如果你的业务会同时使用多个模型建议在代码里抽象一层统一的模型调用接口。这样后续切模型、做路由、加日志都会方便很多。# 文件路径llm_client.py from typing import Callable class LLMClient: def __init__(self, provider: str, call_fn: Callable): self.provider provider self.call_fn call_fn def complete(self, prompt: str, **kwargs) - str: return self.call_fn(prompt, **kwargs)实际项目中这个封装层还应包含超时、重试、token 统计、成本统计、日志上报等能力。模型 API 的稳定性并不完全可控封装层做得越完善上层业务就越少受模型接口波动影响。7. 运行结果与效果验证评测脚本和 API 示例跑起来之后不能只看“有没有返回文本”还要建立一套验证标准。尤其是做多模型对比时至少要关注以下四个结果维度第一成功率和错误率。统计多少任务返回了正常结果多少任务抛异常。如果某个模型错误率明显偏高先排查是不是模型名、API Key、区域权限等配置问题而不是直接归因为模型能力。第二输出格式的合规率。对于 JSON 输出、表格输出等结构化任务是否能被程序正确解析。建议在评测脚本里直接加入格式校验逻辑比如 JSON 解析失败直接标记为不合规。第三耗时和成本。相同任务下不同模型的响应耗时差异可能很大。推理模型通常更慢但正确率可能更高。实际业务中需要根据任务时间敏感度做权衡。第四输出质量和稳定性。同一个 prompt 跑三次结果差异有多大。代码生成任务尤其要关注稳定性因为模型输出稍微变化就可能导致编译失败或逻辑错误。如果任务失败排查顺序应该是先看 API 返回的异常信息确认是鉴权问题、配额问题还是参数格式问题再看网络链路是否稳定有没有超时最后再看代码本身的调用方式是否符合当前模型的官方文档。很多所谓“模型能力差”的问题其实都出在调用姿势不对。8. 常见问题与排查思路把过去一年里开发者最容易遇到的模型接入和评测问题整理成下面这个表格方便快速定位。问题现象可能原因排查方式解决方案调用接口返回 401API Key 错误或未设置检查环境变量和密钥有效期重新生成 Key确认代码读取的是正确的环境变量调用接口返回 404模型名称错误或当前账号无权限查看官方模型列表和账号权限改用正确的模型名或申请对应访问权限上传长文本时报 token 超限上下文长度超过模型限制统计输入 token 数并对照限制截断、摘要或改用更大上下文窗口的模型多模态输入被拒绝图片格式不支持或大小超限查看官方支持的图片格式与大小限制压缩图片、转换格式、必要时抽帧工具调用输出的 JSON 无法解析模型生成了多余文本或格式错误打印原始输出内容开启结构化输出约束或在后处理中提取 JSON相同 prompt 多次回答差异很大温度参数过高或模型本身随机性降低温度固定随机种子如支持对确定性要求高的任务使用低温度推理模型响应非常慢推理模型需要生成内部思考过程对比快速模型与推理模型的耗时按任务复杂程度做模型路由简单任务不调用推理模型新版本效果反而不如旧版本评测任务覆盖不全面检查评测集的难度和场景分布补充业务真实样本按任务分别评估再决定是否升级成本快速上涨使用了大模型处理简单任务在日志中记录 token 用量和成本增加模型路由与配额控制优先使用低成本模型这些问题的共同点是很多现象看起来像“模型能力问题”实际是工程问题。先把调用环境、参数配置、权限配额这些基础项查清楚再讨论模型本身的能力差异才是有意义的。9. 模型选型与升级的工程建议回顾三大模型一年的能力变化最大的启示不是某个模型有多强而是“模型能力正在快速成为基础设施”。基础设施的特点是它会不断升级也会不断变化。因此团队真正需要建立的不是“永久正确的选型结论”而是一套能持续应对模型迭代的工程机制。第一把模型版本作为配置项管理。不要直接把模型名写死在代码里而是放进配置文件或配置中心。这样升级模型版本时只需要修改配置再加上评测验证而不是改代码重新发布。# 文件路径application.properties llm.provideropenai llm.modelgpt-4o-mini llm.temperature0.2 llm.max_tokens2000 llm.timeout30第二建立评测样例库并持续扩充。评测基线不是一次性工作而是需要随业务发展不断更新的资产。每当业务中出现一个新的典型场景就把它加入评测集每当模型发布新版本就跑一遍全套评测。长期积累下来这份评测集本身就是团队最有价值的 AI 工程资产。第三按任务复杂度做模型路由。简单任务用低成本模型节省费用复杂任务用推理模型保证准确率面对多模态输入时再切换到多模态模型。路由规则可以基于关键词、任务类型、输入长度等特征也可以引入一层分类器。第四对模型输出保持“先验证后使用”的原则。代码要编译、跑测试JSON 要解析、校验字段SQL 要在测试库执行并核对结果。模型输出的置信度评估很难自动完成所以在关键链路上增加人工复核机制是必要的。第五安全与权限控制必须前置。如果模型只是做文本生成权限问题还不突出一旦模型可以调用工具、访问数据库、操作文件系统就必须遵循最小权限原则。给模型单独的只读账号、限制可调用工具的范围、对高风险操作增加人工确认这些都是 Agent 应用上线的底线要求。第六记录每次调用的输入、输出、模型版本、耗时和成本。没有日志就无法回答“为什么这个问题之前是对的今天是错的”这类问题。模型版本漂移和接口变化是常态完整的调用日志是排查问题的第一手依据。10. 总结与后续学习方向这三大模型过去一年的能力飞跃本质上完成了从“更强壮的对话机器”到“可进入工程链路的多模态推理执行体”的转变。上下文窗口的扩展让模型能够处理更完整的任务场景多模态输入让模型能够理解更丰富的世界信息推理模型的出现让复杂问题有了更可靠的解决路径工具调用能力则让模型从“给建议的人”变成了“能干活的人”。对开发者来说接下来值得深入的方向有三个一是推理模型的正确使用方式尤其是如何规划任务、控制成本和验证答案二是长上下文和检索增强的结合避免“一味把更多内容塞给模型”三是 Agent 应用中的稳定性和安全边界设计这会是未来一年工程复杂度最高的领域。模型能力还会继续变但评估模型的思路、接入模型的工程框架、围绕模型建立的安全边界是可以长期复用的。与其每次发布新版本都重做一遍选型不如现在就把这套评测和接入体系搭建起来。新的一年真正的竞争力可能不再是“你用了哪个模型”而是“你能不能稳定地把模型能力转化成可靠的业务结果”。