第三章　约束在哪里？

一个团队把 AI 用进日常开发后，最先感到轻松的通常是编码环节。功能初版来得更快，补测试和文档也不再总被排到最后。

几个月后，团队却未必发版更快。代码评审开始排队，测试环境更紧张，联调和验收需要处理的改动变多。有些团队还发现，方案讨论反而增加了。实现变便宜以后，过去只停留在想法里的选择，现在都值得先做出来看看。

这不是 AI 没有提高效率，而是效率提高只发生在一条工作链的局部。要理解后面会发生什么，不能只问“代码快了多少”，还要继续追问：现在真正限制这条链的是什么？

最紧的环节会决定整体速度

可以把开发过程暂时看成一条链：需求澄清、设计、编码、验证、评审、发布，前一个环节的结果往往会影响后一个环节。真实工作当然会来回迭代，并不是笔直的流水线；这个类比仍能说明一件事——整条链单位时间能完成多少，常常取决于其中最紧的环节。

过去，编码在不少团队中就是那个最紧的环节。它占用大量时间和注意力，因此“开发效率”很容易被等同为“编码效率”。当 AI 把部分编码、测试草稿和文档工作的成本降下来，原本排在后面的限制就会露出来。可能是评审能力不够，也可能是测试环境容量有限、跨团队协调太慢、真实验收排队，甚至是需求本身还不够清楚。

这里说的“迁移”，不意味着每一种约束都会一直存在。有些限制确实会被技术消除，就像今天没人再因为打孔卡片不够用而无法计算。更准确的理解是：只要目标和资源条件没有一起改变，多环节系统通常还会有一个最紧的地方。旧限制松动后，注意力便会转向下一处。

我们把这种变化称为约束迁移。

约束迁移并不总是“一个旧瓶颈换成一个新瓶颈”。新限制至少有两种来路。

第一种是显形。评审本来就存在，只是在编码很慢时，评审还应付得过来，没有成为主要的等待点。编码提速后，改动集中到达，评审队列才露出来。

第二种是诱发。实现成本下降以后，团队可能尝试更多方案，也可能把更多功能带进维护范围。新增的活动本身就会制造额外负载。比如，以前一周只能比较一个方案，现在一天就能得到多个原型；比较、选择和验证这些原型，于是成为新的工作。

两种情况的处理方式不同。面对显形的约束，团队需要重新分配资源或改造流程；面对被诱发的约束，则要先判断新增活动是否值得。没有这层区分，“AI 让事情更复杂了”就只是一句无法指导行动的抱怨。

回到开头那个团队。编码变快后，评审排队究竟属于哪一种约束？它原本就在那里，只是过去被编码时间遮住，所以属于显形。一天出现多个原型后，比较、淘汰和维护这些方案的工作又从哪里来？这是更低实现成本诱发的新负载。

这两个判断会改变团队接下来的动作。评审队列露出来了，就要重新安排评审力量、缩小每次改动的范围，或把验收材料准备得更清楚；原型突然变多，则要先问多做几个方案是否值得，不能把所有候选都带进后续维护。

这里没有一张适用于所有团队的“AI 时代新瓶颈”清单。不同团队的限制可能是环境容量、客户采用、决策带宽，也可能仍然是实现本身。重要的是先把变化还原成一条工作链，看看哪里变便宜了，哪里开始等待，哪些新增活动正在消耗注意力。

以后遇到新的 AI 工具、岗位或工作方式，可以先问两个问题：

这两个问题不会给出永久有效的预测。新的限制还会继续变化，某些看似重要的热点甚至可能只是营销叙事。但它们能把注意力从名称和功能列表，移到生产系统真实的卡点上。

前两章让我们看见了任务成本和稀缺性，本章再补上系统视角。在多环节的工作链中，成本下降不会让所有限制自动消散，团队还需要重新找出当前最紧的地方。

下一章将把这套观察用于那些不断出现的岗位名称，看看一个名字背后究竟回应了什么变化。