角色边界重塑，全栈取代分工：快手AI生产力体系成形

编者按：经过三年的AI研发实践，快手已经完成了从工具铺设、个人提效到标杆团队验证的第一轮探索，今年初快手技术团队在 InfoQ首次系统披露了他们的AI研发范式升级历程 "。进入2026年，这套模式开始向万人规模的研发组织复制：AI代码生成率持续提高，越来越多需求进入深度人机协作阶段，部分团队的需求吞吐和交付效率也出现明显提升。但规模扩大之后，一个新的问题暴露了出来：参与同一个需求的开发人员越多，AI带来的提效幅度反而越小。 一些开发和测试环节已经被AI显著加速，但从整体数据看，AI深度参与的需求占比，并没有像预期那样与人均需求交付数同步增长。继续下钻后，快手发现，抵消AI收益的已经不是工具能力，而是工具之外的环节：需求对齐、跨角色协作、任务交接和等待仍然按照传统方式运行；不同开发者使用AI的能力严重分化；业务、产品和研发相互分离的烟囱式组织，也让标杆团队的经验难以规模复制。AI加速了局部工作，也让原有组织中的摩擦更加集中地暴露出来。这意味着，继续提高代码生成率、增加AI工具或者复制最佳实践，已经不足以解决下一阶段的问题。快手因此开始把命题从“如何让研发人员做得更快”，转向“如何用AI重新设计交付流程、角色分工和组织结构”，并在30多个AI先锋团队中展开新一轮实践。这篇文章复盘的，正是快手在2026年上半年撞上这堵“组织墙”之后，如何重新寻找AI提效路径：为什么标杆团队跑得通，规模复制却越来越难；研发提效为什么不等于组织提效；以及当工具红利逐渐见顶后，企业需要改变的究竟是什么。 01 规模复制之后，AI提效为什么越来越难？ AI研发提效基建（实践、度量、平台）都就绪了，标杆团队也跑出来了，按以往推广研发效能的模式，接下来难度应该不大。但实际上，我们发现，L2需求占比每往上推一个层次，要付出的力气比之前多得多，且在宏观上看，L2+需求占比，并不像预期的那样和人均需求交付数成正比。 问题出在哪里了？我们通过微观的调研 + 宏观的数据印证，终于找到了这个阶段真正的3大卡点： ① 人：开发人员的AI开发能力两极分化 从2025年10月开始，我们通过大量的实战演练、必修课、AI活动等覆盖全员。宏观看，人效指标大幅提升，但下钻看，发现出现了明显两极分化的情况。如下图所示，在2025年12月，我们通过观察AI代码生成率发现，30%人员的AI代码生成率已达40%以上，但仍有32%人员AI代码生成率在10%以下： 注：快手内部称为“AI代码贡献率”，分母：所有上线发布的代码行；分子：分母中所有AI生成的代码行。 ② 流程与分工：参与需求开发人员越多，提效幅度越小 我们把提效明显和不明显的需求下钻分析，发现参与需求的人数决定提效幅度，即：参与1个需求的开发人员越多，提效幅度越小。调研结论如下图所示： 继续下钻，我们发现AI确实让开发、测试更快了，但进而暴露出3个新瓶颈，我们总结为AI需求交付中的3个摩擦： 人与人协作的摩擦：AI带来的提效首先发生在局部，开发人员的开发、测试时间确实缩短了，但一天真正开发时间大约只占30%，甚至更少。剩下的大部分时间，都花在需求对齐、协作沟通、任务交接等工作上，而这些协作成本，很快就抵消了开发效率提升带来的收益。人与研发流程的摩擦：大部分团队还是按照传统的研发流程和角色分工做需求，需求估分还是按原来的习惯来估算，不同角色之间的切换、等待，仍然存在。比如，一个前端开发人员用AI做的很快，已经交付了，但后端还没做完，前端开发人员就会切换到其他开发任务，等后端开发完了再开始联调。人与AI协作的摩擦：AI被引入之后，并不意味着人可以立刻把工作交给AI。为了让AI真正发挥作用，人仍然需要投入大量额外的时间和精力。调研中我们发现，AI开发能力一般的人员，会成为需求开发过程中的效率“黑洞”。结合实际实践，会出现常见的四种情况： 人工补位：当AI与研发系统之间还没有完全打通时，开发人员不得不充当两者之间的桥梁，把信息不断搬来搬去。上下文对齐：AI并不了解业务背景，也无法天然理解需求语境，因此开发人员需要不断整理、补充和传递上下文，充当系统之间的“搬运工”。验证与纠偏：AI可以在几分钟内生成代码，但验证这些代码是否正确、是否符合业务需求，往往需要几个小时，甚至更长时间。AI生成和人工验证之间，存在明显的速度不对称。能力边界判断：当开发人员对AI的能力边界还没有形成稳定认知时，低估AI，会错过本可以释放的效率，高估AI，则容易导致返工和重复修改。 综上所述，上面的3种摩擦加起来，就造成了这种普遍现象：参与需求开发人员越多，提效幅度越小。 ③ 业务特点与组织结构：AI标杆团队效率高，但规模复制难 我们发现AI研发范式升级的标杆团队（交付效率、需求吞吐大幅提升），大多数是业产研闭环型的团队，即业务、产品、开发（前端、后端）、测试等角色都在1个组织内，他们在AI研发范式导入后，不仅是开发方法&工具在升级，组织、流程、角色也在发生变化。甚至，有一些团队的“业务”本身也在发生变化，比如从原来提供SaaS平台服务的变成了提供Agent的AI服务。（这个信号值得单独记一笔——不只是研发方式在变，他们交付给用户的东西本身也在变。这个变化会在后面的章节再次出现，并成为理解L3的关键） 相对而言，在业务、产品、研发分别是独立团队的烟筒型组织架构下，想达到预期提效效果是非常困难的。 归因：灯照得见的地方做得不错，卡住我们的是灯照不见的组织和人 如上图所示，结合上面的3大卡点，再回顾我们的AI研发范式升级方案，发现一个误区，我们原来设计的框架里隐含了一个假设——我们假定研发流程、角色、分工都是不变的情况下，提供了AI的效能实践、效能平台、效能度量。但目前，新的卡点正好出现在我们之前没覆盖的部分——研发组织中的人、流程与分工、组织结构： 问题出现在我们框架的盲区里。 软件行业有一个规律：业务特点决定软件架构 和 组织形态，又决定研发范式，研发范式再影响开发过程、方法、工程工具。我们一直在研究AI研发范式，在上述规律的“右边”找解决方案，但找到方案后我们发现更关键的瓶颈却出现在“左边”。很明显，这次AI对业务和研发组织的塑造程度，不同以往。我们想了很久，始终没有头绪，直到回头看了一段60年前的历史。 02 镜子：银行60年，已经帮我们提前把路走完了 我用银行业做镜子，因为它把我们今天面对的问题，60年前就完整走了一遍。 L0 → L1（1960s）：计算机——机器代替手工，内部效率提升，但组织没变 1960年代中期，美国几家大型商业银行几乎同时做了一个决定：花重金引入IBM大型计算机系统。柜员面前从账本变成终端，存款查询从翻册子变成敲几下键盘，算数速度快了十倍不止。 但如果你在那时候走进一家分行的后台，会发现分行行长办公室里什么都没变。审批一笔贷款，还是那条链——材料从柜员传到主任，主任转给副行长，副行长送行长画押。一个决策走下来，快的三天，慢的一周。计算机把记账的速度提上去了，但批准一笔业务的速度，和十年前一模一样。 所有银行同时上了计算机，起跑线整体前移，差距没变。那台机器，本质上是一个更快的算盘。 L0 → L1的核心：生产力升级了，但组织没变，效果是旧事物的加速版。 L1 → L2（1970s）：ATM——存取款全程