AI 还在蒙眼跑 Maven？JetBrains 把 IDEA 变成 MCP Server，让它睁开了眼

Lambert281
0 阅读9分钟

在这里插入图片描述

图：IntelliJ IDEA 显示器化身服务器，MCP 线插上 AI 机器人——它的镜片里第一次映出你的 Problems 视图和 Run 窗口

上周我让一个 AI 编程助手改个 bug。它改完代码，自己跑 mvn package 验证，十秒后告诉我："编译失败"。哪一行失败、是类型错了还是依赖少了，它说不上来——它改的是我的代码，我却看不见它是怎么跑的；它自己也看不见，它只有一根命令行。

本文基于 IntelliJ IDEA 2026.2（MCP Server 自 2025.2 起内置）编写，AI 客户端侧以 CodeBuddy 实测为准，该领域迭代极快，请以官方文档为准。 官方说明：MCP 服务器 | IntelliJ IDEA 文档（50+ 工具的完整清单与客户端配置都在这）。

这事现在有了官方解法：IDEA 把自己开成了一台 MCP Server。AI 客户端连上之后，能直接看你的 Problems 视图、跑你的 Run Configuration、调你的调试器——用的是 IDE 的索引和检查器，不是猜。我已经把它挂进了日常开发流，这篇把是什么、谁能接、怎么配一次讲清。

IDEA 把自己开成了一台 MCP Server

MCP（Model Context Protocol）这个协议 Java 老哥应该不陌生了，今年已经成了 AI 接工具的事实标准，之前我写过用 @McpTool 注解把 Spring 服务暴露给 Claude。那条路是"你的服务当 Server"。

JetBrains 把方向反了过来：IDE 自己当 Server。从 2025.2 开始，IntelliJ IDEA 内置 MCP Server 插件，默认启用，不用装任何额外东西。你本地开着 IDEA，它就监听在本机端口（默认 64342），等 AI 客户端通过 MCP 协议连进来调用。

这件事的分量在于：AI 编程工具此前的信息来源只有文件系统和 shell——读文件靠猜路径，验证靠盲跑构建脚本。连上 IDEA 之后，它拿到的是 IDE 级别的东西：索引、语法树、检查器、运行配置、断点。红色波浪线停在哪一行，AI 终于自己能看见了。

它是怎么干活的：一次工具调用的完整链路

这套东西的工作方式，拆成三层看就清楚了：

在这里插入图片描述

图：IDEA MCP Server 三层工作方式——AI 客户端的请求经 MCP 协议到达 IDE，被分发给对应的 IDE 子系统执行

第一层，AI 客户端（CodeBuddy / Claude Code / Cursor……）。它决定"现在需要 IDE 帮个忙"——比如刚改完代码，想知道有没有红线。

第二层，MCP 协议。客户端把调用封成 JSON-RPC 请求发给 IDEA（本机回环端口 64342，不出你的机器）。官方支持三种传输方式，按客户端选：

传输方式适用场景
HTTP Streamable当前默认，CodeBuddy 走的就是这条
SSE旧版流式，协议方向已弃用，仅兼容老客户端
Stdio客户端本地拉起进程直连的场景

第三层，IDE 子系统——这是和"盲跑 shell"最本质的区别。IDEA 收到请求后，不是去开终端拼命令，而是调用自己的内部子系统：

MCP 工具背后真正干活的是
get_file_problems代码检查器（Inspections）——就是你眼前红波浪线的那套引擎
build_projectIDE 构建系统——增量编译，用的是项目里配好的 SDK
execute_run_configurationRun 管理器——你配好的启动类、程序参数、环境变量
rename_refactoringPSI 索引——语法树级引用查找，不是文本搜索替换
get_symbol_info索引 + 快速文档（Quick Documentation）
execute_terminal_commandIDE 集成终端（确实需要 shell 时的逃生门）

串起来看一次真实的"AI 自己验证改动"（本文写作当天，我们用手搓系列的 ginkgo-agent 仓库就是这么跑的）：

  1. AI 改完代码，先调 get_file_problems——秒级拿到检查器结果，相当于它自己扫了一眼 Problems 视图；
  2. 再调 build_project——IDE 增量构建，返回的是带文件和行号的结构化错误，不是"编译失败"四个字；
  3. 要启动应用时调 execute_run_configuration——直接用你在 IDE 里配好的 Run Configuration，环境变量、JVM 参数天然继承，不用把本地的启动知识再教它一遍；
  4. 碰上危险动作（执行终端命令、跑运行配置），IDE 弹确认框等你点头才放行——这是 Brave 模式关闭时的默认安全闸，后面安全一节细说。

对比一下就明白差距在哪：传统方式是「改代码 → 盲跑 mvn package → 全量编译几十秒 → 拿到一段文本日志自己找错因」；这条链路是「改代码 → 秒级看红线 → 增量构建 → 错误直接带行号」。快在索引和增量，准在结构化，全在它继承了你 IDE 里的一切本地配置。

两个使用细节官方文档专门提了，顺手记下：多数工具建议带上 projectPath 参数消歧（你同时开着几个 IDEA 项目时尤其重要）；所有行号、列号都从 1 开始。

50+ 个工具里，Java 老哥最该知道的几个

官方文档列了 50+ 个工具，按类别铺开是分析、代码洞察、数据库、调试器、执行、文件、搜索、重构、终端、格式化、VCS 等一大串。我挑日常最值钱的几个说：

