快手：万人组织AI研发范式跃迁之路

主要难点

• 用一套产品设计尽量满足多样化的研发场景：工具一边建设一边落地，且需兼容之前散乱各种不同的研发模式和习惯。
• 服务端（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+人次的用户激励，提升用户对产品的接受度。

Case1:通过「研发活动在线化率」分析，深挖出架构不合理问题

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

• 反馈1：新需求开发时，上手门槛特别高，很多需求会涉及到多个模块开发，这会涉及到自己不熟悉的模块，因为架构分层结构不合理，模块耦合度太高，往往需要花大量的时间去熟悉其他模块的代码，最近做了一个新需求，评估是3天的工作量，2天都在看代码，实际的开发联调只有1天。
• 反馈2：模块边界不清晰，代码杂糅一起，新需求的代码，可能会影响到已有功能，导致旧功能的BUG，而且这些BUG在回测时，不容易被发现，导致问题漏测逃逸到线上。

Case2：通过「需求积压率」分析，驱动业务优化需求评审流程和节奏

• 这些被积压的需求，一个月之后，会不会进入排期开发？如果之后会排期开发，说明需求本身的价值还可以，当下是否可以协调资源加快交付？能否可以停掉某些技术需求优先业务交付？是否可以短期加班临时突击？
• 如果后面不会进入排期，是不是这些需求本身的重要性没那么高？在预评审的时候，是不是可以控制需求的优先级？当前的需求评审流程是否可以优化？

• 升级研发模式：通过动态化、配置化等研发模式，让部分需求可以更快速交付。
• 研发过程提效：通过API在线化管理，测试环境稳定性治理、流水线优化、发布优化等措施，降低研发协作成本以及低价值工作占比。
• 管理与协同提效：通过效能洞察，持续识别团队协作瓶颈，并通过排期优化、测试无人值守、人力调配等措施，支撑需求可顺畅流动。
  
  

阶段2：智能化1.0（2024年6月-2025年6月）

从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编程工具，“通用的工具只能达到通用的效果”。因为它们不理解公司内大量的业务概念、存量系统、编程规范等这些知识，所以，只能做一些普通的代码续写、函数级的代码生成，但很快就会到瓶颈。如果想进一步提升AI代码生成的效果，必须想办法让AI编程工具从一个“擅长编程但不懂快手开发场景的临时工”进化为一个“熟悉快手业务的开发工程师”。
• 人和AI协同需要掌握新的开发方法：相比传统编程方法，目前已经发展出了一套AI辅助编程的新方法。如果开发工程师仅使用AI编程工具，却未掌握对应的技巧，不仅不能提效，还可能会降效，比如出现很多“AI乱改业务代码”、“AI生成后还要自己删除”等各种不符合预期的情况。

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

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

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

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

通过挑战赛，让一线研发同学感受AI编程的高效和快乐

通过数据自动识别AI开发高手

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

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

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

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

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

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

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

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

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

阶段3：智能化2.0（2025年7月至今）

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

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

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

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

具体实施上整体有3步：

Step1，AI x 效能平台：建设能同时支持多种研发模式、可自进化的智能研发平台

解决的问题：

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

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

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

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

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

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

1. 从需求交付视角看：同一个需求，开发者可以结合自身对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））。

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

Step2，AI x 效能实践：以需求为中心，导入「AI研发模式」，实现需求端到端提效

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

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

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

  

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

  

  
  

• 团队级实践：导入「AI研发模式」，重塑流程、分工，提升所有需求的交付效率

  通过管理导向、各种活动的形式，鼓励团队Leader主动带领团队进行探索，最终沉淀出了一套适合团队的核心实践：

  

  经过大量的验证，我们的标杆团队（<50人规模）无论在AI转型后的业务感知上，还是客观数据上，均能达到比较优秀的水平，见下表：

  

  
  

• 业务线级实践：大规模研发团队，系统性升级AI研发范式，带来效能提升

  以主站技术部为例，从2023年到2025年，从平台化到数字化再到精益化，2025年开始步入深水区，2个新挑战浮出水面：

  1. 传统的流程、工具优化手段带来的提效收益，边际效应持续减小。

  2. 业务的规模与复杂度持续提升。

  
  

  因此开始探索能否把握AI爆发的机遇，把传统研发流程升级到“AI研发范式”，进而打开组织级效能跃升的新空间。核心实践：
  

• 实践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代码生成率”指标，可以明显看到2025年6-11月出现了一个大幅提升。实际上，在智能化1.0阶段，这个指标达到24%+基本已经是极限了，当我们开始实施智能化2.0后，才开始进一步拉升。

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

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