过去两年，如果你是一名软件工程师，肯定已经接触过一些 AI 编程工具：

• GitHub Copilot
• Cursor
• Trae
• Qoder
• Claude Code
• Codex CLI

AI 正在迅速进入软件开发流程，但如果只是简单列举工具，很难真正理解这个生态。

本文将从两个维度来看AI编程工具的发展变迁：

1. 工具形态：AI 通过什么界面进入开发流程。
2. 交互方式：开发者如何与 AI 协作。

如果把 AI 编程工具的发展放在这两个维度上观察，就会发现一个非常清晰的演化趋势：

工具形态
插件 → AI IDE → CLI Agent

交互方式
自动补全 → 对话 → 编辑修改 → 智能体

这两条路径彼此影响，构成了今天的 AI 编程生态。

工具形态：AI 如何进入开发环境

先来看工具形态，也就是：

AI 是通过什么工具进入开发者的本地环境的。

在今天的本地开发工具生态中，大致可以分成三类：

需要注意的是：本文中的分类是按工具的主流使用形态来区分的
因为在 AI 编程工具生态中，一个产品往往同时存在多种入口。例如：

• Copilot 虽然同时提供 IDE 插件、CLI、Web，但大家通常对他的认识还是VSCode中的插件
• Codex CLI 虽然主要是 CLI，但也可以在IDE中作为插件调用，同时还具备自己的APP

IDE 插件：AI 先作为附加能力进入 IDE

AI 编程工具最早进入开发者工作流的方式，其实非常简单：

IDE 插件

代表工具包括：

• GitHub Copilot
• Tabnine
• Amazon Q Developer

这些工具有一个共同特点：

AI 只是 IDE 的一个附加能力。

开发者仍然使用熟悉的编辑器，例如：

• VS Code
• JetBrains IDE

AI 只是帮助完成一些重复性工作。

例如，当你写下这样的代码：

# quicksort in python
def quicksort(arr):

AI 很可能会直接补全整个函数。

第一次体验这种功能时，很多工程师都会产生一种类似的感觉：

就像有一个人坐在旁边帮你写代码。

但从开发流程的角度看，这一阶段并没有发生根本变化。

开发者仍然需要自己：

• 设计架构
• 组织模块
• 调试程序

AI 的角色更像是：

一个更聪明的自动补全工具。

AI IDE：AI 从附加能力变成环境本身的一部分

随着大模型能力提升，一个问题逐渐变得明显：软件开发不仅仅是写代码。真正复杂的部分往往是：

• 理解项目结构
• 修改已有代码
• 跨模块重构
• 更新测试

传统 IDE 插件很难很好地支持这些任务，因为它们通常只关注当前文件，或者只能有限地理解上下文。于是出现了第二种工具形态：

AI IDE

代表工具包括：

• Cursor
• Trae
• Qoder
• Windsurf
• Kiro
• Antigravity
• CodeBuddy

这些工具的设计理念与 Copilot 有明显区别。它们并不是在 IDE 上“加一个 AI”，而是把 AI 当作 IDE 的核心能力。
在这种环境下，AI 看到的已经不只是当前文件，而是整个项目结构、相关依赖和上下文关系。

例如，开发者可以直接用自然语言描述修改意图：“给这个 API 增加分页功能。”

AI IDE 可能会自动完成以下工作：

• 修改控制器（controller）
• 更新服务层（service）
• 调整数据库查询
• 更新测试代码

这意味着 AI 已经不仅仅是在写代码，而是在参与 整个项目的修改过程。开发流程开始发生变化：开发者不再只是编辑代码，而是开始描述 修改意图。

CLI Agent：在更高能力层级上回到终端

最近一年，另一种工具形态迅速受到关注：

CLI 智能体（CLI Agent）。

代表工具包括：

• Claude Code
• Codex CLI
• Gemini CLI
• OpenCode
• Qwen Code
• Aider

与 IDE 插件和 AI IDE 不同，这类工具直接运行在终端中。例如使用 Codex CLI 时，你可能会看到这样的界面：

$ codex
> fix failing tests
> add oauth login

