3年、1万人，快手技术团队首次系统披露AI研发范式升级历程

编者按

以 ChatGPT 问世的 2022 年为起点，大模型技术进入公众视野已经超过三年。人们普遍见证了 AI 作为新型生产工具对生产力的重塑，但对科技企业而言，这远不止是多了新技术或新产品那么简单。

作为前沿技术的掌握者与实践者，科技公司必须率先完成自身的转型：以极快的速度，不惜试错和阵痛，找到大规模、稳定、高效使用 AI 的组织路径。过去十年，“数智化”浪潮主要聚焦于传统企业如何借助外部工具实现数字化；而如今，AI 正在倒逼科技公司自身成为变革对象。它们必须在人才结构、工具体系、协作流程乃至组织文化上同步革新，否则将难以在 AI 时代维持竞争力。

正是在此背景下，快手首次系统性披露其自 2023 年以来的 AI 研发范式升级历程。

今天，快手发布了名为《快手万人组织 AI 研发范式 跃迁之路：从平台化、数字化、精益化到智能化》的 1.6 万字长文。文章由快手研发效能委员会审稿、经内部深度复盘整理，罕见地呈现了一家超大型科技企业在 AI 时代推进组织级提效的完整图景。

你会在这篇文章中看到快手研发范式的三阶段演进路径，以及快手技术团队对 AI 赋能组织提效的思考：

• 三阶段演进路径：

• 平台化、数字化、精益化（2023-2024 年）：
• 建设一站式研发平台，并标准化需求和工程流程，工具渗透率>95%，流程自动化>94%
  
• 通过建立效能模型，识别交付瓶颈，提升需求交付效率，人均需求吞吐量提升 41.57%
• 智能化 1.0（2024 年 6 月 -2025 年 6 月）：聚焦用 AI 提升个人开发效率
• 建设并推广 AI 编码 / 测试 /CR 等能力，AI 代码生成率超过 30%
• 但发现矛盾——个人主观编码效率提升显著，但组织需求交付效率却基本不变

• 智能化 2.0（2025 年 7 月以后）：聚焦用 AI 提升组织整体效能

• 找到了 AI 研发范式升级路线：L1 AI 辅助（Copilot）→ L2 AI 协同（Agent）→ L3 AI 自主（Agentic）

• 探索出了支撑路线达成的系统性实践：AI x 效能实践、AI x 研发平台、AI x 效能度量
  

• 关键洞察与经验：

• AI 研发提效陷阱： 用 AI 开发工具 ≠ 个人提效 ≠ 组织提效

• 本质问题：如何将个人提效传导到组织提效
  

在全球范围内，如此系统、坦诚且具备工程细节的 AI 提效实践总结仍非常稀缺。对于所有正在探索 AI 落地路径的企业而言，这份来自一线的复盘值得细读。

这也预示着一个新的节点正在到来。当像快手这样的头部公司开始对外输出其 AI 落地的方法论与效能成果，整个行业将面临一种隐形的压力——组织能否高效驾驭 AI，将成为其在 AI 时代竞争力的重要衡量方式。

可以预见，2026 年将成为一批先行者集中展示阶段性成果的窗口期。这些成果首先会以研发效率、工程体系和组织方法论的形式呈现；再过几年，更会传导到公司的财务表现与人才吸引力上。

到那时，所有公司都将不得不回答同一个问题： AI 时代，我们如何重构自己？

快手报告标题：《快手万人组织 AI 研发范式 跃迁之路：从平台化、数字化、精益化到智能化》

早在 2024 年，快手就建设了 AI 编程工具 Kwaipilot，并发布给公司内 10000+ 研发人员使用。经过持续的深度优化和推广，快手整体的 AI 代码生成率，在严格度量口径下（AI 生成并入库的代码行 / 新增代码行）从 1% 达到了 30%+，甚至部分业务线达到了 40%+。同时，在非编码环节，也衍生出了很多 AI 提效工具，比如智能 CR（CodeReview）、智能测试用例生成、智能单元测试等等，但经过大量的调研和数据分析，我们发现了这个不等式：

“用 AI 开发工具 ≠ 个人提效 ≠ 组织提效”

如果以企业的研发效能提升为目标，我们发现：

• 对研发工程师而言：深度使用 AI 开发工具，代码生成率很高，个人主观体感上编码效率提升了 20-40%，但并不代表真正的“个人提效”，因为在现实中，大部分工程师并没有接纳更多的需求，个人需求的交付数没有显著提升。

• 对大型组织而言：我们发现部分 AI 用的好的工程师，确实可以更快更多的完成开发任务，但组织整体的需求吞吐量没有明显提升，需求交付周期也没有明显缩短。

从《2025 年 DORA 报告：人工智能辅助软件开发现状调查报告》中能看到，这也是业界普遍存在的问题。如报告中所述（如下图所示），在对 AI 提效的结果的预估上，各企业普遍对个人效能的提升有信心，而对团队效能的提升预估非常小。

