当代码不再稀缺 - 02

AI 没有消灭瓶颈：Slop 正在吞掉团队的注意力

When generation becomes abundant, attention is all we have.

当生成变得充裕，注意力就是团队最后的稀缺资源。

上一篇写到，我们用 claude 做床位管理项目，AI 几乎取代了人工代码输出，但项目周期只是从预计的六个月缩短到四个月。

Coding 快了很多，code review 和 QA 的绝对耗时却增加了。

这件事有点像把高速公路前半段拓宽到十条车道，却忘了后面的收费站还是两个窗口。入口看起来特别繁荣，车都在往前冲，最后大家整整齐齐堵在下游。

软件项目也一样。

AI 没有消灭瓶颈。它只是非常高效地把瓶颈从“谁来写代码”，搬到了“谁来理解、验证和批准这些代码”。

更麻烦的是，AI 加速的不只是有价值的实现，也包括 AI slop。

这里说的 slop，不只是明显写错的代码。它是那些看起来像完成品、可以顺利进入 PR，却需要人花大量注意力理解和审核，最终又没有增加多少 verification evidence 的产物：重复已有逻辑的实现、缺少 intent 的大 PR、只验证 implementation 的 tests，以及本该 refactor 却继续堆出来的代码。

Slop 的危险不只在于它可能有 bug，而在于它会先消耗团队最稀缺的资源——高质量注意力——然后才让我们发现它没有多少价值。

项目变快，不等于每个环节都要变快

传统项目管理很容易把软件交付理解成工作量问题：

需求有多少
→ 拆成多少 ticket
→ 每个 ticket 需要多少 engineer-days
→ 分给多少人
→ 什么时候可以做完

在这个模型里，coding capacity 通常是最容易看见、也最容易计算的部分。所以我们会做 estimation、排 sprint、看 velocity，再想办法让 engineer 少一点 blocker、多一点 focus time。

AI 改变了其中一个关键变量：implementation 的边际成本大幅下降了。

以前一个 engineer 一周只能认真推进有限的几个实现。现在他可以同时让 AI 修改 API、补测试、做 migration，再顺手生成一个前端页面。代码生产能力突然增加了，但团队每天可以投入的高质量注意力并没有同步增加。

这里说的 attention，不是一个人坐在电脑前的时间，而是他真正理解上下文、比较方案、识别系统风险并做出判断的认知资源。

Reviewer 需要用 attention 理解一段代码为什么成立；QA 需要用 attention 枚举业务状态和 corner cases；EM 和 stakeholder 需要用 attention 澄清 intent、判断 trade-off 和决定能否发布。这些工作不能仅靠“看得更快”稳定扩容。

于是，项目里的 capacity relationship 变了：

Generation capacity 快速上升
→ 高价值实现与 AI slop 同时增加
→ Signal-to-noise ratio 下降
→ 有限的人类 attention 被消耗在筛选、理解、review 和返工
→ Queue 变长，context switching 增加
→ Attention-to-outcome conversion 下降
→ 端到端 lead time 不再继续缩短

这就是为什么 coding speed 不等于 delivery speed。

AI 时代，高质量注意力才是稀缺资源

我们可以用另一个角度理解 AI productivity：

Attention Conversion Rate：单位人类注意力能够转化出多少 verified outcome。

过去，coding 本身消耗了大量时间，进入 review 的代码数量受到自然限制。AI 移除了这层限制以后，团队可以快速生成更多代码，但每一份候选实现仍然需要有人理解、判断和承担责任。

如果代码量增长了三倍，review attention 也增长三倍，而 verified outcome 没有同步增长，团队的 output 看起来提高了，attention conversion rate 却可能下降了。

这里的 attention 不能被假装成一个精确的 story point。初期可以观察它留下的 proxy：

• Reviewer 实际投入的时间；
• PR 等待和往返的次数；
• 为重新加载 context 付出的时间；
• 同时进行的 WIP 数量；
• 关键决策的等待时间；
• 单位周期完成的 verified outcome。

