如何保持思考

想象一下，你正在参加一档节奏飞快、以软件工程为主题的游戏节目。主持人不断翻开写有新问题的卡片，你必须尽快回答：

• 数据库 schema 这么改对吗？
• 这些数据看起来合理吗？
• 这五段文字写的，真是一系列实际做过的手动测试吗？
• 这套架构方案基本说得通吗？
• 这个实现比现有代码更好吗？这个呢？或者这个？

到了 2026 年，工作大概是这样的：当前沿 AI 模型已经能处理任务队列里的大部分工作时，最高效的做法往往是把任务交给 AI Agent，再不断切换查看它们返回的结果¹。这并非完全不需要动脑。快速扫一眼 AI 的回复，立刻判断下一步该怎么处理，其实很考验技巧。不过，这种工作方式确实很少让人有时间慢下来仔细思考。

为什么不慢下来？

为什么一定要这么忙乱？为什么不能慢下来？当然可以，但我不建议这样做。花一整天逐字细读 LLM 的输出，实在是一种痛苦的体验：你得仔细琢磨那些粗制滥造的内容。快速扫一遍，只从中挑出有用的信息，要好受得多。

难道不能干脆多亲手做一些工作吗？遗憾的是，如今科技行业压力很大，这是事实。如果你有余裕放慢工作节奏，那当然很好！但当公司给了你一个“把任务解决速度提高十倍”的按钮时，现实压力会迫使你尽可能多用它，否则就可能落后于同事。

有时我担心，与 LLM 共事正让我变笨。我说的不是某些论文所暗示的那种“真的把大脑融化掉”，而是我越来越依赖快速“浏览与判断”的能力，越来越少用到深度思考和真正创造所需的缓慢“吊床时间”。我不想把这种变化完全归咎于 LLM，因为 2010 年代之后，科技行业也因为更广泛的经济原因变得越来越忙乱。但不管原因是什么，这都让我开始琢磨，怎样才能继续思考，而且是慢下来思考。

要不断思考，就去阅读和写作

对我来说，最有效的办法是多写。更确切地说，是用自己的话写作。用 LLM 写作完全起不到这种作用。哪怕你花了不少功夫反复调整内容，列出自己想表达的要点，也不行。为什么？因为亲自组织词句会迫使你把想法说清楚。说到底，它会迫使你去思考。

当你脑中冒出一个想写下来的念头时，并不代表你已经有了完整的想法。你只是隐约知道它大概要往哪个方向发展，或者只捕捉到一个小片段，日后才可能发展成完整的想法。真正的想法是在写作过程中构建出来的。顺带一提，这就是为什么我不太认同“想法很容易，执行才是一切”²：大多数所谓的“想法”，其实连想法都还算不上。

我还建议真正去读书。书，尤其是内容密集的非虚构作品，恰恰与 AI 粗制滥造出来的内容相反。读得越慢越好。过去几年，我读的非虚构作品越来越多。我认为这并非巧合。我的大脑似乎在本能地渴求信息密集的内容，就像缺钠的人会开始渴望盐一样。

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

不要丢掉这个习惯

以前，我的工作就是整天运用这些脑力，还能因此拿到薪水，那种感觉相当不错。遗憾的是，我认为那样的日子快结束了。软件工程始终需要一定程度的审慎和慢思考，但至少在接下来一段时间里，工作会要求我们在不同的 LLM 输出之间快速切换。想保留慢下来思考的习惯，我们可能得从工作之外想办法。

哪怕只从工作的角度看，彻底丢掉这个习惯也是个严重的错误。仍有许多普通问题很难，当前的 LLM 还无法独立解决。我最常遇到的例子是“在复杂代码库上进行大规模重构”。当前一代 LLM 可以完成这类工作，而且不会犯下太多错误，但还无法做到在工程上恰到好处。有时，你必须只靠自己，从头到尾把问题想清楚。

下面是一篇与本文标签相关的文章。

好的写作追求显然，而非原创

写作不必刻意追求新奇，认真表达那些显然正确、却容易被忽略的事实，反而更可能写出真正原创的作品。

继续阅读……