设计流动摩擦：AI原生团队的核心能力

过去几年，谈及AI对软件研发的影响，业界最常关注的指标是个人生产力：一名开发者能同时推进多少任务、Coding Agent能生成多少代码。确实，AI显著降低了代码执行的边际成本——过去需要数天才能形成的初步实现，如今可能只需数小时。代码、Pull Request和测试的数量都在增加，但从需求提出到用户获得价值的时间却没有等比例缩短。需求、设计、Review、合并、测试和发布仍在排队，局部提速反而让端到端交付变得更不稳定。AI正在把软件研发从「生产能力」问题推向「流动能力」问题。

不均匀加速：打破团队节奏的根源

我把变化在需求、设计、Review、测试和发布之间等待、切换与返工产生的阻力，称为「流动摩擦」。当代码生成的边际成本持续下降，真正限制团队的，已经开始变成这些变化能否以匹配的节奏穿过整个系统。

产品决策：瓶颈不在文档，在于有效决策的产生速度

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

设计交付：挑战不在绘图，在于体验判断的一致性

产品经理当然可以借助AI更快地整理会议记录、生成用户故事、分析竞品，甚至产生大量需求假设。但产品工作的真正瓶颈通常不在于把需求写成文档，而在于获得足够的信息并作出决策。客户会议尚未举行，关键利益相关者没有参与，商业目标尚未明确，优先级冲突没有解决——再完整的用户故事也只是未经确认的假设。 过去，一个产品经理晚一天确认需求，开发团队可能仍在完成上一批功能，这个延迟会被较长的开发周期自然吸收。现在，开发者和Agent可能在几个小时内就消费完已经准备好的任务。产品经理参加半天会议回来，可能会发现开发团队已经没有足够成熟的需求可以继续推进。问题并不是产品经理效率低，也不是开发者过度催促，而是开发环节的消费速度已经超过了团队产生有效决策的速度。

流动摩擦如何被放大为系统返工

设计师面临相似的变化。通过AI生成几个页面、不同风格的界面或者一套初步原型已经非常快，但设计工作的核心并不只是画出页面。设计师需要理解用户路径，处理空状态、异常状态、权限差异和响应式行为；需要在产品目标、技术限制和设计系统之间不断取舍；还需要通过反馈确认一个看起来合理的方案是否真的能够被用户理解和使用。 当开发能力大幅提升之后，设计师很容易成为开发的上游瓶颈。设计稿可能刚刚覆盖主流程，开发者已经开始追问错误处理、批量操作、移动端体验和边界状态。为了避免等待，开发者和Agent可能根据现有组件与常见模式自行补全这些设计。局部实现因此得以继续推进，但原本应该由设计师统一处理的体验决策，开始分散在不同Agent和不同代码分支中。最终，设计师并没有减少工作。相反，他需要在代码已经形成之后重新检查、纠正和统一这些被提前实现的决策。原本应该发生在设计阶段的探索和取舍，被推迟成了开发之后的返工。

如有侵权，请联系删除。