如何保持思考

想象你参加了一档节奏疯狂、以软件工程为主题的游戏节目。主持人不断翻出新卡片，卡片上的问题需要你尽快回答：

• 对数据库 schema 的这项调整对吗？
• 这几组数据看起来合理吗？
• 这五段文字描述的，真的是一系列已经发生过的手动测试吗？
• 这套建议的架构在直觉上站得住脚吗？
• 这个实现比现有代码好吗？那这个呢？还有这个呢？

2026 年的工作有点像这样。当最前沿的 AI 模型能够处理待办队列中的大多数任务时，最高效的工作方式往往是把任务分派给 AI Agent，然后在一个又一个结果之间不停切换¹。这并不算完全不动脑——事实上，快速浏览 AI 的回答并决定如何处理，仍然很需要技巧——但它确实让人少了许多慢下来、仔细反思的时间。

为什么不放慢一点？

为什么一定要这么兵荒马乱？为什么不干脆慢下来？我想你可以这么做，但我并不推荐。把一天都花在逐字细读 LLM 输出上，体验实在很糟糕：小心翼翼地咀嚼、品味每一口 AI 生成的内容。比起这样，快速扫过一遍，从中挑出真正有价值的信息，令人舒服得多。

难道不能更多地亲自动手做吗？不幸的是，正如我曾写过的，如今科技行业的压力很大。如果你有时间和空间以更慢的节奏工作，那当然很好！但当公司递给你一个“把这项任务快十倍完成”的按钮时，你会被强烈激励尽可能多地使用它，否则就有被同事甩在后面的风险。

有时我担心，和 LLM 一起工作会让我变笨。不是一些论文与文章所暗示的那种“真的把大脑融化掉”的意思，而是说：它会让我更偏向心智工具箱里“快速扫读与判断”的部分，而远离深入思考和真正创造力所需要的、缓慢的“吊床时间”。我不想把这种转变完全归因于 LLM；因为 2010 年代之后，科技行业也出于更广泛的经济原因变得越来越急促。但不管怎样，这让我开始思考：我怎样才能继续思考，继续慢慢思考。

想持续思考，就阅读和写作

对我最有效的方法，是多写一点。更准确地说，是用自己的话写。哪怕你已经花了不少力气迭代内容、列出想说的要点，用 LLM 写作也完全起不到这个作用。为什么？因为必须亲自把词句组织起来，会迫使你把想法说清楚。从非常真实的意义上说，它会迫使你思考。

当你脑中有一个想写下来的点子时，你其实并没有真正拥有一个点子。你拥有的，是某个点子可能所在方向的一种感觉，或是一块最终可能变成点子的碎片。你是在写作的过程中，把点子本身建构出来的。顺带一提，这也是为什么我并不认同“点子很容易，执行才是一切”这句话²：大多数所谓的“点子”，其实根本还算不上点子。

另一件我推荐做的事，是读真正的书。书——尤其是内容密集的非虚构作品——恰恰是 AI 生成内容的对立面。读得越慢越好。过去几年里，我读的非虚构作品越来越多，我不认为这是巧合。我想，我的大脑正在自然地渴求信息密度高的内容，就像缺钠的人会开始渴望盐分一样。

事实上，我一直在把这两种方法结合起来：读一本书，然后写写它。自从开始用 LLM 编程后，这个过程正是我一直渴望的东西。我可以仔细读一本书，认真思考它，经常还会再找一两本同主题的书读；然后坐下来，尝试把自己学到的内容说清楚。这种感觉很棒！我能感觉到大脑的某些部分又重新舒展起来。

别丢掉这个习惯

过去，能一整天拿这些大脑区域来工作，而且还能因此获得报酬，确实很不错。遗憾的是，我认为那样的时代正在结束。软件工程中永远都会需要一定程度的审慎和慢思考，但至少在未来一段时间里，我们会被期待着在 LLM 的输出之间迅速切换。为了延续慢思考的习惯，我们可能得在工作之外另找方法。

即使只从工作角度看，彻底失去这个习惯也是一个很大的错误。还有大量普通问题，是当前 LLM 无法独自解决的。我最常遇到的例子是：“在复杂代码库中进行大规模重构”。这一代 LLM 已能在不犯（太多）错误的情况下完成它，但还做不到完成得有品味。有时候，你仍然需要只靠自己的大脑，把一个问题从头到尾想透。