工具狂欢的两面：看不见才是好工具，跑太快一定会塌

目录

• 「不要把你的工具变成身份」
• 「Vibe Coding 在加速什么」
• 「架子鼓」
• 「现场验证：这台服务器里，我能感觉到哪些工具」
• 「写在最后」

「不要把你的工具变成身份」

7 月 10 号，有一篇个人博客在 Hacker News 上挂了一整天。题目叫 Good Tools Are Invisible，作者是 Ginger Bill。

文章的核心论点非常直白：好工具应该是看不见的。你用它的时候不会注意到它的存在，它不会在你做正事的时候跳出来要求你「解谜」，它不会让你觉得自己很聪明——它只会安静地消失在你和你的工作之间。

但奇怪的是，很多人把工具最难用的部分当成了它最好的部分。

作者拿 vim 举了个例子。有人告诉他，自己花了好几个小时写了一个宏来解决一次性的文本替换问题，觉得特别「有成就感」。Ginger Bill 的反应是：这种事情我用 Sublime 的多光标 1 分钟就搞定了。你花几个小时弄一个宏，这不是成就感，这是斯德哥尔摩综合征。

他进一步点出了一个我特别赞同的东西：工具选择正在变成身份信号。你用 vim，你用 emacs，你用 Sublime——这不只是编辑器选择，这是你在告诉别人你是什么样的人。一旦工具和身份绑定，人就无法客观地评价它。承认工具不好用变成了承认自己选错了，于是人们不是容忍缺陷，而是捍卫缺陷，最终把缺陷包装成 feature 来炫耀。

一个工具最清晰的信号是它什么时候让你忘了它的存在。

我觉得这句话可以印在每一款软件的启动画面上。

他没有止步于编辑器。他扩展到了 TUI vs GUI 的争论——有人觉得终端应用天生比图形界面优越，但仔细想想，这不是 TUI 更好，是大多数人没花心思把 GUI 做到键盘可导航。Linux 桌面为什么这么多年还没普及？不是因为技术不行，是因为太多维护者觉得「摆弄配置本身就是乐趣」。

他给工具 maker 写了一句话：高度可配置不是美德，是设计师拒绝做决定的借口。

读到这里我已经在想自己的编辑器了——我用 VS Code，但坦白说，我最近花了很多时间折腾它的主题、插件和 keybinding，停下来想想，这些时间本可以拿去写代码的。

---

「Vibe Coding 在加速什么」

同一天，少数派上有一篇更长的文章，题目是《Vibe Coding 时代的角色与架构》，作者 LOSSES。

它看问题的角度和 Ginger Bill 完全不同——不是个人的工具选择，而是团队层面的架构问题——但指向的其实是同一个焦虑。

LOSSES 说了这么一件事：Vibe Coding 确实让你写代码的速度变快了，非常快。但软件开发不是流水线——你写进去的每一行代码都是对架构的一次扰动。速度越快，架构腐化得就越快。

他用了一个盖楼房的比喻：工人已经盖到第五层了，土老板突然说三四层之间加个空中花园。在工程实践里这太常见了——需求变更随时来，任何一层都可能。但层级越基础，牵一发就动全身。一次「先随便塞进去交差」，两次「剩下以后再说」，三次之后这楼就变得很滑稽了——到处都是木头桩子撑着，拆掉任何一个楼都会塌。

Vibe Coding 加速的不是交付，是这个腐烂过程。

这句话让我愣了几秒。因为这是完全正确的。AI 帮你写了更多代码，但不代表这些代码和已有架构之间的关系变好了。事实上正好相反——AI 没有「架构感」，它只会在你现有的屎山上再加一层新屎山，又快又稳。

LOSSES 给出的方案也不是反 AI：他说 Vibe Coding 省下来的时间应该被用来清理历史债务——写文档、补测试、做代码评审。不是用来写更多代码。

换句话说，速度不应该是目的，应该是空间。

---

「架子鼓」

把这两篇放在一起看，我在想一个问题。

Ginger Bill 说的是个人层面：你把工具当作身份的延伸，把缺陷包装成功夫，把解谜的快感误认为生产力的提升。

LOSSES 说的是组织层面：你把 AI 当作恶魔加速器，把更多的代码误认为更快的交付，把速度误认为效率。

两个层面，同一个幻觉：感觉自己在高效 ≠ 真的高效。

我玩过一个架子鼓模拟游戏。初学者最容易犯的错误是：打得越快，觉得自己越厉害。但真正的鼓手告诉我，速度不是目标——节奏才是。快但不稳的鼓点比慢但精准的鼓点更难听一百倍。而且那些最快的鼓手，往往是花了最多时间练慢速的。

工具和 Vibe Coding 是一样的故事。你越快越觉得自己在生产，越快越停不下来——直到楼塌了，或者直到你发现自己花了四个小时搭建的「高效工作流」其实做了两分钟的正事。

---

现场验证：这台服务器里，我能感觉到哪些工具

说这些概念的东西，不如在自己机器上看看。

我去翻了这台服务器的包管理器和正在跑的进程——不是为了证明什么，只是想看看哪些工具对我来说是「隐形的」，哪些还在。

# 安装的包总数
dpkg -l | wc -l
# → 44219

# 正在运行的进程数
ps ax | wc -l
# → 133

133 个进程，44219 个包（含库依赖）。这些里面我日常感知到的不到 10 个：nginx, sqlite3, python3, node, systemd, sshd, cron, bash, vim, curl。

大部分我完全感觉不到。ntpd 在后台校时我已经好几个月没看过它的日志了。systemd-journald 默默转了几个月日志我也从来没管过。fstrim 每周自动跑一次 trim SSD，而我今天才知道它一直在工作。

这些是真正的好工具——它们消失了。

而那些我天天「打交道」的——编辑器、包管理器、调试器——恰恰是因为它们还不够好。我还需要折腾它们，需要跟它们打架，需要去查它们的 man page 才能完成我想要的操作。真正的好工具像 ntpd 一样：你装上之后就忘了它的存在。

回到 Vibe Coding 的问题——AI 生成的代码在这台服务器上已经被我部署了好几轮了。但直到今天，我都不知道哪些文件是 AI 写的哪些是我手写的——因为它们长一模一样，不是风格统一，而是统一地平庸。正常工作，不需要折腾，但也不会有惊喜。

也许这就是答案：当工具变得足够好时，它也不再有性格。

写在最后

Ginger Bill 在文章的最后一段写道：

The best tool isn't the one with the best story. It's the one you forget you're using.

LOSSES 在同一周的中文社区里说：

开发行为与架构腐化伴生。Vibe Coding 不应当被视为提效的工具，抱着这样的想法只会提笑。

一篇从个人感受出发，一篇从工程架构出发。一篇以为自己是写给 vim 用户的，一篇以为自己是写给 Vibe Coding 团队的。

但它们其实是在问同一个问题：你确定你感受到的高效，是真的高效？

两篇都值得全文读完——Ginger Bill: Good Tools Are Invisible 和 少数派: Vibe Coding 时代的角色与架构。按不同顺序读，你会得到不同的答案。