编程语言AI算法
从 Copilot 到 Agentic：快手重构“人×AI×流程”研发范式实践
基于快手万人研发组织的真实实践，探讨了从 AI 代码生成工具到组织级 AI 研发范式的演进路径。文章指出仅推广 AI 工具无法保证组织效能提升，提出了 L1/L2/L3 分级交付体系与端到端效能度量方案。通过重构人、AI、流程的关系，实现了需求交付周期压缩与人均交付增长，为行业规模化落地 AI 研发提供了参照。
基于快手万人研发组织的真实实践，探讨了从 AI 代码生成工具到组织级 AI 研发范式的演进路径。文章指出仅推广 AI 工具无法保证组织效能提升，提出了 L1/L2/L3 分级交付体系与端到端效能度量方案。通过重构人、AI、流程的关系，实现了需求交付周期压缩与人均交付增长，为行业规模化落地 AI 研发提供了参照。
早在 2024 年，快手就建设了 AI 编程工具 Kwaipilot，并发布给公司内 10000+ 研发人员使用。经过持续的深度优化和推广，快手整体的 AI 代码生成率，在严格度量口径下（AI 生成并入库的代码行/新增代码行）从 1% 达到了 30%+，甚至部分业务线达到了 40%+。同时，在非编码环节，也衍生出了很多 AI 提效工具，比如智能 CR（CodeReview）、智能测试用例生成、智能单元测试等等，但经过大量的调研和数据分析，我们发现了这个不等式：
'用 AI 开发工具 ≠ 个人提效 ≠ 组织提效'
如果以企业的研发效能提升为目标，我们发现：
● **对研发工程师而言：**深度使用 AI 开发工具，代码生成率很高，个人主观体感上编码效率提升了 20-40%，但并不代表真正的'个人提效'，因为在现实中，大部分工程师并没有接纳更多的需求，个人需求的交付数没有显著提升。
● **对大型组织而言：**我们发现部分 AI 用的好的工程师，确实可以更快更多的完成开发任务，但组织整体的需求吞吐量没有明显提升，需求交付周期也没有明显缩短。
从《2025 年 DORA 报告：人工智能辅助软件开发现状调查报告》中能看到，这也是业界普遍存在的问题。如报告中所述，在对 AI 提效的结果的预估上，各企业普遍对个人效能的提升有信心，而对团队效能的提升预估非常小。
快手有 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 个多月。
1.精准的解决方案设计：
● 服务端（KDev 平台）：精准的打造了 4 套标准研发模式，适配了主站实际研发情况。
● 客户端（Keep 平台）：一套平台底层能力，支撑 3 种移动研发场景；通过可配置与定制化能力，满足不同团队流程规范与管理诉求（自动翻转配置、流程与质量卡点配置、团队定制化模板）。
● 前端（KFC 平台）：支持 80% 以上前端应用类型，并通过 8 个流程模板、适配 5 个内部自建的插件，兼顾了前端差异化研发流程和用户习惯。
**2.以用户满意为导向：**提供完整的迁移配套服务，降低用户迁移成本。主要包括：
● **产品质量专项：**用户 BUG 日结。
● **用户体验专项：**持续深度用户访谈，识别体验问题，并优化。5 周内，交付了 73 个功能&体验需求。
○ **用户培训与激励：**通过 12 次培训，50+ 线下访谈，7x24 小时 OnCall、200+ 人次的用户激励，提升用户对产品的接受度。
**1.数据驱动团队级推广：**每周度量进度，驱动各部门接口人推广。
可能大家会有疑惑，为什么三端分别是 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 个技术专项：
1.客户端的架构升级：从根本上解决因为架构问题带来的交付效率低和交付质量差的问题。
2.体验优化：集中优化重点场景的体验问题。
随着这两个专项的落地上线，这个团队的效能数据已经有所改善，产品需求投入占比已经提升到 64%，体验优化占比下降到 6%。
上图是主站技术部下级各团队的需求积压率数据，有些团队的需求积压率持续保持在 80% 以上，意味着需要近一个月的时间才能消化这些积压的需求。这种情况可能存在的问题：
● 这些被积压的需求，一个月之后，会不会进入排期开发？如果之后会排期开发，说明需求本身的价值还可以，当下是否可以协调资源加快交付？能否可以停掉某些技术需求优先业务交付？是否可以短期加班临时突击？
● 如果后面不会进入排期，是不是这些需求本身的重要性没那么高？在预评审的时候，是不是可以控制需求的优先级？当前的需求评审流程是否可以优化？
经过一年时间的系统化提效，主站提效方面进展显著，人均交付产品需求数24 年 7 月份同比增长超过 80%。总结下来，主要有效的措施有：
● **升级研发模式：**通过动态化、配置化等研发模式，让部分需求可以更快速交付。
● **研发过程提效：**通过 API 在线化管理，测试环境稳定性治理、流水线优化、发布优化等措施，降低研发协作成本以及低价值工作占比。
● **管理与协同提效：**通过效能洞察，持续识别团队协作瓶颈，并通过排期优化、测试无人值守、人力调配等措施，支撑需求可顺畅流动。
从 2023 年 6 月开始，我们开始探索大模型在研效领域的应用，主要有 2 个方向：
1.**编码场景：**如何用 AI 辅助编码，提升代码生成效率。
2.**非编码场景：**在研发全流程里，哪些环节可以通过 AI 能力提升单点工作的效率。
其中，最重要的决策是我们决定自己研发一款 AI Coding 工具：Kwaipilot。它包含了大家见过的所有产品形态：
1.**IDE 插件 / AI IDE / CLI：**最符合开发人员习惯的几种形态，插件、IDE 可以做续写、问答、智能体代码生成，CLI 则可更灵活的开启代码生成任务。
2.**智能问答引擎：**有独立的 Web 页面，也会嵌入到上面的产品形态里，为开发人员提供灵活的问答能力。
业界有很多优秀的 AI Coding 产品，比如 Cursor、Claude Code、Krio、Windsurf、Antigravity，快手为什么不选择采购，而是自建呢？其实一年来，我们也一直带着这个疑问在探索，相当于一场大型的公司内部 AB 实验：
从用户体验的角度，我们希望大家'用脚投票'，选择好用的工具：
● 一方面，我们允许开发同学使用任何 AI Coding 产品，可以团队级采购也可以个人购买。
● 另一方面，我们研发了 Kwaipilot，对内推广。
从实际效果的角度，我们以
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online