PostgreSQL码农集散地

AI 时代警惕“注意力塌方”

早上打开电脑,五个 agent 窗口同时在跑,一个在改接口,一个在写测试,一个在排查昨晚的报警,一个在做小范围重构。代码一行没敲,人已经先累了一半 —— 脑子里同时挂着五条没跑完的线,随时可能有哪个突然弹出一句"这里需要你确认"。

为什么"效率变高"和"人变累"这两件事,明明听起来矛盾,却实实在在同时发生了。

AI 时代, 人的注意力在失焦, 并行多任务, 来回切换, 人极难进入心流状态. 这对人类来说, 真的好吗?

被反复撕开的注意力

先说结论:让人疲惫的往往不是工作量本身,而是切换。

心理学家 Sophie Leroy 在 2009 年的经典研究里发现,人从一件没做完的事切到下一件事上时,注意力不会干净利落地跟着走 —— 尤其是上一件事还带着时间压力或者没个明确的结束点。一部分注意力会滞留在原地,拖累接下来这件事的表现,而且这种拖累不是几秒钟就消散,往往会贯穿你接下来一整段工作时间。这就是"没做多少事却觉得被掏空"的直接解释。

加州大学欧文分校的 Gloria Mark 团队做了更进一步的追踪:一次被打断之后,人平均要花二十多分钟才能重新找回原来的专注状态。还有一份实验数据显示,快速来回切换注意力 —— 也就是大部分人以为的并行"多任务" —— 不但不会提高效率,反而会让错误率上升、血压这类应激指标也跟着走高。你在几个终端窗口之间来回巡视五个 agent 的产出,本质上就是在批量制造这种"打断—恢复"的循环,一次又一次。毫不夸张的说, 甚至可能导致猝死概率升高.

再往深一层, 进入心流状态的前提和多任务完全相反: 目标清晰、挑战和能力匹配、反馈要及时、注意力要高度集中而不是四处分散。而"同时监工好几个 agent"这种工作方式, 恰好在结构上把后面两条全破坏了 —— 反馈是延迟且分散的,你得等每个 agent 各自跑完才能回头看;注意力被设计成必须在多个信息源之间来回巡视。这不是你进不去心流,是这套工作模式的结构本身就和心流互斥。

心理学里还有一支专门研究"监控类任务"的分支,发现持续盯着一个信息流、随时准备捕捉那个稀疏但重要的异常 —— 哪怕大部分时间什么都不用做 —— 本身就是一种会随时间累积疲劳、反应变慢、容易漏检的认知负荷, 雷达兵、质检员、安防监控员长期承受的就是这种类型的累。程序员这几年悄悄从"写代码的人"变成了"盯着 AI 写代码、随时准备挑错的人", 干的正是这个活。

AI 效率提升省下来的时间,去哪了

AI 明明把生产环节的时间压缩了那么多, 但是省下来的时间去哪了?

先看两组数字。

Anthropic 在 2026 年的一份行业趋势报告里给出过一个耐人寻味的数据: 开发者现在大约六成的工作量由 AI 完成, 但真正能做到"完全交给 AI、不用人回头看"的任务占比只有 0 到 20%。也就是说,AI 产出得越多, 人需要过一遍的绝对数量也在同步往上走,效率提升并没有换来监督负担的下降。

Sonar 同一年的调查里还有个更扎心的: 九成六的开发者说自己不信任 AI 生成的代码, 但与此同时, 四成六的新代码就是 AI 写的, 八成的 AI 产出在定稿前还得被人工改过。

这两个数字放在一起说明的其实是同一件事 —— 开发者的重心已经从"创作"挪到了"带着怀疑去校对一个不是自己写的东西", 而校对陌生上下文里的代码, 跟写自己构思出来的代码, 完全是两种活。

Salesforce 的一份连接性基准报告里还提到, 企业平均同时跑着十几个 AI agent, 其中一半彼此并不互通、无法协同 —— 这意味着"协调"这件事被默认丢给了坐在中间的那个人去手动完成, 而不是被系统自动吸收掉。

那这部分省下来的时间, 理论上讲应该变成谁的休息时间?