如果只看表面，这会让人觉得像是一次“倒退”：怎么连图形界面都没了，又回到了简陋无比的终端界面。
但如果把开发工具的历史线拉长，这种变化其实又是一种螺旋上升。

在图形界面 IDE 成为主流之前，软件开发本来就是围绕终端展开的，早期开发者使用：vi, emacs此类纯终端的开发工具，并通过终端完成完整开发流程：

• 编辑代码
• 编译程序
• 调试程序
• 运行构建脚本

后来，Visual Studio、Eclipse、IntelliJ IDEA、Xcode 这样的图形界面 IDE，把这些原本分散在命令行里的动作整合进统一界面中，开发效率和体验都得到了显著提升，IDE 也因此长期成为开发环境的中心。

但 AI Agent的出现改变了这一点。因为当 AI 开始执行完整开发任务时，它真正需要控制的不是某个编辑器窗口，而是开发流程本身：

• 阅读代码仓库
• 修改文件
• 运行测试
• 执行构建
• 提交 Git

这些动作在 GUI 中看起来是不同的按钮和面板，但在底层，它们本来就是命令。因此，对 Agent 来说，终端反而是最自然的运行环境。CLI 智能体直接运行在这个控制层上，因此拥有更大的自由度，也更容易与现有工具链结合。

如果从更长的历史来看，这其实是一种回归：

终端编辑器
    ↓
图形界面 IDE
    ↓
AI IDE
    ↓
CLI 智能体

开发工具似乎再次回到了终端。但这不是简单重复，而是一种 螺旋上升。

早期终端只是文本编辑器和命令行工具。
今天终端里的 Claude Code 或 Codex CLI 已经能够：

• 理解整个代码仓库
• 修改项目结构
• 运行测试
• 自动完成开发任务

终端重新成为中心，但它承载的已经不是手工操作，而是 开发流程自动化。

交互方式：开发者如何与 AI 协作

如果说工具形态回答的是“AI 以什么形式进入开发环境”，
那么交互方式回答的就是另一个更核心的问题：

开发者究竟在让 AI 做什么。

从过去几年的发展来看，这种协作方式大致经历了四个阶段。

自动补全（Autocomplete）：AI 先从补全代码开始

最早的 AI 编程工具几乎都属于这一类。

在这个阶段，AI 的作用非常简单：

根据当前上下文预测下一段代码。

这种体验最直观的地方在于，它几乎不改变原有工作方式。
开发者仍然像以前一样写函数、改逻辑、调试代码，只是输入时多了一个非常聪明的补全器。

从协作关系上看，这时的 AI 仍然是被动的。
开发者写到哪里，AI 补到哪里。

它不能主动解释代码，也不能理解更高层的任务目标，更谈不上接管某个开发流程。

因此，这一阶段的核心不是“AI 会写代码”，而是：

AI 先学会了在局部上下文中预测代码。

这也是为什么最早流行起来的是 IDE 插件。
因为对“补全”这种交互方式来说，插件已经足够自然，也足够低摩擦。

对话（Chat）：AI 开始成为可对话的开发助手

随着模型能力增强，AI 开始支持自然语言对话。这是交互方式的一次明显跃迁。

开发者可以直接在编辑器中提问，例如：

• “这段代码在做什么？”

这种变化带来的影响不只是“更方便”，而是角色发生了变化。

在自动补全阶段，AI 更像输入法。
到了对话阶段，AI 开始像一个可以随时提问的开发助手。

它开始承担两类新的任务：

一类是解释，例如解释代码逻辑、说明报错原因、分析依赖关系。
另一类是生成，例如写测试、写注释、写一段样板代码。

很多开发者第一次真正感受到 AI 对开发流程的改变，其实不是来自自动补全，而是来自这里：
你开始可以直接“问它问题”，而不是只等它补全代码。

编辑修改（Editing）：AI 从回答问题走向修改项目

对话之后，交互方式继续向前推进。

如果说对话的重点是“理解和解释”，
那么编辑修改的重点就是：

让 AI 直接修改项目。

在这个阶段，开发者给出的不再只是局部问题，而是更高层的修改意图，例如：

