我最近越来越觉得，AI 编程工具这件事，已经走到了一个很明显的分水岭。

最早那几年，我们谈的是补全。
后来我们谈的是聊天。
再后来，我们开始谈 Agent。
而现在，我们讨论的已经不是“它能不能帮我写代码”，而是：

我到底要不要继续亲自写这段代码。

这听起来像一句夸张的话，但如果你这两年一路用下来，大概率能感受到那种变化：
开发者和 AI 的关系，已经从“辅助”慢慢变成了“委派”。

而我自己的感受，也是沿着这条线一点点变的。

1. 最开始吸引我的，不是模型，是 Cursor 这种“几乎零门槛”的体验

如果把时间往前拨一点，很多人对 AI 编程的第一印象，其实都不是 Agent，也不是所谓的 Vibe Coding，而是 GitHub Copilot 那种“自动补全”的震撼：2021 年 GitHub 把 Copilot 作为技术预览推出，核心卖点就是根据当前上下文直接补全整行甚至整段代码。那时候它更像一个超强的自动补全器，而不是今天意义上的“开发搭档”。

真正让我感觉“这东西变了”的，是 2023 年之后那一波 AI 编辑器。
GitHub 在 2023 年 3 月把 Copilot X 推出来，开始把聊天、文档问答、PR 支持这些能力往开发全流程里铺；差不多同一时期，Cursor 也开始明确把自己往“不是插件，而是 AI-first editor”的方向推。Cursor 在 2023 年的官方文章里，讨论的就已经不是简单补全，而是代码编辑器里上下文、历史、符号关系、执行痕迹这些更复杂的问题了。

我最开始接触 Cursor 的时候，吸引我的其实不是“它用了哪个模型”，而是那种几乎零学习成本的顺滑感。
你打开编辑器，描述需求，按几下 Tab，代码就开始往外冒。侧边聊天、内联 Diff、一键应用修改，全都在一个窗口里完成。对刚接触这波 AI 编程的人来说，这种体验太容易让人上头了。

它不是那种会让你觉得“我在学习一个新工具”的产品。
它更像是在说：你原来怎么写代码，现在就怎么写，只不过旁边多了个很会接话、还能直接改文件的人。

这也是为什么，很多人最开始都会喜欢 IDE 形态的 AI 工具。
因为它给你的不是能力上的震撼，而是控制感上的安全感。

你能看见每一步改动。
你能看见 Diff。
你能看见文件树变化。
你知道 AI 改了什么，也知道自己随时可以打断它。

对于一个刚从传统开发环境迈进来的人来说，这种“所见即所得”的安心感，比模型榜单更重要。

2. 2024 年前后，我们还在“和 AI 一起写”；到了 2025 年，大家开始“把活交给 AI 写”

如果说 2023 年还是“AI 进入编辑器”的一年，那 2024 到 2025 年，真正发生变化的是：
AI 开始从一个聊天对象，变成一个可以独立执行任务的 Agent。

这个变化在 GitHub Copilot 身上其实很典型。
2025 年 2 月，GitHub 官方公开介绍了 Copilot 的 agent mode，强调它已经可以自主迭代代码、识别错误并尝试修复；到了 2025 年 5 月，GitHub 又把 coding agent 推到更明确的位置上，让它在 GitHub Actions 驱动的环境里完成任务、提交 PR，而且开始覆盖 GitHub CLI 和移动端入口。

Cursor 这一侧也在往同一个方向走。
它现在官方文档里把 Agent 定义得很直接：可以独立完成复杂任务、运行终端命令、修改代码；2025 年推出的 Plan Mode，以及 2026 年推出的 Automations 和 Cloud Agents，本质上都说明同一件事——编辑器本身正在从“人主导、AI辅助”变成“人定目标、Agent执行”。

我自己对这件事的体感，是在用 Cursor 用到后面时慢慢出现的。

最开始我很喜欢那种“边聊边改”的感觉。
但时间一长，我会发现一个问题：
当任务变重之后，IDE 的优势会开始变成负担。

比如说：

  • 一个需求会改十几个文件

  • 改完还得跑测试

  • 跑完要修报错

  • 修完还得补文档

  • 最后还得自己再检查一遍有没有把别的逻辑顺手搞坏

这种时候，你其实不再需要一个“在旁边陪你写”的助手。
你需要的是一个能把整段流程接过去跑完的执行者。

而这，恰好就是 CLI 形态开始变得有吸引力的时候。

