我每天都在等AI，却越来越累

本文来自微信公众号： 简写2019 ，作者：余子申，原文标题：《我每天都在等 AI，却越来越累》

让我感到累的，并不是工作量本身，而是项目之间的来回切换。

事情通常是这样开始的。

我把一个A任务交给AI：

写代码、跑分析、生成初稿。

理论上，我只需要等几十秒，或者几分钟。

等待的这段时间，看起来很短。

短到让我几乎不可能什么都不做。

于是我会下意识地切到B：

看一眼另一个项目的进度，

回一条需要思考的消息，

或者顺手点开C任务的草稿。

等AI返回结果，我再切回A。

表面看，一切都很合理，甚至很“高效”。

但一天结束的时候，我却经常只剩下一种感受：

非常累。

而且这种累，很难用“工作太多”来解释。

后来我慢慢意识到，人脑的“带宽”其实非常有限。

我第一次真正意识到这一点，是在很多年前读《思考，快与慢》的时候。

当时我并没有想用它来解释自己的工作方式，只是隐约记住了一个感觉：

人的理性、注意力和控制力，并不是一个随时满格的资源。

直到后来读到《稀缺：我们是如何陷入贫穷与忙碌的》，

我才真正把这种感觉对上了一个非常贴切的词——带宽（Bandwidth）。

余闲与自由

这本书里有一个极其朴素、但击中我的结论：

当你的心里同时挂着太多“未完成的事情”，

你的可用带宽，就会被持续占用。

带宽的感觉，其实非常像电脑的后台进程。

人的认知状态，很像一台电脑：

前台，是你正在做的那件事；

后台，是那些你已经切走、但还没结束的任务。

你可能已经看不到它们了，

但它们依然在运行。

它们会：

占用CPU，

占用内存，

干扰系统调度。

于是就会出现一种很诡异的状态：

你明明只在专心做一件事，

却感觉整个系统越来越慢。

后来我才意识到，

真正拖慢我的，从来不是当前任务，

而是那些还没关掉的项目。

多任务真正的问题，不是并行，

而是跨项目并行。

想清楚这一点之后，我并没有走向另一个极端。

我并没有要求自己一次只能做一件事，什么都不碰。

那样在现实里是行不通的。

真正的变化，是我区分清楚了两种完全不同的并行方式：

项目内并行，以及跨项目并行。

它们对大脑的消耗，完全不是一个量级。

为什么项目内并行，几乎不怎么累？

以我最近在写一份行业洞察报告为例：

我会先让AI去跑第一部分的数据抓取脚本。

在它执行的这段时间里，我并不会跳去做另一个完全无关的项目，

而是继续留在同一份报告里，

去推敲第二部分的结构、论证路径和表达方式。

表面上看，我在“切换任务”；

但实际上，我始终停留在同一个上下文空间中，

只是在不同层级之间移动——

从数据到结构，从结构到表达。

这种切换，几乎不需要重新进入状态，

反而能把等待时间转化为有效推进。

因为这些工作：

• 共享同一个目标，

  
  

• 共享同一个背景，

  
  

• 共享同一套判断标准。

  
  

我不是在重建世界，

只是在同一张地图上移动位置。

从带宽的角度看，

我是在复用同一批后台资源。

真正让人累的，是跨项目切换。

当我从项目A，直接跳到项目B，再跳到项目C时，情况就完全不同了。

每一次跨项目切换，都会同时发生三件事：

• 旧项目并没有真正结束；

  
  

• 新项目需要重新加载完整的世界模型；

  
  

• 多个项目同时占用有限的带宽。

  
  

从《稀缺》的视角看，这本质上是在

主动制造“认知稀缺”。

不是事情太多，

而是同时“开着”的项目太多。

而AI，反而放大了这个问题。

AI让启动一个新任务的成本变得极低，

低到我们几乎不会犹豫。

于是我们可以同时：

• 等一个模型输出，

  
  

• 跑一个分析，

  
  

• 写一半文档，

  
  

• 想另一个选题。

  
  

结果是：

机器在并行，

人却在被后台任务慢慢拖垮。

现在我真正给自己的限制，其实只有一条。

允许并行，

但不允许跨项目并行。

AI可以同时推进多个项目，

但我自己，同一时间只“住在”一个项目里。

在这个项目内部，

我可以前后切换、反复修改、不断推进；

但我不会让多个项目同时占用我的心智带宽。

不是因为我想慢一点，

而是因为我终于意识到：

带宽一旦被挤占，所有事情都会一起变慢。

以前我以为忙，是事情多。

现在我更倾向于认为：

真正的忙，是太多任务还在后台运行。

而效率，很多时候不是来自更激进的并行，

而是来自——及时关闭那些暂时不用的进程。

AI负责并行计算，人负责保持世界的完整。