# IDE 已死 ADE 当立：未来的开发环境
IDE 指“集成开发环境”，由人提供动力，消耗头发与脑细胞，典型的有 VSCode、IntelliJ IDEA、Neovim 等。
Code Agent 指使用 AI 生成代码的工具，由大模型提供动力，消耗 token 与电力，典型的有 Claude Code、Codex、OpenCode 等，后文简称为 Agent。
ADE 指“Agent 驱动开发环境”，它应该是什么样子，现在还没有定论，本文聊一些我的看法。
# 近一年开发模式巨变
2025 年中，我对于 Agent 编程能力的印象是 —— 编写函数级代码的效果还不错，如果让它编写功能模块，调试 bug 消耗的时间，还不如自己手写。
当时费了很大力气，搭建了基于 Neovim 的纯键盘开发环境，纵享丝滑～ 配合 Agent 插件做苦力活，效率拉满。
这个状态持续不到半年，就被老板提醒开发效率太低，于是接受建议，开始尝试基于 Agent 的 SDD（Spec 驱动开发）工作流；
嚯，没想到 AI 进步这么快，只要我仔细检查、修正 Spec 文档内容，让它独立实现一个模块级功能也基本够用。
2026 年上半年，我试用了一些流行的 SDD 方案，最终根据自己的经验或习惯编写 SDD skill，此后基本只看文档不怎么阅读代码了，半小时完成一个模块，感觉自己强得可怕。。。
没过多久，我发现虽然不读不写代码了，但仍然很累，时间都消耗在编写 Spec 背景信息、阅读理解 Spec 文档、对 Spec 文档进行纠错与决策；
Agent 执行编码任务则快得多，总感觉被 Agent 追着跑，更别说达到传说中让 Agent 并发执行任务的境界。
于是在 2026 年中，我开始开发 ADE 产品 —— YorZ（柚子） (opens new window)，完美实现多任务并发，使劲压榨 Agent，还能抽空摸鱼，太爽了～
以后再分享 YorZ 的设计与实现，本文先继续聊 IDE 与 ADE。
# IDE 已死
传统 IDE 的 UI 非常复杂，可交互元素、快捷键都超级多，上手门槛极高。
开发者在 IDE 中编写代码已有悠久的历史，IDE 形态可以总结为：
- 核心组件：代码编辑器、文件管理、调试面板
- 再搭配通用的辅助提效模块：快捷键、版本管理、代码补全、语法高亮
- 然后通过插件系统满足个性化需求
要不是 AI 入侵，这种形态将持续下去，缓慢地演进；
然而变化来得过于凶猛，所有 IDE 都赶紧内置一个 AI 对话框插件，但仍无法挽救 IDE 这种工具形态的消亡命运；
IDE 搭配 AI 对话框，就像在牛车马车上装一个汽车引擎，顶多给牛马省省力，速度肯定提不上来。
注意，这里说的是 IDE 形态消亡，并不意味着 IDE 产品会死亡，如 VSCode 已经有了 Agent 模式；
两年之后，你可能还在使用 VSCode 编程，但它肯定不再是 2025 年之前的样子了，它要活下去就必须进化到 ADE 形态。
# Agent 还不够
最开始 Code Agent 都运行在终端环境，跟 IDE 相反，它们的 UI 都极度简化，甚至过于简陋，就一个对话框；
由于现在的 AI 实在太聪明，加上 Agent 零门槛就能上手，现在只要会打字/会说话都可以开发程序，好不好用另说，小型程序跑起来肯定没问题。
对中大型项目进行长期开发维护，Agent 明显不能满足所有需求，某些场景不得不打开 IDE。
我总结为两个方面的原因：
- 缺失开发过程中必要的 UI 组件；比如偶尔需要看具体代码，或了解文件目录结构，但缺少代码预览与文件树组件
- 无法满足个性化诉求，因为没有插件系统或开放给插件的能力不够；比如社区大量采用 SDD 工作流来改进 Agent 开发体验，但无法开发合适的 UI 来管理 Spec 文档
终端中的 Agent 就像电车底盘，速度可以很快，但驾驶体验肯定好不到哪里去。
就像 IDE 会集成对话框，让 Agent 来生成代码；
现阶段 Agent 厂商也普遍发布了桌面端产品，集成 IDE 中的高频 UI 组件，比如 Git 管理、命令行终端。
# ADE 的形态
IDE 与 Agent 都在参考彼此改进自身，那 ADE = Agent + IDE 吗？
我认为还不够，由于底层的动力引擎切换了（人 -> AI），上层的 UI 必须适应新的引擎。
打造成熟形态的 ADE，还要做好以下三件事：
- 要根据 AI 引擎的特性量身定做新的 UI 组件，比如：
- 对话框组件；因为 AI 主要是输出文字信息，所以必然需要一个对话框进行人机交流
- 并发任务管理组件；因为 AI 天然适合并发执行任务，所以必然需要管理运行中的任务，为任务并发执行创造环境（如 git worktree）
- 要改造传统 IDE 中仍有价值的高频 UI 组件，让它们适配新的环境，比如：
- 我已经不敢想象逐函数断点 Debug 代码了，但 Debug 疑难问题的需求仍然存在，所以应该设计更适合人与 AI 配合的 Debug UI 来替代调试面板
- 我现在已经不太关心具体的代码文件，但仍然需要了解整个系统的架构，所以应该设计系统模块架构图 UI 来替代文件树
- 同时还需要开放的插件系统来满足个性化需求，比如：
- 某些人不习惯所有版本管理操作都交给 AI，就至少需要一个简单的 Git 插件
- 某些人习惯使用 SDD 工作流，会产生大量 spec 文档，那么需要一个 Spec 插件来管理这些文档
鉴于 AI 使得开发程序的交互变得极其简单，同时让程序开发的生产力实现飞跃，除上述三点外，还可以推测成熟形态的 ADE：
- 应该支持移动端，因为交互足够简单，在手机上开发软件的条件已经具备
- 应该支持扩展自身，即在本地开发插件集成到 ADE 自身，而不是强调去插件市场下载；因为生产力提升往往会带来个性化需求的爆发
有机会可以深入聊一聊具体的 ADE UI 设计
# 关于质量的担忧
IDE 形态是传统开发过程所塑造的，开发者追求代码的精确、简洁，相对来说 Agent 输出的代码更加混乱、冗余。
如果全面倒向 ADE，完全让 Agent 生成代码，如何保证软件质量呢？
2025 年初的时候，蛮多人说让 AI 生成代码节省的时间，还不够弥补修 Bug 浪费的时间，现在这种声音越来越小，快要消失了，因为 AI 不仅编程能力进步巨大，修 Bug 的速度也比资深程序员快多了；
如果你现在还感觉 AI 修不了疑难 Bug，那很可能是使用方式需要改进，比如：
- 提供 Bug 相关的所有详细上下文信息（背景信息、重现步骤、相关代码等），而不只是简单描述现象
- 限制 AI 必须以日志或截图为真相依据，禁止无证据猜测、禁止单纯靠源码逻辑推测
就算极端情况 AI 删了数据库，咱也只能想办法避免它犯第二次错误，不可能以后放弃使用 AI；
如同汽车出现后，我们可以制定交通法规（行驶规则、限速、红绿灯），但无法阻挡汽车上路。
所以，为了软件质量更应该积极地打造 ADE 配套的质量工具，针对精密场景制定更严格规则，以适应 ADE 新时代。
# 最后
一两年前大部分代码都还是手写的，现在回头一看，古法编程的技艺恐怕要靠非遗才能传承下去了。
AI 编程能力进步太快，一年左右的时间，我换了好几次开发模式，这次不知道能持续多久（现在又感觉手动测试有点烦），希望 ADE 产品形态快点成熟稳定，快折腾不动了。
关于我对 ADE 形态的思考，可参考我的开源项目 YorZ (opens new window)，虽还在起步阶段，但已覆盖我 95% 以上的开发工作，感兴趣可以关注。
我相信未来 ADE 的终极目标是：流水线式生产质量可控的程序代码；工业批量生产将替代手工制作。
编程源于纺织行业，程序员终将像纺织工人一样被机器替代，多么美妙又残酷的循环啊～