真正的问题不是某个人动作太慢，而是系统正在用最稀缺的高质量注意力，处理越来越多尚未证明有价值的代码。

假设一个团队每天能生成十个 PR，但有限的 review attention 只能支持认真处理五个。

第一天看起来问题不大，queue 里只剩五个。第二天又新增十个、只能处理五个，backlog 就累积到十个。第三天是十五个。过不了多久，reviewer 每天一打开 GitHub，就会看到一面 PR 墙。

这时通常会发生三件事。

第一，PR 越等越久。Author 已经开始下一个任务，等 reviewer 提意见时，自己也要重新加载 context。

第二，团队会倾向于让 PR 更快通过。不是大家突然不在乎质量，而是 queue 本身制造了交付压力。

第三，等待中的 engineer 不会真的闲着。他会继续启动新任务，于是 WIP 越来越多，系统看起来每个人都很忙，但真正进入 production 的东西没有同比例增加。

这是项目管理里最容易掉进去的坑：

把局部 utilization 当成系统 productivity。

每个人都很忙，不代表项目流动得很快。AI 甚至会让这个错觉更强，因为代码、commit、PR 和 ticket completion 都在增长，dashboard 一片欣欣向荣。只有客户还在耐心等待真正能用的结果。

AI 时代，瓶颈可能出现在哪儿？

我们可以把 software delivery 简化成四个环节：

Intent
→ Generation
→ Verification
→ Evidence

Intent：我们到底要解决什么？

包括需求、业务规则、acceptance criteria、system constraints 和 invariants。

如果 intent 不完整，AI 只会更快地回答一个错误的问题。上一篇的床位时间 bug 就是这样：代码正确地判断了“当前时刻是否被占用”，但业务真正想问的是“这一天是否已经被占用”。

Generation：把 intent 变成候选实现

这是 AI 最擅长压缩的环节。代码、测试、文档和 migration 都可以更快生成。

但候选实现只是 candidate，不是 verified outcome。

Verification：我们凭什么相信它是正确的？

包括 code review、QA、security、performance、架构一致性和 failure recovery。

当 generation 变快，大量候选实现会涌入这里。以前隐藏在 coding 时间后面的业务歧义、系统耦合和 corner cases，也会集中暴露出来。

Evidence：上线后，什么证明它真的有效？

测试通过不等于用户问题被解决，成功 deploy 也不等于业务 outcome 发生了变化。最终还要看 production behavior、用户反馈、escaped defects 和实际结果。

AI 主要提高了 Generation，但一个项目能走多快，取决于四个环节中最受限制的那个，而不是最快的那个。

EM 的主要矛盾：如何分配团队的注意力

当代码可以被廉价、大量地生成，EM 面对的主要矛盾不再只是“开发资源够不够”，而是有限的高质量 attention 应该被什么工作消耗。

但 attention allocation 不能被理解成另一张 utilization 表。假如 slop 的流入速度持续超过 review capacity，再聪明的分配也只是在决定先被哪一堆低价值代码淹没。

正确顺序应该是：先减少 attention demand，再按风险分配 attention，最后提升每单位 attention 的 outcome conversion。

1. 阻止 slop 进入人工 review

进入 PR 不应该等于获得 reviewer attention 的资格。团队可以要求 AI 产物在提交前先提供：

• 明确的 intent 和 change rationale；
• 涉及的 business invariants；
• 为什么复用或不复用现有抽象；
• 自动化 tests、static checks 和 duplicate-code checks；
• 风险等级、blast radius 和 rollback plan。

无法回答“为什么存在”或没有基本 verification evidence 的候选产物，应该退回 Generation，而不是让 reviewer 帮它补齐思考过程。

2. 找到真实的 attention queue

不要先看谁最忙，先看工作在哪里等待：

• 需求等待澄清多久？
• PR 等待第一次 review 多久？
• Review 完成后等待 QA 多久？
• QA 完成后等待 release 多久？
• 上线后多久才能获得用户 evidence？

