JetBrains Air 教程：从首次会话到代码审查

这篇 JetBrains Air 教程先讲最实用的一步：在 JetBrains IDE 里启动编码智能体，只交给它必要的项目上下文，再回到你熟悉的代码导航与测试环境中审查改动。第一次不要让它大规模重构。安装 Air Alpha，连接一个智能体，只提供一个文件和一个失败测试；除非 diff 与测试结果都说得通，否则不要接受任何改动。

JetBrains Air 教程速览

把 Air 当作智能体控制室，而不是自动补全按钮。具体工作由智能体完成；Air 负责组织会话、传递 IDE 上下文，并把结果带回 IDE 原生的审查界面。

第一次会话按下面做即可：

1. 从 IDE Marketplace 安装 Air Alpha。
2. 打开一个可随时丢弃的项目或分支，并准备一条能运行的测试。
3. 选择 New Session 预设，访问级别保持为 Standard Access。
4. 发送第一条消息；如果 Air 提示登录，就完成授权。
5. 用 @file: 附加相关文件。
6. 只要求一个小修复，并要求补充测试。
7. 在 Agent Sessions 中检查每个被修改的文件。
8. 亲自运行测试，再决定保留、编辑、提交还是回退改动。

真正有用的闭环就是这些。等这套流程足够可信之后，再考虑并行会话、更多智能体、组织管控和云端接力。

JetBrains Air 到底是什么

Air 位于 JetBrains 项目与一个或多个编码智能体之间。可以把它看作模型工坊里的质检台：智能体把拟议零件送上工作台，IDE 则继续提供尺寸、装配检查和最终决定权。

9 月 22 日发布的版本把 Air 扩展为由三个明确部分组成的系统：面向个人工作的 Air in JetBrains IDEs、用于协作与自动化的 Air Teams，以及负责策略、可见性与成本控制的 Air Governance。本指南只聚焦目前可以实际运行的本地路径，也就是 Air Alpha IDE 插件。

IDE 插件本身并不是新的基础模型。它开箱支持 Codex、Gemini、GitHub Copilot、Claude 和 Junie；JetBrains 还表示，其他智能体可以通过 ACP 接入。ACP 即 Agent Client Protocol，相当于 IDE 与智能体完整工作体系之间的通用接口，涵盖智能体使用的工具和模型路由。

当前的 Air IDE 页面仍把本地到云端的任务接力标为即将推出。想让首次尝试更可靠，就先把任务留在本地，并严格控制范围。

安装 JetBrains Air 插件前要知道什么

Air Alpha 是公开 Alpha 版本，并非悄无声息运行的稳定工具。JetBrains 明确提醒，界面和行为都可能变化，更新节奏预计约为每周一次。遇到问题时，先核对兼容性，再做其他排查。

截至 2026 年 9 月 23 日，Marketplace 面向 2026.2 产品线的当前安装包是 Air 262.8665.463。它支持 IntelliJ IDEA 2026.2 至 2026.2.3，以及列表中其他 JetBrains IDE 对应的 2026.2 版本。Marketplace 也提供 2026.3 产品线的构建，因此实际插件版本会随 IDE 分支而变化。

本次运行的兼容性检查

在隔离配置中，IntelliJ IDEA 2026.2.3（构建号 IU-262.10968.63）成功加载了 Air 262.8665.463，并为一个可随时丢弃的 Node 项目完成索引，没有出现插件错误。检测到的智能体是 codex-cli 0.153.4，但当时尚未登录，而且宿主环境没有图形会话。因此，本文不声称实际完成了交互式 Air 任务、生成了 diff，或跑通了由智能体编写的测试。下文界面步骤依据 JetBrains 当前快速入门文档，以及该插件构建中实际打包的标签。

JetBrains Air 怎么用：完整步骤

1. 安装 Air Alpha

打开 IDE 设置，进入 Plugins，切换到 Marketplace，搜索 Air Alpha，再点击 Install。如果 IDE 提示重启，按提示操作。