• “把这个模块改成异步实现。”
• “把这个服务拆成两个子模块。”
• “给这个 API 增加分页。”

完成这些任务时，AI 往往需要跨多个文件工作：

• 修改业务逻辑
• 更新导入（import）
• 调整接口定义
• 补上测试

这意味着 AI 开始真正参与 项目级别的代码变更。

而这也是 AI IDE 迅速流行的重要原因。
因为如果工具仍然只停留在插件层，AI 很难稳定地处理这种跨文件、跨模块的任务。

所以这里能看到两条路径之间很清楚的呼应关系：

• 交互方式从对话走向编辑修改
• 工具形态也从插件走向 AI IDE

开发者想让 AI 做的事情变了，工具形态也随之演化。

智能体（Agent）：AI 从修改代码走向执行任务

最新的阶段是 智能体。

在这一阶段，开发者给 AI 的不再是局部问题，也不只是修改意图，而是 任务目标。

例如：

• “修复当前失败的测试。”
• “给这个服务增加 OAuth 登录。”
• “升级所有依赖并修复兼容问题。”

为了完成这些任务，AI 通常不会一次性给出答案，而是进入一个循环过程：

1. 阅读代码仓库
2. 修改相关文件
3. 运行测试或构建
4. 根据结果继续调整代码

这个循环可能会执行多轮，直到任务完成。

这与前几个阶段最大的不同在于：

在自动补全、对话、编辑修改里，AI 更多是在“响应请求”。
而到了智能体阶段，AI 开始围绕一个目标主动组织步骤。

这也是为什么 CLI 智能体会在这个阶段迅速崛起。因为一旦交互方式进入智能体工作流，AI 需要操作的已经不是单个文件，而是整个开发环境和工具链。而终端正好提供了最直接的控制面。

所以可以说，CLI 智能体的流行并不是单独发生的，而是交互方式演进到智能体阶段后的自然结果。

CLI 工具流行的另一个原因——订阅绑定

除了技术原因，CLI工具的流行还有一个很重要的现实因素：

订阅体系

目前OpenAI和Claude这两大 AI 公司都采用类似策略：

也就是说，当开发者购买模型订阅时，官方提供的默认编程入口就是 CLI 智能体。用户订阅后自然而然就会倾向于使用官方推荐的工具体系。

需要注意的是：形态与交互并不一一对应

需要特别注意的是，尽管交互方式的变动推动着工具形态的变化，但工具形态和交互方式，并不是一一对应的。

一方面，同一个名字的工具，可能同时提供多种形态。
比如Codebuddy既有 IDE 插件，也有独立 IDE、CLI。本文在分类时，说它属于某一种形态，通常只是指它最典型、最主流的使用方式。

另一方面，同一种形态，也可能支持多种交互方式。
例如，一个 AI IDE 既可以做自动补全，也可以做对话问答、跨文件编辑，甚至支持 Agent 式任务执行；CLI 工具也不一定只用于 Agent，同样可以承载问答和局部修改。

结语

如果把时间线拉长，AI 编程工具并不是一段孤立的技术插曲，而是软件开发工具持续演进中的最新一环。

软件开发环境的变化，始终围绕两个问题展开：

一个是，开发者通过什么界面组织开发过程；
另一个是，工具能替开发者承担多少工作。

从早期终端，到图形界面 IDE，再到可扩展的插件体系，软件开发工具一直在朝着更高效、更集成、也更可组合的方向演化。

AI 编程工具在其上继续推进。

一方面，工具形态在变化：从插件，到 AI IDE，再到回到终端的 CLI 智能体。
另一方面，交互方式也在升级：从自动补全，到对话、编辑修改，再到围绕目标自主执行步骤的智能体。

对 Agent 来说，它需要操作的不是某一个编辑器界面，而是文件、命令、测试、构建、版本控制这些开发流程背后的真实控制面，而这些能力本来就属于终端。

所以，CLI 再次成为焦点，并不意味着倒退，反而更像是一种更高能力层级上的回归：工具回到终端，但目标已不再是手工执行命令，而是让系统参与完成任务。