Lenny 的播客最近访谈了 Simon Willison——25 年经验的工程师。他说了一句话让我停下来想了很久：我现在 95% 的代码不是自己打的。我每天早上 11 点就已经精疲力竭了。

很多人听完松了一口气：原来不是我一个人。

很多硅谷工程师也有同样的感受。Steve Yegge——前 Google、前 Amazon 的工程师——用了一个词：vampiric effect（吸血效应）。AI 让你亢奋，你拼命工作，然后被榨干。他在工作台旁边放了枕头和毯子。高强度 AI 编程，他说每天大概只能撑三个小时。

不是幻觉，BCG 做过研究

BCG 做了一项研究，样本是 1488 名全职工者。14% 的 AI 重度用户已经经历过他们定义的 "AI brain fry"。这批人的重大错误率比对照组高了 39%。

这不是个人体验的问题，这是一个正在发生的集体现象。最先感受到的是用得最深的那批人。

以前瓶颈在工具，现在瓶颈在你

为什么更累？先想一个问题：以前写代码，瓶颈在哪里？手敲、查文档、等编译、等 code review——这些东西占掉了大量时间。但这些都是工具的限制，不是你的限制。

现在这些全消失了。你说一句话，Agent 去写、去跑、去调试。执行这件事，机器扛走了。

但还有另一种负荷，机器没有扛走：验证输出对不对、判断方向要不要调、决定下一步怎么走。这些叫「评估负荷」。每一次都需要你真正在场，没有办法挂机，没有办法分心。

Glorian Mark 在 UC Irvine 研究过注意力切换的代价：被打断一次之后，恢复到原来的专注程度，平均需要 23 分 15 秒。每一次切换，你都在付出将近半小时的认知成本。

同时跑四个 agent——每个都在推进，都在产出，都需要你随时判断。你不是同时盯着四个，你是在它们之间来回切换。四次切换，四份恢复成本，不断叠加。这不是四倍的产出，这是在透支一个固定的账户。

三层负荷

我把这些整理了一下，有三层：

执行负荷——动手做的事。机器扛走了。以前这部分最累人，现在它消失了。

评估负荷——判断和决策。一分没少，全在你这里。每一次 agent 输出结果，你都要判断对不对、要不要改、下一步怎么走。这比以前更频繁了——因为 agent 产出太快了。

焦虑负荷——新增的，以前没有。你不知道每个 agent 在悄悄把什么搞错。你对系统失去了完整的能见度，但责任还是你的。Eddie Osmani 说，agent 数量增加，不代表你这个人可用量增加。你还在承受另一种负荷：不知道每个 agent 在悄悄把什么搞错的焦虑。

业界在怎么应对

说实话，还没有人真正解决这个问题。现在有的只是一些摸索：

一些团队开始限制 agent 的并发数量，强制人一次只跟一个 agent 深度协作。一些人在写更好的 prompt 和结构化流程，减少判断的颗粒度。还有一些团队在做"同步点"设计——agent 每完成一个阶段停下来汇报，人在同步点做判断，而不是持续监控。

这些都不是终极方案。但我越来越觉得，AI 工具的设计者需要认真思考一个问题：如果用户每次判断都要付出 23 分钟的恢复成本，那你设计的工具是在帮助人，还是在透支人？