JetBrains以Air应对AI代码审查瓶颈

AI 写代码更快之后，开发者未必更轻松，瓶颈可能转到了审查、追踪和返工。JetBrains 在 2026.3 版本中推出的 Air，想解决的就是这件事：把不同 coding agent 的会话、改动和反馈放回 IDE，让开发者能接手它们产出的代码。

这篇发布说明值得看的，不只是支持了哪些模型，而是它如何组织多人分工般的 AI 编程流程。不过，功能可用与效率提升是两回事，免费入口和已有订阅能否复用，也都有具体条件。

Air 要解决的是代码写完之后怎么办

原文引用 Atlassian《2026 开发者体验报告》：49% 的开发者每周花四小时或更久，审查 AI 输出并修正提示词。这个数字描述的是两项工作合计，不能直接理解成纯代码审查时间。

JetBrains 据此提出的判断是，生成速度上来后，开发者更需要知道改了什么、是否适合进入代码库，以及会话结束后能否继续维护。

Air 的定位是运行和审查 agent 的工作区，Junie 才是其中一个 coding agent。

这一区分很关键。Air 不要求所有任务都交给 JetBrains 自家的 agent，而是试图提供统一的协作入口。

它可以集中展示跨项目会话，区分哪些 agent 正在工作、哪些需要输入、哪些结果还没读，并通过通知提醒开发者。针对重复任务，还能把 agent、模型和指令存成 preset，减少每次重新配置的步骤。

并行任务则可以各自使用本地 Git worktree。它让同一个仓库拥有多个工作目录，避免几个 agent 同时修改同一份文件。但原文明说，agent 自行创建的 worktree 暂时还不会被 Air 追踪。工作目录隔离也不等于最终改动没有冲突，合并时仍需审查。

审查环节的重点是 Code Notes。开发者可以在具体代码行留下问题或修改要求，再把批注连同代码上下文发回原会话。终端 agent 也支持这套流程。

它解决了一个很实际的麻烦：不用反复复制代码、描述文件位置，再让 agent 猜自己指的是哪一处。不过，批注传得准确，只能减少沟通损耗，不能代替对实现的判断。

IDE 的价值，在于让 agent 用上代码工具

Air 放进 IDE，真正有价值的部分是把已有工具开放给 agent。

原文介绍，通过 IDE 的 MCP server 和内置 skills，受支持的 agent 可以检查代码诊断结果、运行构建和运行配置、查询数据库，以及调用 IDE 自身的重构功能。这里的 MCP 可以理解为工具接入接口，让 agent 有机会调用开发环境里的能力。

原文还列出性能分析、数据库管理和语义代码搜索。调试器则明确提到 IntelliJ IDEA 和 CLion，不能据此推断所有 JetBrains IDE、所有 agent 都有完全相同的支持范围。

这条路线有合理之处。比如重命名一个符号，文本替换只能处理字符匹配，IDE 重构可以利用代码结构和引用关系。agent 能调用这些工具，就有机会减少手工修改带来的遗漏。开发者也能用同一套工具检查结果，包括导航、inspections、测试和调试。

但「能够调用」与「每次正确调用」之间还有距离。原文没有提供不同 agent 的完整能力矩阵，也没有展示代表性任务的失败案例。

文末附带的相关内容声称，JetBrains IDE intelligence 通常让 agent 的整体效率提高 20–30%，最佳情况约为 65%。这段材料没有展开样本、效率定义、基线和测量方法，不能直接当成 Air 的实测收益，更不能据此估算团队能节省多少人力。

远程开发也有一个明确边界：连接 remote backend 后，Air 和 agent 都在后端与代码一起运行。团队评估时需要检查后端环境中的工具和账号配置，不能只看本机是否已经装好 agent。

订阅可以带过来，但入口不能选错