3. “Vibe Coding”火起来，不是因为大家突然变懒了，而是因为工具真的跨过了一个门槛

2025 年有个词突然变得很流行：vibe coding。

这个词是 Andrej Karpathy 在 2025 年 2 月公开提出来的；GitHub 在 2025 年的 Octoverse 里也专门提到，vibe coding 成了那一年一个非常显眼的开发趋势，指向的是一种“从想法直接跳到可运行原型”的工作方式。

我觉得很多人会误解这个词，以为它只是“随便写写”“不讲工程”。
但它真正流行起来，背后其实是一个很现实的前提：

模型和工具终于强到，足以让“先别管代码细节，先把东西跑起来”这件事变得可行。

也就是说，vibe coding 不是一种哲学先诞生，然后工具跟上；
而是工具先跨过门槛，大家才发现，原来开发可以先从“描述结果”开始，而不一定从“设计实现”开始。

这也是为什么我会觉得，Cursor 这类产品在 2024 到 2025 年那么容易让人上头。
因为它们第一次把“我有一个想法，先把它做出来看看”这件事，压缩到了很短的链路里。

你不用先开一堆文档。
不用先想完整架构。
不用先把每个目录规划好。
甚至很多时候，连 API 文档都可以边做边补。

你只需要开口描述，AI 就会把一个雏形先给你堆出来。
那种感觉特别像：

你不是在写代码，而是在不断把一个模糊想法往现实里拽。

所以我完全理解为什么那么多人会爱上这种开发方式。
因为它真的很接近一种创作体验。

4. 但也是在这个阶段，我开始第一次认真意识到：IDE 不是终点

我后来从 Cursor 往外看，很大一个原因，其实不是它不好，而是我慢慢发现了自己需求的变化。

一开始我最在意的是“快不快”。
后来我最在意的是“顺不顺”。
再后来，我最在意的变成了：

它到底能不能把重活接过去。

当免费额度用完、开始付费、开始认真比较模型质量的时候，这件事会变得尤其明显。
你会开始在意：
Auto 模式够不够稳？
高级模型到底值不值这个价？
上下文会不会乱？
改动会不会越来越“发散”？
它到底是在帮你省时间，还是在制造另一种形式的返工？

也是在这个阶段，我开始接触 CLI 形态的工具。

最开始那个落差感是很真实的。
因为你从 Cursor 这种高度可视化的环境，切到终端里的对话窗口，第一感觉一定是：这也太糙了。

IDE 里有 Diff 高亮，有文件树，有报错，有按钮，有侧栏。
CLI 一上来就是一堵文字墙。
它读了什么、改了什么、正在做什么，全靠你自己从输出里理解。

说白了，IDE 给你的感觉是“它在你眼前工作”；
CLI 给你的感觉则是“它在后台办事”。

刚开始当然会不习惯。
但也正是从这里开始，我意识到：
我可能并不总是需要“看着它工作”。

很多时候，我真正想要的是：

  • 我把任务交代清楚

  • 它自己去读库、找文件、改逻辑

  • 它自己跑命令、修错误、补测试

  • 最后把结果端回来给我审

这时，CLI 的意义就出来了。

5. 2025 年之后，CLI 不再只是“命令行聊天”，而是真的开始长成 Agent 形态了

CLI 真正让我改观，不是因为终端多酷，而是因为这条线上的产品，在 2025 年之后成长得非常快。

Anthropic 在 2025 年 2 月随着 Claude 3.7 Sonnet 一起公布了 Claude Code；到 2025 年 5 月，Claude Code 转为更广泛可用，开始支持 GitHub Actions 背景任务，以及 VS Code 和 JetBrains 的原生集成。它现在官方定义得很明确：这是一个 agentic coding tool，可以读代码库、编辑文件、运行命令，还能接 IDE、桌面端和浏览器。

OpenAI 的 Codex 也是类似路线。
现在官方文档把 Codex CLI 直接定义为本地运行的 coding agent：能在选定目录里读代码、改代码、跑命令，开源，而且用 Rust 写，强调的是“本地、快、能干活”。后续还加了 skills、SDK、非交互式模式，明显是在往自动化和工程化工作流延伸。

Google 这边的 Gemini CLI 也不是一个简单壳子。
官方 GitHub 直接把它写成“an open-source AI agent”，强调它是把 Gemini 直接带进终端的一条轻量路径。后续路线图和讨论里，也明显能看出它在往 skills 和 agent framework 的方向扩展。

