编者按：经过三年的 AI 研发实践，快手已经完成了从工具铺设、个人提效到标杆团队验证的第一轮探索，今年初快手技术团队在首次系统披露了他们的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——存取款全程自动化，机器直接服务用户，但组织必须跟着变十年之后，ATM 出现了。ATM 做的不是让人更快地做原来的事，而是让机器承担了原来只有人能做的事——存取款。这意味着同一家银行，可以用更少的人完成同样的服务。柜员可以从 10 个人变成 6 个人，服务量不降反升。但这件事的真正影响不在于砍编制，而在于：组织必须跟着变。网点的角色变了：不再只是“人来办事的地方”，而是 ATM + 柜员的组合服务点。服务模式变了：24 小时服务成为可能，网点排班要调。客户关系变了：客户“不来也行”，入口不止一个了。团队规模变了：更少的人做更多的事，分工方式必须调整。但不是所有的银行都看到了这个机会，花旗银行（Citibank）看到了，他们是把组织适配做到位的那个。他们不只装 ATM 砍编制，而是把 ATM 当客户入口重新设计了网点的运营方式：24 小时 ATM 网络全城铺开、网点角色从“唯入口”调整为“服务组合之一”、服务流程跟着重建。1977 年纽约大雪，多数银行网点关门停业，花旗 ATM 照常运转，大量储户当周转入。1977 到 1981 年，花旗纽约零售存款市场份额从 4%增长到 13%，增幅接近三倍。而那些只砍编制不调组织的区域储蓄银行，市场份额被持续蚕食，其中多家在 1980 年代被兼并或倒闭。L1 → L2 核心：AI/机器承担了更多工作，更少人干更多活。但组织必须跟着变，不变就停在 L1，适配程度决定效率提升程度。注意：这个阶段银行提供的业务本质没变——还是存款、取款、贷款，只是服务渠道更多、组织效率更高。L2 → L3（1990s-2010s）：网银+移动支付——系统自主干活，业务形态和组织同时彻底重构1990 年代网银出现后，真正跨过去的银行做的不是“让 ATM 做得更好”，而是重新定义了银行和客户的关系。一个在外地出差的客户想申请一笔小额贷款，他在笔记本电脑上提交了申请，大约三十秒后，系统给出审批结果。以前这件事要回到网点递材料，等两到四周。为什么能 30 秒出结果？因为系统自主干了原来只有人能干的事——审批：审批规则变成了代码，风控经验变成了模型，原本做“信息中转”的审批岗从“审材料的人”变成了“写规则的人”分行行长从地方性决策中枢变成了区域服务经理——不是因为他能力不够，而是信息不再需要经过他中转了，系统能做他以前做的事。所有角色同时进入了同一个系统——客户、柜员、审批员、风控、运营，全部在同一条数字链路上运转。中间层消失，速度才真正起来。但网银做得再好，银行还是“你去的地方”。2010 年代，。支付嵌在买东西里，理财嵌在刷，贷款嵌在消费的瞬间里。银行不再是“你去的地方”，它变成了“无处不在的能力”。组织也跟着变了：从按地区分工，变成按场景和用户旅程设计。没有人再说“我们在用计算机提效”，因为计算机已经是水和电，是基础设施，不再是效率工具。网银和移动支付，前后连续，核心逻辑相同：系统/AI 自主干活，业务形态本身变了，角色重新定义，组织必须重建。L2 → L3，有一个本质差别：L2 是组织形态变了，但业务本质没变。L3 是业务形态和组织形态同时变，两边互相倒逼，螺旋式上升——正因为业务形态变了，组织才必须重建。也正因为组织重建了，新的业务形态才能落地。银行和我们，同一个规律：L1 工具变，L2 组织变，L3 业务和组织同时变先看银行：再用同一套逻辑映射到 AI 研发范式的变化：两张表放在一起，规律就出来了。L0 → L1：技术在升级，但组织、角色、业务一个没变。更快的工具，不等于更快的组织。L1 → L2：工作流程升级、人的角色、组织形态开始发生部分变化。但业务形态没变——银行还是存款、取款、贷款，我们还是交付软件功能。L2 的关键是：组织要跟着技术变，变的程度决定你的效率能提升多少。L2 → L3：是另一个量级的事。不仅是组织形态的变化，而是业务形态本身也在变——银行从“你去的地方”变成了“无处不在的能力”。这个变化一旦发生，其他维度（流程、组织、角色等）被倒逼着全部重建。L3 不是 L2 的延续，是命题变了。看完这三段历史，我们自己的命题就出来了：L2 阶段，组织应该怎么变？L3 阶段，当业务和组织形态都要变时，图景是什么？这才是 2026 年，我们真正需要找到答案的命题。03 体系升级：「研发效能」的终点 是 「AI 生产力」的起点命题变了，路就得重走一遍。不是“如何让研发组织更快”，而是“如何用 AI 重塑业务和组织”。于是，基于新命题，我们重新推演了一遍路径。重新推演：旧路径从研发出发走不通，新路径从全员出发从研发角度看，路径是：AI × 工具 → AI × 研发人员 → 推动研发组织变革。这条路走到边界就停了，因为研发推不动整条链路。从组织角度看，路径是：AI × 工具 → AI × 员工 → AI × 团队 → AI × 组织。关键的转折在第二步：不是 AI × 研发人员，而是 AI × 所有人员。只有全员 AI 化，整条链路才能真正重建——这是 L2；业务本身的 AI 化才可能发生——这是 L3。这一步的转变，意味着命题本身变了。不是“研发如何做得更快”，而是——如何把 AI 能力持续供给给组织里的每一个人、每一个团队，促成更大的变革。这不是技术命题，是供给命题。类比一下：传统人力外包，是把人的能力商品化，按需供给给需要的团队，降低成本、提升灵活度。AI 做的是同一件事——只是供给的不是人力，而是 AI 能力。把 AI 能力商品化，按需供给给每个角色、每个团队、每个组织。因此，我们必须把命题从“研发效能”切换到——AI 生产力（AI Productivity）： 以 AI 能力为核心供给，面向组织内所有人员和团队，系统性提升个人效能、团队协作效率和业务交付质量。这不是换名字。目标变了、供给方变了，路径、产品形态、组织形态都得跟着重构。道阻且长：三道鸿沟，导致全行业没人跑出来命题换了，路径清楚了，但不代表好走。全行业里这么多头部大公司，这么多高智力密度的组织，为什么目前为止还没有真正跑出来的实践呢？不是不想走，是每个阶段有不同的鸿沟在挡着：三个阶段，三道鸿沟，三种跨法，为什么跨不过去？下面是我们交流下来了解到的行业普遍现状：L0 → L1，工具鸿沟：各大厂内部的 AI 产品正在“百团大战”，每个 AI 产品都在内部竞争，靠功能和运营争夺用户量，难以形成合力。这会带来 3 个层面的问题：问题 1：公司内的 AI 基建分散，看起来什么都有，实际上，杂而不纯，博而不精，很难聚焦解决有深度的技术和产品问题，更无法积累公司级 SKill、知识等 AI 资产。问题 2：无驱动力为每个不同角色研究应该怎么用 AI 提效，更不用说提供公司级统一的 AI 提效最佳实践了。问题 3：由于 AI 产品的成本（Token 量）和用户量成正比，内部用户使用越多成本越高，但由于对内部用户的提效价值讲不清楚，成本难以分摊到业务线，因此每个 AI 产品背后都是自持的成本“负债”。L1 → L2，组织鸿沟：就算内部工具真的统一了，组织问题会成为第二个瓶颈，这会遇到 2 个层面问题：问题 1：AI 基建团队和业务产研团队的关系，这里最要命的还是 Token 成本。AI 基建团队希望让更多业务线和人员使用，然后把成本分摊给业务线。但在业务线的视角下，同样的一笔钱应该用业界最好的工具，用户满意度更高、效率更好，这个判断非常合理。但一旦这么操作，公司 AI 基建和 AI 资产的统一进程就会被阻断。问题 2：业务产研团队的组织结构问题。大厂普遍是垂直的烟筒型团队，产品、运营、前端、后端一般各有一个高阶 Leader 负责，要打通这些团队之间的部门墙，让其协同并探索新的模式，重组协作流程，会影响利益分配，需要非常强大的组织能力和管理魄力。L2 → L3，业务鸿沟：解决组织鸿沟后，业务怎么 AI 化往往才会被提上日程，这对大厂来说更是难于登天了。每道沟需要的是完全不同的解法，这也是命题必须转换的原因，因为这些问题全部都超出“研发效能”能解决的问题范畴了。因此，想真正跨越这三道鸿沟，需要的不是更好的工具，而是从命题到体系的全面重构——这就是快手「AI 生产力」体系诞生的原因。解决方案：快手「AI 生产力」体系——五阶段跨越三道鸿沟快手会如何跨越这三道鸿沟？先看在新命题、新路径下，快手实例化后的「AI 生产力」体系全景：五阶段路径：AI 能力从工具渗透到组织的全景蓝图路径是目标，打法是手段。要在这五个阶段里真正推进，我们同步推进三条主线。执行策略：组织转型 × AI 基建 × 制度演进，三线并行04 实践：L2 → L3 全新探索，跨越鸿沟，从 研发提效 到 组织跃迁（2026 年 H1）体系设计完了，接下来，是如何带着全公司的组织一起往前走。由于研发组织在 AI 范式升级上走得最靠前，本次还是先重点介绍研发组织在 L3 级的全新实践。在公司所有核心技术负责人的集中讨论与决策下，采用了主航道 + 快速路的双轨策略：主航道：各业务线继续规模推进 AI 研发范式升级，以 L2+需求占比达到 80%为目标——提高下限。快速路：挑选 30 多个"AI 先锋团队"，覆盖公司内不同业务不同类型的团队，规模从 10 人到 100 人不等，不设边界去探索 AI 组织进化的上限——这是在探索两个问题：L2 的上限在哪里？L3 的图景是什么？（这些团队可以探索 L2 → L3 或 直接从 L1 → L3）“快速路”是我们在 2026 年 H1 必须趟出来的新路，下面重点分享实践过程：实践前：四类团队、四种实践这些团队各有特点，不能一刀切的用统一的方式去探索，锁定单一路线会错过上限，野蛮探索又容易浪费半年跑偏。好在，我们评估后发现，有 2 个制约因素决定了每个团队能走哪条路：因素 1 是「团队类型」，2 类团队在实践上一定会有明显差异：因素 2 是「交付类型」，由于业务特点不同，系统复杂度不同，团队交付的需求能 AI 化的程度也有明显差异，也分为 2 类：因此，以「团队类型」作 X 轴，「交付类型」作 Y 轴，把研发团队整体分为四个象限（如下图所示）。不同象限的团队，由于 2 个因素的约束，探索的目标和实践的方式是有差异的。我们让这些团队在各自象限内先去探索“上限”，这样就可以避免过于激进或保守的情况。框架中的实践①-⑥是什么含义的呢？因为我们发现，这四大类实践之间存在着转换关系：理论框架有了，接下来是真正的检验——半年实战。实践后：通过实践洞察规律——“研发组织 AI 进化论”经过半年的实践和验证，我们提炼出了一套完整的研发组织 AI 化路径，适用于公司所有不同类型的研发团队，全景如下图所示：同时，我们发现，在实践层面，四类团队有差异，但也有非常明显的共性和演进趋势：下面通过 3 个例子，让大家更明显的看出 AI-Native 组织的变化：注：由于 L3 案例涉及敏感业务信息，因此下面的案例选择了非敏感业务的团队，由于不同团队的实践过程基本一致，因此这样大家可以更好的了解更多细节。案例 1：商业化某团队，L2 → L3 交付模式怎么变？商业化风控是典型的高对抗业务，需要“产-运-研-算-数”多角色协同、链路冗长。随着黑产用 AI 升级攻击手段，传统交付模式的问题不再是“效率低”，而是根本跟不上对抗节奏。因此，团队选择从 L2 跃升 L3，转型路径分三步：梳理价值链路 → 把 SaaS 工具平台 CLI 化再 Skill 化 → 建立 AI 知识库。最终形成统一入口，转型后研发只需“输入需求 + Review 产出”，需求理解 → 代码生成 → 部署 → 自测 → 状态流转全部由 AI 自动驱动，真正实现了风险事件快速响应。下面是这个团队的 AI 研发范式升级过程：准备阶段：团队能力 AI 化 Step 1：梳理团队核心流程Step 2：相关系统 CLI 化Step 3：核心链路 Skill 化...