在快手，我们发现仅推广研发各阶段的 AI 提效工具，已经偏离了企业研发效能提升的核心目标，最终必然会导致 2 个问题：

• 投入很大，但企业整体的研发效率提升不明显：虽然通过调研很容易能收到大量的个人效率提升反馈，但个人提效无法传导到组织提效。

• 效能平台开始割裂：传统 DevOps 平台仍承担研发主流程，每天被高频的使用，却无法演进到下一代 AI 研发平台（顶多扩展一些单点的 AI 功能）。新生的 AI 编程工具，只取代了传统 IDE，又无法与老平台协同演进。

为了解决上述 2 个问题，我们从 2025 年开始进行了更激进的探索和变革，我们称之为“AI 研发范式升级”，最终，通过一系列的实践，找到了一条能借助 AI 能力平滑通往研发智能化的路径。

正逢 2025 年年末，我们把镜头拉远，将时间回溯到 3 年前，对快手研发效能的演进做一个系统性总结，有踩过的坑，也有做出的突破，希望为更多企业提供经验和参考。

快手有 10000+ 研发、8+ 业务线，研发效能的演进可以分为 3 个大阶段，如上图所示：

• 阶段 1：平台化、数字化、精益化（2023-2024 年）：通过建设三端一站式研发平台、需求流 & 工程流标准化，解决了研发交付流程散乱，既无标准也无数据的问题。再通过建立效能模型，识别交付瓶颈，提升需求交付效率。

• 阶段 2：智能化 1.0（2024 年 6 月 -2025 年 6 月）：在研发全流程中开始建设 AI 能力，包括 AI 编码、AI 单元测试、AI CR、AI 手工用例生成、AI OnCall 等等，并进行全员推广。经过 1 年多的实践，基本上完成了全员普及，在主观调研中，开发人员主观体感上效率提升 20-40%，在客观数据上，AI 代码生成率也在持续增长。但同时也发现了矛盾点：需求交付效率基本不变，即个人效率提升未能有效传导到组织效率提升。

• 阶段 3：智能化 2.0（2025 年 7 月 +）：从“推广 AI 工具，让开发者使用”回归到了更本质的元问题：如何用 AI 提升需求端到端交付效率？经过半年多的探索，终于找到了新的路径，并得到了充分的数据验证。我们称这套解决方案为“AI 研发范式”，主要解决了 3 个问题：

• AI x 效能实践：如何用 AI 提升工程师的生产力，并将个人提效传导到组织提效。

• AI x 研发平台：支撑需求交付全流程（从分析到编码再到发布）的研发工具链，如何整体演进到智能化？即下一代的智能研发平台，应该是什么样的？而不仅仅是只推广 AI 编程工具或在原有工具链上增加一些散点的 AI 提效功能。

• AI x 效能度量：如何在效能度量指标的基础上，构建 AI 提效的指标体系，能清晰的量化过程和结果，为组织级的 AI 研发范式升级提供有效指引。

这个阶段的解决方案，业界相关的分享已经非常多了，但从实际情况看，在千人规模的技术团队中，能做好、做深、做透的实践非常稀有。

因此，我们直接分享 1 个具体的案例，以便能更好的看清快手的研发效能从基础建设到效能提升的全过程，这也是我们之所以能更快跃迁到 AI 研发范式的重要基石。案例来源是快手最核心的技术团队之一——主站技术部，是快手 APP 的研发团队，开发人员规模千人以上。

首先，主站技术部的实践依托一套公司级的研发效能基建，由横向团队「研发效能中心」提供，如下图所示，这是在 2023 年快手当时的研效基建，主要分为：

效能平台：项目管理平台（Team）、三端一站式研发平台（KDev（服务端）、KFC（前端）、Keep（客户端））、琅琊阁（效能度量）、质量平台（KTest 等）

效能实施：效能 BP 专家（Business Partner），负责深入各业务线，提供专业支持。

了解快手的研效基建后，下面开始重点介绍主站技术部的实践过程。

需求流和工程流均不标准，开发人员的工作分散在各处，日常开发体验差、学习成本高，又无法实施有效的质量防护措施，还不能沉淀准确的研发过程数据持续度量与改进。

达成的效果

通过推广三端一站式研发平台，定义需求、研发的标准流程，将研发全流程标准化。核心度量指标与结果如下：

• 用一套产品设计尽量满足多样化的研发场景：工具一边建设一边落地，且需兼容之前散乱各种不同的研发模式和习惯。

• 服务端（KDev 平台）：需要支持一些特殊的研发模式（比如 Master 模式、窗口模式）。

• 客户端（Keep 平台）：移动端研发场景多样化，包括 APP、动态化、    SDK。

• 前端（KFC 平台）：前端应用类型多（Web、Node、低码、KRN（动态化）、小程序），研发流程和习惯散乱。

• 研发流程规范差异大：不同团队间，不同的技术栈的研发流程上存在一定差异，包括研发流程配置、流程各阶段信息字段、单点环节所需的工具能力不同等。

