过去几年，我们讨论 AI 对软件研发的影响，最常使用的仍是个人生产力：一个功能要多久，一名开发者能同时推进多少任务，Coding Agent 能生成多少代码。AI 确实显著降低了执行成本，过去数天才能形成的初步实现，现在几个小时后就可能进入 Pull Request。

但开发者变快，不代表团队同比变快。代码、Pull Request 和测试都增加了，从需求提出到用户获得价值的时间却没有等比例缩短。需求、设计、Review、合并、测试和发布仍在排队，局部提速反而让端到端交付变得更不稳定。

AI 正在把软件研发从生产能力问题推向流动能力问题。当代码生成的边际成本下降，真正限制团队的，开始变成需求、设计、验证和反馈能否以匹配的节奏穿过整个系统。

AI 对团队各环节的加速并不均匀

如果 AI 能够将每个角色的产能同时提升五倍，团队或许只需要扩大整体吞吐量就可以了。现实却不是如此。AI 对不同工作的加速程度存在巨大差异：它非常擅长生成文本、代码、页面和测试骨架，却不能以同样速度完成客户访谈、组织决策、业务取舍、用户验证和跨团队协调。正是这种不均匀的加速，打破了团队原来相对稳定的工作节奏。

产品工作受限于决策，而不是文档生成

产品经理当然可以借助 AI 更快地整理会议记录、生成用户故事、分析竞品，甚至产生大量需求假设。但产品工作的真正瓶颈通常不在于把需求写成文档，而在于获得足够的信息并作出决策。客户会议没有举行，关键利益相关者没有参与，商业目标尚未明确，优先级冲突没有解决，再完整的用户故事也只是未经确认的假设。

过去，一个产品经理晚一天确认需求，开发团队可能仍在完成上一批功能，这个延迟会被较长的开发周期自然吸收。现在，开发者和 Agent 可能在几个小时内就消费完已经准备好的任务。产品经理参加半天会议回来，可能会发现开发团队已经没有足够成熟的需求可以继续推进。问题并不是产品经理效率低，也不是开发者过度催促，而是开发环节的消费速度已经超过了团队产生有效决策的速度。

这也解释了为什么“让产品经理使用更多 AI”只能部分缓解问题。AI 可以帮助产品经理更快地探索可能性，却也可能同时产生更多需求、更多备选方案和更多需要确认的假设。需求的数量增加，并不等于可安全进入开发的需求增加。真正稀缺的仍然是经过业务判断、用户验证和团队对齐的有效需求。

设计工作受限于体验判断，而不是绘图速度

设计师面临相似的变化。通过 AI 生成几个页面、不同风格的界面或者一套初步原型已经非常快，但设计工作的核心也并不只是画出页面。设计师需要理解用户路径，处理空状态、异常状态、权限差异和响应式行为，需要在产品目标、技术限制和设计系统之间不断取舍，还需要通过反馈确认一个看起来合理的方案是否真的能够被用户理解和使用。

当开发能力大幅提升之后，设计师很容易成为开发的上游瓶颈。设计稿可能刚刚覆盖主流程，开发者已经开始追问错误处理、批量操作、移动端体验和边界状态。为了避免等待，开发者和 Agent 可能根据现有组件与常见模式自行补全这些设计。局部实现因此得以继续推进，但原本应该由设计师统一处理的体验决策，开始分散在不同 Agent 和不同代码分支中。

最终，设计师并没有减少工作。相反，他需要在代码已经形成之后重新检查、纠正和统一这些被提前实现的决策。原本应该发生在设计阶段的探索和取舍，被推迟成了开发之后的返工。设计产能不足并不只是让开发等待，它还会诱使开发提前消费不成熟的输入，并把差异放大成更多代码变化。

开发同时经历上游饥饿和下游拥堵

于是，一个 AI 原生团队可能同时出现两种看似矛盾的状态。一方面，开发者认为没有足够的需求和设计可以继续工作，团队出现了上游饥饿；另一方面，已经生成的代码又在 Review、合并和测试环节大量排队，团队出现了下游拥堵。不是团队没有工作，而是工作分布在价值流的不同位置，无法继续向前流动。

这正是 AI 对团队流动最反直觉的影响。开发能力的提升并不会简单地把整条价值流向前推动，它首先改变的是各环节之间原有的产能比例。当需求决策仍然是 1.2 倍，设计交付是 1.5 倍，代码生产变成 5 倍，而 Review 与测试只提升到 1.3 倍时，开发环节就像一条突然扩宽的高速公路：入口没有足够车辆，出口又无法承接已经进入的车流。

