核心观点：好工具理应"隐身"——打造这样的工具，才是工具开发者的终极目标

我见过一种很普遍的现象，也一直对此持反对态度：把工具的缺陷包装成"解谜游戏"，美其名曰"充满乐趣"。

我根本不希望工具"有趣"。我要的是工具能隐身。

编辑器之争

就拿vim举个例子——这只是个例子，其他编辑器也存在类似问题。我常看到有人吹捧vim，不是因为它真正的优势，反倒把它的短板说成值得"玩味"的谜题。

有人跟我说，为一次性文本重构任务写个宏有多"好玩"。可当我看到具体操作和耗时后，真实想法是：换Sublime，我用多光标一分钟就能搞定，实在不行写个简单脚本也比这快。

我得说明白：我不是说编辑器对工作流程不重要。我质疑的是，有些人近乎狂热地信奉一款工具，只因为它能带来"黑客感"——而这恰恰是vim或emacs吸引新手的核心卖点。

这就是我所说的"隐身工具"：当你熟练掌握一款编辑器时，无论它是什么，它都会退居幕后，让你专注于工作。可一旦它无法轻松完成某项任务，就会立刻"现形"。让我费解的是，这么多人把这种"摩擦"——也就是为绕过工具局限付出的额外努力——当成"乐趣"，还以此证明工具的优越性。

我很清楚自己常用的Sublime有不少缺点，但我不会把这些缺陷包装成有趣的小谜题。我只会因为它缺少我真正需要的功能而烦躁，不得不写个插件，或者换个别的程序来实现我想要的文本处理效果。

我用Sublime已经15年了，选择它有几个原因：它的快捷键兼容图形操作系统的操作逻辑（在不同应用间切换时，几乎不需要转换思维）；99.999%的情况下，多光标都比宏好用——过去十年里我只在Sublime中用过两次宏，两次都是设置宏的时间比直接写脚本还长——（因为多光标能提供直观的视觉反馈）；而且它让我在文本编辑流程中遇到的"谜题"最少。我觉得vim在基础编辑上更顺手，但批量操作（不是指grep这类操作）的表现远不如Sublime，这也是我一直用它的原因。我也没觉得vim的移动操作比我的Sublime流程高效多少，这可不是因为我没尝试或不熟悉——说实话，这些年我已经忘了大部分vim移动指令，因为根本用不上，也没必要用。而且我几乎从不在终端里写代码，所以对终端编辑器完全没需求。

如果有人真心觉得vim、emacs或其他工具好用、高效，我不会批评他们的选择——毕竟人都习惯用自己熟悉的东西。但我要说的是另一群人：熟悉感让他们对工具的缺陷视而不见，甚至把缺陷当成值得炫耀的"游戏"。

工具即身份认同

这类争论之所以变得像宗教圣战，部分原因在于工具选择成了一种身份标识——它代表你是谁。"黑客感"不只是一种审美，更是一种群体信号，这才是真正的陷阱。一旦你把自我身份和工具绑定，承认工具的缺陷就像承认自己的不足。于是人们不再容忍缺陷，转而开始辩护，最后甚至将其当作亮点炫耀。对于把工具视为自我一部分的人，你根本没法和他们坦诚讨论工具的优劣。

感觉高效 vs 真正高效

我之前提到的编辑器宏的例子，本质上是"感觉高效"和"真正高效"的差距。解决一个繁琐的问题会带来一种"我很聪明"的快感，人们很容易把这种感觉当成实际产出。有些工具让困难的操作显得充满英雄主义，让小聪明看起来像重大成就，表面上显得"强大"，实则效率低下。真正的检验标准不是你操作时有多投入、多有成就感，而是实际耗时和出错次数。很多被人极力推崇的工具，在这个标准下都会败下阵来。

如果高效才是你的目标，那请认真审视自己的看法，找到真正能提升效率的方式。你会得到意想不到的结果。

终端UI vs 图形界面（GUI）

类似的例子还有人推崇终端应用胜过GUI。如果你一整天都得待在终端里，那终端的优势不言而喻，但大多数程序员并非如此。

推崇终端UI（TUI）的人常批评GUI应用："我没法只用键盘操作。"

那又怎样？这并不代表GUI应用本身就不好，只能说明现有的GUI做得不够好，没实现键盘导航。GUI完全可以支持键盘操作，只是大多数开发者懒得做——通常是因为他们没意识到，很多时候键盘导航比频繁摸鼠标高效得多。如果说某款特定的TUI应用比同类GUI应用更好，这是合理的观点，但说TUI本质上优于GUI，就完全是误解了。

这是个常见误区：人们看到某类工具的现状，就误以为它的局限是天生的、不可改变的，可实际上只是没人花心思去改进而已。

Linux桌面的普及困境

2026年了，"Linux桌面元年"依然遥遥无期。其中一个根本原因是：很多Linux用户就爱折腾配置文件来定制系统——这对他们来说是"乐趣"，是一种解谜游戏。

我也经历过那个阶段。但过了一段时间，我只希望系统能正常工作。我再也不想花上几小时甚至几天去配置所有东西，我希望默认设置就足够好用，偶尔需要微调时，几秒就能搞定。

高度可配置不该是工具的目标，而应是必要时才启用的选项。打造一款符合人体工学的工具，核心在于提供优秀的默认设置，同时在必要时保留自定义的空间。

这种"非必要复杂性"意外地受到很多程序员和技术爱好者的喜爱，给他们一种奇怪的安全感。

提供优秀的默认设置，本质上是工具开发者的责任。我们总习惯把负担推给用户：让用户去配置、去调整、去学习。很多时候，这种负担其实是设计者不愿做出决策的结果。"高度可配置"往往只是借口——开发者不愿明确产品定位，把问题全丢给用户。优秀的默认设置是对用户时间的尊重：开发者做一次决策，就能省去上千用户各自摸索的麻烦。工具设计的一部分是保留"逃生舱"——但这些选项是给真正有特殊需求的少数用户准备的，绝不能用来替代对常规需求的优化。

陡峭学习曲线是"特色"？

我还见过一种辩护：难用才是关键，它能筛选掉不够投入的人，一旦你跨过门槛，就能终身受益。但学习曲线是成本，不是优点。理论上，这种成本或许值得付出，但回报必须是真正的效率提升，而不是"我熬过来了"的满足感。很多时候，这种逻辑只是沉没成本的美化："我花了好几个月学习，它肯定值得，你也该跟着学。"这又是一种解谜游戏，只不过这次谜题就是工具本身。

结语

我不是在反对任何特定工具，而是在反对一种思维方式。用vim也好，emacs也罢，或是Sublime都没关系，关键是选一款能退居幕后、让你专注工作的工具。这是唯一的检验标准，而且因人而异。我反对的不是工具选择本身，而是围绕选择产生的那些说辞：把缺陷说成特色，把绕开缺陷的努力包装成回报，把工具从"使用的物件"拔高到"自我的一部分"。

工具真正为你服务的最明显标志，是你不再注意到它——它隐身了。你不会把它的缺陷当成爱好来庆祝，只会偶尔感到烦躁，然后想办法绕过去。你不会为它辩护，因为你的身份认同不依赖于它。你也不会把"聪明感"当成真正的高效，因为你会认真区分二者的差别。

当然，你完全可以享受工具带来的编程乐趣。但请诚实地分辨，哪些是工具真正的优点，哪些是你说服自己去喜欢的部分。最好的工具不是故事讲得最好的那个，而是让你忘了它存在的那个。

好工具理应"隐身"——打造这样的工具，才是工具开发者的终极目标。