• 用户迁移成本大：迁移过程中，需持续关注和解决用户问题，包括用户体验变化、用户学习成本、用户情绪。

• 落地时间紧迫：一般互联网大厂类似的工作基本会持续 6 个月以上，快手主站只用了 1 个多月。

• 精准的解决方案设计：

• 服务端（KDev 平台）：精准的打造了 4 套标准研发模式，适配了主站实际研发情况。

• 客户端（Keep 平台）：一套平台底层能力，支撑 3 种移动研发场景；通过可配置与定制化能力，满足不同团队流程规范与管理诉求（自动翻转配置、流程与质量卡点配置、团队定制化模板）。

• 前端（KFC 平台）：支持 80% 以上前端应用类型，并通过 8 个流程模板、适配 5 个内部自建的插件，兼顾了前端差异化研发流程和用户习惯。

• 以用户满意为导向：提供完整的迁移配套服务，降低用户迁移成本。主要包括：

• 产品质量专项：用户 BUG 日结。

• 用户体验专项：持续深度用户访谈，识别体验问题，并优化。5 周内，交付了 73 个功能 & 体验需求。

• 用户培训与激励：通过 12 次培训，50+ 线下访谈，7x24 小时 OnCall、200+ 人次的用户激励，提升用户对产品的接受度。

• 数据驱动团队级推广：每周度量进度，驱动各部门接口人推广。

可能大家会有疑惑，为什么三端分别是 3 个平台，而不是一套平台。因为从实际情况看，服务端、前端、客户端的底层模式、流程都有比较大的差异，强行整合，不仅对产品用户收益不大，反而牺牲了要兼容不同端的流程、习惯差异化的灵活性，给标准化的推进增加难度。因此，我们在用户层面上，还是三套平台，分别解决各自领域的问题，但在底层的基础能力用的是一套，比如流水线、权限等。

主站的研发效能早在 2022 年就开始启动了，当时在探索北极星指标阶段，缺少度量体系，更多是根据一线开发者的开发痛点反馈，进行偏工具流程等的优化，没有核心指标的牵引，项目都无法推进，更谈不上论证给业务带来的价值。在 2023 年 3 月再次重启效能项目时，北极星指标初步定义为 “有效需求吞吐量”，但是当时需求有效性的衡量难度太大，内部无法达成共识，项目推进困难，而且也无法看清业务堆积和开发人效情况。

随着流程标准化的落地，研发数据的置信度大幅提升，为效能度量提供了土壤。因此，我们定义了以“人均交付产品需求数” 为北极星目标来看清业务开发交付能力，同时观测需求颗粒度（避免单一指标跑偏：度量什么得到什么，种瓜得瓜种豆得豆）来保障交付提升的良性发展，逐步建立了一套更全面的指标体系（多指标互相佐证约束，hack 成本极高）来体现业务交付产能和交付效率，以及组织和个人效率情况。

快手的效能度量体系如下图所示：

注明：SP：Story Point，快手用于度量需求工作量的单位。

借助这套全面完备的指标体系，我们不仅避免了依赖单一指标可能导致的偏差，还有效防范了效能数据被 hack 的风险，确保了效能数据的准确性和可靠性。

有效能度量体系，首先我们可以为任何一个业务线做系统性的体检，如下图所示，依托数据和经验，可以逐一拆解出核心的优化专项，并以效能项目的形式实施。

其次，在研发流程和管理上，也能洞察出更多平时看不见的 Case，深入改进，下面是 2 个具体的洞察与改进案例：

上图是主站技术部下级各团队的研发活动在线化率，其中有一个团队出现了数据异常，分析之后可以发现存在不少问题：

• 横向来看，这个团队的研发活动在线化率处于中上水平，但产品需求投入占比只有 59%，处于末尾水平。而且产品需求中体验优化占比 11.44%，又是各团队中最高的。那么问题来了，“时间都去哪儿了？”

• 再下钻一层，这个团队的缺陷占比 14%，也是各团队中最高的，且 Oncall& 排障占比 6% 也不低。

因此，数据表明，此团队可能存在的问题：在缺陷问题、体验问题、Oncall& 排障消耗了团队大量的投入，以至于无法消化更多产品需求。所以，通过对团队核心成员的调研和访谈，基本可以找到根因：和客户端的架构劣化有关，比如：

• 反馈 1：新需求开发时，上手门槛特别高，很多需求会涉及到多个模块开发，这会涉及到自己不熟悉的模块，因为架构分层结构不合理，模块耦合度太高，往往需要花大量的时间去熟悉其他模块的代码，最近做了一个新需求，评估是 3 天的工作量，2 天都在看代码，实际的开发联调只有 1 天。

• 反馈 2：模块边界不清晰，代码杂糅一起，新需求的代码，可能会影响到已有功能，导致旧功能的 BUG，而且这些 BUG 在回测时，不容易被发现，导致问题漏测逃逸到线上。

