一篇飞行前文章：深入探讨 Google Gemini 2.5 Pro
Continue 的核心价值观之一始终是选择的自由——为工作选择合适模型的自由。在我写这篇文章的时候，我正在等一堆衣服烘干，以便为 Google Next 2025 打包，所以此时谈论 Google 的 Gemini 2.5 Pro 似乎很合适。以及它是如何改变我一个项目的开发工作流程的。
自从我开始使用 Continue 以来，我的编码效率大大提高了。最近，我一直在开发 Atrax，一个模型上下文协议（MCP）代理。让我沮丧的是，许多示例 MCP 服务器开箱即用地缺少安全性措施。而且大多数都设计成由开发人员在本地运行，使用个人凭据、PAT 等，分散在各处……那么，如果我们能用安全的东西来保护不安全的 MCP 服务器，并且只需要在一个地方管理凭据，由 oauth2 保护，会怎么样？它能行得通吗？
上下文挑战
在构建 Atrax 时，我面临着需要大量上下文的挑战。对于不熟悉大型语言模型的人来说，“上下文长度”指的是模型一次可以处理的信息量——本质上是它的工作记忆。
每个标记（英语中大约是 ¾ 个词）都会计入此上下文限制，无论是您的输入还是模型的输出。当您处理复杂的代码库或技术文档时，这些限制会变得非常令人头疼。
在开发 Atrax 期间，我不断地参考 MCP Inspector 和 TypeScript SDK。我发现自己很难让模型保持在正确轨道上，去使用 SDK 而不是尝试重新发明序列化方法。
我输入的上下文越多，模型在处理方式上就越会偏离、变化或摇摆不定。这尤其令人恼火，因为它会提出一种实现方案，但行不通，然后用完全不同的方案“修复”它，也行不通，然后又回到第一种方案……如此循环往复。我感觉自己陷入了一个由几乎行得通但总是不完全行得通的解决方案组成的无休止循环。
我注意到 Continue Hub 刚刚添加了 Gemini 2.5 Pro，所以我决定尝试一下。差异立竿见影。凭借 5 倍的上下文长度（大约 100 万个标记，而我之前使用的是 20 万个），我可以包含全面的文档和示例，而不会牺牲性能。
除了原始上下文长度之外，Gemini 2.5 Pro 似乎更精确地遵循指令。不再试图在 SDK 提供了序列化逻辑时自己编写。不再将测试成功的路径硬编码到代码中。
在 Continue 中使用 Gemini 2.5 Pro
以下是入门方法：
- 访问 Continue Hub 并找到 Gemini 2.5 Pro 模块。
- 将其添加到您的 Continue 助手。
- 按照 Google 的文档设置 API 密钥。
- 在您选择的 IDE 中选择它。
就是这样！配置完成后，您可以直接在开发工作流程中使用 Gemini 的所有功能。
更大的图景
上下文处理和指令遵循方面的改进不仅仅是小升级——它们正在改变我们使用 AI 编码的方式。能够包含更多文档、更多代码示例和更详细的指令从根本上改变了这些系统帮助我们的方式。
虽然每个模型都有其优点，但工具箱中拥有像 Gemini 2.5 Pro 这样的选项可以确保您能够为特定任务选择正确的工具。这正是 Continue 的宗旨——赋予开发人员选择权。
归根结底，目标保持不变：让开发人员的能力得到增强，而不是被自动化。通过访问能够更好地理解我们意图并能够处理更多上下文的模型，我们可以专注于更高层次的问题，同时让 AI 处理更多实现细节。
我很期待看到这些能力如何继续发展，以及它们将如何进一步改变我们的开发工作流程。
加入我们 Discord 上的其他 Go 程序员，讨论 Gemini 2.5 Pro 是否真的更擅长 Go，或者是否只是感觉如此。我很想听听您的经验！