AI 时代，效率大幅提升，为什么我反而更累了？

AI 时代，效率大幅提升，为什么我反而更累了？

AI 把“做一件事”的成本降下来了，却没有自动把节省的时间还给我们。更多时候，它只是让更多事情能够同时进入同一天。

2026 年 8 月 20 日，我和几位技术从业者在线上讨论了一个看似矛盾、却越来越真实的问题：

AI（Artificial Intelligence，人工智能）已经帮助我们提效这么久，为什么很多人没有变轻松，反而变得更忙、更累了？

我自己就是一个很典型的例子。

我是做 ERP（Enterprise Resource Planning，企业资源计划）、系统集成和软件开发的。过去一年，我对 AI 的使用已经从简单问答，逐渐进入了真实的工程流程：让 Codex 阅读项目、修改代码、运行测试和排查问题；让大模型整理需求、编写接口文档、分析数据和检索资料；有时还会让多个 Agent（智能体）同时推进不同子任务。

从结果上看，我确实比以前快了很多。

过去需要几小时整理的方案，现在十几分钟就能拿到初稿；过去需要手动搭建的代码骨架，现在可以快速生成；过去要在多个页面和文档之间来回查找的信息，也可以被迅速汇总。

但奇怪的是，我并没有因此拥有更多空闲时间。

相反，我的工作列表更长了，同时运行的任务更多了，需要学习的东西更多了，对最终结果承担的责任也更重了。一天结束时，我完成的事情可能比以前多，但大脑却像同时开了几十个没有关闭的浏览器标签页。

这让我逐渐意识到：

AI 提升的主要是局部任务的执行效率，而人的疲惫来自整个工作系统的总负荷。

两者并不是同一个指标。

一、AI 缩短了“首稿时间”，却未必同等缩短“可信交付时间”

过去我们谈效率，常常只计算一件事情从开始到产出需要多久。

但在真实的软件工程和企业交付中，一个结果出现，并不代表工作已经完成。

我更愿意把时间拆成两个部分：

• TTFD（Time to First Draft，首稿时间）：从提出问题到拿到第一个可见结果所需的时间。
• TTTO（Time to Trusted Outcome，可信结果时间）：从提出问题到结果经过验证、可以被真实采用并由人承担责任所需的时间。

AI 对 TTFD 的压缩非常明显，但对 TTTO 的改善并不总是同样显著。

以一个真实的系统需求为例，完整交付通常包含：

理解业务
→ 明确边界
→ 设计方案
→ 生成或编写代码
→ 审查代码
→ 准备测试数据
→ 执行测试
→ 处理异常
→ 与相关人员确认
→ 部署上线
→ 观察结果并承担风险

AI 最擅长压缩的，往往是中间的“生成方案”和“编写代码”。

但需求有没有理解错、字段有没有遗漏、权限是否安全、数据是否会被污染、异常场景是否覆盖、结果能不能上线，这些工作仍然需要人判断。越是涉及生产环境、财务数据、客户业务和系统权限，最后的审查成本越不可能被完全省略。

所以，AI 可能把四小时的编码压缩成半小时，却不一定把整个交付周期从四天压缩成半天。

更准确地说：

AI 让结果更早出现了，但“可以信任这个结果”的时间未必同步提前。

这也是为什么我们经常产生一种错觉：模型明明很快，我却还是很忙。

二、节省下来的时间，并没有变成休息，而是变成了更多需求

假设过去完成一个需求需要四小时，现在借助 AI 只需要一小时。

理论上，我应该多出三小时。

但在大多数工作环境里，这三小时很少会变成真正的空闲。更常见的结果是：

• 继续处理下一个需求；
• 同时多开几个任务；
• 提高交付频率；
• 增加文档、测试和汇报；
• 尝试过去没有资源尝试的新项目；
• 接手原本需要其他角色完成的工作。

于是，单位任务的成本虽然下降了，任务总量却迅速上升。

这可以概括为一个很简单的关系：