通过效能的客观数据再结合主观调研，就可以看清“架构劣化”这种深层次问题，也可以对症下药了。解法是这个团队实施了 2 个技术专项：

• 客户端的架构升级：从根本上解决因为架构问题带来的交付效率低和交付质量差的问题。

• 体验优化：集中优化重点场景的体验问题。

随着这两个专项的落地上线，这个团队的效能数据已经有所改善，产品需求投入占比已经提升到 64%，体验优化占比下降到 6%。

上图是主站技术部下级各团队的需求积压率数据，有些团队的需求积压率持续保持在 80% 以上，意味着需要近一个月的时间才能消化这些积压的需求。这种情况可能存在的问题：

• 这些被积压的需求，一个月之后，会不会进入排期开发？如果之后会排期开发，说明需求本身的价值还可以，当下是否可以协调资源加快交付？能否可以停掉某些技术需求优先业务交付？是否可以短期加班临时突击？

• 如果后面不会进入排期，是不是这些需求本身的重要性没那么高？在预评审的时候，是不是可以控制需求的优先级？当前的需求评审流程是否可以优化？

经过一年时间的系统化提效，主站提效方面进展显著，人均交付产品需求数 24 年 7 月份同比增长超过 80%。总结下来，主要有效的措施有：

• 升级研发模式：通过动态化、配置化等研发模式，让部分需求可以更快速交付。

• 研发过程提效：通过 API 在线化管理，测试环境稳定性治理、流水线优化、发布优化等措施，降低研发协作成本以及低价值工作占比。

• 管理与协同提效：通过效能洞察，持续识别团队协作瓶颈，并通过排期优化、测试无人值守、人力调配等措施，支撑需求可顺畅流动。

从 2023 年 6 月开始，我们开始探索大模型在研效领域的应用，主要有 2 个方向：

• 编码场景：如何用 AI 辅助编码，提升代码生成效率。

• 非编码场景：在研发全流程里，哪些环节可以通过 AI 能力提升单点工作的效率。

其中，最重要的决策是我们决定自己研发一款 AI Coding 工具：Kwaipilot。它包含了大家见过的所有产品形态：

• IDE 插件 / AI IDE / CLI：最符合开发人员习惯的几种形态，插件、IDE 可以做续写、问答、智能体代码生成，CLI 则可更灵活的开启代码生成任务。

• 智能问答引擎：有独立的 Web 页面，也会嵌入到上面的产品形态里，为开发人员提供灵活的问答能力。

业界有很多优秀的 AI Coding 产品，比如 Cursor、Claude Code、Krio、Windsurf、Antigravity，快手为什么不选择采购，而是自建呢？其实一年来，我们也一直带着这个疑问在探索，相当于一场大型的公司内部 AB 实验：

从用户体验的角度，我们希望大家“用脚投票”，选择好用的工具：

• 一方面，我们允许开发同学使用任何 AI Coding 产品，可以团队级采购也可以个人购买。

• 另一方面，我们研发了 Kwaipilot，对内推广。

从实际效果的角度，我们以“AI 代码生成率”为核心观测指标，持续收集用户 / 团队的反馈，识别不符合预期的代码生成 Case，研究解决方案，再投放实验。最终，经过 1 年的探索，实践结果让我们坚定了继续走自研 Kwaipilot 的路线。

注明：2025 年 12 月开始，在 Kwaipilot 已规模应用后，由于安全原因，探索按代码分级封禁三方 AI Coding 工具，仅涉及到部分开发人员。

下面简单分享一下我们的实践过程，相信大家会更容易理解我们的选择。整个 AI Coding 的推广过程分为 3 个阶段：导入、优化、固化

这个阶段很好理解，我们鼓励开发人员在日常工作中默认使用 AI 编程工具，主要目的是让大家拥抱 AI，在意识和行为上先有一个转变。

当然，各种各样奇怪的使用姿势也会出现：

• 一些同学，尤其是校招入职的同学，在我们的培训和引导下，会深度使用 Kwaipilot。

• 一些同学会多种 IDE 混开配合使用。其中，有“团购客”，哪家这个月免费就用谁，也有“付费用户”，主要以个人购买 Cursor 为主。

这里最大的副作用，就是个人编码效率不一定全员获得了提升，通过调研看，出现了明显的两级分化的情况。腾讯研究院出品的《AICoding⾮共识报告》中也揭示了类似的情况：

我们通过用户数据和技术 Leader 推荐找到了一批公司里的“AI 开发高手”，那些用 AI 辅助编码切实提升了效率的开发人员。

一边重点收集他们在使用过程中的问题，集中想办法解决，一边把他们的优秀开发技巧淬炼出来，提炼共性，形成最佳实践。

这个阶段，我们发现，有别于那些网上随处可见的所谓的 Vibe 编程场景（用对话的形式直接做一些独立应用或小游戏等），在真实的业务需求开发场景里，想用好 AI 编程工具提升效率，有 2 个非常大的门槛：

