作者：Sean Goedecke
想象一下，你是某档节奏飞快、以软件工程为主题的游戏节目的嘉宾。主持人不断翻开写有新问题的卡片，而你必须尽快作答：
- 这项数据库模式调整正确吗？
- 这些数据看起来合理吗？
- 这五段文字描述的，真的是一系列实际进行过的人工测试吗？
- 这个架构建议经得起直觉检验吗？
- 这个实现比现有代码更好吗？还是这个？或者这个？
2026 年的工作体验有点像这样。当前沿 AI 模型能够完成你任务队列中的大部分工作时，最高效的工作方式往往是把任务分派给 AI 智能体，然后不断在它们返回的结果之间切换上下文 1。这并非完全不需要动脑——事实上，快速浏览 AI 的回复并迅速决定下一步该做什么，需要相当多的技巧——但它的确让人更少有时间进行缓慢、审慎的思考。
为什么不慢下来？
为什么一定要这么忙乱？为什么不直接慢下来？我想你当然可以，但我不推荐。整天逐字细读 LLM 的输出，实在是一种痛苦的体验：像细嚼慢咽一样，认真品尝每一口 AI 泔水。快速浏览，从中挑出有用的信息碎片，要轻松得多。
难道不能多亲手完成一些工作吗？遗憾的是，如今的科技行业压力很大。如果你拥有足够的时间和空间慢慢工作，那当然很好！但当公司给了你一个“把这项任务快十倍解决”的按钮时，你会受到非常强烈的激励，尽可能多地使用它，否则就有可能被同事超过。
我有时会担心，与 LLM 一起工作正在让我变笨。不是某些论文暗示的那种“真的把大脑融化了”，而是它让我的思维工具箱越来越偏向快速的“浏览与判断”，却远离深度思考和真正创造力所需要的、缓慢的“吊床时间”。我不想把这种变化完全归咎于 LLM，因为 2010 年代之后，科技行业变得更加忙乱也有更广泛的经济原因。但无论如何，它都让我开始思考：怎样才能继续清晰地、缓慢地思考？
要继续思考，就去阅读和写作
对我来说，最有效的方法是多写。更确切地说，是用自己的语言写作。借助 LLM 写作完全起不到同样的作用，即使你花了不少力气反复修改内容、列出自己想表达的要点也不行。为什么？因为亲自组织语言会迫使你把想法清楚地表达出来。从非常实际的意义上说，它迫使你去思考。
当你脑中有一个想写下来的念头时，你其实还没有真正的想法。你拥有的只是一种模糊的方向感，知道想法也许在哪里；或者只有一块可能最终发展成想法的碎片。真正的想法是在写作过程中被构建出来的。顺带一提，这也是为什么我不太认同“想法很容易，执行才是一切” 2：大多数所谓的“想法”，其实甚至还称不上想法。
我还建议你阅读真正的书。书籍——尤其是信息密度很高的非虚构作品——正是 AI 泔水的反面。读得越慢越好。过去几年里，我读的非虚构作品越来越多，我不认为这是巧合。我觉得自己的大脑正在本能地渴求高信息密度的内容，就像缺钠的人会开始渴望盐一样。
事实上，我一直在把这两种方法结合起来：读完一本书，然后写点关于它的东西。自从开始用 LLM 编程以来，这个过程恰好满足了我一直以来的渴望。我可以认真读一本书，深入思考，常常还会继续阅读一两本讨论同一主题的书，最后坐下来，努力说清楚自己究竟学到了什么。感觉非常棒！我能感觉到大脑里的一些部分又开始舒展开来。
别失去这个习惯
过去，我能靠整天使用大脑的这些部分来获得报酬，那种感觉很好。遗憾的是，我认为这样的时代正在结束。软件工程中永远都会为一定程度的审慎、缓慢思考留下空间，但至少在一段时间内，人们会期待我们在多个 LLM 输出之间快速切换。我们或许不得不在工作之外寻找办法，继续保持慢思考的习惯。
即使只从工作的角度来看，我也认为彻底失去这个习惯会是一个大错误。仍有许多普通问题对当前的 LLM 来说太难，无法独立解决。我最常遇到的例子是“对复杂代码库进行大规模重构”。这一代 LLM 已经能够完成这种工作而不犯下太多错误，但它们还做不到有品位地完成。有时候，你必须能够完全依靠自己的大脑把一个问题想透。