Google 推出了 Gemini 3.1，支持 200 万 token 的上下文窗口。每篇报道都将其视为突破性进展。对于特定场景——处理整个代码库、分析整本书、检索数小时的视频内容——这确实很有用。但营销宣传制造了一个危险的假设：更大的上下文 = 更好的输出。
事实并非如此。在大多数真实场景中，上下文的质量远比数量更重要。一个聚焦 5,000 token、包含准确信息的提示词，产生的输出效果通常优于随意塞入 50 万 token 的冗余内容。
核心要点
上下文窗口就像存储空间：拥有更大的车库并不会让你成为更好的司机。真正重要的是你把什么放进上下文中，而不是可用空间有多大。上下文工程（选取正确的上下文）才是产生更好结果的关键技能，而非上下文窗口的大小。
为什么更多上下文不等于更好的输出？
“中间丢失”问题。研究一致表明，LLM 对长上下文中间部分的内容关注度较低。开头和结尾的信息处理准确度更高，而埋在第 10 万 token 处的内容则容易被忽略。这不是缺陷，而是 Transformer 注意力机制的固有特性。一次性塞入 200 万 token 的上下文，意味着其中很大一部分实际上对模型不可见。
信噪比。当你把整个代码库上传到 200 万 token 的上下文窗口时，大部分代码与你的具体问题无关。模型必须自行判断哪些文件重要，而它并不总是能做出正确判断。针对性上传 3–5 个相关文件，通常比一次性上传整个代码库能得到更准确的答案。
Token 成本随上下文规模线性增长。处理 200 万 token 的成本远高于处理 5,000 token。对于日常任务——撰写邮件、生成摘要、回答问题——你可能多付 400 倍的费用，却只换来微小（甚至为零）的质量提升。
| 上下文策略 | 输出质量 | 成本 | 速度 |
|---|---|---|---|
| 5K token 聚焦上下文 | 优秀——模型精准聚焦关键信息 | 极低 | 快速 |
| 50K token 相关文档 | 很好——复杂任务中更多上下文有帮助 | 中等 | 良好 |
| 500K+ token 完整转储 | 不稳定——取决于任务和“中间丢失”效应 | 高 | 较慢 |
| 2M token 最大填充 | 仅适用于特定任务（代码库搜索、图书分析） | 极高 | 非常慢 |
📬 觉得有价值？我们每周用实用分析穿透 AI 营销。 订阅至你的收件箱 →
---大上下文窗口何时真正有用？
大上下文窗口仅在以下三种场景中真正有价值：
1. 在大型文档中搜索特定信息。“在 50 份合同中查找所有提及‘取消政策’的内容。”这是检索任务，而非分析——更多上下文意味着可以搜索更多文档。
2. 跨多个来源交叉引用信息。“比较这 20 篇研究论文的方法论部分。”这需要同时保留多份文档——小上下文窗口无法实现。
3. 分析整个代码库。“找出所有调用支付 API 的函数，并检查其错误处理逻辑。”这需要跨整个项目的可见性。Claude Code 通过 CLAUDE.md 文件实现，而 Gemini 的全量加载方式同样有效。
对于其他所有场景——写作、起草、总结、分析单一文档、回答问题、创作内容——上下文质量永远胜过上下文数量。
真正重要的技能是上下文工程——从可用信息中选取正确的 5,000 token。提示词优化器可帮助你将最相关的上下文以最有效的方式重构到提示词中。
---📬 想要更多类似内容？基于研究的反直觉 AI 分析。 免费订阅 →
---常见问题
那么 Gemini 的 200 万上下文就没用了？
并非如此。对于上面列出的特定场景（大型文档搜索、跨文档引用、代码库分析），它确实具有变革性意义。问题在于，营销宣传将上下文窗口大小描述为通用质量提升，而它实际上是一种专门能力。大多数日常 AI 任务受益于聚焦的上下文，而非海量上下文。
我应该根据上下文窗口选择 AI 模型吗？
只有当你经常处理超大文档或代码库时才需要。对于大多数用户，模型间的质量差异（Claude 的写作质量、GPT 的吞吐能力、Gemini 的多模态能力）远比上下文窗口大小更重要。
理想的提示词长度是多少？
对于大多数任务，200–500 字结构良好的上下文（ICCSSE 框架）即可产生最佳效果。除非你需要包含 AI 必须分析的实际参考文档，否则超出这个长度会带来收益递减。
免责声明：本文部分链接为联盟链接。我们仅推荐亲自测试并 regularly 使用的工具。详见我们的完整免责政策。