• AI 编程工具不“懂”业务和系统：我们发现一个规律，无论用多好的代码大模型和 AI 编程工具，“通用的工具只能达到通用的效果”。因为它们不理解公司内大量的业务概念、存量系统、编程规范等这些知识，所以，只能做一些普通的代码续写、函数级的代码生成，但很快就会到瓶颈。如果想进一步提升 AI 代码生成的效果，必须想办法让 AI 编程工具从一个“擅长编程但不懂快手开发场景的临时工”进化为一个“熟悉快手业务的开发工程师”。

• 人和 AI 协同需要掌握新的开发方法：相比传统编程方法，目前已经发展出了一套 AI 辅助编程的新方法。如果开发工程师仅使用 AI 编程工具，却未掌握对应的技巧，不仅不能提效，还可能会降效，比如出现很多“AI 乱改业务代码”、“AI 生成后还要自己删除”等各种不符合预期的情况。

为了降低门槛，在这个阶段我们做了 2 项工作：

升级 AI 编程工具

上图是优化后的 Kwaipilot 的产品矩阵，都解决了哪些问题呢？一张表可以概览出来：

沉淀并推广「AI 辅助编码」最佳实践

我们将大量“AI 开发标杆”个人的共性实践沉淀成了一份标准的指南和实战课程，让所有开发工程师，通过学习指南和课程，可以完整的掌握所有关键技巧。

既然已经验证了 AI 编码对效率提升的有效性，且已经有了固定的工具、方法、实战课程，接下来就是如何把这些习惯固化在组织的日常工作中，让所有研发人员大范围的升级开发技能。我们主要用了 3 个措施：

• 增量人员：强化入职培训，从源头培养 AI-Native 开发者。

• 存量人员：牵引 AI 在团队、研发流程、个人工作中渗透。

• 文化影响：通过活动运营、奖励机制激发更多同学拥抱 AI。主要是一些自下而上能让更多一线研发被看见。

持续的推广，在编码场景上，80%+ 的开发人员都开始用 AI 辅助编码，如下图所示，可以看到 AI 代码生成率每月线上增长。

同时，在非编码场景中，我们在研发流程中建设的单点 Agent 能力也开始在研发平台中陆续透出，用 AI 能力辅助部分研发活动提效。

最终，我们对研发各阶段的 AI 提效情况，做个一个完整的评估：

最后顺便提一下，众所周知，目前大家在业界看到的“代码生成率”指标，包括各大厂披露的、AI 编程工具自己度量，基本都是不置信的，要么只统计了编程工具里的生成的代码和提交的代码作为分子分母，要么是在分母上做了一些限定（比如某些场景下不纳入分母统计）。但因为我们会用这个指标作为公司级 AI 编码推广的目标，因此对度量的精度和置信度要求非常高，一路“踩坑”过来后，最终使用了最严格的度量方法：

• 分母：新增代码行，统计公司内所有最终入库的 Commit 中的代码行。

• 分子：将分母的每一行代码，和 AI 生成的代码进行比对，如果编辑距离<50%（相似度高），则纳入统计。

这套实现无法在 AI 编程工具端实现，需要由公司内部的代码平台、AI 编程工具一起提供数据，并在离线数据层进行精确的计算，计算分母中每一行新增的代码和分子中 AI 生成代码的编辑距离，符合要求才能被统计为分子。

经过 1 年多的努力，从数据上看，研发各环节效率都在提升，尤其是编码环节提升很大。在 AI 热潮下，我们也看到很多开发人员、团队 Leader 都在分享自己效率提升数据和案例，按道理来说，公司整体的研发效能应该提升了吧？我们从全局视角，分析了一个核心业务线的客观研发数据，结果发现了非常反直觉、令人困惑的情况：AI 代码生成率持续在增长，但需求交付效率基本不变。

为什么呢？我们做了深入的调研，排除了少量个例，观察总结了大多数普遍使用“AI 辅助编码”的开发人员的用法和客观研发数据，发现在真实业务交付场景中，只用“AI 辅助编码”这种开发方法，对需求的开发周期影响非常有限。主要原因如下：

洞察

不过调研中也有额外收获，我们发现在真实的业务需求开发中，已经存在着 3 种不同的开发方法，对效率提升的程度有着根本性的差异。如上图所示。我们把三种开发方法总结出来做了一个定义：

• AI 辅助编码：在标准开发流程的基础上，在编码环节，依托 AI 编码工具，使用各种 AI 生成代码的技巧，提升编码效率。如果熟练掌握，可以缩短一部分编码时间，但如上文中的调研归因，由于只是节省了碎片化的编码时间，联通、测试、需求评估等不变，因此对整体的开发任务缩短帮助不大。

• AI 辅助开发：在研发全流程的各环节均使用 AI 辅助的方式，提升整体开发效率。需要由人把需求拆分为多个开发任务，不同开发任务调用不能的 AI 能力来完成，再由人来审核和优化产出物。由于从技术设计到编码到测试等各环节都可以节省时间，因此加总起来后，可以将研发任务的开发周期缩短 30% 左右。

