等 AI 的时间去哪了

你让 Claude Code 重构一个认证模块。它开始工作——读文件、分析依赖、制定计划、写代码、跑测试。

进度条在走。预计还要 8 分钟。

这 8 分钟你做了什么？

盯着终端看输出滚动？拿起手机刷了一圈朋友圈？切到另一个 tab 想处理另一件事，但刚刚加载了一半 context，Claude 跑完了，你被拉回来 review 结果——然后发现你已经忘了前面那个任务进行到哪了？

所有”AI 帮你省了 X 小时”的叙事里，有一个被系统性忽略的变量：AI 工作本身需要时间，而人在这段时间里的状态既不是”工作”也不是”休息”——是”等待”。

这个等待不是空闲。它是一种认知上的半占用状态：你不能完全脱离（因为随时需要 review 结果），也不能深入另一件事（因为切换成本太高）。它是 2025 年程序员最大的隐性时间黑洞。

操作系统在 60 年前就解决过这个问题。它叫”进程调度”。

一个 60 年前就解决过的问题

1960 年代的计算机有一个痛苦的现实：CPU 非常快，但 I/O（磁盘、打印机、网络）非常慢。一个程序在等磁盘读完数据的时候，CPU 就干坐着。闲着。浪费。

解决方案是多道程序设计——当一个进程在等 I/O 时，CPU 切到另一个进程继续工作。后来发展出了越来越精密的调度算法：

FCFS（先来先服务）：谁先到谁先跑，简单但效率低——一个慢进程能堵住整条队。
Round Robin（时间片轮转）：每个进程给一小段时间，轮着来。公平，但切换太频繁时有开销。
优先级队列：重要的进程先跑。灵活，但需要准确判断优先级。
多级反馈队列：动态调整——新进程高优先，长时间没跑完的自动降优。

这些算法的核心目标是三个：最大化 CPU 利用率、最小化等待时间、在公平和效率之间平衡。

现在把”CPU”换成”你的注意力”，把”进程”换成”AI 任务”，你会发现这是完全同构的问题：

你的注意力是稀缺资源（就像 CPU），一次只能全力处理一件事。
AI 任务有很多（就像等待执行的进程），各自需要不同的时间。
AI 在推理的时候（就像进程等 I/O），你的注意力在闲置。
目标同样是三个：最大化你的产出、最小化无效等待、在深度和广度之间平衡。

但有一个关键差异：操作系统的 context switch 成本是微秒级。你的大脑的 context switch 成本是分钟级。

这个差异决定了：人不能像 CPU 那样频繁切换。 人的最优策略不是”更快地切换”，而是”更少地切换”——或者更准确地说，只在值得切换的时候切换。

19% 更慢的真相：调度开销

2025 年 7 月，METR 发布了一项让所有人意外的研究：16 位经验丰富的开源贡献者使用 AI 工具（Cursor + Claude 3.5 Sonnet）完成复杂任务时，比不用 AI 慢了 19%。

不是初学者。是资深开发者。不是简单任务。是他们自己维护的开源项目里的复杂任务。

而且——开发者自己报告”感觉更快了”。客观测量说：不，你更慢了。

为什么？

研究者识别了几个因素：写 prompt 的时间、审查 AI 代码正确性的时间、调试 AI 引入的微妙错误的时间。但这些只是表面。

更深层的原因是 Gloria Mark（UC Irvine）的研究揭示的：每一次任务中断平均需要 20+ 分钟恢复。 对程序员来说，10-15 分钟恢复到编辑状态，30-45 分钟恢复到深度 flow state。如果你每 15 分钟被中断一次，你永远不会进入 flow。

AI 工具做了什么？每隔几秒到几分钟就给你一个建议：接受？拒绝？修改？每一个建议都是一次微型中断。你的大脑必须从”实现模式”切到”审查模式”，做判断，然后再切回来。

研究者把这叫做 “orchestration overhead”——编排开销。工作没有消失。它从”写代码”变成了”管理 AI 写的代码”。对于复杂的、需要持续注意力的逻辑，这种来回切换是净负收益的。

这就是调度问题的核心矛盾：AI 让执行变快了，但让调度变贵了。 如果你的调度策略是”让 AI 每写一行我就 review 一行”——恭喜，你把自己变成了一个效率极低的”人肉 round-robin 调度器”，context switch 成本把 AI 节省的时间全部吃掉了。

四种人机调度策略

既然这是一个调度问题，那就可以有系统化的策略。以下四种从简单到复杂：

