了解 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 結對程式設計夥伴協作。