AI 智能体时代的「多任务陷阱」：等待也是工作的一部分

2026年10月11日

AI 智能体让开始变得容易，也同样容易让人过度承诺。每一次等待都变成开启新任务的邀请，而每一项任务分到的我们就少一点。

几天前，我运行了一个智能体工作流，持续了四十多分钟，开发和审查一个功能。在它运行期间，我在另一个会话中开始了另一项任务。

这算多任务处理吗？界限在哪里？

我没有明确的答案。但这个问题让我注意到一些我想谈谈的事情。

大语言模型改变了我们开发软件的方式，这带来了好事，也带来了坏事。

大约一年前，我加入了一家我此前毫无经验领域的公司。在那第一年里，我对核心库做了一些大规模重构。这很难，也很耗时。但在 AI 之前，如果有人让我做这种重构，我会要求更多时间来先了解产品。更可能的是，根本没人会考虑让我对一个近 20 年历史的代码库做大规模重构。

AI 扫除障碍。它让开始变得容易。而这正是风险的起点：当开始变得容易时，过度承诺也变得容易。我们想交付更多，身边的人也开始期待更多。更重要的是，我们自己想交付更多。

这个问题并不新鲜。卡尔·纽波特的《慢生产力》并不是关于 AI 的，因为这些问题早在 AI 之前就存在了。如果你是任何类型的知识工作者，你可能知道那种感觉：那种要完成超出自己能力之事的紧迫感。

大多数时候，我们试图用两种方式之一来跟上：降低产出质量以完成更多事情，或者同时做很多事情。

降低质量，我指的是交付没有测试覆盖的软件。毫无准备地去开会，或者没拿到所需信息就离开。创建没有清晰、可用文档的软件。发布功能却不衡量其影响。

多任务处理，我指的是在任务内部的短暂等待期间切换到别的事情，或者更糟，在开会期间切换（这也很不礼貌）。

这些事我都做过，有些现在还在做。

无论是不是泡沫，大语言模型都会留下来，而它们让这两个陷阱都更容易掉进去。当智能体在工作时，我可以开始别的事情。我可以并行运行多个会话。每一次等待都变成开启新任务的邀请。

智能体产出代码的速度比我理解和审查它的速度更快。随着运行的会话增多，每个产出得到的我的注意力就更少。纸面上我交付得更多。实际上，每一项任务分到的我就少一点，质量在我没注意到的情况下下降。

在《解析极限编程》中，肯特·贝克写道：

你无法通过降低质量来更快地把软件交付出去。相反，你通过提高质量来更快地把软件交付出去。

为了更快而降低质量是一种偏见，而 AI 让它比以往任何时候都更诱人。速度在开始时是真实的，但工作会回来。测试不充分的软件带着缺陷发布，每个功能都得修了又修，修了又修。如果你跳过为会议做准备，你就得再次联系那个人，或者更糟，靠猜测犯下更大的错误。如果你不衡量功能的影响，你就无法决定该放弃什么，只能继续维护。

AI 可能会把我们推向相反的方向：编写更好的测试、进行更深入的研究、在同一个任务中探索更多想法。那是更多的深度，而不是更多的任务。但这并非默认会发生的事。默认情况下，我们只会做更多。

那么，回到我那四十分钟的工作流程。在此期间做别的事情算是多任务处理吗？

我正在尝试以大约十五分钟为阈值，但说实话，我不知道界限在哪里。每一个新任务，即使是“简单”的任务，都会消耗精力和注意力。而我越是匆忙，它就越有可能回到我身上。

我所知道的是，填满每一次等待的压力是问题的一部分。当智能体在工作时，那种“你做得不够”的感觉，正是促使我们打开另一个任务、然后再一个，直到没有一个任务得到它应得的关注的原因。

等待是工作的一部分。你不需要为此感到内疚。

如果你感到烦躁，利用这段“空闲时间”去深入钻研，提升你正在做的事情的质量：重新阅读你的智能体写的代码，重新阅读问题，向另一个智能体提问，以更好地理解正在发生什么以及为什么。