Air 本身免费，但其背后的智能体仍可能需要账户、订阅或 API 计费。如果你正卡在费用判断上，JetBrains Air 是否免费一文拆分说明了插件成本与智能体成本。

2. 打开一个失败成本很低的项目

先用一个可以丢弃或重置的现有项目。理想的首次任务只涉及一个相关文件，有一个可观察的失败现象，以及一条能证明改动是否生效的命令。

例如：slug 辅助函数没有正确处理连续空格、格式化工具漏掉一个边界情况，或某个小型校验函数有一条失败的单元测试。第一次不要碰迁移、身份验证、部署代码或大范围依赖升级。

打开会话前，先记录基线：

• 当前分支或临时 worktree；
• 准确的测试命令；
• 该测试当前是通过还是失败；
• 预计会被修改的文件。

这样一来，审查依据是前后对比，而不是主观感觉。

3. 选择 New Session 预设

主工具栏上的 New Session 按钮会用当前选中的预设启动会话；需要切换预设时，点击旁边的下拉箭头。

预设是一份已保存的启动配置。它会选择智能体，也可以预先指定模型、推理强度、访问级别和会话界面。Air 会把它在本机检测到的智能体与内置预设一起列出。如果选中的智能体尚未安装，插件可以提示你安装。

首次任务请选择 Standard Access。在当前插件中，Standard Access 允许智能体读取、编辑项目内的文件，并在项目内运行命令；访问项目外文件或网络时仍需批准。Full Access 则会取消网络访问及修改机器上任意位置文件时的批准检查，不适合作为第一次会话的默认选项。

4. 发送第一条消息并授权智能体

只有智能体真正需要授权时，授权流程才会出现。输入一条简短消息并按 Enter。如果 Air 找到智能体已在本机使用的凭据，会话会直接继续；否则会显示 Choose a sign-in method to continue。

具体方式取决于智能体：

• 智能体登录可以转到浏览器或终端继续；
• 符合条件的 JetBrains AI 许可证或组织工作区可以提供额度；
• Add an AI provider 会打开 Tools | Air | Accounts，用于配置第三方订阅或 API key。

在 Accounts 中选择 More Providers，添加所需凭据，点击 Test Connection，再用 OK 保存；随后回到会话并选择该 provider。

不要把密钥粘贴进任务 prompt。凭据应放在 provider 连接流程中配置。

5. 只添加任务真正需要的上下文

Air 可以通过添加上下文控件附加文件、commit 和 skill。你也可以输入 @file: 指定文件，或用 @folder: 指定文件夹。两者差别很大：附加一个相关文件，像是把故障零件递给维修人员；附加整个仓库，则像把车库里所有东西都倒在工作台上。

第一次只附加实现文件，并明确写出测试命令。只有当智能体确实需要理解现有模式时，再加入测试文件。

6. 提出范围明确、能够验证的改动

好 prompt 应同时写清缺陷、允许修改的范围和验证命令。例如：

修复 @file:src/slug.js 对连续空白的处理。新增或更新最小范围的相关测试。运行 node --test。不要更改依赖，也不要触碰无关文件。如果测试命令无法运行，请停止并说明原因。

这样的 prompt 给智能体划出了终点；“改进这个辅助函数”没有。

7. 跟进会话，但不要用过程描述打分

智能体会汇报进度，也可能提出问题。补充缺失的需求，只批准你理解的操作；对意外的网络请求或项目之外的文件访问尤其谨慎。

进度文字可以提供上下文，但不能作为证据。真正的证据，是最终 diff 加上一条你可以亲自复跑的测试。

8. 在 Agent Sessions 中审查改动

打开 Agent Sessions，展开已完成的会话，并逐一查看每个被修改文件的 diff。当前安装包提供 Show Diff、Generate summary... 和 Revert 操作。JetBrains 的快速入门说明，你可以保留、编辑、提交或回退修改后的文件。

按以下顺序审查：

