在 Skyscanner 使用 JetBrains MCP 为 Codex 提速 | OpenAI 开发者
来源: https://developers.openai.com/blog/skyscanner-codex-jetbrains-mcp 抓取时间: 2026-07-21 16:25:50
了解 Skyscanner 如何通过将 OpenAI 的 Codex CLI 与 JetBrains IDE 集成，为他们的 AI 助手提供与人类开发者相同的调试和测试工具。
在 Skyscanner，我们一直在寻找在不影响质量的前提下加速开发的方法。在过去的几个月里，我一直在尝试将 OpenAI 的 Codex 作为我的日常工作流中的结对程序员。
关键是什么？我使用 JetBrains 的模型上下文协议（MCP）服务器将 Codex CLI 连接到 JetBrains 的 IDE：本质上让 AI 能够看到并使用 IDE 的功能。这种集成改变了游戏规则。在这篇文章中，我将分享让 Codex 访问 JetBrains 工具如何提高其解决问题的能力并加快我们的开发速度。
为 Codex 提供 IDE 上下文
使用 JetBrains MCP 服务器 与 Codex 协作意味着 AI 现在可以利用我的开发环境的丰富上下文——这些是它通常不会"看到"的东西。
通过 JetBrains MCP，Codex 可以向 IDE 请求额外的上下文，例如：
- 查找文件问题：使用 IntelliJ 检查分析文件中的错误和警告，并返回确切的问题（包括错误消息和位置）。
- 执行运行配置：运行预定义的运行配置（如单元测试、代码检查工具或格式化工具）并获取退出代码和输出。
这被证明是极其强大的——通过利用人类开发者在编写、编译和测试代码时依赖的相同反馈循环，Codex 可以使用 IDE 的上下文更有效地检查和验证其输出，减少迭代时间。
更快地捕获错误：一个真实示例
当我正在为使用 Databricks Java SDK 的代码中的错误处理编写单元测试时，我提示 Codex 帮我创建一个异常场景的存根。它自信地生成了一行 Java 代码，看起来像这样：
var stubError = new NotFound("dummy error");
乍一看，这看起来很合理——我们想要模拟一个 NotFound 错误。但片刻之后，IntelliJ 用一条粗大的红色下划线高亮显示了这一行。
问题：Databricks SDK 中的 NotFound 异常类没有接受单个字符串参数的构造函数（您可以在 Databricks SDK 源代码中看到这一点：NotFound.java）。换句话说，Codex 建议的代码永远不会编译。
默认情况下，Codex 不会知道这个错误。它可能只会在稍后尝试运行测试时才意识到出了问题。然而，由于 JetBrains MCP 集成，Codex 立即注意到了错误。在幕后，Codex 调用了 IDE 的 get_file_problems 工具来检查文件，立即返回了编译问题（没有匹配的构造函数）。
如果没有 MCP，可能的流程会是：
- 生成代码
- 确定如何运行单元测试
- 运行单元测试（可能需要向用户升级命令）
- 读取和解析失败消息
- 尝试修复错误
使用 JetBrains MCP，这个循环要紧凑得多：
- 生成代码
- 向 JetBrains 询问文件问题
- 修复 IntelliJ 报告的确切错误
这节省了时间和上下文，感觉非常像与一位工程师结对编程，他立即说："啊，那个类没有那样的构造函数——它实际上需要不同的东西。让我快速修复一下"。
预定义的测试和格式化
我喜欢的另一个优势是让 Codex 直接从 IDE 驱动我们现有的构建和测试工具。对于我们的大多数项目，我已经在我的 IDE 中定义了本地运行配置，例如运行测试、格式化和代码检查。通过 JetBrains MCP，Codex 可以按需发现并运行这些配置。
实际上，这减少了 Codex 弄清楚如何运行这些功能所需的时间和上下文，帮助它专注于原始问题。通过这一更改，我观察到 Codex 在运行测试、格式化或代码检查时不再遇到困难。
因此，在我的 自定义智能体指令 中，我指示 Codex 在每次更改后运行测试、代码检查和格式化。
## 代码编辑说明
完成编辑后
- 使用 jetbrains mcp（如果可用）查找任何问题
- 如果可用，运行格式化命令
- 如果可用，运行代码检查命令
我注意到 Codex 现在经常自己解决问题，而不需要我干预。作为一名开发者，这感觉像是一个巨大的胜利：
- 我不必每次 Codex 更改内容时都手动运行测试、代码检查和格式化。
- 我不必将错误消息复制粘贴回聊天中。
- Codex 可以获得关于其更改是否有效的快速、精确的反馈，减少反馈循环的次数。
这让我有更多时间专注于手头的任务：交付高质量的可运行软件。
这对我们的构建方式意味着什么
将 Codex 与 JetBrains MCP 集成使我们的 AI 助手在我们的开发过程中变得更加能干和可靠。我们看到的一些实际好处是：
- 更快的反馈循环：Codex 从 IDE 获得关于编译错误和失败测试的即时反馈。
- 更少的来回提示：Codex 不必总是等待我运行某些东西并粘贴错误消息——它可以直接查询 IDE。
- 更高质量的建议：因为 Codex 可以看到 IDE 看到的东西，它的修复更有可能在第一次尝试时就编译通过并通过测试。
- 与现有工作流更好的对齐：Codex 插入到我们现有的工具中，而不是发明自己的工具。
总的来说，它将 Codex 从一个独立的工具变成了我们开发生态系统中一个更加集成的部分。
总结
对于我们 Skyscanner 来说，关键的见解很简单：上下文就是一切。Codex 本身就很强大，但具有 IDE 感知能力的 Codex 要有效得多。这种上下文为 Codex 提供了更多的洞察力，使其能够更快地生成准确的修复，并进一步增加我对其输出的信任。
我们希望我们的故事能激励其他人尝试这些集成。它真的感觉不像是在使用一个工具，而更像是在与一个能看到我们所看到的东西的 AI 结对程序员合作。