了解 Skyscanner 如何将 OpenAI 的 Codex CLI 与 JetBrains IDE 集成，大幅增强其能力，让 AI 助手能够使用与人类开发者相同的调试和测试工具。
在 Skyscanner，我们一直在探索如何在保证质量的同时加快开发速度。过去几个月里，我一直尝试在日常工作流程中让 OpenAI 的 Codex 担任结对编程伙伴。
这次有什么不同？我通过 JetBrains 的 Model Context Protocol（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 结对编程伙伴协作。