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

AI摘要 快手AI研发范式进入组织级重构阶段，发现规模扩张后人机协作效率边际递减，根源在于需求对齐、跨角色协作与组织壁垒等非工具性瓶颈。

AI提效瓶颈已从工具能力转向流程与组织设计；30个先锋团队正试点AI驱动的交付流程与角色重定义；业务-产品-研发烟囱结构阻碍最佳实践规模化复用。

适合技术负责人、研发效能工程师、AI工程化负责人阅读。

编者按： 经过三年的 AI 研发实践，快手已经完成了从工具铺设、个人提效到标杆团队验证的第一轮探索，今年初快手技术团队在 InfoQ首次系统披露了他们的AI研发范式升级历程 。进入 2026 年，这套模式开始向万人规模的研发组织复制：AI 代码生成率持续提高，越来越多需求进入深度人机协作阶段，部分团队的需求吞吐和交付效率也出现明显提升。

但规模扩大之后，一个新的问题暴露了出来： 参与同一个需求的开发人员越多，AI 带来的提效幅度反而越小。 一些开发和测试环节已经被 AI 显著加速，但从整体数据看，AI 深度参与的需求占比，并没有像预期那样与人均需求交付数同步增长。

继续下钻后，快手发现，抵消 AI 收益的已经不是工具能力，而是工具之外的环节：需求对齐、跨角色协作、任务交接和等待仍然按照传统方式运行；不同开发者使用 AI 的能力严重分化；业务、产品和研发相互分离的烟囱式组织，也让标杆团队的经验难以规模复制。 AI 加速了局部工作，也让原有组织中的摩擦更加集中地暴露出来。

这意味着，继续提高代码生成率、增加 AI 工具或者复制最佳实践，已经不足以解决下一阶段的问题。快手因此开始把命题从“如何让研发人员做得更快”，转向“如何用 AI 重新设计交付流程、角色分工和组织结构”，并在 30 多个 AI 先锋团队中展开新一轮实践。

这篇文章复盘的，正是快手在 2026 年上半年撞上这堵“组织墙”之后，如何重新寻找 AI 提效路径：为什么标杆团队跑得通，规模复制却越来越难；研发提效为什么不等于组织提效；以及当工具红利逐渐见顶后，企业需要改变的究竟是什么。

AI 研发提效基建（实践、度量、平台）都就绪了，标杆团队也跑出来了，按以往推广研发效能的模式，接下来难度应该不大。但实际上，我们发现，L2 需求占比每往上推一个层次，要付出的力气比之前多得多，且在宏观上看，L2+需求占比，并不像预期的那样和人均需求交付数成正比。

问题出在哪里了？我们通过微观的调研 + 宏观的数据印证，终于找到了这个阶段真正的 3 大卡点：

从 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 研发范式升级的标杆团队（交付效率、需求吞吐大幅提升），大多数是业产研闭环型的团队，即业务、产品、开发（前端、后端）、测试等角色都在 1 个组织内，他们在 AI 研发范式导入后，不仅是开发方法 &工具在升级，组织、流程、角色也在发生变化。甚至，有一些团队的“业务”本身也在发生变化，比如从原来提供 SaaS 平台服务的变成了提供 Agent 的 AI 服务。（这个信号值得单独记一笔——不只是研发方式在变，他们交付给用户的东西本身也在变。这个变化会在后面的章节再次出现，并成为理解 L3 的关键）

相对而言，在业务、产品、研发分别是独立团队的烟筒型组织架构下，想达到预期提效效果是非常困难的。

如上图所示，结合上面的 3 大卡点，再回顾我们的 AI 研发范式升级方案，发现一个误区，我们原来设计的框架里隐含了一个假设——我们假定 研发流程 、 角色 、 分工都是 不变的情况下，提供了 AI 的效能实践、效能平台、效能度量。但目前，新的卡点正好出现在我们之前没覆盖的部分——研发组织中的人、流程与分工、组织结构：

软件行业有一个规律：业务特点 决定 软件架构 和 组织形态 ，又决定 研发范式 ， 研发范式再影响 开发过程、方法、工程工具。我们一直在研究 AI 研发范式，在上述规律的 “右边” 找解决方案，但找到方案后我们发现更关键的瓶颈却出现在 “左边” 。很明显，这次 AI 对业务和研发组织的塑造程度，不同以往。我们想了很久，始终没有头绪，直到回头看了一段 60 年前的历史。

我用银行业做镜子，因为它把我们今天面对的问题，60 年前就完整走了一遍。

1960 年代中期，美国几家大型商业银行几乎同时做了一个决定： 花重金引入 IBM 大型计算机系统 。柜员面前从账本变成终端，存款查询从翻册子变成敲几下键盘，算数速度快了十倍不止。

但如果你在那时候走进一家分行的后台，会发现分行行长办公室里什么都没变。审批一笔贷款，还是那条链——材料从柜员传到主任，主任转给副行长，副行长送行长画押。一个决策走下来，快的三天，慢的一周。计算机把记账的速度提上去了，但批准一笔业务的速度，和十年前一模一样。

所有银行同时上了计算机，起跑线整体前移，差距没变。那台机器，本质上是一个更快的算盘。

L0 → L1 的核心： 生产力升级了，但组织没变，效果是旧事物的加速版。

十年之后，ATM 出现了。ATM 做的不是让人更快地做原来的事，而是让机器承担了原来只有人能做的事——存取款。这意味着同一家银行，可以用更少的人完成同样的服务。柜员可以从 10 个人变成 6 个人，服务量不降反升。

但这件事的真正影响不在于砍编制，而在于： 组织必须跟着变 。

网点的角色变了：不再只是“人来办事的地方”，而是 ATM + 柜员的组合服务点。

服务模式变了：24 小时服务成为可能，网点排班要调。

客户关系变了：客户“不来也行”，入口不止一个了。

团队规模变了：更少的人做更多的事，分工方式必须调整。

但不是所有的银行都看到了这个机会，花旗银行（Citibank）看到了，他们是把组织适配做到位的那个。他们不只装 ATM 砍编制，而是把 ATM 当客户入口重新设计了网点的运营方式：24 小时 ATM 网络全城铺开、网点角色从“唯入口”调整为“服务组合之一”、服务流程跟着重建。

1977 年纽约大雪，多数银行网点关门停业，花旗 ATM 照常运转，大量储户当周转入。1977 到 1981 年，花旗纽约零售存款市场份额从 4%增长到 13%，增幅接近三倍。

而那些只砍编制不调组织的区域储蓄银行，市场份额被持续蚕食，其中多家在 1980 年代被兼并或倒闭。