策略一：串行阻塞

你 → 下指令 → 等 AI 跑完 → review → 下一个指令

你就是那个 1960 年代的单道程序 CPU——一次只跑一个任务，等 I/O 的时候干坐着。

适用场景：AI 任务很短（< 30 秒），或者你对结果高度不确定需要立即看到。代价：大量等待时间被浪费。Claude Code 跑 8 分钟你就闲 8 分钟。现实：大多数人的默认模式。也是效率最低的模式。

策略二：时间片轮转

你 → 给 AI 发任务 A → 切到任务 B 工作 → AI 完成 A → 暂停 B → review A → 继续 B 或切到 C

这是经典的 Round Robin——在多个任务间切换，每个给一段注意力。

适用场景：你有多个相互独立的任务可以并行推进。代价：context switch。每次切换你都要付出”重新加载上下文”的认知成本。如果任务 B 很复杂，切走 5 分钟再切回来可能需要 10 分钟恢复。 关键技巧：任务 B 必须是低 context 成本的——写文档、回 Slack 消息、做简单的 code review、整理 TODO list。这些任务不需要深度 flow state，随时可以中断和恢复。

策略三：异步批量队列

你 → 批量准备 5 个任务规格 → 全部发给 AI / 多个 agent → 去做自己的深度工作 → 1小时后统一 review 所有结果

这是最高效的策略——把人和 AI 的工作完全解耦。AI 批量执行，人批量审查。没有来回切换。

Addy Osmani（Google Chrome 团队）描述了这种方法：”I’ve dabbled in this ‘massively parallel’ approach; it’s surprisingly effective at getting a lot done.”

适用场景：任务可以被清晰定义（spec-first）且相互独立，你不需要实时看到每一步的结果。代价：需要前期投入更多时间做任务规划和规格编写。如果 spec 不清晰，AI 可能跑偏了一小时你才发现。 关键前提：你必须有足够的任务分解能力——把一个大目标拆成多个独立的、规格明确的子任务。这本身就是一种高阶技能。

策略四：分层调度（人做决策层，AI 做执行层）

你的注意力只停留在"架构决策"和"方向判断"层面
AI 处理所有"实现细节"层面的工作
你只在 AI 遇到架构级问题时被"中断"（类似 OS 的硬件中断）

这是最接近”人类作为操作系统内核”的模式——你不参与每一行代码的生产和审查，你只在更高的抽象层工作：定义问题、设计架构、判断方向、验收结果。

适用场景：你对问题域有深刻理解，能写出精确的高层 spec，且 AI 的执行质量足够高不需要逐行审查。代价：对 AI 能力的信任需要建立过程。如果 AI 经常在细节上出错，你会被频繁”拉回”执行层，分层就崩溃了。现实：目前只有少数顶级开发者能稳定运行在这个模式。但随着 AI 能力提升，这会成为越来越多人的目标状态。

并行化的收益和代价

Faros AI 的遥测数据给出了大规模真实环境下的画面：

指标	高 AI 使用率团队 vs 低使用率团队
每日交互任务数	+9%
每日 PR 数	+47%
任务完成率	+21%
合并的 PR	+98%
PR 大小	+154%
Review 时间	+91%
Bug 数 / 开发者	+9%

这张表讲了一个完整的故事：AI 确实帮开发者做更多的事（吞吐量涨了），但代价是每件事都更大、更难审查、更容易出错。

Faros 的研究者说得很准确：”这不是传统的多任务处理（研究已证明反效果）。这是工作方式的根本转变——当 AI 可以分担工作量时，工程师能同时编排多个并行的工作流。”

但他们也发现：单任务速度并没有提升。 并行化提高了总吞吐量，但没有让任何单个任务变快。如果你只做一件事，AI 可能还让你慢了 19%。

这正是调度策略的分水岭——你的产出不取决于”AI 能多快完成一个任务”，而取决于”你能同时编排多少个 AI 任务”。而后者的上限由你的调度能力决定：你能拆出多少独立子任务？你能容忍多少并行流的认知负担？你能多快做出 review 决策？

METR 测的是单任务效率。Faros 测的是系统吞吐量。两个结论同时为真：AI 让单任务变慢了，但让系统变快了——前提是你会调度。

不会调度的人，经历的是 METR 的结论：更慢、更累、”感觉快但实际慢”。会调度的人，经历的是 Faros 的结论：更多产出、更多并行、更高吞吐。

差别不在 AI 的能力。差别在你这个”调度器”的能力。

