角色边界重塑，全栈取代分工：快手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——存取款全程自动化，机器直接服务用户，但组织必须跟着变 十年之后，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 化 Step 4：建立团队AI知识库 应用阶段：AI深度参与交付 商业化风控团队的需求交付，基于 crc-dev-flow 这个SKill作为统一入口，打通需求理解、代码生成、部署、自测、状态流转的完整链路。研发只需关注两件事：输入需求、Review 产出——其余环节由 AI 自动完成。我们对比下L2和L3研发过程，开发者使用视角下的变化。 L2阶段，人和AI协同模式：All in 快手KATE平台，人为主，AI为辅，串联需求全流程。 L3阶段，人和AI协同模式：All in 快手 MyFlicker平台。AI为主完成需求全流程，AI推流程、调其他研发工具、用知识，包括KATE在内的研发工具全部CLI化被SKill调用，人在每个环节校验。 注1：快手AI提效平台演进路线：Kwaipilot（编码辅助） → CodeFlicker + KATE （AI工程师） → MyFlicker（AI全能工作伙伴）注2：如上两个视频均使用了非敏感代码仓演示，旨在让大家看清需求全流程交付过程，其中不涉及具体业务代码和地址。 案例2：企业应用团队，业务+组织形态怎么同时变？ 企业应用-内部行政服务团队（会议室/班车管理等），原来是50+人的传统职能型组织，业务扩展重度依赖产品研发排期，响应慢、协作成本高。转型路径是2个同步进行的重构： 业务形态：从SaaS Web+小程序切换为Skill接入通用AI Agent，业务同学可以自主开发Skill直接响应需求。组织形态：从产品/前端/后端/测试四职能，重构为FDE + PDE + 全栈的AI-Native三角，团队规模从50+精简到20人左右，研发成本和协作成本同步大幅降低。 下面是这个团队的AI研发范式升级过程： 业务升级 组织升级 研发模式升级 准备阶段：团队能力AI化 原来的研发经验（知识、Skill等）被沉淀到Agent中 应用阶段：人和Agent协同完成交付 案例3：主站技术部，千人级研发组织怎么变？ 快手主站技术部进行了千人规模的AI研发范式升级实践，直面“AI个人提效 ≠ 组织提效”这一核心矛盾，提出“信息-流程-组织”三层重构框架，并以直播礼物业务为案例验证了组织AI转型的效果和收益：基于Agent的端到端交付，将礼物上新周期从20天压缩到4天。 主站技术部已就这次转型做了完整的复盘，框架、数据、过程细节都在里面，本文不重复，有兴趣直接看原文：《迈向AI Native：技术团队的范式跃迁与组织进化"》 阶段性进展：各项效率指标飙升的背后，是交付模式、角色分工、组织形态、业务形态的变化 从最终结果上看，快手整体的研发效能指标：人均需求交付数↑ 10%；需求平均交付周期↓ 11%+。但更有价值的是下面这些过程指标的变化，可以从数据角度透视出研发过程的变化： 过程指标：L2+需求占比，从13.23% → 64.87%，增长近4倍。 观察指标：再从人员效率的角度，回过头来验证下2025年看的指标——AI代码生成率 趋势的变化：不知不觉已经翻倍，从30%→60%+。 分布的变化：AI代码生成率超过40%的人员持续增加，从2025年Q4的30% → 47% → 77%，且持续提升。 这些数字的背后，不是工具更好用了，而是交付模式、角色分工、组织形态甚至业务形态在同步重构。 研发组织的变化只是全景的一半，非技术团队和AI基建的变化留给下次 研发组织的变化只是全景中的一部分，同步在变化的，其实还有2个事情： 非技术团队：产品、运营、分析、行政、HR等非技术工种，也正在用AI重塑自己的工作方式——有案例，有数据，变化真实存在。而且从规模和深度来看，非技术团队的「AI × 全员」、「AI × 团队」实践，它们的价值可能比技术侧更大、意义更深。AI提效基建：随着基建的统一以及对公司全员的深入服务，AI产品、AI技术、Token机制、AI实践推广方式等各方面都涌现出了全新实践。 由于本文篇幅所限，这部分内容留给下一次分享。届时，我们会发布完整的「AI生产力」体系的实践和案例，比如： Token制度：如何用“Token经济学”同时解决——让更多人用AI、让更多团队负责人主动用AI转型、让Token在被有管控的情况下有价值的用（消除浪费、对公司产生价值）、让Token成本不断下降但产生的价值持续提升。组织转型：技术&非技术团队如何联合实现业务&组织跃迁？纯非技术团队（运营、数据分析、职能团队等），如何快速用AI实现组织转型？AI产品：All in One的AI产品长什么样？在个人提效场景下，如何低成本扩展AI能力，打破传统Saas工具的边界，实现全领域全场景AI服务？在团队提效场景下，如何支撑团队AI、组织AI的建设？（目前业界能看到的任何AI产品，体验和能力都是割裂的，相对来说，我们的AI产品已经是下一代了）AI技术：支撑万人企业全员使用的AgentOS，有哪些核心技术？模型服务层、内核层（记忆、自进化、AgentSDK等）、本地+云引擎层、资产层（Skill、CLI、知识等）、评测&可观测层、Agent端到端安全体系、AI生产力度量体系、各垂直Agent能力。我们是如何快速建立，并在1-2个月内实现技术突破的？ 如下图所示，本次只能先用一张图让大家初窥「快手 AI生产力」的全貌，待下一次分享再详细道来。 05 总结与展望：旧地图找不到新大陆 这张图里有一条暗线，比所有显性的判断都重要：我们每一次真正的认知升级，都不是因为看到了新机会，而是因为撞到了墙。 L0 → L1的阶段，我们以为工具铺开就够了，撞到了“个人提效 ≠ 组织提效”的墙——才理解，L2需要方法和组织跟着变。L1 → L2的阶段，我们以为研发组织变了就够了，撞到了“研发提效 ≠ 组织提效”的墙——才理解，L3不是做得更好，是命题换了。L2 → L3，墙更隐蔽——不是“做得不够好”，是“解错了题”。三道鸿沟横在面前，每道的跨法完全不同，用上一阶段的方法跨不过去。 每次撞墙都不是失败，是认知边界的显形。看不到墙，才是真正危险的——那意味着你在用旧地图走新领地，以为路是对的，只是走得不够快。症状越来越熟悉：工具铺了很多，数字也在动，就是感觉没打通。 这三个难度的跳变不是线性的： L0 → L1，是从“没有”到“有”——这一步最容易，因为工具在推，阻力最小，大多数团队已经完成了。L1 → L2，是从“顺势”到“逆势”——所有直觉都在告诉你继续加工具，但真正要做的是用新的开发方法，并且动流程、分工，这是反直觉的。L2 → L3，是从“解题”到“换题”——所有经验都在告诉你继续优化L2，但真正要做的是承认L2的地图上没有L3，这比反直觉更难，它要求你放弃已经验证过的路径。 每一级的难度跳变，本质上都是认知成本，不是执行成本——真正的门槛不是“会不会做”，而是“愿不愿意先承认旧地图不够用”。执行力强的团队反而更容易卡在这里：他们太擅长解当前的题了。 诚实地说，我们也在这场转型里，不是站在外面观察它。全员AI化之后非技术工种怎么转型、AI-Native小队能复制到多大规模、业务鸿沟的充分条件是什么——这些我们有方向、有实践，但不一定是“最佳”，只能说还在验证答案的路上。这篇文章写的是2026年上半年的实践，不是终局的答案。但有一点是明确的： 研发效能的终局，是没有研发效能——当AI能力真正成为供给品，也没有人再叫它“AI生产力”，它只是基础设施。 就像今天没有人说“我们在用计算机提效”——每当新命题出现，老命题会自然消解，而更大的变革才真正开始。 06 写在最后：先把自己AI-Native化——一切转型的起点 在2026年3月，我们基本确定了必须从“研发效能”升级为“AI生产力”，并设计了全新的路径和实践。但理论能不能走通，需要一个实验田来更充分的验证，最近的，就是「研发效能中心」这个团队本身。 为什么先拿自己开刀？ 两个理由：第一，「研发效能中心」本身就是"业产研闭环型"团队，具备转型的结构条件；第二，如果连建设AI提效基建的组织都没AI-Native化，怎么说服其他团队这条路可行？ 于是从3月开始，这个团队正式升级为「AI生产力中心」，两个方向同步推进： 产品&技术升级：将CodeFlicker + KATE（研发各环节Agent） + 30+传统研发工具链，升级为MyFlicker（通用Agent）+ Skill/CLI（原生Skill或垂直Agent）+ AgentOS，从只服务技术人员到服务全员。组织升级：早在25年9月，就取消了横向的产品团队，按业务方向（研发各阶段）组成独立的全功能团队。这次又进一步升级，把团队匹配新的产品、技术方向继续打散成多个小组，每个组都是“AI原生交付团队”，用自己建设的能力先服务好自己，把“递归飞轮”转起来。 直到4月，这个过程基本完成，孵化出的全新AI基建也完成灰度验证，5月，随Token机制的正式发布，开始面向全公司大规模推进AI-Native组织转型，并在2个月之内基本达成第一阶段的战略目标——全员AI提效 + AI先锋团队完成AI转型。 所以，「研发效能中心」→「AI生产力中心」不仅仅是改了一个名字，而是系统性的组织重构： 在这个过程中，我们还有一个额外收获，一个非常关键的发现——一个团队要走到L3，自身需要具备一些前提条件——没有这些条件，再好的路径也走不动。我们把这些前提条件提炼为规律，称之为成为“AI-Native组织的四个公理”： 这背后是一个递归飞轮： 团队负责人深入理解和使用AI → 团队更好地AI化 → 交付业务更好地AI化 → 负责人进一步加深理解……循环往复，每转一圈，所有变量都在增强。 以「AI生产力中心」为例，这个团队的递归飞轮如下图所示： 一转眼到了8月份，这四个公理已经不再只是理论，而是真实的经验总结。当我们用它们回头观察快手内转型成功的30多个AI先锋团队，发现“无往不利”： 每一个跑出来的团队，都满足这四个公理。每一个卡住的团队，都能在这里找到缺失的那一环。 所以，如果你现在想探索组织级的AI转型，有一件事比选工具、建平台、找方法更重要——把负责这件事的团队先AI-Native化。 把递归飞轮跑起来：负责人先成为AI超级个体，才能带动团队；团队先AI-Native化，才能交付好的AI业务；AI业务跑起来，才能反过来加速组织的AI进化。 这条路，得自己先走了一遍，就能验证出在你的企业里，AI转型是否真的能走通。 本文作者 快手-企业应用部：王诩（快手 企业应用部负责人、AI研发范式升级项目负责人）快手-商业化技术部：朱鞘（快手 商业体系AI研发效能 项目负责人）快手-主站技术部：李思（快手 主站 AIDevops 项目负责人）快手-AI生产力中心（原研发效能中心）：沈浪、李京、王硕、于旭东、王娟、王贤等