• AI 协同开发：在某些需求开发中，通过完全用自然语言和 AI 交互的方式（类似业界比较流程的说法 Spec/Vibe 开发）完成需求交付，提升需求端到端交付效率，需求整体的开发周期可以缩短 40% 左右。

举个例子说明，会更容易理解三种开发方法对效能提升程度的影响。例如 1 个需求分解出 2 个开发任务，1 个前端、1 个后端，其中前端工程师接到开发任务，正常评估从设计、开发、测试、合入主干需要 5 天，其中编码 1 天：

• 如果用「AI 辅助编码」，他自己的评估还是 5 天，只不过相比以前，可以节约一部分时间做一些杂事，但到不了可以接更多开发任务的程度。

• 如果用「AI 辅助开发」，他可以整体节约 1.5 天，只用 3.5 天就可以完成。但需求整体能不能快，还需要看另一个接任务的同学，以及对应的联调、集成测试、发布的周期。

• 如果用「AI 协同开发」，首先必须改变协同模式，比如 2 个人均使用这种模式开发或者 1 个人全栈的做，假设 1 个人全栈独立做要 10 天，且不需要和别人集成 & 验证，开发周期可以缩短到 6 天左右。

有了 3 种开发方法的定义，我们就能很容易的评估出理想和现实间的差距，我们取了 1 个业务线 3 个月所有已交付的需求进行分析，发现 50%-70% 的需求，在不改变原有开发流程、规范、人员协同模式的情况下，可以使用提效幅度更大的「AI 辅助开发」模式。此外，还有 2%-10% 的需求，可以更激进的使用「AI 协同开发」。但实际情况上，团队里只有不到 10% 的人在使用「AI 辅助开发」或「AI 协同开发」开发方法，有对 AI 开发特别感兴趣的校招生，也有积极拥抱 AI 喜欢自己探索的资深开发者，但由于人数过少，对团队整体研发模式的变化无法起到带动的作用。

上面一个阶段，我们称之为“智能化 1.0”阶段，即以编码场景的 AICoding 为中心提效，并逐步辐射非编码场景的 AI 提效。但主要瓶颈就在于开篇提到的 AI 研发提效陷阱：用 AI 开发工具 ≠ 个人提效 ≠ 组织提效。

在智能化 1.0 阶段最大的收益是什么呢？大部分研发人员都开始主动使用 AI 开发工具了，同时，找到了个人提效的最佳实践。但接下来才是深水区，我们需要回归效能提升的元问题：“如何用 AI 提升需求端到端交付效率？”。

经过充分的复盘、洞察和验证，我们找到了新的可行的路径，并重新设计了解决方案，我们称之为“AI 研发范式”，它的实践体系框架，如下图所示：

我们根据需求交付中 AI 的参与程度，定义了“需求 AI 研发成熟度”，将需求划分为 3 个等级 L1、L2、L3，不同等级的需求，需要使用对应的开发方法。不同开发方法，对底层研发工具的 AI 能力也有不同程度的依赖。用一张表对上图做一下解读：

注明：当前快手整体所处阶段为 L2，2026 年年度目标为 L2&L3 需求占比达到 80% 以上。其中，依赖研发平台在研发流程中各环节提供 AI 能力，AI 能力根据不同的应用成熟度分为 M1-M4，当前图中为 2025 年 12 月现状，2026 年会将 M2 级（已在一定范围内验证成功）能力全部达到 M3，从而支撑总目标的达成。

具体实施上整体有 3 步：

解决的问题：

• 能支持多种研发模式：不同 AI 研发成熟度的需求，它们的交付流程都是一样的，差异点在于开发方法。因此我们无法为不同的需求、不同的开发方法匹配不同的平台，而是要思考如何用一套平台，来支撑多种开发方法：完全不使用 AI 的标准开发流程、只用 AI 辅助编码的开发流程、更激进的使用 AI 辅助开发或协同开发的开发流程，都应该在同一个平台上完成。这样，我们的需求交付效率，才可以随着人的能力的提升、AI 能力的提升，持续变快。

• 产品形态可进化：产品形态随主要研发模式的变化持续演化，从人主导最终变为由 AI 主导；能与传统平台协同进化。

• AI 效果可进化：能随大模型的升级、Agent 技术的升级、企业 / 个人知识的丰富，持续提升 AI 效果。

解决方案：建设下一代智能研发平台

如上图所示，有 4 个关键点：

下面重点介绍下为了支撑组织级研发范式跃迁，Flow 这种子产品形态的独特优势。

• 从需求交付视角看：同一个需求，开发者可以结合自身对 AI 的理解和开发技能的掌握，在同一种产品形态上选择不同开发方法。

• 标准开发 / AI 辅助编码：工作流中所有节点，完全由人工来完成和推进。其中“编码”节点会跳转到 IDE 中，可以用 AI 辅助编码。对用户而言，收益相对来说最小，和原来相比，由于 Flow 的每个节点内嵌或自动兼容了各工具平台的功能，因此仅节约了用户平台跳转的切换与学习成本。用这种模式交付的需求，会被度量为 L0/L1 级需求（AI 辅助（Copilot））。

