IDE已死？开发者正集体逃离编辑器

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：程序员不再“写”代码，而是在“管”智能体。当IDE退化为底层工具，编程的重心正向“编排层”大迁移。文章来自编译。

开发者工作的重心正在转移。不是消失，而是转移。它正在从在单一窗口内进行持续的、逐行的编辑，转向监督那些能够规划、重写文件、运行测试并提交更改以供审查的智能体（Agents）。我们所熟知的 IDE 也许将不再是软件开发的首要工具，或者将发生剧烈演变。

在包括我自己在内的许多开发者每天都在使用的工具中——如 Conductor、Claude Code Web、GitHub Copilot Agent、Jules、Vibe KanBan，甚至 cmux——同样的转变在不断显现：控制面（control plane）正在成为主要的交互界面，而编辑器则退居其后，成为其下的数个工具之一。

Cursor 刚刚发布了 Glass——这是一个专门为“让与智能体协作变得清晰、直观且可控”而打造的新界面。在这里，智能体管理成了核心体验，而传统的编辑器则成了当你需要深入细节时才去动用的工具。开发者的反应立竿见影：

“现在的 Cursor 感觉更像是一个智能体编排器，而不是 IDE。并行管理智能体变得更容易了。”

但 Glass 只是大趋势中的一个数据点。像 cmux 这样的终端 UI 突显了我们熟悉的界面是如何演进，以更好地管理智能体工作流的。

cmux 终端应用截图

从编辑文件到驾驭工作流

从历史上看，IDE 针对“紧凑的内部循环”进行了优化：打开文件 → 编辑 → 构建 → 调试 → 重复。所谓“终结”其论点是，一旦智能体能够自主执行其中的大部分环节，这个循环就不再是生产力的核心单位。

新的循环看起来是这样的：指定意图 → 委派 → 观察 → 审查差异 (diffs) → 合并。它与“带聊天窗口的自动补全”之间的区别在于，它具备工具使用的自主性，并配有旨在让这种自主性可控的界面。

你可以看到，在已经广泛使用的工具中，这一趋势正在上演。Claude Code Web（或桌面版）和 Codex 让开发者可以将定义明确的任务交给在隔离云环境中运行的智能体，进度在浏览器中可见——无需终端，无需本地环境配置。

GitHub Copilot 的智能体可以独立规划并实施多文件更改、创建分支、运行测试，并提交 PR 供审查；开发者的主要工作变成了审查结果并进行迭代，而不是指挥每一个步骤。

Conductor 采取了不同的方法：一个桌面应用，用于在隔离的工作区中同时运行多个 Claude Code 智能体，并实时监控所有智能体的进度。而 Google 的 Jules 则处理异步后台任务——你分配工作，它运行，完成后你再查看结果。

这些工具的共同之处在于一种心智模型：工作单位是智能体，而不是文件。值得优化的界面是那些能帮助你指挥、监控和审查智能体的界面，而不是那些帮你打字更快的界面。

编排层初具规模

只有当你观察到不同工具之间趋于一致的特定界面模式时，这种“取代论”才具有说服力。

工作隔离作为一项原语（primitive）。并行运行的智能体需要互不干扰。几乎这个领域所有严肃的工具都选择了 git worktrees（或类似技术）作为解决方案。Conductor 将每个智能体会话映射到其独立的隔离工作区。Vibe Kanban（如上图所示）在其看板驱动的智能体工作流中也做了同样的处理。这种模式几乎无处不在，因为问题是真实存在的：没有隔离，并行运行的智能体就会制造混乱。

规划和任务状态作为主要 UI。像 Vibe Kanban 这样的工具已经用“任务和状态”取代了“标签页和文件”，将其作为最高层级的心智模型。你创建任务卡片（一个落地页、一个后端服务、一个邮件集成），将每个任务分配给一个智能体和模型，并像管理轻量级项目看板一样管理整个工作——只不过这个“团队”是在自主运行。这是一个恰好由智能体负责实施的项目管理界面。

后台智能体与异步优先设计。这个领域当中一些最有趣的工具甚至让你在执行过程中保持同步都不尝试了。Cursor、Copilot 以及 Antigravity 都支持后台智能体，它们无需你在场即可运行——你定义意图，然后离开，等它们完成后再回来审查。Jules 的运作方式类似：分配任务，回来查看代码差异（diff）。其潜台词是，你的注意力太宝贵了，不应浪费在盯着进度条上。这与 IDE 那种实时的、同步的反馈循环有着显著的不同。