总工作负荷
≈ 任务数量 × 每个任务的定义、切换、审查、沟通与兜底成本

AI 主要降低了单个任务中的部分执行成本，却同时让更多任务获得了“值得开始”的资格。

过去，一个想法如果需要投入三个人两周，大家会谨慎评估；现在，一个 Demo（Demonstration，演示原型）半天就能做出来，于是十个想法都可以试一遍。

单次试错成本下降了，但试错数量可能从 1 个增加到 10 个，甚至 100 个。最终消耗的注意力、审查时间和维护成本，反而可能比过去更高。

这也是我在会议讨论中非常有共鸣的一点：

AI 降低了开始一件事的门槛，却没有自动降低结束、筛选和放弃一件事的难度。

我们不是因为做得慢而累，而是因为太多事情都变得“可以做了”。

三、Agent 可以并行运行，但人的注意力仍然近似单线程

AI 时代最容易让技术人员兴奋的一件事，就是并行。

我可以让一个 Agent 修改代码，让另一个 Agent 查资料，再让第三个 Agent 编写文档。它们都在运行，我似乎从一个执行者变成了一个调度者。

但问题是，Agent 可以并行，人脑却不能真正并行理解多个复杂上下文。

每个任务都需要我记住：

• 它为什么开始；
• 当前做到哪一步；
• 输入信息是否完整；
• 哪些假设还没有验证；
• 输出应该如何验收；
• 失败以后从哪里恢复；
• 最终由谁承担责任。

当几个任务同时处于未完成状态时，它们并不会从大脑中完全退出。即使我已经切换到另一项工作，上一项工作的上下文仍然会残留。

组织行为研究把这种现象称为 Attention Residue（注意力残留）：人在任务之间切换以后，一部分注意力仍会停留在上一个任务上，从而影响当前任务的专注和表现。后续研究还发现，在被打断前先写下一个简短的“恢复计划”，可以减轻这种影响。

这与我的实际体验高度一致。

过去，我可能完整地写完一个函数、解决一个问题，再进入下一个任务。过程虽然慢，但容易进入 Flow（心流）状态，也能获得清晰的完成感。

现在，多个任务不断返回结果，我需要频繁地阅读、判断、追问、修正和重新派发。产出增加了，但完整的沉浸过程减少了。

于是出现了一个新的矛盾：

AI 提高了任务并发量，却降低了人的认知闭环率。

任务越多，真正被大脑确认“已经结束”的任务反而越少。

四、我从“亲自执行”变成了“持续判断”，而判断比执行更消耗精力

AI 经常被描述成替人干活，但在复杂工作中，它更像是重新分配了工作。

过去，我主要消耗精力去执行：写代码、查资料、整理文档。

现在，越来越多的执行可以交给 AI，但我必须承担更多判断：

• 这个问题是否值得做；
• 模型是否理解了真实需求；
• 输出看起来合理，实际上是否正确；
• 方案是否符合现有系统架构；
• 哪些代码可以直接采用；
• 哪些风险需要人工验证；
• 什么时候应该继续迭代；
• 什么时候应该停止。

执行工作通常有明确动作，而判断工作往往充满不确定性。

尤其是在 AI 输出“八成正确”的时候，人最累。它不是完全错误，因此不能直接丢弃；也不是完全可靠，因此不能直接采用。人需要逐段检查、补充上下文、寻找隐蔽错误，并为最终结果兜底。

这也是为什么 AI 生成得越快，人有时反而越疲惫：

生成速度决定了结果到达我的速度，而我的判断速度决定了结果离开我的速度。

当输入端被 AI 无限加速，而验收端仍然由一个人承担时，人的注意力就会成为新的系统瓶颈。

五、能力边界扩大以后，职责边界也跟着扩大了

AI 让一个工程师能够完成过去多个角色共同完成的部分工作。

我可以写代码，也可以整理需求；可以做架构分析，也可以生成测试方案；可以写接口文档，也可以准备演示材料；可以在后台开发，也可以进一步接触业务和客户现场。