到了这个阶段，CLI 的意义已经不是“没有界面的聊天框”了。
它其实是在形成一套非常明确的工作方式：

需求输入 → 代码库探索 → 计划拆分 → 文件修改 → 命令执行 → 测试验证 → 结果回传

一旦你习惯了这种节奏，就会发现它和 IDE 最大的差别，不是功能，而是角色分工。

在 IDE 里，你和 AI 更像是一起坐在工位前。
在 CLI 里，你更像是把任务交给了另一个工程师。

6. 这也是为什么，Claude Code 会让我觉得它特别适合“重活”

如果只说我对这波 CLI 工具的整体判断，我会觉得 Claude Code 是最接近“成熟搭档感”的一个。

原因并不只是模型强。
更重要的是，Anthropic 对它的定位很清楚。
Claude Code 的文档和工程博客里，反复强调的是 agentic coding、best practices、context engineering、long-running agents；它不只是想帮你改一段代码，而是想帮你完成“理解代码库—制定策略—执行修改—验证结果”这一整套事。

这类工具给我的最大感受是：
它不再只是帮你“生成代码”，而是在替你“消化复杂度”。

以前一个大型重构，最痛苦的不一定是写代码本身，而是：

  • 先摸清上下文

  • 找到真正相关的文件

  • 判断哪些依赖不能动

  • 改完之后确认影响面

  • 再补测试和文档

这些事情很耗注意力，也很耗精力。
而一个好的 CLI agent，恰恰是把这部分工作吃下去了。

所以我现在会觉得，Claude Code 这类工具最适合的不是“小修小补”，而是那种真正有工程重量的活：重构、迁移、补测试、扫技术债、读陌生代码库。

7. 但这不意味着 IDE 没价值。恰恰相反，IDE 变成了另一个更重要的角色

我并不觉得未来会是 CLI 干掉 IDE。
我更相信的是，IDE 和 CLI 会越来越像“前台”和“后台”。

这点其实从很多产品最近的演化也能看出来。
Cursor 现在除了编辑器里的 Agent 之外，还有 Cloud Agents、Automations、多种插件和外部集成，已经明显在往“代理运行平台”扩。

GitHub Copilot 也是一样：IDE 里的 agent mode 和 GitHub 上的 coding agent，本来就是两个层次——一个在本地环境里自主编辑，一个在 Actions 驱动的环境里独立完成任务。

这说明一个很重要的趋势：

未来的开发界面，不再只是“编辑代码的地方”，而会变成“管理 agent 的地方”。

IDE 的价值并不会消失。
它只是从“唯一工作场所”，慢慢变成：

  • 看结果的地方

  • 调试的地方

  • 审查的地方

  • 处理局部精修的地方

  • 做前端可视化反馈的地方

这一点对我个人使用习惯的影响很大。

我现在越来越少把 IDE 看成“主战场”，而更愿意把它看成“控制台”。

小需求、小改动、前端调样式，我还是会更喜欢待在 IDE 里。
因为这些事情天然需要强反馈、强可视化、强交互。

但一旦任务进入：

  • 架构调整

  • 大面积重构

  • 复杂逻辑迁移

  • 批量文件修改

  • 自动化验证

我更愿意切去 CLI，让 agent 去跑完整流程，然后再回到 IDE 里做审查和收尾。

8. Kiro 和 Antigravity 的出现，也让我意识到：下一阶段不是“更会写代码”，而是“更会组织复杂开发”

如果说 Cursor、Claude Code、Codex、Gemini CLI 这些产品，解决的是“让 AI 更像开发者”，那 Kiro 和 Antigravity 让我看到的是另一件事：

下一阶段的问题，可能不是代码生成，而是复杂度管理。

Kiro 在 2025 年 7 月发布时，就把核心放在 spec-driven development 上：把高层需求结构化成 requirements、design、tasks，再交给 agents 去实现。它官方甚至直接说，Kiro 很适合 vibe coding，但更重要的是把原型带进生产。

Google 的 Antigravity 则更激进一些。
它在 2025 年 11 月正式亮相，被定义为 agent-first development platform。官方文档和博客里最核心的表达，不再是“聊天”“补全”，而是 workspaces、agents、skills、Mission Control 这类概念，本质上是在把开发环境重新组织成一个多代理编排平台。

这两类工具让我越来越相信一件事：

这波 AI 编程的终点，未必是“每个人都坐在 IDE 里跟 AI 一起敲”。
更有可能的终点是：

  • 需求先被结构化

  • 任务再被拆解

  • 多个 agent 并行执行

  • 人主要负责定义目标、设置约束、审查结果