十九世纪经济学家 Jevons 发现过一件类似的事“杰文斯悖论”: 蒸汽机烧煤的效率提高了, 煤炭总消耗量却没降, 反而因为"划算了"而涨了上去。

Box 的 CEO Aaron Levie 把这套逻辑搬到 AI 身上, 他的判断是: AI 让知识工作变便宜,不会带来更短的工时,只会带来更高的产出预期、更快的迭代节奏、每个人要扛的任务范围越来越大 —— 效率提升本身, 正在变成一个不会让工作变少、只会让工作变多的陷阱。

AI agent 要真正兑现效率红利, 前提是"需要人持续投入管理、监督和大量上下文" —— 效率红利从来不是白来的, 它有一个交换条件, 而这个交换条件恰恰落在了使用 AI 的个体身上, 没有被系统自动吸收掉。这就是为什么"效率变高"和"个人更累"完全可以同时成立, 二者压根不矛盾。

不过这个阶段不会永远持续, 效率提升到一定程度终究会超过市场扩张的速度"。所以眼下更准确的说法是: 在当前这个阶段, 组织默认把省下来的时间转成了更高的产出预期, 而不是更少的工时, 这不是哪家公司故意压榨, 而是效率工具在缺少主动的工作量重新设计时,天然会被拿去"多做事"而不是"少做事"。

人被重新定义成"监督者"

如果把镜头拉得更远一点, 会发现人被重新定义成"监督者"这件事在历史上早发生过好几轮, 只是主角换了一茬又一茬。

学界研究"算法如何管理人"已经研究了小半个世纪: 呼叫中心时代靠录音监听、话务统计实现了当时"前所未有的管理控制水平"; 平台经济时代, 外卖骑手、网约车司机被算法调度、评分、纠错, 这种控制被形容为从"监狱式的中心化监视"升级成了"渗透进整个劳动过程的自动化数据采集" —— 控制的密度是一路往上走的, 不是随自动化程度提高而变松。

有意思的是, 今天 AI coding agent 场景里发生的其实是个反转版: 过去是算法管理人, 现在变成了人管理一堆算法, 但"监督"这件事本身作为一种独立的劳动类型, 并没有因为被监督的对象从人换成了 AI 就消失。哪怕是那种所谓"关灯也能跑"的全自动化“黑灯工厂”, 依然离不开人来做设备的初始设置、成品的质量抽检、机器的维护维修 —— 自动化几乎从来不是彻底的替代, 而是把人从"直接生产者"重新安放成了"监督加维护者"。程序员现在的处境, 某种意义上更接近一个质检员, 而不是过去那个从零构思代码的作者。

不过把程序员完全等同于"被动执行监督流程的质检员", 多少有点低估了这件事里还剩下的主动性。拆任务、写清楚给 agent 的验收标准、设计整个编排的分工方式, 这些事本身仍然是有创造性、需要判断力的高价值工作, 只是这份创造性发生在传统心流理论定义的"专注写代码"之外, 还没有找到属于它自己的、能带来成就感的形态。

历史上看,"监督加维护"这个角色一旦被组织正式确立成一个独立工种 —— 比如工厂里专门的质检岗、呼叫中心专门的质检团队 —— 它的疲劳是可以靠轮班、明确的抽检比例、容错阈值这些制度手段去管理和分担的, 累这件事不会凭空消失, 但可以被结构性地分掉, 而不是无限叠加在一个人原本的写代码职责上面。

现在大概率是过渡期问题

"AI 越高效、人越累"这个现象成立的前提:

  • 你手上盯着的不止一个信息源, 而且它们进度和上下文彼此不连续;
  • 这些产出需要你做判断性校验, 而不是能被规则自动裁决;
  • 校验的时间点由 agent 决定, 不由你自己说了算;
  • 而组织又默认把省下来的时间换成了更快的交付节奏, 没有制度性地把它划给你休息或深度工作。

如果哪天"校验 AI 产出"被正式当成一个有独立时间预算、独立验收标准的工作环节, 不再是被要求实时盯着、见缝插针地夹在写代码中间, 那种连轴转的疲惫感就会减轻, 即便"监督"这件事本身永远不会彻底消失。

又或者监督的活, 以后也有独立的 Agent 干了, 人类彻底解放.