Gemini 2.5 Pro深度测评：100万token上下文到底有多好用

为什么现在写这篇

Gemini 2.5 Pro在今年三月悄悄更新了，这次带来的最大变化是正式把100万token的上下文窗口推向了稳定版本。我在SFD实验室测了两周，有一些实际使用的判断想记下来——不是跑基准测试，是真实工作场景。

先感受一下规模：100万token大约等于750万汉字，或者约750本普通长度的中文技术书。实际工作里能装的东西：一个完整的代码库（10万行以内）、过去一年的所有会议记录、一个完整项目的所有文档。

我测了一个具体场景：把SFD实验室CMS项目的全部后端代码（约8万行）塞进上下文，然后问它「找出所有可能存在SQL注入风险的地方」。结果：它找出了3处，其中2处我们之前的人工代码审查漏了。这是真实数据，不是演示。

这两个是我目前日常工作里用得最多的两个模型，区别比较明显：

长上下文处理：Gemini 2.5 Pro明显更强。把大段代码或文档塞进去，Gemini更少出现「中间部分信息丢失」的情况。Claude在超过20万token的时候，开始对上下文中间的信息注意力下降，Gemini在80万token时表现依然稳定。

推理深度：Claude 3.7在需要多步逻辑推导的任务里更可靠。我测了一个「给定约束条件，设计最优系统架构」的题目，Claude的答案更有结构，Gemini有时候在第三四步推导里漂移。

中文写作：Claude更地道。Gemini的中文在语法上完全正确，但读起来有一种轻微的翻译腔，在要求文笔的场合（比如公众号文章、品牌文案）会比较明显。

代码能力：基本持平，都很强。Gemini在大型代码库的理解上有优势，Claude在新代码的生成质量上稍好。

长上下文不是免费午餐。把100万token全塞进去，响应速度会明显变慢——我测试的平均响应时间从普通对话的2秒增加到了15-25秒。如果你的工作流对延迟敏感，要考虑只传必要的上下文。

另一个坑：价格。Gemini 2.5 Pro的输入价格是3.5美元/百万token，100万token一次请求就是3.5美元。如果你每天跑大量长上下文任务，成本会很快累积。建议先用较小的上下文窗口验证方案，确认可行再扩到全量。

强烈推荐用Gemini 2.5 Pro的场景：大型代码库审查、长文档分析（如合同、报告）、需要跨多个长文档做关联分析的研究工作。

不建议的场景：对延迟敏感的实时交互、需要纯中文写作质量的内容创作、预算有限的高频调用。

Gemini 2.5 Pro不是要替代Claude，而是补了一块Claude没那么强的地方：超长上下文的稳定处理。如果你的工作里有大型代码库分析、超长文档处理这类需求，值得认真评估。如果你主要做的是对话、写作、常规推理，Claude 3.7目前仍然是我的首选。

两个模型都值得常备，根据任务切换。

SFD编者注：我们现在的工作流是：代码审查用Gemini 2.5 Pro（大上下文），内容创作和对话用Claude 3.7，成本比只用一个模型低了约40%，质量没有明显差距。