1. 范围： 是否只有预期文件发生了变化？
2. 行为： 实现是否准确解决了目标故障？
3. 测试质量： 如果没有这次修复，新增测试是否会失败？
4. 副作用： 配置、依赖或公共接口是否被改动？
5. 验证： 离开智能体的过程描述后，你亲自运行的测试是否仍然通过？

如果 diff 已经接近正确，可以自行编辑，或给下一轮留下精确反馈。如果修改范围出乎意料，就回退并用更严格的 prompt 重新开始。不要因为解释听起来合理，就用一次 commit 奖励它。

JetBrains Air 的成本账怎么算

Air 改变的是编排这一项成本，不是底层智能能力的价格。插件的软件费用增加 $0；接入的智能体则可能消耗现有订阅、API 余额或 JetBrains AI 额度。

对于已经为智能体付费的团队，这一点很关键。在还没人知道第二个控制界面能否改善审查之前，它往往先意味着又多一个 seat。以公开价格作参考，GitHub 目前列出的 Copilot Business 是每位用户每月 $19，Enterprise 是 $39。十个 Business seat 每月就是 $190，额外用量尚未计入。Air 可以连接受支持的智能体，不额外收取 Air 插件费用，但 IDE 许可证、provider 订阅、API 用量和人工审查时间都不会因此消失。

所以，真正要回答的预算问题很窄：这个免费的本地审查界面，能否让现有智能体投入更容易被指挥和验证？先用一个团队、同一类任务做测试，再决定是否购买或标准化其他东西。

六类使用场景：谁最能从中受益

1. 已经为多个智能体付费的 JetBrains 团队

如果工程团队让 Codex 负责一类工作、Claude 负责另一类工作，就可以从同一个 IDE 环境启动两者，为它们附加同一份项目上下文，并在一处审查被修改的文件。收益并不一定是 token 更便宜，而是减少工具切换，并围绕团队已经购买的订阅建立一致的审查习惯。

2. 处理小型、可测试缺陷的维护者

维护者可以附加出错的辅助函数，说明一个回归问题，要求补上一条聚焦的测试，并在改动进入分支前审查 diff。当诊断已经明确、机械式修复却会挤占更深入工作的时间时，这种方式最划算。

3. 刚进入陌生客户代码库的顾问

顾问可以借助 IDE 的代码导航检查 symbol，只附加相关文件，再要求智能体完成边界清晰的改动。把任务留在临时分支中并使用 Standard Access，可以降低陌生仓库规范导致修改失控的概率。其价值在于更快熟悉项目，而不是假装智能体知道客户没有写明的规则。

4. 把可复现 bug 变成回归测试的 QA 工程师

能够复现 bug 的 QA 工程师，可以附加相关文件和测试区域，要求生成最小回归测试，再检查这条测试是否真的捕捉到故障。价值在于缩短从复现问题到形成可审查工程产物的交接路径。

5. 通过具体 diff 教授审查方法的资深开发者

资深开发者可以让智能体先提出一个小型实现，再带着经验较少的同事，在熟悉的 IDE 中逐项讨论范围、假设、测试设计和回退决策。产出不只是代码，也是一场围绕真实改动集展开、过程可见的审查练习。

6. 在同一任务上比较智能体的平台团队

平台团队可以使用不同预设运行同一个边界明确的任务，然后比较改动文件、测试行为、批准次数和审查投入。相比对照聊天回答，这种评估更有价值，因为判断单位是在同一仓库中经过验证的改动。

值得围绕 JetBrains Air 构建的两类产品

1. 为智能体改动生成审查证据的 sidecar

这是更强的机会。可以做一个小型配套工具，把智能体会话整理成审查包：任务、附加的上下文、改动文件、测试命令、测试结果、人工决策和最终 commit 引用。工程经理和受监管团队会愿意为一份清晰记录付费，而且它不依赖究竟是哪一个智能体生成了代码。

需求足够具体：ai powered code review platform 在美国每月约有 1,900 次搜索，并带有商业意图。GitHub 的 Business seat 为 $19、Enterprise seat 为 $39，也说明团队已经在为编码辅助和治理留预算。