换句话说，
“写代码”这件事本身，正在慢慢从中心位置退下去；
“组织开发”反而开始变成更核心的能力。

9. 回头看这几年，我觉得 AI 编程大概经历了三个阶段

如果一定要按时间顺序，把这几年串成一条线，我会这样理解。

第一阶段：补全时代

大约从 2021 年 Copilot 技术预览开始，AI 编程最主要的价值还是“加速输入”。它更像一个聪明的自动补全器，帮你少打字，偶尔给你灵感。

第二阶段：聊天和编辑时代

2023 年前后，Copilot X、Cursor 这类产品开始把 AI 放进编辑器主界面，代码生成不再只是补全，而是开始进入问答、改写、解释、跨文件编辑。这个阶段的关键词是：AI 开始理解局部上下文。

第三阶段：Agent 和 Vibe Coding 时代

到了 2025 年，vibe coding 成为流行词，Copilot agent mode、Claude Code、Kiro、Antigravity 这些产品陆续出现，说明行业重心已经从“帮你写”转向“替你做”。这个阶段的关键词是：AI 开始接管完整任务流。

而 2026 年给我的感觉则更进一步。
现在很多产品都在强化 plan、skills、subagents、automations、background tasks，这意味着行业已经不满足于“会写代码的聊天机器人”，而是在认真做“可以持续工作的软件代理”。

10. 所以今天的 CLI vs IDE，本质上已经不是界面之争，而是工作流之争

这也是我现在最明确的一个判断。

今天再讨论 CLI 和 IDE，已经不能只看“哪个界面更舒服”。
真正的区别其实是：

IDE 更适合什么？

IDE 更适合这些场景：

  • 需要强反馈

  • 需要实时调试

  • 需要边看边改

  • 要做 UI、样式和交互

  • 你还不想完全把执行权交给 AI

它解决的是：
怎么更舒服、更安心地和 AI 一起工作。

CLI 更适合什么？

CLI 更适合这些场景：

  • 任务描述可以一次讲清

  • 需要跨文件大改

  • 需要自动跑命令和测试

  • 需要集中处理重构、迁移、批量修改

  • 你更愿意让 AI 当执行者，而不是副驾驶

它解决的是：
怎么更高效地把一整段开发工作委派出去。

所以在我看来，CLI 和 IDE 并不是替代关系。
更像是你在不同阶段、不同任务里，选择不同的“交互密度”。

你越想盯过程，越会偏 IDE。
你越愿意看结果，越会偏 CLI。

11. 如果要给我这条路径做个总结，那大概是这样

最开始，我被 Cursor 吸引，是因为它让我第一次觉得 AI 编程这件事足够顺滑、足够轻松、足够“像真的”。
后来我开始折腾 CLI，不是因为我突然不喜欢 IDE 了，而是因为我发现自己想让 AI 接的活越来越重了。

我并不是从“喜欢 IDE”变成了“讨厌 IDE”。
而是从“我想和 AI 一起写”，慢慢变成了“我想让 AI 先去写完，我再来审”。

回头看，这其实也正好对应了这几年整个行业的演进：

  • 一开始，AI 只是帮你写得快一点

  • 后来，AI 开始帮你想

  • 再后来，AI 开始帮你做

  • 接下来，AI 很可能会开始帮你组织整套开发流程

所以如果今天再让我说一句最直白的话，我会这么总结：

Cursor 这类 IDE，让我第一次享受到 AI 编程。
Claude Code、Codex、Gemini CLI 这类 CLI，让我第一次认真思考：以后是不是很多代码，真的不用我亲自写了。

而 Kiro 和 Antigravity 这类更新一代的产品，又在继续提醒我：

也许真正要被重写的，不只是“怎么写代码”，而是“软件开发这件事本身”。

这几年 AI 编程工具的变化，看上去像是从 Copilot 到 Cursor，再到 Claude Code、Kiro、Antigravity 的产品更替；但更深层的变化，其实是开发者角色的变化。我们正在从“亲自实现的人”，慢慢变成“定义目标、设置约束、审查结果的人”。对我来说，Cursor 代表的是 AI 编程最舒服的入口，CLI 代表的是 AI 编程真正开始进入生产力阶段，而 Kiro 和 Antigravity 则像是在提醒我们：下一代开发环境，可能不再是编辑器，而是一个专门用来调度 agent 的工作台。