角色边界重塑，全栈取代分工：快手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 个摩擦：

1. 人与人协作的摩擦：AI 带来的提效首先发生在局部，开发人员的开发、测试时间确实缩短了，但一天真正开发时间大约只占 30%，甚至更少。剩下的大部分时间，都花在需求对齐、协作沟通、任务交接等工作上，而这些协作成本，很快就抵消了开发效率提升带来的收益。

2. 人与研发流程的摩擦：大部分团队还是按照传统的研发流程和角色分工做需求，需求估分还是按原来的习惯来估算，不同角色之间的切换、等待，仍然存在。比如，一个前端开发人员用 AI 做的很快，已经交付了，但后端还没做完，前端开发人员就会切换到其他开发任务，等后端开发完了再开始联调。

3. 人与 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 个同步进行的重构：

1. 业务形态：从 SaaS Web+小程序切换为 Skill 接入通用 AI Agent，业务同学可以自主开发 Skill 直接响应需求。

2. 组织形态：从产品/前端/后端/测试四职能，重构为 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 代码生成率

1. 趋势的变化：不知不觉已经翻倍，从 30%→60%+。

1. 分布的变化：AI 代码生成率超过 40%的人员持续增加，从 2025 年 Q4 的 30% → 47% → 77%，且持续提升。

这些数字的背后，不是工具更好用了，而是交付模式、角色分工、组织形态甚至业务形态在同步重构。

研发组织的变化只是全景的一半，非技术团队和 AI 基建的变化留给下次

研发组织的变化只是全景中的一部分，同步在变化的，其实还有 2 个事情：

1. 非技术团队：产品、运营、分析、行政、HR 等非技术工种，也正在用 AI 重塑自己的工作方式——有案例，有数据，变化真实存在。而且从规模和深度来看，非技术团队的「AI × 全员」、「AI × 团队」实践，它们的价值可能比技术侧更大、意义更深。

2. 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 生产力中心」，两个方向同步推进：

1. 产品 &技术升级：将 CodeFlicker + KATE（研发各环节 Agent） + 30+传统研发工具链，升级为 MyFlicker（通用 Agent）+ Skill/CLI（原生 Skill 或垂直 Agent）+ AgentOS，从只服务技术人员到服务全员。

2. 组织升级：早在 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 生产力中心（原研发效能中心）：沈浪、李京、王硕、于旭东、王娟、王贤等