• AI 辅助开发 /AI 协同开发：工作流中多个关键节点均有 AI 完成，人进行结果审查。多个节点之间的上下文可以有效传递，比如 AI 完成需求分析、技术设计后，产出的 AI 友好结构化文档可以自动传递到 AI 编码节点，以提升代码生成的准确性。有些节点暂时无法由 AI 完成的，比如“提测”节点，仍然由人来操作。用这种模式交付的需求，会被度量为 L2 级需求（AI 协同（Agent））。

• AI 自主开发：部分需求可以实现全流程 AI 完成，人只需要在需求上线前或上线后进行审核。这种模式下，整个 Flow 是全自动运行的不需要人工参与。用这种模式交付的需求，会被度量为 L3 级需求（AI 自主（Agentic））。

• 从开发者视角看：整个过程依然非常丝滑和简洁，下图是一个需求交付中 Flow 的整个工作过程，大家可以感受一下：

支撑「AI 研发模式」的方法和平台都有了，这个阶段的关键是如何把这些作用在团队日常交付的需求上。我们分 3 个层面落地：

个人级实践：导入「AI 辅助开发 / AI 协同开发」开发方法，并树立标杆

首先人的开发方法要变化。我们重复了第一阶段“优化”与“固化”的实践，让大部分研发人员从“AI 辅助编码”的方法升级成“AI 辅助开发”，让小部分专业能力更强的人员，选修“AI 协同开发”方法。我们同样通过实战课程、典型案例、人员培训等手段，对人的开发方法进行升级。

当然，即使这样，从数据上看，个人用 AI 提效的效果还是存在两极分化的情况。我们对 2025 年 6 月 -12 月的数据进行了分析得到如下结论：

实践 1：Top-Down，战略驱动

• 明确战略导向：主站技术部提出了“AI First”的战略思想，鼓励全体员工开展工作之初，优先将 AI 作为核心驱动力，加速技术创新、优化业务流程、深度融合 AI 技术，为产品与服务注入新活力和新可能性。

• 发布白皮书：将战略导向具象化为思考、方法与规划，为全员提供明确指引。

• 成立重点项目：在研发领域，成立了 AI DevOps 项目，统一设计解决方案并推广实施。

实践 2：AI x 效能实践

• Step1：将需求分级，按需求 AI 研发成熟度定义：

• L1 AI 辅助（Copilot）：人主导，AI 主要在编码环节提供辅助。

• L2 AI 协同（Agent）：人和 AI 更深度的协同完成需求开发，在研发全过程中，更深度分解任务给 AI 完成，人进行修改、调整、确认。

• L3 AI 自主（Agentic）：人类似产品经理，把需求澄清清楚并交给 AI 来完成，并进行最后的验收。

• Step2：分级实施

• 让所有需求达到 L1 级（AI 辅助，Copilot）：推广个人级实践，依托 Kwaipilot 工具实现全员掌握，最终覆盖所有需求。

• 让大部分需求能持续升级到 L2 级（AI 协同，Agent）：开展团队级实践，从试点到推全，重塑流程、分工。

• 小部分需求探索能达到 L3 级（AI 自主，Agentic）：圈选出颗粒度小且独立的需求，构建全技术栈 / 职能端到端交付链路，通过全栈、跨栈，减少协作节点，进而形成效率跃迁，最终达成 AI 自主交付。

• Step3：项目化推进

• 成立组织级重点项目，Top-Down 实施。

实践 3：AI x 效能平台。基于需求全流程构建 AI 能力，逐一“点亮”能力并规模推广落地：

• 构建 AIDevOps 能力矩阵与建设路线图：基于研发效能白盒化，分析交付流程中各原子环节的人力投入比重、AI 能力建设 ROI，形成决策建设哪些 AI 原子能力。

• AI 原子能力建设：与研发线共建交付流程环节内的 AI 原子能力 20+，研发流程环节覆盖超过 60%，从需求准备到发布运维各环节。

实践 4：AI x 效能度量：建设 AI 研发成熟度模型，可将需求分级度量（L1、L2、L3 级需求占比），牵引各级实践落地。

经过 1 年多的项目实施，最终探索出了一条组织级的 AI 研发范式升级路线，从数据上也能看出明显的变化：

最后在效能度量上一样也需要升级，基于效能实践的探索，我们配套建立了「需求 AI 研发成熟度」模型（如下图所示），用于度量一个需求在研发过程中的 AI 使用程度，这样我们就可以按 L2&L3 级需求的比例，来牵引实践过程，也可以专门度量 L2&L3 级需求的交付周期的变化，来印证提效结果。

再回到全局视角，从数据上看，如果只看“AI 代码生成率”指标，可以明显看到 2025 年 6-11 月出现了一个大幅提升。实际上，在智能化 1.0 阶段，这个指标达到 24%+ 基本已经是极限了，当我们开始实施智能化 2.0 后，才开始进一步拉升。