工具干什么解决了什么
get_file_problems调 IDEA 检查器扫文件，返回错误/警告AI 改完代码自己看"红色波浪线"，不用等编译
execute_run_configuration按名字启动你的 Run Configuration启动 Spring Boot 应用、跑测试，返回真实输出
build_project构建项目并返回编译错误验证不再是黑盒 mvn package
rename_refactoring上下文感知重命名改方法名全项目引用一起动，不做文本替换
reformat_file按项目自身规则格式化AI 不用猜你的缩进风格
xdebug_* 一族（13 个）下断点、步进、看变量、改值AI 能开调试会话查问题，仅 Ultimate 版

还有两个容易忽略但实用的：get_symbol_info 相当于让 AI 用你的"快速文档"查符号签名；execute_terminal_command 是在 IDE 集成终端里跑命令，输出上限 2000 行。

一句话：这套工具不是"又一批 shell 命令"，是把 IDE 的语义能力外包给了 AI。

主流 AI 编程工具，谁接得上

IDEA 这边把 Server 开好了，客户端那边各家进度不一样。官方"自动配置"列表里目前是这几家：

AI 客户端接入方式说明
Claude Code一键自动配置官方列表，另有调试器技能 /ij-debugger 可复制
Codex一键自动配置官方列表
Cursor一键自动配置官方列表
VS Code一键自动配置官方列表
Windsurf一键自动配置官方列表
Claude Desktop一键自动配置官方列表
CodeBuddy手动配置（JSON）不在自动配置列表，但完全可用——本文实测

自动配置的本质是 IDEA 帮你把连接信息写进各家的配置文件，省得手抄端口。CodeBuddy 没进这个列表，得自己写 JSON——但就几行的事，而且手动配置反而让你拿到一个自动配置给不了的自由度：多项目路由。下面直接上实录。

CodeBuddy 配置实录

IDEA 侧先开 Server：Settings | Tools | MCP Server，勾选 Enable MCP Server。这一步会有第三方应用权限提示，看清楚再确认。

CodeBuddy 侧：侧栏对话面板右上角 CodeBuddy Settings → MCP 标签 → Add MCP，在打开的 JSON 文件里加：

{
  "mcpServers": {
    "idea-ginkgo-agent": {
      "type": "streamable-http",
      "url": "http://127.0.0.1:64342/stream",
      "headers": {
        "IJ_MCP_SERVER_PROJECT_PATH": "/Users/lambert/code/blog/ginkgo-agent"
      }
    }
  }
}

三个关键点：

  1. type 用 streamable-http。CodeBuddy 官方文档的示例只有 stdio 类型，但 IDEA MCP 是 HTTP 服务，实测 streamable-http 直连没问题（这也符合 MCP 传输层的大方向——SSE 已弃用，Streamable HTTP 是默认，我此前在 MCP 无状态升级那篇里写过）。
  2. IJ_MCP_SERVER_PROJECT_PATH 这个 header 是多项目的钥匙。我日常挂着两个 IDEA 项目：开源的 ginkgo-agent 和一个公司项目，两个 MCP Server 配置指向同一个端口 64342，靠这个 header 告诉 IDEA"这次调用路由到哪个项目"。给每个项目起个名字（idea-ginkgo-agent、idea-别的项目），AI 调用时指名道姓，互不串台。这一点官方文档没展开，是我配置时试出来的。
  3. 配完重启会话生效，然后可以直接验证——让它"看一下当前 git 状态"，回来的就是 IDEA 里的仓库信息：
currentBranch: dev-E01, isClean: true

回来的不是 shell 里 git status 的文本，是 IDE VCS 子系统给的结构化数据。

安全这条线，先别急着放开

把 IDE 开给 AI，权限面不小，JetBrains 的默认姿势是收着的：

  • Brave 模式默认关闭。默认情况下，AI 要执行终端命令或运行配置，每一次都要你人工点确认。设置里可以开"无需确认直接跑"（Brave 模式），开了等于 AI 能在你机器上静默执行任意 shell 命令——我的建议是日常别开，至少在你还没摸清这个 AI 的脾气之前别开。
  • 工具白名单：50+ 个工具在 Settings | Tools | MCP Server 里可以逐项启停。用不上的（比如数据库工具）直接关掉，权限面收敛到最小。
  • 数据库工具单独说：官方建议给 AI 配只读权限的数据库用户。
  • 作用域限制：文件分析类工具只管项目目录内的文件，AI 没法借 IDE 的手去翻你磁盘上别的东西。

我的判断

该开的人群：主力 IDE 是 IDEA、且已经在用 AI 编程工具的 Java 老哥——这是零成本升级，Server 就在你 IDE 里躺着，客户端配置几行 JSON。收益最直观的场景是"AI 改代码 → AI 自己用 IDE 验证"这个闭环，蒙眼跑 Maven 的时代可以结束了。

要知道的两条边界：一是调试器工具包（xdebug 那 13 个）只有 Ultimate 版内置，社区版少这块最性感的能力；二是它要求 IDEA 开着——AI 是搭你 IDE 的便车，不是替代你的 IDE。

对我自己来说，它改变的是协作姿势：以前我是 AI 的"眼睛和手"（帮它看报错、帮它跑构建），现在这些它自己来，我回到该待的位置——看 Diff、下判断。我们手搓企业智能体系列的 ginkgo-agent 仓库已经立下规矩：所有构建、运行、调试操作一律走 IDEA MCP，IDE 能看到的东西，不许 AI 蒙着眼猜。

【今天用 IDEA MCP 做 E02 开发的实操感受——最大的感觉调试不用我亲自动手了，而且AI工具知道调试结果】

avatar
文章
阅读
粉丝