从个人成长角度看，这当然是一件好事。

但在组织中，能力增长往往会被迅速转换成职责增长。

“既然你能做，为什么不一起做？”

于是，工程师逐渐承担产品、测试、项目管理、业务分析和客户沟通等工作。行业里越来越受关注的 FDE（Forward Deployed Engineer，前置部署工程师）或 FDSE（Forward Deployed Software Engineer，前置部署软件工程师），本身就是这种角色扩张的体现：工程师不只负责写代码，还要直接理解客户问题、设计方案、落地部署，并把一线经验反哺产品。

这种模式能够缩短反馈链路，但也意味着一个人需要同时具备：

• 工程实现能力；
• 系统化思维；
• 业务理解能力；
• 沟通与协调能力；
• 现场解决问题的能力；
• 抽象和产品化能力。

AI 让个人能力半径扩大了，但如果组织没有重新划分边界，这个半径就很容易变成责任半径。

一个人看起来越来越像一支团队，也就越来越容易承担一支团队的负荷。

这也是所谓 OPC（One-Person Company，一人公司）叙事背后经常被忽视的一面：AI 的确能够让一个人调度更多数字劳动力，但这个人仍然要承担目标、取舍、质量、客户关系和最终责任。

六、学习本身也变成了一条永远不会清空的工作流

AI 技术迭代速度极快。

新的模型、新的 Agent、新的协议、新的开发范式和新的概念不断出现。从 Prompt Engineering（提示词工程）到 Context Engineering（上下文工程），再到 Agent Engineering（智能体工程），每隔一段时间都像有一套新方法需要理解。

对技术人员来说，这会形成一种持续的拉扯：

• 不学习，担心很快落后；
• 学习了，又需要尽快应用；
• 应用了，还要验证是否真的有效；
• 刚形成方法，新工具又出现了。

2026 年微软对 10 个国家、2 万名 AI 使用者的调查中，65% 的受访者担心如果不能快速利用 AI 适应变化，自己会落后；与此同时，只有约四分之一的 AI 使用者认为所在组织的领导层在 AI 方向上保持了清晰、持续的一致性。

这种状态很像一边高速输入，一边被要求立即输出。学习不再只是积累，而是变成了持续交付的一部分。

最终，我们不仅在完成工作，也在维护一套不断变化的“完成工作的方法”。

七、这不是单纯的个人错觉：生产率提升和工作强度上升可以同时发生

关于 AI 是否真正提高生产率，研究结果并不是一个统一的倍数。

NBER（National Bureau of Economic Research，美国国家经济研究局）对客户支持场景的研究发现，生成式 AI 工具使每小时解决问题的数量平均提升了约 14%，其中经验较少的员工受益更明显。

但在另一项针对有经验开源开发者的随机对照研究中，METR（Model Evaluation and Threat Research，模型评估与威胁研究机构）发现，使用 2025 年初的 AI 工具时，参与者完成熟悉代码仓库中的任务反而平均多花了 19% 的时间。METR 在 2026 年公布的后续数据中观察到可能的加速迹象，但置信区间仍跨越“没有明显提升”的范围，因此还不能简单得出统一结论。

这两类结果并不矛盾。它们说明：

AI 的效率收益高度依赖任务类型、使用者经验、上下文质量、验收标准和组织流程。

与此同时，OECD（Organisation for Economic Co-operation and Development，经济合作与发展组织）的研究也记录到另一面：AI 可以减少重复劳动、提升表现和工作满意度，但更高的绩效目标、任务复杂度以及算法化管理，也可能提高工作强度。OECD 在 2025 年发布的韩国劳动力市场报告中还指出，许多员工在企业采用 AI 后，并没有明显感到身体或精神负担下降。

微软 2025 年的 Work Trend Index（工作趋势指数）同样呈现出这种“能力增长与能量不足并存”的状态：53% 的管理者认为生产率仍需提高，而 80% 的员工和管理者表示，自己缺少完成工作所需的时间或精力。

