没有地方比得上 $HOME：从 Vim 到 VS Code 再回到 Vim 的十年之旅

# 无处不家 $HOME 原文来源：https://starikov.co/no-place-like-home/ **注意 📜** 这是一篇关于 *AI* 的文章。所有观点仅代表我个人，不代表我的雇主。请查阅我的 **披露声明 (https://starikov.co/disclosures/)**。 让我带你走过文本编辑器的十年。自2016年起，我主要通过 shell 编程，我的 dotfiles 可以追溯到 2017 年 (https://github.com/IllyaStarikov/.dotfiles/commit/8fd8d8f6c0ce0a73bd05221c1563af83932b9012?ref=starikov.co)。我曾经写过一篇文章，认为你应该深切关心你使用的工具 (https://starikov.co/being-passionate-about-tools/)。2026 年，我使用的工具和那时一样。但其他很多东西都变了。 我进入了大型科技公司，注意到身边的工程师很少有人使用和我相同的工具套件。大多数人生活在 GUI 编辑器中，终端是可选的，shell 是后来才加上去的东西。我发现很难与同事沟通意图。所以，出于 FOMO（害怕错过），我决定尝试不同的东西。在使用了十年的 Vim 之后，我把日常主力工具换成了 VS Code。 然后，大约在 2025 年，工作本身也变了。我的工作量和处理方式突然不同了。 ## 适合我的 IDE？ 一开始感觉很不错。工具集成得很好：版本控制是一个面板而非 man 手册，文件树就在那里，调试器和运行按钮点击一下就到位。在使用之前不需要给任何东西起名字；每个动作都是一个菜单，每个菜单都是一个按钮。对于刚起步的人来说，它降低了门槛，让你在理解底层的机器之前就能高效工作。 我的“哦，这居然能用”时刻微妙而令人愉快：编译器会在输出中打印文件路径、行号和列号，有一天我意识到我可以点击它，然后直接跳转到源代码中的那个位置。这正是 IDE 承诺的：它就这么工作了。 我从 IDE 中学到了很多经验，并把它们带到了 Vim 中，几乎所有这些都可以归结为一个按键：转到定义（`gd`，是的，我需要设置语言服务器）、查找所有引用（`gr`）、重命名所有出现的符号（`F2`）、灯泡快速修复（`F4`）、语言服务器自动补全、用于错误提示的问题面板（`xx`）。我甚至把模糊文件打开器绑定到 `Ctrl-P`，和 VS Code 中的按键一样。 它也有缺点。按键和字符之间有一点点延迟，刚好让你注意到；一次按键的编辑变成了命令面板、模糊匹配、回车；打开一个 5000 行的文件，风扇像跑道上的喷气机一样旋转。终端生活在一个狭窄的底部条中，只有几行高，而我整个工作流曾经就放在那里。在我笔记本电脑上调整好的编辑器，从来不会完全是我台式机上等待我的那个编辑器。每一个问题都很小，但加在一起就成了繁文缛节。 到最后，感觉就像维护一个精致的花园。我要不断清除窗格才能看到更多代码，而重启之后它们又会长出来。 我的 VS Code 设置，在使用了十年 Vim 之后切换成的日常主力工具。 我的典型工作流是： 1. 光标停留在我刚写的一个函数里。它调用了一个我不熟悉的 API，所以我松开键盘，鼠标悬停在上面，等待索引器启动。 2. 右键点击符号，扫描菜单，点击“转到定义”。一个新标签页在另一个文件中打开，滚动到我并不知道的位置。 3. 那个定义又调用了一个辅助函数。悬停，等待工具提示，再次点击“转到定义”。第三个标签页堆积起来。 4. 阅读辅助函数，然后在标签栏中寻找我原来的那个标签。点击回去，误点隔壁标签，纠正。 5. 回到我的函数，用鼠标拖选错误的参数，然后修复调用。 6. 点击进入终端窗格，运行文件，等待结果。 ## $HOME，甜蜜的 $HOME 当时的想法和现在一样：为所有人设计的 IDE 会把你优化成平均水平。这并不意味着 IDE 不好，或者使用 IDE 的人应该感到不好（就连 John Carmack 也信赖 Visual Studio (https://lexfridman.com/john-carmack/?ref=starikov.co)，那是一个完整的微软 IDE，不是 VS Code）。这仅仅意味着当你生活在代码中时，工具是值得投资的（即使是你的 IDE）。 在 Vim 之前我用过 Xcode、Sublime Text 和 Atom，我仍然认为当时的 Sublime 是史上最佳。借助 shell 工具，我能够为自己打造完美的环境。我喜欢以思考的速度编码。我觉得通过键盘导航、修改和操作代码更加舒适。我喜欢完全可自动化的环境。我喜欢掌控一切。 我的 Vim 设置，回到家里的终端。 我的典型工作流是： 1. 光标停留在我刚写的一个函数里。它调用了一个我不熟悉的 API，所以我原地阅读它。不用鼠标，不需要唤醒任何东西。 2. `gd` 跳转到定义，并且跳转会记录下来，方便我返回。 3. 那个定义又调用了一个辅助函数。再次 `gd`，在跳转列表上再加一跳。 4. 阅读辅助函数。`Ctrl-o Ctrl-o` 沿着跳转列表原路返回，回到我的函数。 5. 回到我的函数，`ci(` 在普通模式下替换参数，不需要选择框。 6. `Ctrl-w` 切换到 tmux 窗格，从历史中调出运行命令，回车；输出就在原地显示。 同样的六步。但没有一步需要我的手离开键盘主行。 ## AI 的那一切 坦白说：FOMO 并不是我决定尝试 VS Code 的唯一原因。我的 dotfiles 已经过时，几乎五年没有动过。复活它们意味着要花好几天时间重构，才能重新编码，或者切换到 VS Code 并立即开始编码。我选择了后者。 但后来 AI 彻底颠覆了这个前提。尤其是 Claude Code 在 2025 年改变了一切；你能看出我是什么时候开始使用它的吗？ 2017-Q1 16 2017-Q2 50 2017-Q3 72 2017-Q4 32 2018-Q1 18 2018-Q2 92 2018-Q3 13 2018-Q4 32 2019-Q1 13 2019-Q3 32 2019-Q4 52 2020-Q1 32 2020-Q2 18 2020-Q3 22 2020-Q4 72 2021-Q4 12 2022-Q2 12 2023-Q3 22 2024-Q1 72 2025-Q2 32 2025-Q3 675 2025-Q4 23 2026-Q1 166 2026-Q2 31 维护 dotfiles 的成本就是用来做这件事的 token 成本。但你可能会问，随着工具围绕 AI 迅速变化，终端明天还会重要吗？在我看来，它会变得更加重要。写代码的成本很小；读代码的成本仍然是你的阅读速度。 我阅读我发送到生产环境的每一行代码，你也应该这样。现在任务发生了变化，但思考方式没有变：你花在阅读代码上的时间越多，你就越应该投资于帮助你阅读的工具。 阅读代码不是线性的。你从你的函数跳到 API，再到它的辅助函数，然后回来。这就是上面两个列表所描述的动作，也是编辑器成败的关键。Vim 是如何比 IDE 更好地做到这一点的？因为它本身就是为这个目的设计的。 在 Vim 中打开一个文件，开始输入，不会有任何字符出现。你处于普通模式，按键是移动的词汇，而不是输入：`j/k/h/l` 在缓冲区中移动，`/` 跳转到你能命名的任何东西，`gd` 跳转到定义，`gr` 列出所有引用，`Ctrl-o` 在跳转列表中回退，`%` 跳转到匹配的括号，`ci(` 重写括号内的内容而不需要选择框。每一个都是阅读的方式。输入是你主动请求的一种模式，在字符出现之前需要故意按 `i`，完成后立即退出。编辑器的默认状态是你最常做的事情：查看已经存在的代码，像阅读一样在其中移动，不需要唤醒索引器，也永远不需要伸手去拿鼠标。 IDE 是反向构建的。文件一打开，光标就在插入点闪烁，准备输入，而每一次阅读动作都是后来加在上面的第二层：需要找到菜单、定义面板、点击来追踪引用。默认是写；阅读是你添加的东西。 这在以前只是喜好问题。AI 把它变成了整个工作的核心。当写一行代码的成本是一句英文句子时，昂贵的部分不再是生成代码，而是阅读返回的代码，而这些代码往往不是键盘前的人写的。Vim 在九十年代就为这种移动构建了它的语法，早在那之前几十年，这种移动就成为了瓶颈。 你可能会反驳说，智能体甚至改变了这一点：你在审查面板中查看它们的 diff，而不是在移动的缓冲区中阅读。但 diff 只是钥匙孔。要信任一个变更，我仍然会打开它涉及的文件，并追踪它调用的东西，而那种追踪是发生在编辑器里，而不是审查面板里。审查面板告诉我什么改变了；Vim 让我明白它意味着什么。 VS Code 和 Vim，沿着对角线拼接在一起。 ## 什么有用，就用什么 我尝试了新东西。不要放弃你现在使用的一切，用我的方案替换；找到你工作流中的一个部分，看看是否可以改进，保留有效的东西。如果我必须选择从哪里开始，那就试试 Vim 的按键绑定吧。学习一个新编辑器很难。一次学一个按键是可持续的。某个下午，我直到午餐时间才注意到鼠标没电了。我一直在某个不需要它的地方待着。 仍然没有比 $HOME 更好的地方。