JetBrains 动手了。
这家统治了 Java、Kotlin、Python 开发者工具链近二十年的公司，刚刚发布了一个和自家 IntelliJ 系列完全不同的东西——Air。它不是又一个带 AI 补全的 IDE，而是一个从底层逻辑就不一样的产品：你不写代码，你写任务描述，然后看 AI 干活。
JetBrains 给它的定位叫 ADE（Agentic Development Environment，智能代理开发环境）。注意，不是 IDE。这个命名本身就是一个信号：他们认为开发者的核心工作正在从「编写」转向「调度与审查」。
一句话讲清楚 Air 是什么
传统 IDE 的工作流是：你写代码 → 编译 → 调试 → 提交。
Air 的工作流是：你描述任务 → AI Agent 规划并执行 → 你审查结果 → 合并或打回。
听起来像 Cursor、Windsurf 或者 Devin？表面上是，但 JetBrains 的切入角度不太一样。
核心设计：Task 是一等公民
Air 的整个交互模型围绕「任务（Task）」构建。这不是聊天窗口里随便打一句话那种任务，而是一个有明确生命周期的工作单元：
- 用户用自然语言描述需求
- Agent 分析上下文，制定执行计划
- 任务在隔离环境中运行（本地工作区、Git worktree、Docker 容器，未来还会支持云容器）
- 执行完成后进入审查阶段
- 用户决定接受、修改或拒绝
关键词是「隔离」。每个任务跑在独立的环境里，不会污染你的主分支。这解决了现有 AI 编码工具的一个大痛点——你让 AI 改了一堆文件，结果发现改坏了，回滚成本极高。Air 的做法更接近 Code Review 的心智模型：Agent 提交的是一个「待审查的变更集」，而不是直接往你的代码里塞东西。
多 Agent 并发，这才是真正的差异化
市面上大多数 AI 编码工具是单线程的——你给一个指令，等它做完，再给下一个。Air 支持多个 Agent 并行工作。
什么意思？你可以同时开三个任务：
- 一个 Agent 在重构用户认证模块
- 另一个在写单元测试
- 第三个在修一个 CSS 布局 bug
它们各自在独立的 Git worktree 里干活，互不干扰。你像一个技术负责人一样，分配任务、巡视进度、审查产出。
这个设计哲学很有意思。它不是在模拟「一个更快的程序员」，而是在模拟「一个小型开发团队」。JetBrains 显然认为，AI 编码的瓶颈不在单次生成的质量（那是模型层的事），而在于如何高效地调度和管理多个并发的 AI 工作流。
和 Junie CLI 的配合
同期发布的还有 Junie CLI，这是 JetBrains 的命令行 AI Agent 工具。如果说 Air 是图形化的调度中心，Junie CLI 就是可以嵌入 CI/CD 管线的执行单元。
两者的关系类似于 GitHub 的 Web 界面和 gh CLI——同一套能力，不同的使用场景。你可以在 Air 里交互式地调试任务描述，确认效果好了之后，把同样的 prompt 模板丢进 Junie CLI，跑在自动化流水线里。
这意味着 JetBrains 的野心不止于「辅助编码」，而是要覆盖从开发到部署的整条链路。
和竞品比，Air 的位置在哪？
现在 AI 编码赛道已经相当拥挤了，简单做个对比：
| 产品 | 定位 | 核心差异 |
|---|---|---|
| Cursor | AI-native 代码编辑器 | 基于 VS Code，强调内联编辑体验 |
| Windsurf | AI IDE | Cascade 多步推理，上下文理解强 |
| Devin | 自主 AI 工程师 | 全自动，人类介入少 |
| GitHub Copilot Workspace | 任务驱动开发 | 和 GitHub 生态深度绑定 |
| JetBrains Air | 智能代理开发环境 | 多 Agent 并发 + 隔离执行 + JetBrains 工具链 |
我的判断：Air 的真正优势不在 AI 能力本身（底层模型大家都能调），而在两点——
第一，JetBrains 对代码语义的理解深度。做了二十年静态分析、重构引擎、类型推断的公司，在「理解代码结构」这件事上有巨大的积累。这些能力会直接影响 Agent 的上下文构建质量。一个能精确找到「这个函数被哪些地方调用了」的工具，和一个只能做文本搜索的工具，给 AI 提供的上下文质量天差地别。
第二，企业级开发者的信任。用 IntelliJ 的团队，很多是金融、电信、大型互联网公司的后端团队。这些团队对代码安全、审计追溯、权限控制有硬性要求。Air 的「任务隔离 + 审查机制」天然适配这类场景。相比之下，Devin 那种「全自动」的路线在企业落地会遇到更多阻力。
一些值得关注的细节
从目前公开的信息来看，有几个点值得开发者留意：
执行环境的灵活性。任务可以跑在本地工作区、Git worktree、Docker 容器，未来还会支持云容器。这意味着你可以根据任务的风险等级选择隔离程度——改个文案用本地 worktree 就行，重构核心模块可能要丢进 Docker 里跑。
不绑定特定模型。从 JetBrains 近期的 AI 策略来看（Junie 已经支持多种模型后端），Air 大概率不会锁死在某一个 LLM 上。这对开发者来说是好事——你可以根据任务类型选择最合适的模型，复杂架构设计用 Claude，快速代码生成用 GPT，推理密集型任务用 DeepSeek。如果你在用 OpenAI Hub 这类聚合服务，切换模型的成本几乎为零。
审查体验是成败关键。AI 生成代码容易，审查 AI 生成的代码难。如果 Air 的审查界面只是一个普通的 diff view，那它和「AI 提 PR 你来 review」没有本质区别。JetBrains 需要在审查环节提供足够强的辅助——比如自动标注「这段改动影响了哪些下游调用」「这个重构是否保持了行为等价」。这恰恰是 JetBrains 的强项，但目前还没看到太多细节。
这对开发者意味着什么？
说实话，ADE 这个品类还很早期。Air 刚发布，产品成熟度未知，实际体验如何要等开发者大规模使用后才能判断。
但方向是清晰的：开发者的角色正在从「代码的直接生产者」转向「AI 工作流的设计者和审查者」。这不是说写代码的能力不重要了——恰恰相反，你需要更强的代码阅读能力、架构判断力和系统思维，才能有效地审查 AI 的产出。
一个有趣的类比：Air 之于传统 IDE，有点像 Kubernetes 之于手动部署。你不再直接操作底层细节，而是声明你想要的状态，让系统去实现。但你必须理解底层，否则出了问题你连日志都看不懂。
对于团队来说，值得思考的问题是：
- 你的代码库是否有足够好的文档和类型标注，让 AI Agent 能理解上下文？
- 你的 CI/CD 管线是否足够健壮，能兜住 AI 生成代码的质量风险？
- 你的 Code Review 流程是否需要调整，以适应「人审查 AI 代码」这个新场景？
这些问题不是 Air 特有的，而是整个 AI 编码时代的共性挑战。但 Air 的发布，让这些问题变得更加紧迫了。
写在最后
JetBrains 做 Air 这件事本身就很说明问题。这家公司靠卖 IDE 许可证养活了几千人的团队，现在亲手做一个「可能让传统 IDE 变得不那么重要」的产品。要么是他们看到了不得不变的趋势，要么是他们想在变革中掌握主动权。大概率两者都是。
产品地址：air.dev，感兴趣的可以去看看。目前处于早期阶段，建议先观望，等社区反馈出来再决定是否投入时间学习。
参考来源
- Linux.do 社区讨论：JetBrains 出了一个新工具 Air — 社区开发者对 Air 的初步讨论和工具链接分享