Air 支持 Junie、Codex、Claude Agent、GitHub Copilot，也通过 ACP 接入其他兼容 agent。原文还列出 Gemini、DeepSeek、OpenCode、Cursor、Pi、Grok、Kimi 和 Kilo。ACP 在这里承担的是 agent 接入协议的角色，不代表这些产品的功能和计费方式已经统一。

兼容 agent 可以从本机已有安装接入，也可以从 registry 添加。认证方式取决于具体组合，可能使用供应商订阅、API key 或 JetBrains AI。

最容易混淆的是 Claude 的两个入口。

已有 Claude Pro 或 Max 的用户，需要进入 Manage Agents，为 Claude 选择 Terminal，再新建会话，打开全屏编辑器标签页中的 Claude Code 并登录。聊天视图中的 Claude Agent 则需要 JetBrains AI 订阅或 Anthropic API key。不能因为终端入口支持现有订阅，就认定聊天入口也能直接复用。

免费入口是 Junie Lite：使用 JetBrains Account 登录即可，不要求付费 JetBrains AI 订阅，但受 fair use 约束，条款和可用模型可能调整。原文建议，日常问答可选 Lite 或 Luna，并将 Effort 设为 Off；已有 AI Chat 对话会自动转换成 Junie 会话。

代码补全继续可用，且不消耗 JetBrains AI 配额。对于 next edit suggestions，正文写支持 JetBrains AI 订阅或 GitHub 登录，FAQ 却只提到 JetBrains AI 订阅。原文没有解释两处口径差异，不能替它补齐条件。

从 AI Assistant 迁移，还有几项实际变化：

• Air 可查看当前会话的 token 或金额成本，以及 JetBrains AI 剩余配额和重置日期；Codex、Claude、Copilot 订阅的同类视图仍在开发，组织用户可通过链接进入 JetBrains Console。
• Air 可以根据选中的改动生成 commit message，也能切换到熟悉的右侧工具窗口，路径为 Settings → Show Chat → In Toolwindow。
• AI Assistant 作为独立插件继续支持到 2027 年初；若入口被隐藏，可以连按两次 Shift，搜索 Open AI Assistant。
• 如需关闭 Air，可以进入 Settings | Plugins 禁用并重启 IDE。

原文还明确表示，Air 不会自动启动 agent 或向供应商发送代码，用户需要先选择并授权。后续数据处理仍取决于所选 agent 和供应商的条款。

我的判断

我认同它把审查放回工作流中心。对于已经长期使用 JetBrains IDE 的团队，统一会话、逐行反馈、直接运行检查，确实比在终端、聊天窗口和编辑器之间搬运上下文更顺手。

但这首先是一套工作流设计，原文尚未证明它能普遍提高交付效率。49% 的调查数据说明审查负担值得关注，并不能证明 Air 能减轻多少负担。功能发布说明也不是对照实验。

和「终端 agent 加 Git diff」相比，Air 的优势在于会话组织、反馈上下文和 IDE 工具接入。如果平时一次只处理一个任务，改动也很集中，原文提供的材料不足以说明迁移收益。并行任务越多、审查往返越频繁，这些能力才越可能发挥作用。

能追踪 agent 的工作，不等于已经验证 agent 的结果。

团队仍要检查行为是否符合需求、测试是否覆盖关键路径，以及代码能否长期维护。Air 提供了完成这些工作的工具入口，责任仍在开发者手里。

能拿来做什么

• 如果经常让 agent 并行修改同一仓库，可以先用 Air 为任务分配独立 worktree，再逐个审查结果，并确认这些目录确实被 Air 追踪。
• 审查前端或 Node 改动时，可以用 Code Notes 标出具体问题，再结合测试和代码检查验证下一轮结果，减少重复解释位置与上下文的时间。
• 已有 Claude Pro 或 Max 订阅的用户，可以按终端入口接入 Claude Code；评估成本时，要区分供应商账单、JetBrains AI 配额和免费入口的使用限制。
• 准备从 AI Assistant 迁移时，可以先验证常用问答、补全、next edit suggestions 和配额查看是否满足需求，再决定日常使用多少 agent 功能。