Skyscanner 通过 JetBrains MCP 增强 Codex CLI 的开发实践

了解 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 中定义了本地运行配置，例如运行测试、格式化和 lint。借助 JetBrains MCP，Codex 可以按需发现并运行这些配置。

在实践中，这减少了 Codex 弄清楚如何运行这些功能所需的时间和上下文，帮助它保持对原始问题的专注。有了这一变化，我观察到 Codex 在运行测试、格式化或 lint 时不再磕磕绊绊。

因此，在我的自定义代理指令中，我指示 Codex 在每次更改后运行测试、lint 和格式化。

## 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 每次更改内容后手动运行测试、lint 和格式化。
我不必再把错误消息复制粘贴回聊天中。
Codex 能快速、精确地获得关于其更改是否真正有效的反馈，从而减少反馈循环的次数。

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

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

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

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

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

总结

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

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