使用IDE和CLI混合工作流进行AI编程
目录
最近读了一篇文章 I Finally Tried Cursor CLI After Weeks of Ignoring It，讲述了作者从完全依赖 IDE 转向 CLI 与 IDE 混合使用的经历，总结一下。
为什么一直用 IDE #
用 IDE 的理由很直接：
- 文件树、代码、终端、Git 变更，所有信息一屏呈现
- 鼠标点击跳转，操作直觉，上手快
- 语法高亮、自动补全、内联报错、调试工具，功能完整
- 用久了形成肌肉记忆，切换成本高
终端主要用于执行命令，IDE 里本来就有内置终端，需要跑命令直接在里面跑就行了，没必要单独开一个窗口。
真正去试了 CLI 之后 #
作者某天出于好奇，打开终端，用 Cursor CLI 生成了一个简单函数。命令发出去，代码出来了，没有任何多余的步骤。他又试了几次，然后就回不去了。
他总结了三点感受：
速度快。 CLI 的响应几乎是即时的，不需要等界面渲染、面板刷新、复制粘贴。每次迭代大约节省 15 秒，一个开发会话下来能省好几分钟。时间本身不是关键，关键是更低的摩擦让人更愿意频繁尝试。
更专注。 IDE 界面上同时有文件树、Git 面板、AI 聊天窗口、各种通知，即使不需要，它们也在视野里。CLI 只有提示词和输出，没有其他干扰，更容易进入心流状态。
更直接。 IDE 里用 AI 生成代码的流程是：打开聊天面板 → 输入 → 等待 → 查看输出 → 复制 → 切回编辑器。CLI 是：输入 → 得到代码。少了好几个中间步骤。
CLI 适合做什么 #
在实践中总结出了 CLI 比较适合的场景：
- 从零编写新代码：新函数、新组件、新模块，描述清楚需求，直接拿到代码，快速迭代
- 生成一次性脚本：备份脚本、文件处理脚本、正则表达式，不需要打开完整项目
- 探索多种方案：让 CLI 同时给出三种实现思路，快速比较，再去 IDE 里落地
这些场景的共同点是：任务明确、自包含、不需要太多上下文。
IDE 还是不可替代的 #
CLI 没有取代 IDE，只是补充了它。有几类任务，IDE 的优势是 CLI 无法弥补的：
调试。 可视化断点、逐行步进、变量监视、调用栈查看，这些工具在终端里做起来很笨拙。遇到 bug，还是得回到 IDE。
重构。 全局重命名、查找所有引用、可视化 Diff，这些操作需要看到改动在整个代码库里的影响范围，IDE 的视觉上下文是必要的。
大型项目导航。 几十上百个文件的项目，需要文件树、多标签页、跨文件 Git 变更视图，CLI 的专注反而成了局限。
阅读和理解代码。 语法高亮、代码折叠、结构化的视觉呈现，让阅读已有代码更轻松。
混合工作流 #
作者最终形成的工作流大概是这样：
CLI 生成初始代码
↓
IDE 集成到现有代码库
↓
CLI 迭代优化具体函数
↓
IDE 调试、清理、提交
决策逻辑也很简单：
| 场景 | 工具 |
|---|---|
| 新建功能/函数 | CLI |
| 快速脚本 | CLI |
| 探索方案 | CLI |
| 调试问题 | IDE |
| 重构代码 | IDE |
| 大型项目导航 | IDE |
| 阅读理解代码 | IDE |
一点感想 #
这篇文章让我想到一个普遍的问题：习惯用的工具不一定是最合适的工具。
IDE 用久了，会觉得它是唯一正确的选择。但工具本身没有高下，只有适不适合当前的任务。CLI 的速度和专注适合生成新代码，IDE 的视觉上下文适合理解和修改已有代码。两者结合，比单独用任何一个都要好。
如果你也是 IDE 重度用户，可以试着从一个小场景开始，比如只用 CLI 来生成工具函数，坚持一周，看看有没有什么变化。