最小可售版本不必控制智能体。它可以接收 diff 与测试输出，要求 reviewer 完成 checklist，再导出签名后的 Markdown 或 JSON 记录。风险在于平台：Air 仍处于 Alpha，接口可能每周变化，JetBrains 也可能自行补上更丰富的证据或审计功能。因此，护城河必须是跨智能体策略与耐久报告，而不是某个 IDE 里的一个轻量按钮。

2. 针对具体仓库的智能体配置顾问

可以做一款 onboarding 工具：检查仓库所用语言、测试命令、敏感路径和贡献规范，然后推荐安全的首次任务模板与预设配置。它适合卖给需要在多种仓库中采用智能体的团队，因为现在每位开发者都在重复配置工作。

广义需求规模很大：ai coding assistant 在美国每月约有 18,100 次搜索，ai powered coding agent 约有 8,100 次。MVP 可以由仓库问卷、自动生成的配置说明、边界明确的起步 prompt 和冒烟测试 checklist 组成，初期不需要深度集成 IDE。

难点是防御性。JetBrains、智能体厂商或仓库模板都可能吸收通用配置建议。产品要成立，就必须加入组织专属的策略检查，并拿出证据证明推荐配置能够减少失败或范围失控的改动。

JetBrains Air 的局限，以及客观结论

如果你本来就偏爱 JetBrains IDE，同时希望保留智能体选择权，又不想放弃 IDE 原生审查，Air 最有价值。但它绝不是把无法验证的高风险改动交出去的理由。

目前有三个约束最重要：

• 它仍是 Alpha。 标签和行为可能按约每周一次的发布节奏变化。
• 插件免费，工作并不免费。 智能体授权、订阅、API 用量、IDE 许可和人工审查仍是彼此独立的成本。
• 本地才是可靠的起点。 IDE 页面仍把云端接力描述为即将推出，因此首次工作流不要建立在合上笔记本后任务仍会继续这一前提上。

Standard Access 也不等于只读。它允许智能体修改项目内文件并运行命令。请使用临时分支或 worktree，检查 diff，并亲自重跑测试。

结论很直接：如果 JetBrains 已经是日常工作环境，Air 值得用一个小改动试一试；但如果没有回退方案、provider 策略和审查证据，现在还不适合把它定为敏感仓库的强制入口。

下周一就做这一件事

挑一个能用一条命令测试的 bug，把它放到临时分支中，在一台开发者机器上安装匹配的 Air Alpha 构建，选择 Standard Access，附加一个相关文件，然后要求最小修复和一条回归测试。只有当 diff 足够克制，而且你亲自运行测试也能通过时，才保留改动。这一个闭环，比看一周智能体演示更能说明问题。

JetBrains Air 有什么用？

JetBrains Air 负责协调编码智能体，以及智能体在 JetBrains IDE 内外使用的上下文、会话和审查流程。在本地 IDE 插件中，你可以选择智能体，发送带项目上下文的任务，再到 Agent Sessions 中检查最终改动。

JetBrains Air 和 Claude Code 的主要区别是什么？

Claude Code 是一个编码智能体。Air 则是多智能体控制与审查界面；根据现有集成和授权情况，它可以同时运行 Claude、Codex、Junie、GitHub Copilot、Gemini、OpenCode，以及兼容 ACP 的智能体。

哪款 IDE 最适合智能体编程？

没有放之四海而皆准的赢家。如果团队已经依赖 JetBrains 的导航、检查和 diff 工具，Air 很有吸引力。真正合适的环境，是你能够可靠约束、检查、测试并回退智能体工作的环境。

JetBrains 可以免费使用吗？

Air Alpha 插件免费；JetBrains IDE 以及 Air 背后的智能体可能另有许可证、订阅或 API 成本。

如果你希望围绕自己的仓库和审查规则建立一套安全的智能体工作流，可以了解 AI 智能体开发。