并行智能体的注意力管理。当许多智能体并发运行时，真正的瓶颈在于知道哪一个现在需要你。这就是为什么像 Conductor 这样的工具会展示跨会话的实时进度，而 cmux 则为终端窗格引入了通知环和未读标记。“智能体需要关注”正在成为开发者环境的一等公民事件——这是需要路由和分流的任务，而不仅仅是被注意到。

嵌入软件生命周期的智能体。GitHub 的 Copilot 编程智能体是异步的，受控制层保护，并由 GitHub Actions 驱动——它与代码实际交付的方式（Issue → PR → CI → 合并）挂钩，而不只是与代码编写的方式挂钩。

没有任何工具声称 IDE 已经过时——许多工具仍然与之互操作。但这些不断重复的模式（并行工作区、差异优先的审查、任务状态、后台执行、生命周期集成）正是“IDE 终结”的支持者在谈论重心转移时所指的东西。

为什么开发者仍然需要 IDE

对“IDE 已死”论调最好的反驳是：IDE 仍然将几个真正棘手的问题压缩到了一个高保真反馈循环中：精准导航、局部推理、交互式调试，以及通过直接操作来理解系统的能力。

即使是最雄心勃勃的编排工具也保留了手动编辑的“逃生出口”。比方说，在线程内审查差异、对更改发表评论，然后在编辑器中打开结果进行手动调整。这承认了人工干预仍是预期工作流的一部分。

智能体工具本身也凸显了局限性所在。大型仓库中的多文件重构仍然是软件工程智能体面临的最艰巨挑战之一。在这些场景下，交互式代码导航和人类判断仍然最为关键——你需要持有系统的整体心智模型，而智能体无法仅凭上下文完全重建该模型。

让开发者坚持使用 IDE 级检查的失败模式是“智能体做得就差那么一点点”。当某件事有 90% 的正确性却存在细微错误时，寻找问题的成本往往超过了你自己动手编写的成本。对于高风险的变更，IDE 仍然是进行深层、精确检查的最佳工具。

新的代价：审查疲劳与治理开销

如果开发变成了“并行运行多个智能体”，工作流就会继承一些更像分布式系统管理而非文本编辑的问题——可观测性、权限、隔离和治理。

智能体工作流反转了劳动模式。你不再是编写者，而是审查者。这听起来像是一种进步，直到你在一天结束时盯着来自 12 个并行智能体的 12 份代码差异（diffs）。审查疲劳真实存在，这也是为什么这个领域最深思熟虑的工具都专注于注意力路由、结构化计划和审查优先的关卡，而不是默认推动完全的自主性。

随着智能体获得更多工具、仓库和外部系统的访问权限，安全面也在扩大。当智能体可以浏览网页、查询数据库、写入文件系统并触发部署时，它们“被允许做什么”变得与它们“能做什么”同样重要。

在可观测性和控制方面，集成在 IDE 中的智能体模式已经开始推动显式的工具日志和审批关卡。一旦智能体进行异步操作并触及 CI 流水线，治理问题就不再是可选项。

谁会幸存：IDE、控制面，还是两者兼有

对现状的清晰解读是：“IDE 已死”在方向上是正确的，但作为一种字面上的预测则是错误的。

这一主张最强力的版本是：IDE 不再是主要的办公空间，而是退化为几个从属工具之一——用于针对性的检查、调试和最终编辑；而规划、编排、审查和智能体管理则转移到了仪表板、任务追踪器、可观测终端和云控制面中。

“大 IDE”的构想同样得到了充分支持。新的“IDE”是一个提供多智能体编排、隔离工作区、权限和审计日志、差异优先审查、可靠工具连接以及注意力路由的系统。文件编辑器依然存在，只是它不再是入口。

IDE 并没有走向消亡，它正在被“去中心化”。工作重心正在向外迁移——迁移到编排界面，人类回到那上面去定义意图，委派给并行的智能体运行环境，并花更多时间进行监督、审查和治理，而不是敲键盘。

IDE 对于正确性、理解力以及智能体仍难以应对的棘手问题依然至关重要。但它不再是做编程这件事情的唯一场所——而且对于越来越多的人来说，它不再是他们的首选之地。

译者：boxi。