AI 编程工具提速了个人，却没提速团队
很多工程团队都经历了这样的路径：调研市面上的 AI 编程工具、选择最合适的、让所有人都上手、用起来——然后个人生产力确实在上升。工程师出活更快了，演示效果更好看了，领导层也满意了。
但时间一长，一个让人困惑的现象出现了：团队的整体速度好像并没有变快。Sprint 速率还是老样子，功能卡在同样的地方，复盘会上听到的还是那些老抱怨。AI 工具承诺的额外产能去哪了？有什么东西在消耗它，但很难准确指出是什么。
工具变了，工程师的工作方式变了，但围绕工作的流程——交接流程、就绪和完成的定义、评审节点、签入签出——并没有随之进化。当企业给赛车换了新引擎，却忘了更新车手的训练体系。
约束理论：当瓶颈转移了，你也得跟着转移
有一个经典的管理理论叫约束理论（Theory of Constraints）：每个系统都有一个约束点，解决了一个，新的约束就会立刻出现。单纯提升约束点的效率并不能提升整个系统的产出，只会在下一个瓶颈前制造更多库存——工作堆积如山，却无人处理。
这个道理在制造业被广泛理解，但在软件开发领域，应用得并不一致。我们倾向于把流程改进当作有价值的事情本身，却懒得问一句：这样做是否真的推动了关键指标。
长期以来，代码生成确实是真实且合理的约束点。写出好软件需要时间——我们早已习以为常的那套组织基础设施，包括敏捷、Sprint、故事点、速率追踪，都是为管理这个现实而设计的，目的是保证可预测性和计划性。
而 AI 已经在很大程度上缓解了这个瓶颈。用 Intuit 工程总监 Eric Anderson 在一期 Podcast（Leaders of Code）里的话说，软件开发中一行代码的边际成本现在已经是"我们做的事情里最便宜的了"。
但大多数组织仍在沿用为旧约束设计的流程。Sprint 结构没变，交接模式没变，PRD 模板没变，设计评审节点没变——全都是老样子。Anderson 的团队在最近一次季度规划中坐下来说："咱们别这样了，让我们重新设想一下交付这个路线图真正需要什么。"他审视团队积压的工作后发现，他们一直在想一些格局太小的事情。代码不再是难题，那时间到底花在了哪里？大多数工程组织还没有提出这个问题。
新瓶颈的真正面貌
新的瓶颈从不自报家门。它只是反复出现在同样的地方，一次 Sprint 接一次 Sprint，而原因总是被归结到错误的方向。以下是它的真实样貌。
构思与需求定义
当代码变得廉价，一份模糊或考虑不周的需求文档的成本反而上升了。一台调校良好的 AI Agent 会精确地按照你的描述去构建——如果你的描述本身就不完整，你很快就会发现这个问题，而返工的责任也不在 AI。知道自己到底想做什么（以及为什么做）——这种纪律性在 AI 时代反而更重要，而不是更不重要。那些把需求发现和定义当作"开始写代码前顺手填一下"的团队，迟早会在周期时间上感受到切肤之痛。
设计交接
Eric 提了一个尖锐的问题：当 UI 迭代成本几乎为零时，"设计完成"究竟意味着什么？传统的交接模式——设计完全定稿后再交给工程、此后才开始写代码——在返工成本高、耗时长的时候是合理的。但这个等式已经变了。在很多情况下，等设计完全敲定再开始构建，只是在凭空增加延迟。
评审与判断
产出增加了，评审的覆盖面也随之扩大。如果一位高级工程师现在要监督&管理过去需要一个团队才能完成的工作，那么代码审核&查验和架构监督就会成为新的瓶颈。这一点在那些大规模部署 AI 但没有相应调整评审、QA 或技术签核流程的组织中已经可见一斑。当产出翻倍但评审能力没有增长，必然会有某个环节承受不住。
跨职能协作
这一点很容易被忽视，因为它不会出现在工程指标里。但工程团队现在的速度往往远远超过了产品、设计、法务、安全的响应节奏。这种错位会催生另一种浪费：工作已经完成，却被束之高阁，等待那些从未被设计成高速运转的签核流程。如果瓶颈在团队外部，看不见、也更难改——但并非不可能。
重新思考"准备好做"的定义
传统的"准备好"定义——完整规格说明书、已完成的设计、所有依赖已解决——是为了保护昂贵的工程时间而构建的。但我们已经不在那个世界了。Anderson 描述了 Intuit 正在转向一种模式：PM 和工程师实时共同开发功能，而不是沿着链条向下传递最终规格。在这种模式下，设计变成了起点，而不是严格的前置条件。
压缩想法与实验之间的距离
AI 最大的价值可能不是更快的代码生成，而是更快的学习。Anderson 提到，Intuit 从选择两个实验中的哪一个来运行，进化到能够运行九个、90 个甚至 900 个实验。实现这一点需要一个为实验而设计的流程，而不仅仅是执行为导向的流程：更短的周期、更轻量的"完成"定义，以及围绕所学而非所交付来定义成功指标。
把跨职能摩擦当作工程问题来对待
瓶颈在工程团队之外——产品、设计、法务或安全——但这并不意味着它不是你的问题。想要加快速度的工程负责人，同样需要帮助相邻团队和职能加快速度。这可能意味着在探索阶段更紧密地配对，或构建共享工具来消除审核&查验流程中的人工工作。仅仅是承认摩擦的存在，就是有用的第一步。
真正的问题
让我们回到开头提到的那支团队：他们有了升级后的工具、更高的个人生产力，但他们仍然没有更快地前进。没有东西坏掉，但流程正在吸收这些收益，不让它们出现在最终产出中。
工具不同于流程，工具是很容易改变的，所以组织会推出新工具并称之为"转型"，因为这比彻底改造流程要容易得多。如果你多年来一直把衣服扔在地板上，买一个新衣柜不会改变你的行为方式，除非你也把流程从"衣服→地板"转变为"衣服→衣柜"。新工具可以推动和鼓励流程变革，但流程本身也需要在某处发生进化。
如果代码不再是瓶颈，你的组织是否围绕真正的那件事在运转？
评论