在 Skyscanner 使用 JetBrains MCP 为 Codex 赋能

了解 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 在每次更改后运行测试、代码检查和格式化。

## Code edit instructions

After you've finished editing

- Use the jetbrains mcp (if available) to find any problems
- Run format command if available
- Run lint command if available

我注意到 Codex 现在经常自己解决问题，无需我介入。作为开发者，这感觉是一个巨大的胜利：

我不必在 Codex 每次更改某些内容后手动运行测试、代码检查和格式化。
我不必将错误消息复制粘贴回聊天中。
Codex 能够获得快速、准确的反馈，了解其更改是否真正有效，从而减少反馈循环的次数。

这让我有更多时间专注于手头的任务：交付高质量的可用软件。

这对我们的构建方式意味着什么

将 Codex 与 JetBrains MCP 集成，使我们的 AI 助手在开发过程中明显更加强大和可靠。我们看到的一些实际好处包括：

更快的反馈循环：Codex 能从 IDE 获得关于编译错误和测试失败的即时反馈。
更少的来回提示：Codex 不必总是等我运行某些内容并粘贴错误消息——它可以直接查询 IDE。
更高质量的建议：因为 Codex 能看到 IDE 所看到的内容，其修复更有可能在第一次尝试时就编译通过并通过测试。
与现有工作流程更好地对齐：Codex 接入我们现有的工具，而不是自己另起炉灶。

总体而言，它将 Codex 从一个独立工具转变为我们的开发生态系统中更加集成的一部分。

总结

对我们 Skyscanner 来说，关键见解很简单：上下文就是一切。Codex 本身很强大，但具备 IDE 感知能力的 Codex 效率要高得多。这种上下文让 Codex 获得更多洞察，使其能够更快地产生准确的修复，并进一步增加我对它输出的信任。

我们希望我们的故事能激励其他人尝试这些集成。它确实感觉不那么像是在使用一个工具，而更像是在与一个能看到我们所见的 AI 结对程序员协作。