Claude Code系列教程3：为什么只提供了终端

1.3 为什么要在终端里写代码？

打个比方：你正在写一个新功能，突然发现需要改一个底层工具函数，它散落在三个文件里，有些调用还跨了模块。你打开编辑器，全局搜索，一个文件一个文件地翻，小心翼翼地改完，再跑一遍测试——红了。看报错，查堆栈，修好，再来一遍。

这个过程中真正花在“想清楚怎么改”的时间，可能不到一半。剩下一半是机械劳动：找文件、改引用、等编译、点鼠标。

把 AI 放到终端里，首要目的就是压缩这些机械劳动。

你可能用 VS Code、JetBrains 或者 Vim。不管你用哪个，在写代码的过程里，都绕不开终端。跑 npm test、git log、grep、make build——这些操作天然就在命令行里完成。

那么，如果你的 AI 搭档也蹲在同一个终端里，事情就变简单了。你不需要把文件内容复制粘贴到聊天窗口，不需要自己描述“我的项目里有一个叫 UserService 的类，它在 src/services/user.ts 的第 42 行……”。Claude Code 就站在项目根目录，它自己会看。

这是一种上下文上的降维打击。当你对 Claude Code 说“帮我重构一下登录模块的错误处理”，它真的会去读你的 auth/login.ts，去读 errors.ts，去找所有调用它的地方，然后直接改。中间不需要你做传输工。

在使用浏览器 AI 聊天时，我们常常不自觉地扮演了一个“中间人”角色：AI 输出代码，我们阅读、验证、复制，再回到编辑器粘贴。代码如果能跑，万事大吉；如果不能，复制报错，再问，再复制。这个过程其实很打断心流。

Claude Code 的设计思路是让你重新回到“思考者”的位置上。你说想法，它动手。改完后你直接在终端里看到 diff，决定是否接受。它还可以顺手帮你跑测试、跑 lint。你坐在那里，更多时候是在读代码、做决策，而不是在反复切换窗口。

你可能会问：那为什么不直接在编辑器里搞一个 AI 插件？

编辑器插件当然有用，而且很多团队已经在用了。但终端里的 Claude Code 有几个不太容易被插件替代的地方：

无编辑器的束缚。 你今天用 VS Code，明天换 Neovim，甚至在没有 GUI 的远程服务器上，Claude Code 都能用。它跟你选择的工具无关。
可以做更多“出格”的事。 在终端里，它可以执行任何 Shell 命令。这意味着它能做的事情边界广阔得多——可以帮你启动 Docker 容器验证数据库迁移，可以拉取远程分支并检查冲突，可以在修改代码后自动运行 e2e 测试。这些事情，编辑器插件通常不敢随便做，或者根本做不了。
批量处理和自动化。 你可以把 Claude Code 塞进脚本里，让它帮你去处理几十个仓库、批量生成文档、自动处理 Issues。这时候它已经不是“助手”了，而是流水线里的一环。

之前我需要把一个 JavaScript 项目迁移到 TypeScript，大概两万多行代码。我的做法不是手动一个个文件加类型，也不是指望一个编辑器插件帮我全部搞定。

我是直接在那个项目目录下启动 Claude Code，告诉它：“把这个项目逐步迁移到 TypeScript 严格模式，每次改几个文件，每改完一批就跑一下 tsc --noEmit，如果报错就自己修，直到全部通过。”

接下来的半小时里，我基本只做了一件事：看它改的 diff，点头或摇头。偶尔告诉它“这里的类型别用 any，定义一个 interface”，它就继续干活。最后项目编译通过，比我预估的时间快了好几倍。

这当然不是说 Claude Code 就比插件聪明。但它能够自己完成“修改-验证-修复”这个闭环，这是它和聊天式 AI 最根本的区别。

把 AI 装进终端，本质上是给了它执行的能力，而不仅仅是建议的能力。

它让你的代码仓库不再是一堆只能被读取的文本，而变成 AI 可以“触摸”、修改、验证的真实环境。这是一个巨大的跨越。

你依然掌握着项目的方向和所有关键决定，但那些繁琐的、低创造性的、需要反复跳转的工作，有了更合适的承担者。