在微软对消息负荷最高的 20% 用户的统计中，核心工作时段平均约每两分钟就会收到一次会议、邮件或聊天打断。AI 可以帮助处理其中一些信息，但如果工作系统本身仍然不断制造通知、会议、任务和临时需求，AI 也可能只是帮助我们以更高速度留在同一条跑步机上。

八、真正决定我是否轻松的，不是“节省了多少时间”，而是“效率红利被分配到哪里”

AI 节省下来的时间，大致有三种去向：

1. 继续增加吞吐量：接更多需求、做更多项目、生成更多内容；
2. 提高结果质量：增加测试、重构、复盘，沉淀可复用资产；
3. 归还给人：减少工作时长、恢复注意力、学习或休息。

如果没有主动分配，效率红利通常会默认流向第一种。

新的任务会自动填满被释放出来的时间，组织也会逐渐把新的速度当成正常基线。昨天借助 AI 完成的超额产出，很容易变成明天必须持续完成的标准产出。

因此，我现在越来越认同一句话：

没有被显式分配的效率红利，最终都会被新的需求吃掉。

真正可持续的 AI 提效，不应该只问“还能多做多少”，还应该问：

• 哪些工作可以彻底不做；
• 哪些流程可以合并；
• 哪些结果可以复用；
• 哪些任务不值得开始；
• 节省下来的时间是否有一部分真正归还给人。

如果 AI 只能帮助我往一天里塞进更多工作，它提高的是吞吐量，不一定提高我的生活质量。

九、我正在尝试的几条调整原则

我并不准备少用 AI。相反，我认为 AI 已经成为软件工程中不可逆的一部分。

但我开始调整使用方式：不再只追求“同时跑多少 Agent”，而是追求“有多少结果能够完整闭环”。

1. 同一主题可以并行，跨主题尽量串行

我可以让多个 Agent 围绕同一个目标分别做代码、测试和文档，但尽量避免同时推进多个彼此无关的大主题。

这样可以共享同一套上下文，减少大脑频繁切换。

一句话概括就是：

Agent 可以多线程，人保持主线单线程。

2. 限制 WIP（Work in Progress，在制工作）

不是所有可以开始的任务都应该立即开始。

我会给进行中的核心任务设置上限。只有一个任务完成验收、明确暂停或正式放弃以后，才让新的大任务进入。

AI 让“开始”变得太便宜，因此更需要人为提高开始标准。

3. 委派前先写验收标准

没有验收标准的任务，AI 越快生成，后面越难收尾。

在交给 Agent 之前，我会尽量明确：

目标是什么：
输入和约束是什么：
什么结果才算完成：
必须通过哪些测试：
哪些风险需要人工检查：
结果应该保存在哪里：

这样，AI 输出的不是一堆“看起来不错”的内容，而是更接近可以验证的交付物。

4. 切换任务前，留下“可恢复现场”

每次暂停复杂任务时，记录一段很短的恢复信息：

当前目标：
已经完成：
尚未验证：
主要风险：
恢复后的第一步：

这相当于给自己的大脑保存一个 Checkpoint（检查点）。下次回来时，不需要重新加载全部上下文，也能减少注意力残留。

5. 按风险分配审查强度

AI 生成的所有内容都需要判断，但并不需要用同样力度审查。

涉及生产环境、财务数据、权限、隐私和不可逆操作的内容，需要完整验证；普通草稿、格式转换和低风险资料整理，可以采用抽查或自动化校验。

如果所有输出都按最高强度审查，人会被审查成本淹没；如果所有输出都直接采用，风险又会被推迟到线上爆发。

6. 把探索和交付分开

新模型、新工具和新玩法很有吸引力，但我不再让每一次好奇都立即进入正式工作流。

探索可以有固定时间和固定预算；只有证明能够稳定提高质量、降低成本或减少风险的工具，才进入长期流程。

否则，所谓提效很容易变成持续换工具、迁移上下文和重复搭建工作流。