你的注意力才是 CPU

回到那个 8 分钟。Claude Code 在跑。你应该做什么？

答案取决于你运行的是哪种调度策略。

如果你是串行阻塞模式（大多数人的默认）：这 8 分钟基本浪费。你会拿起手机，或者焦虑地盯着进度条。然后 Claude 跑完了，你 review 结果。再发下一个任务。再等。一天下来你实际的”高产出时间”可能只有 3 小时。

如果你是异步批量模式（高效开发者的目标）：你不会只发一个任务。你会在早上花 30 分钟把今天要做的事拆成 5-8 个独立的、spec 清晰的子任务。然后启动 3 个 parallel agent 或者给 AI 队列发任务。接下来 2 小时你做自己的深度思考工作——写架构文档、做技术决策、和同事讨论方向。2 小时后统一 review 所有 AI 的产出。一天下来你同时推进了 8 件事。

具体的操作建议：

1. 给你的任务分三类。 - 可完全委托：有清晰输入输出规格的实现任务（写测试、重构、格式化、翻译文档）→ 直接发给 AI，不用等。 - 需要协作：方向大致清楚但细节需要人判断的任务 → 用 chunked iteration（每一步看一下，给方向）。 - 必须自己做：需要深度思考、创造力、或政治判断的任务 → 不要用 AI，保护你的 flow state。

2. 用”等待期”做低 context-switch 成本的事。

AI 跑的时候不要切到另一个高复杂度任务——那会让你两件事都做不好。切到”快餐式”任务：回消息、检查邮件、写简短文档、整理 TODO。这些任务的 context 加载成本接近于零，可以随时中断。

3. 批量 review，不要逐条 review。

每次 AI 给你一个建议你就切过去看——这是最昂贵的调度模式。积攒起来，一次看 5 个结果，做统一判断。就像 code review 应该看整个 PR 而非一行一行 live 盯着写。

4. 投资”规格编写”能力。

异步批量模式的前提是你能写清楚 spec。如果你写的指令模糊、AI 理解偏了、跑了 20 分钟是错的——那你不但没省时间还浪费了。写 spec 的能力 = 你作为”调度器”的质量。模糊的 spec 就像操作系统给进程分配了错误的内存地址——结果是 segfault。

5. 保护 deep work 时间块。

最终极的调度策略不是”把等待时间填满”——而是让等待时间从你的工作日里消失。怎么做？把所有 AI 任务前置到工作日开始时（发任务、设 spec、启动 agent），然后整个上午做 deep work，下午统一 review 和迭代。AI 的推理时间被你安排在了你本来就不需要它结果的时段。

这不是效率技巧的集合。这是一个关于注意力经济学的核心问题：当 AI 把执行成本降到接近于零，调度成本成为了新的瓶颈。你的价值不再由”你能写多快的代码”决定——而由”你能多高效地编排人和 AI 的协作”决定。

Token 弹性那篇文章里我说”省了 38 分钟”——这是个需要修正的说法。更准确的表达是：在最优调度策略下，AI 的推理时间可以被完全隐藏在你的其他工作里，等效于”省了 38 分钟”。在最差调度策略下，你多了 10 分钟的等待和 20 分钟的 context-switch 恢复——净效果可能是负的。

操作系统的调度器是透明的——你不需要告诉 CPU 什么时候该切换进程。但在人机协作中，你就是你自己的调度器。没有人帮你切换。没有人帮你决定什么时候该深度工作、什么时候该 review AI 产出、什么时候该批量发任务。

这个调度器的质量，决定了 AI 对你来说是”19% 更慢”还是”47% 更多产出”。

附：本文引用的资料来源

METR 研究（AI 让有经验开发者慢 19%）：https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Gloria Mark 中断恢复研究：引用自 https://super-productivity.com/blog/ai-coding-tools-focus-guide/
Faros AI 遥测研究（10,000+ 开发者）：https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings
Faros AI 原始报告：https://www.faros.ai/blog/ai-software-engineering
Addy Osmani 2026 AI Coding Workflow：https://addyosmani.com/blog/ai-coding-workflow/
AI Coding Tools 对 Focus 的影响：https://super-productivity.com/blog/ai-coding-tools-focus-guide/
Cerbos：AI Coding 的生产力悖论：https://www.cerbos.dev/blog/productivity-paradox-of-ai-coding-assistants
Agentic Coding 成本分析（Vantage）：https://www.vantage.sh/blog/agentic-coding-costs