项目瓶颈经常不在执行时间，而在两个动作之间的等待时间。Queue 还会反复打断团队，让有限的 attention 消耗在重新加载 context，而不是验证真正重要的风险。

3. 限制进入瓶颈的 WIP

如果 reviewer 一次只能处理五个 PR，继续生成第六到第二十个 PR 并不会让项目更快，只会让 queue 更长。

与其要求 engineer “保持忙碌”，不如让团队优先帮助当前最接近 verified outcome 的工作通过瓶颈：补 context、拆小 PR、补测试、准备 test data，或者直接一起解决 reviewer 发现的系统问题。

4. 按风险分配 verification attention

不是所有 AI 代码都值得相同强度的 review。

• 文案和低风险 UI 调整，可以走 fast path；
• 核心业务规则、权限、账务和数据 migration，需要更强的人工 review；
• 重复性检查交给 static analysis、tests 和 automated evals；
• 人类注意力留给 intent、invariants、system fit 和 blast radius。

如果所有变更都逐行重审，我们只是用昂贵的人类时间重新执行了一遍 AI 的工作。

5. 提升 attention conversion，而不是只优化上游

如果 QA 是瓶颈，就让 QA 更早参与 intent 和 acceptance criteria，而不是等代码完成后才开始找遗漏。

如果 review 是瓶颈，就减少 PR size、补齐变更上下文、自动检查重复代码，并明确哪些 system invariants 必须被验证。

如果 stakeholder decision 是瓶颈，再多 coding agent 也解决不了问题。这个时候最有价值的工作可能不是继续生成实现，而是缩小 scope，快速获得一个能改变决策的 evidence。

这其实不是一个新理论

看到这里，一个资深 EM 可能会说：这不就是 Theory of Constraints、WIP limit 和 flow management 吗？几十年前就有了，AI 有什么新鲜的？

这个反对意见是对的。

瓶颈理论不新，局部优化不等于系统优化也不新。真正变化的是：AI 在很短时间内大幅改变了各环节的相对 capacity。

过去，coding 本身足够慢，很多需求歧义、review 压力和 QA permutations 被自然摊在 implementation 周期里。现在 Generation 突然提速，这些问题被同时推到下游，原来还能凑合运行的流程开始排队、膨胀，甚至失控。

所以我们不需要发明一套听起来很 AI-native 的新名词。我们需要做的是重新测量系统，然后承认昨天的 bottleneck 已经不是今天的 bottleneck。

EM 该换一个问题

过去我们经常问：

怎么让每个 engineer 完成更多工作？

AI 时代更应该问：

怎么让每单位人类 attention 转化出更多 verified outcome？

两个问题看起来很像，管理动作却完全不同。

前者会让你增加 ticket、提高 utilization、要求更多 output；后者会让你减少无价值的 review surface、控制 WIP、保护 reviewer attention、把 QA 前移，并把最好的认知资源留给 intent、invariants 和高风险决策。

团队的高质量生产力，不再主要受代码生成速度限制，而是受 attention conversion rate 限制。

AI 没有消灭软件项目的瓶颈。它只是让我们再也不能假装 coding speed 就是 delivery speed。

下周可以做的一个小实验

选一个刚完成的 feature，把它从需求提出到 production evidence 的全过程画出来。

每个阶段记录三件事：

1. 真正在被处理的时间；
2. 等待下一个人或下一个环节的时间；
3. 哪些活动消耗了高质量 attention，却没有增加 verification evidence。

然后问团队四个问题：

• 最长的 queue 在哪里？
• Attention 主要消耗在理解业务风险，还是阅读重复和低价值代码？
• 哪个环节正在被上游持续喂入更多工作？
• 如果只能改善一个环节，哪个改善最可能提高 attention conversion rate？

先不要买新的 AI tool，也不要急着提高工程师的 output target。

先找出注意力正在被什么消耗，再决定如何释放瓶颈。很多时候，这比再加一条“高速公路”有用得多。

当 generation 变得近乎无限，attention is all we have。EM 真正需要保护和分配的，不再只是开发人天，而是团队把 intent 转化成 verified outcome 的有限认知能力。