局部提速如何转化为系统返工

当开发比上下游快得多，团队通常会让 Agent 提前探索、顺手重构或补更多测试，试图填满产能。这些工作本身有价值，却会持续增加尚未完成的变化，把局部提速转化为系统返工。

不成熟的需求更快地变成代码

过去，需求歧义会在开发过程中逐步暴露。现在，Agent 可以根据当前上下文迅速选择一个合理解释，并形成完整实现。歧义没有消失，只是更快地被固化成了代码。

例如，“管理员可以导出成员列表”并没有说明管理员的权限模型，也没有说明导出哪些数据。前端、后端和测试 Agent 都可能给出局部合理的实现，却未必表达同一个业务决策。等差异在 Review 中暴露，一个待澄清的问题已经变成一组需要修改的代码、测试、文档和接口。

更多并行开发带来更多合并与所有权问题

开发速度提升之后，团队自然会增加并行度。Git 冲突只是最表层的问题；即使代码能够合并，不同 Agent 仍可能在相邻模块中引入不同的抽象、命名和错误处理方式。

每个 Pull Request 单独看都可能正确，放在一起却会失去一致性。作者的信心来自与 Agent 交互的完整过程，Reviewer 看到的只有最终 Diff，Code Review 也就从代码检查变成了上下文恢复。AI 降低了写代码的成本，却提高了团队共同拥有代码的成本。

测试规模增长并不等于验证能力增长

AI 很擅长根据实现补充测试，但测试数量增加，不等于验证能力增长。由实现生成的测试很容易证明“代码按照当前写法运行”，却未必证明“系统实现了正确的业务行为”。

并行变化还会扩大需要验证的组合空间。测试团队不仅要选择真正对应风险的测试、解释结果和定位失败，还要替上游恢复意图、发现分歧。问题发现得越晚，开发阶段节省的时间就越容易以 Bug 修复、回归测试和重复交付的形式回到系统中。

AI 原生团队需要优化变化的 Flow

解决办法不是压住 Agent，也不是让产品、设计和测试一起追赶开发的峰值速度。AI 对不同环节的加速天然不均匀，团队真正需要优化的，是变化如何进入系统、跨越角色并获得验证。目标不是让每个环节都更忙，而是让工作以更少的等待和返工穿过整条价值流。

1. 先形成最小决策。 需求不必因此变得更长。团队只需要在大量代码产生之前，确认业务语义、核心路径、风险边界和完成条件，让关键分歧在最便宜的时候出现。
2. 用小批次吸收开发产能。 AI 的优势应该用来缩短小批次的实现周期，而不是扩大需求和 Pull Request。更小的变化能更早获得反馈，也更容易 Review、测试、合并和回滚。
3. 让上下文和证据随代码交付。 一个可 Review 的变化，不能只有代码和自动生成摘要，还要带上目标、关键假设、影响范围、验证结果和仍然存在的未知，降低 Reviewer 逆向恢复上下文的成本。
4. 用背压控制并行度。 当 Review、测试或集成已经饱和时，继续增加开发并行度只会制造库存。团队应该减少新功能并发，或者让 Agent 转向补充验证、整理上下文和消除已有风险。

代码已经够快，真正稀缺的是团队流动能力

过去的软件工程长期围绕生产能力展开。我们优化语言、框架、构建系统、部署平台和开发环境，希望更快、更可靠地产生软件。Coding Agent 进一步降低了代码生产成本，也让开发第一次可能从价值流中的主要瓶颈变成最快环节。

当这种变化发生后，团队不能继续只优化开发。产品能否持续形成有效决策，设计能否及时提供可消费的体验边界，代码能否以小批次安全并行，Review 能否获得足够上下文，测试能否验证真正的业务行为，生产反馈能否回到下一轮决策，这些共同决定了变化是否能够持续穿过整个系统。

AI 原生团队的竞争力，不在于能够同时启动多少 Agent，也不在于一天能够生成多少需求、原型、代码和测试。真正重要的是，团队能够让多少变化以较少的等待、冲突和返工，从一个尚未确认的想法，持续流动为用户可以感知的价值。

代码可能已经足够快了。真正需要被重新设计的，是整个团队的 Flow。