7. 用“通过验收的价值”衡量 AI，而不是用生成量衡量

代码行数、文档页数、调用次数和 Token（令牌）消耗，都不是最终价值。

我更愿意用下面这个公式判断 AI 的 ROI（Return on Investment，投资回报率）：

AI 价值密度
= 通过验收并产生真实作用的结果
÷（人工时间 + AI 成本 + 审查返工 + 协调成本 + 风险成本）

只有真正被采用、通过验证、能够复用或产生业务结果的产出，才应该进入分子。

否则，我们可能只是以极高效率制造了更多需要处理的信息。

十、组织也必须重新设计工作，而不是只给个人增加 AI 工具

这个问题不能完全靠个人自律解决。

如果组织只是购买 AI 工具，然后立即提高每个人的交付指标，那么个人提效最终必然演变成工作强化。

真正的组织提效至少需要完成几件事：

• 从代码量、文档量和工时，转向衡量业务结果、交付周期、缺陷率和可复用资产；
• 重新设计需求、研发、测试、发布和反馈的完整链路，而不是只加速其中一个环节；
• 明确人与 Agent 的责任边界，避免“AI 做错、个人全责，AI 做快、个人加量”；
• 控制团队的进行中任务数量，防止局部提速造成系统拥堵；
• 把一部分效率收益用于质量、学习和恢复，而不是全部换成更高负荷。

微软 2026 年的 Work Trend Index 提出，组织文化、管理支持和人才机制等组织因素，对员工自我报告的 AI 成效解释力超过个人心态和行为因素的两倍。

这至少说明了一件事：

AI 能不能真正让人工作得更好，主要不是工具安装问题，而是工作系统设计问题。

结语：AI 改变了稀缺资源，但没有消除稀缺

过去，很多工作的瓶颈是执行能力。

现在，AI 正在让执行能力变得越来越充足。与此同时，新的稀缺资源变成了：

• 注意力；
• 判断力；
• 上下文掌控力；
• 选择和放弃的能力；
• 完成闭环的能力；
• 对结果负责的精力。

所以，AI 时代效率大幅提升，我为什么反而更累了？

不是因为 AI 没有提效，也不是因为我不会使用 AI。

而是因为提效主要发生在局部任务上，新增的需求、并发、判断和责任却作用在整个人身上。AI 压缩了工作的执行时间，但如果我们没有主动管理边界，它也会进一步压缩生活的空间。

我现在更想追求的，不再是让 AI 帮我完成尽可能多的事情，而是：

让 AI 帮我减少不必要的事情，把真正重要的事情做对、做完，并把一部分效率真正还给自己。

也许这才是 AI 时代更值得追求的效率。

参考资料

1. Microsoft, 2025: The year the Frontier Firm is born, 2025-04-23。
2. Microsoft, Breaking down the infinite workday, 2025-06-17。
3. Microsoft, Microsoft 365 Copilot, human agency, and the opportunity for every organization, 2026-05-05。
4. OECD, Artificial Intelligence and the Labour Market in Korea, 2025-10-27。
5. OECD, Artificial intelligence, job quality and inclusiveness, 2023-07-11。
6. Erik Brynjolfsson, Danielle Li, Lindsey R. Raymond, Generative AI at Work, NBER Working Paper, 2023。
7. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025-07-10。
8. METR, We are Changing our Developer Productivity Experiment Design, 2026-02-24。
9. Sophie Leroy, Theresa M. Glomb, Tasks Interrupted: How Anticipating Time Pressure on Resumption of an Interrupted Task Causes Attention Residue, Organization Science, 2018。
10. Palantir, Forward Deployed Software Engineer, accessed 2026-08-27。

数据与研究结论均有适用范围。微软数据包含供应商调查和产品遥测，METR 的开发者实验样本与任务场景较特定，OECD 的部分调查来自金融与制造业。本文将这些材料用于解释可能机制，而不是将任何单项研究视为适用于所有人和所有工作的统一结论。