AI 代码生成率 30%，交付周期纹丝不动 - 快手万人团队踩过的坑和找到的路
快手技术团队最近发了一篇万字长文，复盘他们 10000+ 研发人员在 AI 研发提效上的三年探索。文章信息密度很高，我将其中PR话术剥掉之后，发现里面藏着几个对整个行业都有参考价值的硬核洞察。
这篇文章要说的核心问题只有一个：你的团队用上了 AI，为什么交付还是那么慢？
一个反直觉的不等式
先说快手披露的那组数据。
在最严格的度量口径下（把 AI 生成并最终入库的代码行和所有新增代码行做比对，编辑距离小于 50% 才算），他们的 AI 代码生成率从 1% 爬到了 30%+，部分业务线甚至到了 40%+。通过内部调研，开发人员主观感觉编码效率提升了 20-40%。
数字看着挺好。但当他们从全局视角，分析了核心业务线的客观研发数据后，发现了一个令人困惑的事实：
AI 代码生成率持续增长，但需求交付效率基本不变。
翻译成大白话：程序员觉得自己写代码确实快了，但从老板视角看，需求该多久交付，还是多久交付。团队的吞吐量和交付周期，纹丝不动。
这不是快手一家的问题。2025 年的 DORA 报告（Google 出品的全球研发效能调查报告）里也指出了同一个现象：各企业普遍对 AI 提升个人效能有信心，但对团队效能的提升预估非常低。
快手把这个发现总结成了一个不等式：用 AI 开发工具 ≠ 个人提效 ≠ 组织提效。
碎片化时间陷阱：省下来的 10 分钟去哪了？
为什么个人提效无法传导到组织提效？快手做了深入调研后归纳了几个原因，我觉得其中两个最值得展开。
第一个：碎片化时间陷阱。
AI 帮程序员省下的时间是什么样的？是”写那个函数”的 5 分钟、”改那个 bug”的 10 分钟。这些时间碎片散落在一天的工作里。如果没有被刻意重新组织，它们不会自动汇聚成”多做一个需求”的整块时间。实际情况是，大部分工程师并没有因此接纳更多需求——省下的碎片被会议、等待联调、等待 code review 这些事情填满了。
这让我想到之前写过的一个观察：GitHub 的一份开发者调研显示，开发者花在等待构建（build）和等待 code review 上的时间，和写新代码的时间差不多。AI 加速了”写”，但”等”的部分原封不动。
第二个：木桶效应。
软件交付是一条流水线：需求评审 → 技术设计 → 编码 → 联调 → 测试 → 发布。编码只是其中一环，而且在很多团队里，编码环节的耗时可能只占总交付周期的 20-30%。AI 让这一环变快了，但联调要等其他端的同学，测试要排队，发布有窗口期。短板没变，整条线就快不起来。
快手的调研数据很直白：一个原本评估 5 天的开发任务，其中编码 1 天。用了 AI 辅助编码后，评估还是 5 天，只不过编码那天轻松了一些。
AI 是放大器，不是万能药
这里要提快手做对的一件事：他们没有在 2023 年直接上 AI 工具，而是先花了一年多时间做了三件”不性感”的基建工作：平台化、数字化、精益化。
具体来说：
- 平台化：建设三端（服务端/前端/客户端）一站式研发平台，把分散在各处的开发活动统一到标准流程上。一个月内推全了 1000+ 人的团队（效率确实猛）。
- 数字化：建立效能度量体系，以”人均交付产品需求数”为北极星指标。注意这里的衡量单位是交付的产品需求，不是代码量，也不是 commit 数。
- 精益化：通过数据识别瓶颈，对症下药。比如他们分析一个团队的”研发活动在线化率”，发现产品需求投入占比只有 59%，深挖下去发现根因是客户端架构劣化，缺陷和 oncall 消耗了大量产能。最终解法是做架构升级，和 AI 一点关系没有。
快手自己在总结里引用了 DORA 报告的一句话，我觉得很准确：
AI 是”透视镜”与”放大器”。在协同良好的组织中，AI 能使效能再提升 25%；在架构松散的组织中，AI 会暴露流程断点和数据孤岛。
说白了：你家流程本来就乱，AI 不会帮你理顺，只会让乱象更加显眼。 指望”买个 AI 工具就能提效”的管理者，大概率会失望。
之前写过的哈佛-宝洁联合实验也佐证了类似的观点：单独使用 AI 的个人，解决方案质量居然和不使用 AI 的团队相当。AI 提升的是个人能力的上限，但要在组织层面产生效果，需要重新设计协作方式。
从 Copilot 到 Agent：三级跳框架
这是快手这篇文章里我认为最有价值的部分。他们从实际业务中观察到三种 AI 开发方法，对效能的影响截然不同。
L1：AI 辅助编码（Copilot 模式）
大部分人目前的用法。在 IDE 里用 Cursor、Copilot、Claude Code 做代码补全、函数生成、问答。效果：编码效率提升 10-20%，但对需求整体交付周期影响有限。原因前面说过了：碎片化时间 + 木桶效应。
L2：AI 辅助开发（Agent 模式）
不止是编码环节用 AI，而是在研发全流程都让 AI 参与：需求分析、技术设计、编码、测试。人把需求拆分为多个任务，不同任务调用不同的 AI 能力完成，人负责审核和优化。由于全链路都在提速，效果叠加后，开发周期可以缩短约 30%。
L3：AI 协同开发（Agentic 模式）
最激进的模式：人变身 PM，把需求用自然语言描述清楚交给 AI，AI 端到端完成从设计到编码到测试。Karpathy 那个“Vibe Coding”的概念就属于这个范畴，不过快手在实践中发现，Vibe Coding 那些网上随处可见的”AI 做个小游戏”的场景和真实业务交付差距极大。真要在业务需求上用这种模式，前提是需求颗粒度够小、够独立，而且工程师本身能力要足够强（能全栈，能判断 AI 输出质量）。效果：开发周期缩短约 40%。
快手用了一个具体的例子来说明三者的差异。假设一个需求拆出 2 个开发任务（前端 + 后端），其中前端正常评估 5 天，编码 1 天：
- L1 模式：评估还是 5 天，只是编码那天轻松点，省下的时间做做杂事。
- L2 模式：从设计到编码到测试全面提速，可以 3.5 天完成。但整体快不快，还要看后端同学的进度和联调安排。
- L3 模式：改变协作方式，比如 1 个人全栈做（原本要 10 天），不需要和别人集成验证，用 AI 协同后可以压到 6 天。
关键洞察在这里：从 L1 到 L2 到 L3，变化的不是工具，而是人机协作的方式和组织协同的流程。
快手分析了某个业务线三个月的已交付需求后发现：50-70% 的需求在不改变原有流程的情况下，就可以升级到 L2 模式；另有 2-10% 可以探索 L3。但现实中，只有不到 10% 的人在使用 L2 或 L3。
潜力巨大，执行率极低。这大概也是很多团队的现状。
度量的真话：别被虚荣指标骗了
快手在文章里说了一句狠话：业界看到的”代码生成率”指标，基本都是不置信的。
为什么？因为大多数 AI 编程工具自己报的数字，要么只统计工具内部的生成和提交，要么在分母上做了限定条件。这就像一个考试只考自己擅长的科目，然后宣布自己考了满分。
快手的做法是业内我见过最严格的：
- 分母：公司内所有最终入库的 commit 里的新增代码行，全量，无例外。
- 分子：把分母中每一行代码和 AI 曾经生成的代码做比对，编辑距离 < 50%（相似度高）才算 AI 贡献。
- 实现方式：不在 AI 工具端统计，而是由代码平台 + AI 工具联合提供数据，在离线数据层做精确计算。
这种度量方式没法作弊，但成本也高，需要企业有统一的代码平台和数据基建作为前提。
而且，快手到了后期已经不再把”AI 代码生成率”当核心指标了。他们转向了两个更直接的指标：
- L1/L2/L3 级需求占比：有多少需求在用全流程 AI 模式交付
- 需求交付周期变化：端到端的交付时间到底缩短了没有
数据显示，最先完成 AI 范式转型的标杆团队，L2&L3 级需求占比达到 20.34% 时，需求交付周期下降了 58%。两个指标呈现明显正相关。
这说明什么？看点”代码生成率”做做汇报可以，真想提效就得看需求端到端的交付周期。
三条行动建议
从快手三年的探索中，我提炼三条对大多数团队都适用的建议：
1. 先体检，再上 AI。
如果你的团队连研发流程都没标准化、度量体系都没建立，先别急着买 AI 工具的企业版。AI 只会让混乱变得更快、更贵。先把数字化基建做好，AI 的效果才能叠加上去。
2. 目标是”用 AI 改变工作方式”，而非”用 AI 写更多代码”。
从 L1（AI 辅助编码）到 L2（AI 辅助开发）的跃迁，关键在于让 AI 参与需求分析、技术设计、测试等全链路，而不仅仅是加速编码。这需要制定新的实践标准，做培训，树标杆，甚至重新设计团队的协作模式。
3. 度量要诚实。
不要用 AI 工具自带的”采纳率”自欺欺人。如果你真想知道 AI 有没有帮到你的团队，去看需求交付周期、人均需求吞吐量这些端到端的指标。过程指标可以参考，但别当成目标。
AI 研发提效不是一个购买决策，是一场组织变革。工具可以买来，但人的工作方式、团队的协作流程、管理者的度量思维，这些都需要一起变。快手用了三年、一万人的规模踩了这条路，至少证明了一件事：路径是存在的，但捷径是不存在的。