生产力的海市蜃楼
文章摘要
这是一篇极短的文章——全文不到六百个英文词——但它讲的故事击中了很多人。作者 Alex Kotliarskyi 回忆了他在 Facebook 时期遇到的一位传奇工程师，文中化名 Bob。Bob 是个产出惊人的工程师，Facebook Groups 就是他负责交付的（还有其他不少东西），同时他也是黑客马拉松界的传奇，一次又一次拿出爆款。
那时候的作者是个重度生产力痴迷者。他有一套定制的 Vim 配置，为 Hack（Facebook 内部的 PHP 方言）写了自己的语法高亮和代码片段；他的整套复杂装置包括跑在 mosh 之上的 tmux、自定义的 hphpd 快捷键、以及花哨的 git 别名。
所以当他在一次公司黑客马拉松上被安排坐在 Bob 旁边时，他兴奋极了，准备好接受启蒙。
Bob 打开笔记本电脑，启动了……原版 Sublime Text。它甚至没有正确的语法高亮，一半代码的颜色都是错的。Bob 不用热重载。他不用调试器。他在代码里到处撒 printf，然后耐心等日志出来。
作者当场震惊：这家伙到底是怎么这么高产的？
毫不意外，Bob 当天赢了黑客马拉松。而作者说，他当时太专注于 Bob「怎么做」，以至于完全错过了 Bob「在做什么」——他记得那是 Groups 里买卖帖的支持功能，后来演化成了 Facebook Marketplace。Bob 的产品品味和直觉，比他用什么编辑器配置重要得多。
作者说，每当他刷 X 的时候就会想起这个故事。每天都有人发明一种承诺会改变一切的新工作方式。其中一些也许真的会。但归根结底，最重要的是解决对的问题。
文章没有给出任何方法论，也没有说「所以你不该配置你的工具」。它只是把这个对照摆在那里，让读者自己去想——而 HN 上四百多分和一百五十多条评论说明，这个对照确实戳中了某种普遍的自我怀疑。
HN 评论精华
讨论的走向相当集中：绝大多数人认同这个故事的核心，但很快分化为两派——「折腾工具就是拖延症」派，和「好工具确实降低心智摩擦，问题只在于何时停手」派。另外有一小撮人试图把话题拽向 AI，被其他人明确推了回去。
「改装车爱好者」这个比喻
firasd 开场就给出了本帖最流行的框架：他最近一直在想「gearhead」（改装车迷）这个词——所有那些说「兄弟，把这个 skill 装进你的 agent harness，一切都会改变」的人，其驱动力和汽车改装文化里折腾排气系统的人在很大程度上是相同的冲动。业余爱好者折腾编程配置有它的好处（乐趣），但如果以为这对终端用户有任何影响，或者以为它比认真思考产品和代码更能影响工作的质与量，那就是个错误。
volkk 提出了一个更精准的替代类比：车改人的最终目的本来就是改车，没有像软件那样的产品终点。他认为更贴切的是摄影社群——他自己有段时间痴迷摄影，然后意识到大多数人爱的其实就是……买东西。他们只是收集相机和镜头，拍出极其平庸的照片。「结果真正的创造力比买个新镜头、或者第 100 次改你的 vim 配色和更新某个别名带来的多巴胺要难得多，也远没有那么立刻令人满足。我确信这背后有某种心理学：人们太害怕真正做出点什么，因为那意味着他们真的把自己暴露出去了。」
gherkinnn 给这两种现象贴上了正式标签：GAS（Gear Acquisition Syndrome，装备购置综合症）和 Productive Procrastination（生产性拖延），并附上了维基百科和斯坦福日报的链接。「买越来越精致的键盘、无休止地调语法高亮和看板，永远会输给『直接开干』。」
Theodores 引用了 Paul Graham 关于拖延的文章：拖延不一定意味着躺在沙发上，那个把家里收拾得「不合理地整洁」的人也在拖延，只是用羽毛掸子和漂白剂的方式。而且他们觉得自己很有生产力，还有「洁净近于神圣」的满足感。他说自己认识有人给发件箱邮件建了组织化的文件夹，管理层印象深刻，而他在心里嘀咕真正的活儿还没干。
PaulRobinson 讲了本帖最完整的一个故事。他少年时是《红矮星号》的粉丝，剧中角色 Rimmer 准备考试时花了太多时间反复迭代改进他的复习时间表，最后彻底忘了复习，考试前夜才发现自己有一份漂亮的复习时间表但没时间复习了。「Rimmer 的复习时间表」后来在他工作过的好几个地方成了「我们准备太多、干得太少，直接开始吧」的简称。他还讲了自己的经历：他花了九个月试图想清楚一个软件该怎么建——他想要它完美——而老板们为延期焦虑不已。某个夜晚，出于焦虑和想给老板看点东西的心情，他晚上七点坐下来开始在编辑器里即兴发挥，一直干到通宵。凌晨五点做完了。上午九点上线。上午十一点第一批客户开始付钱。之后三个月他都不需要再改它。
那一刻他决定忽略一句他此前一直相信的名言——那句广泛归于林肯的「给我六小时砍一棵树，我会用前三小时磨斧头」（他调侃道，正如另一句名言所说，「你在互联网上读到的引言 90% 都归错了人」——马克·吐温）。他承认某些情况下准备确实必要：如果斧头是钝的，六小时也砍不倒树。但更多时候你只是在拖延。「你可以去找另一把斧头。你可能发现现有的斧头挺好，一小时就能砍倒树，而不是磨三小时再砍半小时。但通过磨斧头而不是砍树，你有了一种在向目标努力的错觉，而实际上你没有。而且你猜怎么着，磨斧头比砍树容易得多也不那么出汗，所以还更舒服——有什么不喜欢的呢？」他最后给出了一句总结：「做一件不是那件事的事，不等于做那件事。」但他也划清了边界：写测试是在做那件事，不是拖延；加运营和业务指标是在做那件事，不是拖延。因为那些是「那件事」的一部分。「你的提示词不是那件事的一部分，你的 tmux 配置也不是。」
反方：工具流畅度是真实的
nine_k 给出了本帖被最多人认同的反驳，他直接称之为伪二分法：好的匠人确实深切在乎他们的工具，但工具是达成目的的手段，不是玩具。他有一堆匹配自己工作流的小生产力工具：微型 shell 脚本和函数、自定义 Emacs 函数和设置、控制窗口摆放的小工具，累计花了很多天去搭建和调整。「但当我需要跳进一个任务时，一切就绪。语法高亮在那儿，代码导航在那儿，代码分析在那儿，我可以用几个键把注意力区域里的东西按我想要的方式重排，可以用几个字母按我想要的方式驱动 git。我不需要调任何东西。没有东西打扰我，没有东西分散我，没有东西因为要求我做体力活而浪费我的时间、打断我的专注。」他的建议是：投资你的工作环境，调好你的椅子，调好你的 shell 提示符，调好你的编辑器设置。舒服了？好。现在你可以忘掉它们了，它们就在那儿为你工作。专注在你真正的问题上。但他也承认：「无休止地折腾工具以至于吃掉你所有时间，可能是你在回避那个令人生畏、毫无灵感的任务的信号。但这不是工具的问题，没那么简单。」
skydhash 补充了一个关键区分：「（至少对我来说）这不真的关乎速度，而关乎心智摩擦。因为你对工具流畅，你就不用花时间去想它们。」他还指出《程序员修炼之道》里管这叫「编辑器流畅度」（editor fluency）。
sodapopcan 精确地重新表述了那句被批的话：「『为打字优化』真正的意思是：『为你能多快回到思考状态而优化』。我见过有经验的程序员用简单编辑器飞快，也见过有人用 IDE 慢得要死。这篇短文没有深入这类问题：『Bob 是需要在正确位置右键点鼠标然后选择「垂直分屏」，还是瞬间就让那事发生？』我职业生涯里做过大量结对编程，很多人哪怕是好开发者，用起电脑来感觉像我在看我的婴儿潮父母。」
DrewADesign 讲了一个务实的转变：他曾有一套完美符合自己心意的 neovim 配置，但它很脆弱，理论上无限灵活，实际上改起来太麻烦以至于无法随手调整。后来两个不相关的插件变更在一个大项目末期把他的配置搞出了大问题，他转向了 JetBrains 系（Rider、PyCharm、WebStorm）。有一点学习曲线，但功能的可发现性好太多，加上几个一键安装的插件，五分钟内就能在任何机器上做到他需要的一切。「我发现，对我而言，学会在一个设计良好、开箱即用的环境里做我想做的事，回报远大于试图在我的机器上并行管理一个迷你基础设施项目。」
bayesianbot 提供了一个诚实的中间立场：对他来说定制配置不是从「真正的任务」里偷走的时间——他在不想干活或者在为下一步做背景思考时做定制。「这是一种在我没状态时保持大脑为编程预热的有趣方式。我猜 80-90% 的定制是浪费时间，但那些最终留下来的可以真的很有用，每天省下几十次时间/精力。」
「都是关于选对问题」
4lx87 用一句话点透：「最有生产力的程序员能够选择最有影响力的问题去解决，以及怎么解决它？这里有个教训。」
treszkai 给出了本帖理论化程度最高的一条：这是效率（efficiency，作者所追求的）和效果（effectiveness，Bob 拥有的——解决对的问题而且只解决那个问题）之间的区别。两者不在同一个坐标轴上衡量：Bob 也许能靠更好的配置提高 20% 效率，从而把交付价值提高 20%；但作者在效率上早已饱和，再好的工具也赢不了黑客马拉松，因为他被卡在更高层的抽象上（方向、想法、愿景、市场洞察）。他还补了一刀：「类似地，再多效率提升也不会让微软产出高质量软件，因为他们在优化别的指标。」
readthenotes1 指出这几乎是直接出自 Fred Brooks《人月神话》的观察（源于 1960 年代）：「许多软件开发者宁愿做解决问题的基础设施，也不愿真的解决问题。」Sharlin 一句话总结：「想写游戏引擎的人比想写游戏的人多。」
movpasd 提出了一个「专家陷阱」的解释：当你擅长某件事时，调用那部分能力所需的努力少得多，而且通常能从非专家那里立刻得到轻松的正面反馈。对工程师来说那就是代码、工具，还有生产力系统和其他在编程中有用的抽象思维模式。反过来，真正思考你的产品和领域是困难的。「所以在心理上，很容易陷入那些每单位努力带来的心智和社交回报都相对容易的技术性事务，而你感觉很有生产力。但这并不总是客观上对时间的最佳利用。」
YouWhy 给出了一个更黑暗的假说：「生产力」优化工作本质上是工程师逃离与问题域的模糊性、政治、含混、失败风险和其他痛苦正面交锋的出口。「唉，解决一个来自真实世界的问题，需要直面这个世界——比如在脑子里走一遍用户工作流的乏味，或者通过清晰表达和提议一套联合策略来让别人配合你。我不相信为痛苦而痛苦，但好的交付有一种内在的运动员品质，而一个人无法成为运动员，除非接受为赛道训练意味着精通管理痛苦——而且是在赛道上，不是在别处。」
最精彩的两个故事
jbyers 贡献了本帖最高票的两个亲历故事，值得完整转述。
第一个：2000 年代初，他们有个远程工程师（他们在硅谷，此人在中欧），产出量惊人，而且是全方位的明星——支持团队其他人、修 bug、写文档、人还特别好。团队开玩笑说他一定是把活儿外包给了整个镇子的人。费了很大劲搞定签证后他终于来访，全办公室都很兴奋。他带来一台小笔记本，屏幕只有 13 寸 MacBook Pro 的一半大，坐下就开始写代码。一小时后有人问他家里用什么机器，要不要借个大显示器或台式机？他说：你在说什么，这就是我唯一的电脑。「你能听见蟋蟀的叫声，因为团队每个成员都有同一个念头：如果他在这么小一台笔记本上都这么高产……」
第二个：他们公司做了第一个在 Linux 上的 Oracle ERP 实施，在 2000 年代初这是件大事，过程非常痛苦，需要和 Oracle 的团队一起修各层的大量 bug。多轮升级之后他们告诉 Oracle 需要更多马力，Oracle 同意派出他们最好的顾问，宣传得像《低俗小说》里 Harvey Keitel 演的那位「清道夫」。办公室里的 Oracle 团队对他敬若神明。
这人来了，非常友好、说话轻柔、毫不张扬。他们让他坐在一台 Windows 机器前，问他需要什么。他说：我只需要访问各个系统的权限，这个原版 Windows 装机就挺好。
他打开了记事本。他不会盲打，他是二指禅。「我心想：这人是 The Wolf 的概率是零。」
然后他看着这人在记事本里写 SQL 和 PL/SQL，写巨大的查询，没有任何参考资料、没有任何干扰，慢慢地一个键一个键敲。他意识到：这人不打错字，不回退。他看看问题，思考几分钟，跟人聊聊，再想一会儿，跑几个探索性查询，磨出一段代码，粘进去运行，然后下一个。显然不是每个查询都完美运行，但他 90% 的工作是在脑子里做完的，然后只是把带子放出来。
「他几周内做的事比其他顾问六个月做的还多。我不确定他有没有碰过删除键，而且我确定他除了记事本什么都没用。长话短说，你看几个这样的人干活，就再也不敢对『优秀是什么样』做任何假设了。永远不要低估那些不像你、不用花哨编辑器、不符合你脑中理想高产形象的人。用他们如何对待其他人、以及他们的产出来评判他们。」
其他有分量的碎片
hokapo 讲了一位数学教授的做法：他写研究算法时用的是纯文本编辑器，因为他想让编码变慢，好有时间把问题想透。「当我们把所有例行公事自动化掉时，就没有空间留给那些手上忙碌时冒出来的创造性想法了。这在 AI agent 时代尤其适用。当造东西这么快时，我需要刻意时不时停下来，想想是不是真的值得钻进某个兔子洞，还是我该重新评估真正的问题是什么。」
bob1029 说他离电脑越远做的事越多，把三台显示器减到一台后生产力大幅提升。「我大部分问题是在切菜或者割草的时候解决的。坐在闪亮技术面前并不会魔法般地赋予人更快做出更高质量决策的能力，我发现恰恰相反。我能大幅超越客户的开发团队，仅仅因为我不是全职员工，可以空闲足够久来用慢的方式思考他们的问题。让 Teams 的状态圈保持绿色的紧迫感（以及相关的生产力表演）在很多公司里制造了大量愚蠢决策。」（croemer 顺手开了个玩笑：「看你的用户名，你就是文章里的 Bob 吗？」）
discreteevent 提出了一个结构性解释，并链接了一篇相关文章：有一个泡沫，VC 支持的公司并没有产出人们真正使用或付费的东西，所以为了给估值找理由，它们转而展示自己有多高产。他引用的那篇文章对比了这类公司（「虚无主义者」）和游戏开发者：「永远不盈利的风投支持初创公司，其虚假生产力与其高估值普遍非物质的本质相关联；而游戏工作室靠产品的盈利能力生死。」「在一个『重要的不是你赚多少，而是你值多少』的经济部门里，那些工作流建立在如今占 Product Hunt 产出近 40% 的生产力应用之上的公司，其劳动实际上并不指向创造一个东西，而是指向创造一个东西的表象。」（不过 jeremyjh 补了一句：游戏开发者在工具上投入巨大精力，只是不特别在文本编辑器上。）
jreynar 说他记得 Facebook 时期的 Bob，并补充了一个动机层面的解读：选对问题很重要，但他认为还有一种对地位的追求导致了大量生产力表演。「人们认为——在某些环境里也确实如此——忙碌能确保自己被重视。而没有比坚持要用一个新工具、然后负责保持里面的数据最新更好的让自己忙起来的方式了。Notion 用好了是无价的，但我给几家公司做过顾问，在那里『打理 Notion 花园』成了某人的工作，尽管那里并没有任何增量价值。」他给出的解法是聚焦结果：没人在决定黑客马拉松赢家时在乎 Bob 的工具选择可能拖慢了他。
试图把话题拽向 AI 的尝试
nsoonhui 问：不太明白文章的点在哪，因为有了 AI 我能比没有时快得多地清空积压。这怎么就不是真实的生产力提升？
回应相当不客气。raincole 说：「不太明白你评论的点在哪，但 AI 兄弟们有把每场讨论都变成 AI 讨论的名声。」Cthulhu_ 更直接：「这篇文章不是关于 AI 的，是关于开发者和他们精心搭建的编码配置被一个用纯编辑器的人击败。你没有被人身攻击。」blargey 补充：「哪怕最便宜的 LLM 摘要都会清楚地告诉你这不是关于 AI 讨论的。」sodapopcan 给出了一条更有建设性的说法：「如果你真的必须在这里提 AI，更相关的评论会是你可能把 AI 工作流搞得过于复杂，或者过度关注提示词。」skydhash 则贡献了一句纯玩笑：「清空积压最快的方式是删掉它们。/s」
不过后续的讨论确实自然地流向了 AI 时代的对应现象。antonvs 说他在公司里正看着这一幕上演：「折腾 skill 的人无一例外是对实际发货产品影响最小的人。我怀疑他们希望自己能撞上那个让他们变得高产的魔法配方。」breppp 也说：「在 AI 世界里你看到的是那些过度精致的提示词 markdown 文件，我的 agent 给四个 agent 团队做绩效评估，每个团队都有自己古怪的人格特质。」Nursie 则贡献了一句黑色幽默，回应「90% 的时间该用来思考」：「那 90% 的时间应该用来等 Claude 请求权限了！」
nagoff 提供了本帖唯一一个量化数据点：他有自己小团队从前 AI 基线开始的数据，加上 GitHub Copilot 后每人每天的 PR 数翻倍，加上 Claude Code 后是基线的五倍。
raincole 提到他见过的最好的艺术家至今还在用 Photoshop CS6（配一块没有屏幕的 Wacom）。gniv 认为大多数专业人士对工具都很保守：掌握它们花了很长时间，改变很难。_rousbound 说他父亲至今用 Borland 的编译器和 IDE 编译 C++ 程序，完全没有语法高亮，而且这是个商业产品，不是宠物项目或爱好。「真的让我惊叹。」