当然，我们在内部的数据观测上，其实已经不再看“AI 代码生成率”指标了，它只是一个单点的过程指标，片面且孤立。我们现在有了更直接的度量指标。从过程上，我们观测多少需求被采用全流程 AI 研发模式交付，从结果上，我们直接观察需求的交付效率变化。

• L1、L2、L3 级需求占比：有多少需求的 AI 研发程度可以达到 L1、L2、L3 的阶段。

最后也总结下我们一年来的实践心得，目前看完全印证了《2025 年 DORA 报告：人工智能辅助软件开发现状调查报告》中的洞察：

“从 DevOps 到 AI 辅助开发：AI 是“透视镜”与“放大器”

• AI 是“透视镜”

• 在协同良好的组织中（如流程清晰、数据打通的团队），AI 能使 DevOps 效能再提升 25%。

• 在架构松散的组织中，AI 会暴露流程断点、数据孤岛等隐性痛点。

• AI 是 “放大器”

• 如同亚马逊通过微服务转型释放 DevOps 价值，AI 辅助开发也需重新设计工作流程（如 “AI 提案 — 人类决策” 闭环）、角色分工（如专职提示工程师）与治理机制（如 AI 代码审查标准），否则无法释放真正价值。

对于大型组织的研发效能提升，AI 不是“万能药”，而是“透视镜”和“放大器”，它不会自动修复组织问题，而是先把组织历史积累的长板和短板一并透视出来，再全部放大。幸运的是快手的研发效能实践一直保持客观、务实的风格，先把地基打稳（平台化 / 数字化 / 精益化），再通过在研发各环节建立 AI 提效能力，先一边落地一边充分验证对个体的提效情况，再体系化的推进组织级 AI 研发范式升级。最终发现，AI 在传统研发效能基建的基础上，像放大器一样增幅了每个环节，为组织带来研发范式级的跃迁。

如下图所示，我们基于张乐老师的“研发效能黄金三角”框架之上做了升级，能更清晰的表达出快手的实践框架：

最后，再把镜头拉远，回到宏观视角看——2025 年我们所做的种种努力，不过是这场 AI 变革的开端。由 AI 驱动的生产力跃升和生产关系重塑，正在重新定义软件开发的每一个环节。这不是一场短跑，而是一场马拉松，不是一次技术升级，而是一次范式革命。

快手已经在这条路上积累了宝贵的经验，但真正的挑战和机遇还在前方。未来已来，一起共同探索 AI x 研发效能的无限可能吧！

• 快手研发效能中心：秦巍（研发效能解决方案 & 智能工具产品负责人）

• 快手主站技术部：胡伟（主站 AIDevOps 项目负责人）、马坤（主站研发效能项目负责人）

感谢快手研发效能中心与快手主站技术部的授权，使我们有机会系统梳理并总结快手在过去三年中的实践经验。

快手向来崇尚“行胜于言”的实干精神，也因此我们往往专注于行动，而疏于对外分享。然而，过去一年间 AI 技术的迅猛发展，正深刻改变着研发效能领域的格局。在与行业同行的交流中，我们既看到层出不穷的创新探索，也注意到在实践、方法与工具建设方面仍存在不少共性问题。这些问题若不及早重视，很可能导致未来大量返工与资源浪费，甚至偏离客观规律，影响企业研发效能提升的既定路径。

为此，我们决定把我们的探索与实践经验分享出来——无论是曾经踏过的“坑”，还是有幸跨过的“河”，都希望能为企业与同行们在“AI × 研发效能”的探索中，降低试错成本，注入更多成功可能。

当然，快手的 AI 研发范式升级仍在沿着这条路径演进中：L1 AI 辅助（Copilot）→ L2 AI 协同（Agent）→ L3 AI 自主（Agentic）。目前，我们的研发效能体系已经初步完成 AI 化升级，全景图如下图所示：

2026 年正在探索 L2 → L3 的跃迁路径，我们将定期梳理实践经验，持续向业界输出更多有价值的内容，主要包括：

• 实践与技术：欢迎关注「快手技术」公众号。我们将持续分享具体实操方法与技术解析，例如：个人、团队乃至业务线如何借助 AI 提升效能？有哪些落地案例？研发各环节 Agent 的核心技术及调优方法有哪些？等等。

• 平台与工具：我们将智能化 1.0 阶段沉淀的产品 Kwaipilot 进行了全面升级与开放，它在快手内部历经数千名研发同学的反馈与打磨，已完成三代演进：Code Copilot → Code Agent → Multi-Agent & Agentic Coding，目前已在海外发布，产品名为 CodeFlicker，希望服务全球开发者，也欢迎国内同行下载体验（https://www.codeflicker.ai/）。后续，我们还会持续把快手在智能化 2.0 阶段的探索成果融入 CodeFlicker，希望让更多企业级开发者受益。