谷歌工程师用1984年小说打脸AI编程：3倍速写代码后，团队崩了

2024年，某大厂内部数据显示：接入AI辅助编程工具后，开发者日均代码产出增长340%。三个月后，该团队交付周期反而延长了22%。

这不是孤例。全球超过60%的科技公司正在重复同一套剧本——用AI给非瓶颈环节加速，然后看着系统整体窒息。

「三杯红酒后的决策」

周二早晨，工程VP站在投影前，浑身散发着2017年币圈早期玩家那种亢奋。刚参加完一场 vendor dinner，三杯黑皮诺加一个demo，他带着「重大发现」回来了。

会议室里一半人点头，另一半突然对笔记本电脑产生浓厚兴趣。资深工程师面无表情，心里盘算着：现在反驳，还是稍后更新领英。

没人问那个关键问题：速度，朝向哪里？

VP审视了整个软件交付体系，找到那个本来就已经很快的环节，决定让它更快。他在流水线上发现了一个不是瓶颈的工位，然后往里面砸钱。

懂系统的人都知道，这不仅没用，会让一切变得更糟。

一本制造业小说的诅咒

1984年，Eli Goldratt写了《目标》——一部关于制造业的小说，莫名其妙地对软件行业极具杀伤力。这也是你读过的最有用的商业书籍，尽管它技术上算虚构。这几乎与大多数KPI框架完全相反。

核心概念是约束理论（Theory of Constraints）：

每个系统有且仅有一个约束。一个瓶颈。整个系统的吞吐量由该瓶颈的吞吐量决定。在修复瓶颈之前，其他一切都不重要。

大部分人理解到这里。他们没理解的部分，才真的可怕：

机械地思考这个问题。如果A工位生产小部件更快，但B工位（瓶颈）的处理速度不变，你只是在A和B之间制造了一堆未完成的小部件。库存上升。交付周期上升。B工位的人现在被淹没。堆积造成混乱，没人知道下一步该做什么。质量暴跌，因为所有人都在救火，而不是思考。

我猜你们中有人正在经历这个。我经历过。糟透了。

PR队列里的尸体

你的开发者产出PR的速度前所未有。太好了。太棒了。金星贴纸。谁去把彩带炮拿来。

现在这些PR涌进审查队列，而你的审查员没有变成三倍。没人给审查员变成三倍。甚至没人想过审查员，因为vendor的slide deck里没提审查员。

于是PR开始积压。一天。两天。一周。作者已经上下文切换到下一个AI辅助功能，等审查意见回来时，他们几乎不记得第一个功能是干什么的。「你能解释一下这个函数是做什么的吗？」他们盯着自己八天前写的代码，像在看陌生人的日记。

上下文切换成本被低估了。微软研究院2019年的一项研究发现，开发者每次中断后需要平均23分钟才能恢复深度工作状态。AI让编码速度提升3倍，但审查瓶颈让中断频率提升了5倍。

净收益为负。但仪表盘上只显示「代码行数增长」，所以VP继续举杯。

被无视的约束清单

代码审查只是冰山一角。在大多数组织中，真正的瓶颈藏在PPT不会展示的地方：

需求清晰度。产品经理用AI一天生成50份PRD，开发团队花三天搞清楚「智能优化」到底指什么。

测试环境。代码编译从20分钟降到2分钟，但 staging 环境排队从1小时变成4小时，因为基础设施团队没收到AI预算。

决策延迟。技术方案评审会每周一次，AI辅助开发的特性三天就写完，然后等四天等架构委员会的空档。

认知负载。开发者同时维护的代码库数量从3个变成7个，因为「AI能帮你快速上手」。没人统计过跨项目切换导致的bug增长率。

Goldratt在《目标》里写过一个场景：工厂老板拼命优化每台机器的利用率，结果库存爆炸、现金流断裂。四十年后，软件行业的「机器利用率」叫「开发者代码产出」，库存叫「待合并PR」，现金流叫「交付周期」。

剧本没变，只是演员换了。

那些提前醒来的团队

并非所有人都在撞南墙。GitLab 2023年公开了内部转型数据：在引入AI编码助手前，他们先花了八个月重构审查流程——并行审查机制、自动分配算法、审查时间SLA。AI工具上线后，端到端交付周期缩短31%。

顺序很重要。约束理论的第一步是识别瓶颈，不是加速非瓶颈。

Shopify的做法更极端。他们的「开发者体验」团队被赋予否决权：任何新工具上线前，必须证明它不会加剧现有瓶颈。2024年初，他们否决了三个AI代码生成工具的采购申请，理由是「审查和测试基础设施未就绪」。六个月后，竞争对手在社交媒体上炫耀「AI代码占比90%」时，Shopify默默完成了瓶颈扩容，然后一次性接入。

这种克制在财报电话会上很难解释。「我们为什么比对手晚半年用AI？」但CEO Harley Finkelstein在内部备忘录里写：「我宁愿解释为什么慢，也不愿解释为什么崩。」

仪表盘上的幻觉

问题是，瓶颈很难在仪表盘上显形。

代码行数、提交频率、AI生成占比——这些数字漂亮、即时、可横向比较。审查等待时间、上下文切换成本、决策队列长度——这些需要人工埋点、跨系统关联、长期追踪。

于是组织自然选择优化前者。这不是恶意，是结构性懒惰。

一位前Google工程总监在离职博客中写道：「我们花了两年让AI写代码更快，最后发现交付延迟的80%来自『等待某人做决定』。那个『某人』通常是我。而我当时正在看AI写代码的进度报告。」

他用了个类比：给汽车引擎加装涡轮增压，但轮胎还是自行车胎。速度表指针会动，车不会快，只会更危险。

速度崇拜的代价

软件行业对速度的执念有其历史根源。2001年敏捷宣言、2010年代持续交付运动、2020年代DevOps文化——每一波都在强化同一叙事：更快就是更好。

这个叙事在约束存在且被解决时成立。当它被无视时，「更快」变成局部优化，系统整体受损。

制造业在1980年代学过这一课。日本丰田生产方式的精髓不是「快」，而是「流动」——识别瓶颈、保护瓶颈、逐步扩容。Goldratt把这套逻辑抽象成通用理论，四十年后，软件行业正在重新发明轮子，只是这次轮子是AI生成的，还没经过测试。

一个讽刺的细节：许多推广AI编程工具的公司，内部并不用这些工具开发自己的核心系统。不是因为他们知道约束理论，而是因为他们的核心系统已经够脆了，经不起再堆一层未完成 inventory。

如果你正在评估AI工具

几个具体的问题，比「能提升多少代码产出」更重要：

你的审查队列当前平均等待多久？接入AI后，这个数字会如何变化？

开发者同时维护的项目数量是多少？AI降低的「上手成本」会诱导这个数字上升吗？

从「代码写完」到「生产环境运行」，哪个环节耗时最长？AI工具作用于这个环节之前还是之后？

如果AI让编码速度提升X倍，你的瓶颈环节能在多长时间内扩容到匹配？扩容成本是多少？

这些问题的答案不会出现在vendor的slide deck里。它们需要你走出会议室，去工位旁边看PR队列的长度，去统计staging环境的排队时间，去追踪一个需求从提出到上线的全路径。

Goldratt在《目标》结尾让主角意识到：「 throughput 不是机器运转的速度，是卖出去的产品数量。」对软件而言，不是代码产出的速度，是价值交付的速度。而价值交付的速度，由最慢的环节决定。

那个环节，此刻正在你组织的某个角落堆积 inventory，等待被看见。

你的仪表盘上，有它的实时数据吗？