# 人类开发者的注意力是AI编程系统的核心瓶颈

- 来源：meng shao (@shao__meng)
- 发布时间：2026-05-29 09:24
- AIHOT 分数：65
- AIHOT 链接：https://aihot.virxact.com/items/cmpq988q102xcslno6vsrz6us
- 原文链接：https://x.com/shao__meng/status/2060170352316318106

## AI 摘要

AI编程系统中，人类开发者的注意力是不可并行的稀缺资源。智能体可并行工作，但其结果必须由人审查、判断和决策，这一过程无法并行，被称为“编排成本”，类比于Python的GIL。盲目增加智能体数量不会提升最终质量，反而因大量上下文切换增加审查负担。成熟的AI编程能力在于合理分配注意力：按自身审查能力控制智能体数量，将深度思考时间留给最关键的架构与决策环节。

## 正文

活人开发者的注意力是整个 AI Coding 系统里最稀缺、最慢、最不能并行的资源！

启动 Agent 很容易，但理解结果、判断质量、处理冲突、决定能不能合并，仍然必须由人完成。Agent 可以并行工作，但人的判断不能并行。所以真正限制产出的，不是 Agent 数量，而是人的审查与决策能力。

@addyosmani 把这个问题称为 Orchestration Tax，可以理解为"编排成本"或"调度成本"。

你启动 10 个、20 个 agent，看起来很忙，界面上也有很多任务在跑。但这些任务最后都会排队等待你：
· 看结果是否正确
· 判断是否符合架构
· 检查代码质量
· 处理不同 Agent 之间的冲突
· 决定哪些可以合并

这一步无法完全交给机器，因为它涉及系统理解、工程判断和长期维护责任。

所以，多 Agent 并不等于多了几个"你"。最后真正承担责任的，还是一个人。

最关键的工程类比
第一是 Python 的 GIL。线程可以很多，但真正执行关键部分时，要经过一个单线程限制。Addy 说，人就是 AI Agent 系统里的 GIL。Agent 可以同时跑，但一到需要理解、判断、合并时，都要等你。

第二是 Amdahl's Law。系统加速的上限，取决于仍然无法并行的那部分。在 AI 编程里，无法并行的部分就是人的判断。Agent 数量增加，只是让等待你审查的任务变多，不会自动提高最终交付质量。

这也是文章最重要的技术含义：优化非瓶颈部分，不会提高系统吞吐量。 如果瓶颈是审查和判断，继续增加 Agent，只会制造更多待处理工作。

为什么"忙"不等于"高产"
Addy 反复强调：现在的工具确实让人更有生产力，但也让人更累。

原因是，多 agent 工作会带来大量上下文切换。你每次去看一个 agent 的结果，都要重新加载它的任务背景、改动范围、相关代码和潜在风险。CPU 的上下文切换很快，但人的上下文切换很慢，而且恢复不完整。

所以 5 个 agent 不是 5 倍产出，而可能是：
· 5 次重新进入不同问题
· 5 组需要审查的改动
· 持续担心哪个任务正在出错
· 更容易降低审查标准

最危险的情况是，人因为太累，开始接受自己并没有真正理解的代码。短期看似推进了，长期会损害对系统的理解。

所以真正成熟的 AI 编程能力，不是同时开更多 agent，而是知道：
· 哪些任务适合交给 agent
· 哪些任务必须自己深度参与
· 什么时候应该批量审查
· 什么时候应该停止调度，专心思考一个复杂问题
· 哪些验证可以让机器先完成，减少人的负担

Addy 给出的实践原则
第一，Agent 数量要按你的审查能力来定，而不是按工具界面能开多少来定。多数人真正能认真审查的并行任务，可能只是个位数。

第二，把任务分层。隔离、明确、低耦合的任务适合放给后台 Agent；复杂 bug、架构设计、关键重构，不适合同时并行太多，因为这些任务本身就需要人的判断。

第三，批量审查。频繁来回查看不同 Agent，会消耗大量注意力。让 Agent 多跑一段时间，然后集中审查，比不断切换更有效。

第四，把人的注意力留给真正需要判断的部分。测试、截图、格式检查、基础验证，可以要求 Agent 自己先完成。人主要看关键设计、边界条件、风险和可维护性。

第五，保护深度思考时间。有些时候最高价值的动作不是继续管理 Agent，而是停止多线程工作，完整地思考一个核心问题。

### 引用推文

> Addy Osmani：http://x.com/i/article/2059839454370828288