文末领取PPT！
在 AI 深度渗透软件工程、个体效率与组织效能之间鸿沟日益凸显的背景下，快手主站千余名工程师支撑着日活数亿用户的核心产品，其 AI 原生转型正面临"换了引擎却未重构流水线"的系统性困境。
本文整理自 快手主站 AIDevops 负责人李思 在 GIAC 2026·深圳站的分享《迈向AI Native：技术团队的范式跃迁与组织进化》。
【演讲摘要】
89%的企业已把AI投入实际业务，但生产力提升只有0.29%。DORA 报告也显示，个体效能上去了，组织效能却没变。AI 到位了，研发体系还是老样子，必须围绕 AI 重新设计。
过去一年踩了不少坑。24年下年代码生成率从17%涨到30%，交付周期却没变。后来发现 只有不到10%的工程师真正变了，差异不在用不用 AI，而在有没有改变工作方式。快手把范式分成 L1 辅助、L2 协作、L3 自主，走两条路：L1 到 L2 铺开，L1 到 L3 特定场景突破。但 个人快了组织没快，AI 越快人和人协作摩擦越大，人机摩擦也成了新负担，根源在围绕人设计的结构卡住了 AI。
解法就是三层重构。信息层面让 AI 能拿到知识，流程层面从串行改成 Agentic 模式，组织层面交付和守护分开、产研边界溶解。后面直播礼物的案例就是三层重构的落地缩影——方向、分镜、生成、评审都由 Agent 做，人只定目标，上新周期从20天压到4天以内。目前 L2 已成主流范式，较 L1 周期缩短20%到30%。
往前看还有验证规模化和先锋队模式两个难题。但说到底，变革落在每一个人身上。知识能被看见，品味和判断却很难，组织得给这些看不见的价值一个位置。人人都在加速，也要给远见留空间。 AI 跳过了慢慢写的过程，更要给年轻人慢慢生长的机会。范式在变，组织在变，底色永远是每一个工程师。
【演讲实录】
过去一年多，我们一直在推进千人规模研发团队的 AI Native 转型，包括研发范式的升级，以及整个团队怎么做组织层面的进化。今天想和大家分享一下，快手主站目前在这个方向的进展、心路历程和一些具体的实践，主要分享如下三个部分：
第一部分是宏观判断——行业目前在哪里，以及我们为什么要做 AI Native ；第二个是千人级实践——过去一年多做了哪些事情，踩了哪些坑，以及具体的思路和解法；第三个是组织进化相关的思考—— AI 改变的不只是代码，也在改变我们的人和协作的方式，我们是怎么做组织协作的演进，以及人才画像相关的一些思考。这是一个"打怪升级"的演进过程。 一、行业在哪里：AI Native 的宏观判断
先看一组行业数据，NBER 今年对美英德澳四个国家的高管做了一个调查，发现89%的企业已经把 AI 投入到了实际业务，听起来占比非常高。但同时这份报告的另一个数字是：企业平均实际的生产力提升只有0.29%。高期待和低成效形成了一个非常鲜明的对比。右边这张图是《 DORA 2025 AI 辅助软件开发现状调查报告》，对 AI 在软件开发领域的影响提供了一个全景扫描，结论是个体效能提升非常显著，但组织的效能并没有太多变化。中间这条鸿沟，也是我今天想要分享的核心问题。
从历史层面看这个问题，可能不是今天才有的。19世纪末，随着从蒸汽机到电动机的技术成熟，美国的工厂纷纷把引擎换成了电动驱动，大家以为从此效率会飞涨，但经过了30年，生产力并没有什么起色。真正的转变发生在1920年代，企业这时不再是换引擎，而是从整个流水线、车间动线、生产系统进行了一次重组，这次重塑彻底带来了效率的质的飞跃。
今天，我们面对的也可能是同样的局面。我们给每个工程师装上了 AI 的伙伴或者工具，但底层的研发体系仍然是老样子——如果在这套体系上只是装上 AI，那我们可能也是在重复历史的故事。所以可以看到：智能已经领跑，范式正在重塑。我们需要的是 围绕 AI 重新设计研发体系和组织协作，这就是我们 AI Native 驾驭智能的进化之路。
二、千人级实践踩坑：个人提效 ≠ 组织提效
这些道理听起来都没错，但真正让我们理解它的，不是理论，而是一年多实践中踩过的每一个坑。
快手主站有一千多名工程师，在推进研发智能化的过程中，我们总结的坑是这两个不等式：第一，用 AI 开发工具不等于个人提效；并且，个人提效也不等于组织提效。
接下来分享下我们的故事，带入一下当时的情境。
24年下半年，我们从编码环节开始引入 AI。代码生成率从17%提升到了30%，各个研发环节的采纳率也都保持在较高水平。
看到这些数据时，大家都很兴奋，认为研发交付效率应该会明显提升。然而，当我们把整体效能数据拉出来分析时，却发现一个出乎意料的结果：整个研发交付周期几乎没有变化。换句话说，新功能真正触达用户的时间，并没有因为 AI 的引入而缩短。
更有意思的是，我们进一步做了一些局部分析，发现约90%的工程师几乎没有发生明显变化。
于是，我们找到了这不到 10% 的工程师，试图回答一个问题：他们到底是怎么工作的？
我们发现，真正的差异并不在于有没有使用AI工具，而在于有没有改变自己的工作方式。也就是说，他们是 怎么和 AI 一起工作。有人把 AI 当作辅助工具，在需要的时候提供帮助；也有人让 AI 优先完成大部分工作，再由人负责判断、修改和审查。
所以，真正的问题需要重新定义：并不是在推动 AI 工具的使用，而是如何推动研发范式的升级——让原本只发生在不到10%工程师身上的高效工作方式，沉淀为一套可复制、可推广的研发范式，并在整个组织中系统性地发生。
基于这些思考，去年上半年，我们开始尝试回答另一个问题：AI 时代的研发范式，到底应该是什么样的？
我们把它划分为三个阶段。
* L1 是 AI 辅助，AI 在部分环节提供信息；
* L2 是 AI 协作，AI 在部分工作单元提供初稿，人做完善；
* L3 更自主，AI 自主完成需求交付。
方向有了，接下来就是回答另一个问题：这条路应该怎么走？
最开始，我们的思路其实很朴素——所有场景都沿着同一条路径演进，从 L1 到 L2，再到 L3，循序渐进地完成研发范式升级。
但实践之后，我们发现，不同研发场景的演进条件并不相同。比如一些 B 端、从0到1的场景，任务边界清晰、风险可控、容错空间也更大，非常有机会直接实现端到端交付，而不必按部就班地经历每一个阶段。
因此，我们最终设计了两条演进路径。
第一条是 L1 → L2 的主航道，在大规模研发场景中持续推进研发范式升级。
第二条是一条 快速路，聚焦结构成熟、边界清晰的特定场景，尝试直接跃迁到 L3，实现 AI 驱动的端到端交付，推动研发效率实现非线性提升。
但 L1、L3 这些是交付的模式，组织关注的是什么呢？是一个结构。
我们规划了组织范式的演进路线：25年初，以 L1 为主，逐步 L1 收窄，最终 L2 和 L3 成为主流范式。经过半年的建设，L2、L3 的交付需求占比提升了，一些标杆团队的 Coding 时间也明显缩短了，看起来一切都在向好的方向走。
但把视角再拉到组织效能上，情况就不一样了。
我们基于当时的效能数据做了一些分析和归因，发现个体效率确实提升了—— CR 代码生成率都在涨，个体耗时投入在降；但在协同层面，端到端的周期其实并没有太大变化。个人虽然提效了，但在组织和协同层面，传导的链条是断的。
为什么个人变快了，组织没快呢？时间到底去哪儿了？
基于千人团队的实践，我们得到两个非常重要的洞察。
第一个洞察是：AI 越快，人和人之间的协作摩擦反而越明显。
AI 带来的提效首先发生在局部，最典型的就是编码环节。工程师的 Coding 时间确实缩短了，但一个工程师一天真正写代码的时间，大约只占 30%，甚至更少。剩下的大部分时间，都花在需求对齐、协作沟通、任务交接等工作上，而这些协作成本，很快就抵消了编码效率提升带来的收益。
第二个洞察是：人机协作本身，正在成为一种新的隐性成本。
AI 被引入之后，并不意味着人可以立刻把工作交给 AI。为了让 AI 真正发挥作用，人仍然需要投入大量额外的时间和精力。
结合大家的实际实践，我们把这些成本归纳为四类典型的协作摩擦。
* 第一类是 人工补位。当 AI 与研发系统之间还没有完全打通时，人不得不充当两者之间的桥梁，把信息不断搬来搬去。
* 第二类是 上下文对齐。AI 并不了解我们的业务背景，也无法天然理解需求语境，因此工程师需要不断整理、补充和传递上下文，充当系统之间的"搬运工"。
* 第三类是 验证与纠偏。AI 可以在几分钟内生成代码，但验证这些代码是否正确、是否符合业务需求，往往需要几个小时，甚至更长时间。AI 生成和人工验证之间，存在明显的速度不对称。
* 第四类是 能力边界判断。当大家对 AI 的能力边界还没有形成稳定认知时，低估 AI，会错过本可以释放的效率；高估 AI，则容易导致返工和重复修改。
这些都是我们在真实研发实践中反复观察到的现象。也正是这些协作摩擦，让我们意识到：真正制约 AI 研发效率的，已经不再是模型能力，而是人与 AI、AI 与系统、人与人之间的协作方式。
那这些摩擦的根源到底在哪儿呢？我们总结了两层约束。
第一层是能力性约束：AI 的能力边界不确定，产出可信度不稳定，验证和纠偏的工作高度依赖人工。在人机摩擦里，蓝色的这部分——验证纠偏、高估和低估——主要来源于能力层面。但能力层面会随着 AI 本身模型能力的提升，以及我们在工程 Harness 层面的建设不断提升。
第二层是研发体系的结构性约束。我们的研发体系一直都是为人设计的——人有什么特性呢？认知带宽有限，注意力稀缺，所以需要按技术栈分团队，需要多个环节分阶段开发测试上线，还有产品研发设计这些角色去协作。在这套体系下就会映射出三个方面的投影：信息、流程、组织，形成这样的结构。在这个结构下，人和人之间的摩擦就会存在——协调、交接、对齐；同样这套结构也在卡着 AI。当技术栈切分以后，信息系统、技术设施都是分离的。
站在 AI 的视角来看，它其实很难获取完成任务所需的上下文。开发一个需求，客户端代码在一个仓库，前端代码在另一个仓库，后端又分散在多个微服务中；需求文档、设计文档、API 文档也分别存放在不同系统里。AI 无法像人一样跨系统理解和关联这些信息，于是，人只能不断充当桥梁，去补充上下文、搬运信息、连接系统。
归根结底，这些协作摩擦并不是模型能力的问题，而是研发基础设施和协作体系的问题。过去的研发环境，更多是围绕"人如何协作"设计的，而不是围绕"AI 如何协作"设计的。
因此，当模型能力真正转化为 AI 的执行效率后，这些效率并不能直接传递到组织层面，而是不断被协作结构中的各种摩擦所消耗，最终形成大量结构性损耗。结果就是：AI 看起来越来越聪明，但组织整体的效率提升却十分有限。
这也是我们一年多实践中最大的收获之一：真正需要升级的，不只是 AI 能力，而是支撑 AI 工作的研发结构。只有重塑这套结构，才能把模型的智能真正转化为组织的效率。
三、围绕 AI 重塑研发体系：信息·流程·工程基座
那我们是怎么做的呢？我们需要围绕AI重塑研发体系。在讲AI如何改变之前，先讲一下度量——如果度量不了效率，就没有办法改进效率。
第一个阶段是平台化、数字化和精益化，这是在打地基——把研发活动在线化，让数据可信，才有资格谈度量；同时建立效能北极星，以及多个指标做交叉验证。
第二个阶段，我们把效能从一个模型变成了可拆解、可归因的指标体系，能看到每一个地方卡在哪里、出了什么问题。这也是前面那个分析的过程——为什么个人快了，组织没快，卡在了哪里。
第三个阶段就是现在，在效能模型的基础上扩展出了 AI 度量的维度，能够进一步看到组织的 AI 渗透率和 AI 成熟度。没有前三年的积累，我们今天并没有底气说AI让组织快还是没快，因为连快没快都量不出来。
接下来是我们的行动框架，基于前面那三层框架——信息、流程和组织。
信息层面：首先 AI 能不能拿得到信息？
我们的信息架构从围绕人转变成围绕 AI 进行重组。第二个是拿到信息以后能不能做得好，工程基座怎么样——比如 infra、评测体系、反馈闭环构建的情况。第三个是 AI 做得好以后，我们敢不敢放手、能不能信得过，这就是保障体系——验证、观测、约束。
第二个视角是流程层面，即研发流程：从传统的基于人协作的软件开发生命周期，怎么过渡到 AI-Native 的SDLC。
第三个是组织：组织形态、人才画像是什么样的，角色边界应该怎么划分，怎么样有一套新的评价体系，以及组织拓扑、组织治理与文化。
先看工程环境这一层。工程环境可以认为是一套广义上的 Harness Engineering。大家都在聊 Harness Engineering 应该怎么做，以及关于 Loop Engineering 的讨论。我今天更想分享是：我们应该把重点放在哪儿，哪些是真正应该投入的。我们的出发点是 AI 的能力在持续涌现，但很多东西是它内化的，比如工程脚手架里我们给模型打的一些补丁——但哪些是它真正内化不了的？就是企业里面的事实、判断和责任。
第一个是事实：模型能力再强，它并不能知道你此刻系统的真实状态。所以第一个要投入的是让模型能看到正确的世界——包括信息架构的重组、私域基础设施的 AI 友好化、面向企业内的知识工程。
第二个是判断：定义什么是对的、好的，这只能由我们自己来定义。验证工程和评测驱动是把判断力固化为系统和组织能力的一种最关键的方式。也有一个观点我非常认同：我们有没有把最优秀、最高效、高绩效的工程师放在评测体系里面，这是 AI 化能否成功的关键。
第三个就是责任：AI 模型能力越强，守底线就越重要。AI 的能力边界越来越大，它对应的自主半径会扩大，潜在的爆破半径也会扩大。但如果 AI 闯了祸，真正承担代价的还是我们自己。所以这三个层面非常重要：第一个是工程的卓越性，即当前的技术水位；第二个是工程保障，质量稳定性、安全等方面；第三个是持续的工程治理，通过约束可见、回滚、应急预案等兜底机制和响应机制来确保底线守得住。
再看研发流程层面，我们希望的是一个 Agent 驱动的 SDLC。传统方式是在 AI 增强下，基于多阶段、多角色协作流程，只是把 AI 加进来了，所以有很多损耗。目标态是意图驱动、面向结果的端到端交付。
但很多场景目前很难一步到位，我们的渐进思路是：先把协作和执行做一个分层。人与人之间的协作在这个阶段完全避免不了，我们就先把它分层——比如产品、设计、研发之间有一些接力，能不能把人之间的协作变得更松散？人与人之间比较擅长松散、模糊和创造性的沟通，而 Agent 擅长的是结构化、确定性的、可重复的执行，所以把这两层分开。让人把所有需要对齐的事前置消化掉——意图对齐、决策冻结，全部在这一层完成，不让协作摩擦渗透到 Agent 执行链路里。
在中间通过工具让产出能被 Agent 消费：比如给产品在生产力工具里，通过 Skill 或工具化的方式，把意图转化成结构化的 Spec；或者通过 Design Agent，让设计师构建出更贴合实现的视觉稿以及局部场景；还可以通过原型驱动的开发来降低损耗，避免通过 PRD 或设计稿进行信息交接。人在上面自由沟通，工具自动把各自的产出汇合成结构化的 Specs。经过人的审核、决策冻结之后，协作摩擦前置消化掉，保持执行链路的 AI 高自主。
四、组织进化：协作重塑与人才重构
第四部分就是组织的变革、协作的进化以及人才的重构。组织的这一层是整个变革最深的，同时在千人团队里，组织的惯性阻力肯定很大。所以我们首先做先锋的试点和验证，蹚出一些路，然后再做规模化的复制。
在技术栈这个层面，我们之前是按技术栈来切分的，逻辑是：自己交付的功能、自己写的代码和自己守护的代码，是一拨人，因为只有他们最懂这套代码。但在AI时代，这个逻辑被打破了——当一个 AI Agent 能帮前端工程师写出相对合格的后端代码，或者反之，继续把交付和守护绑在一起，反而会让效率变成瓶颈。所以我们把交付和守护做了一个分层：交付层把前端后端这些职能抹平了，定义它叫做功能 Owner，通过AI协同完成交付。
但守护还是需要专业的人，也就是目前技术栈团队的架构师，负责定标准、建机制、守门禁这些方向。经过组织机制和形态的渐进式过渡，我们发现这样以后可以完成单人闭环，协作摩擦也会降低。
前面讲的都是研发内部协作和组织设计的变化，产研之间其实也会发生一些变化。很多需求的判断并不一定都在研发——设计优化的判断力在设计师，运营需求的判断力在产品运营。所以另外一个思路是主动赋能这些角色，让他们有能力自己交付。
那这样是不是有一些需求可以不经过研发？所以我们做了一些事情，比如给设计师构建自主交付的能力，给产品构建自主交付的通道。当角色边界溶解以后，研发系统正在从所有需求的默认承接方变成复杂专业问题的承接方，工程师的工作会更聚焦，同时也能向更多可能性延展。
接下来是组织层面的画像。在人才结构之前，得先回答一个问题：在 AI 变革的时代，我们的组织到底需要什么样的工程师。所以我们尝试做了一些人才画像的定义。最终的观点是：AI 时代工程师的价值是底层特质乘以能力基座乘以核心杠杆。
五、三个叩问：洞察、远见与温度
前面都是在讲效率，但 AI 时代技术团队的边界价值是不是只是让交付更快更多呢？研发提效本身也只是一个起点，AI 时代技术团队需要从高效交付走向价值共创。这里引用蚂蚁的 CTO 梁纥老师的一个类比：玻璃最早在欧洲发明以后，传到了东方。
最早玻璃被当做器皿的改良——之前都是用陶瓷杯，现在变成玻璃杯，它是一种奢侈品。但在西方，人们用它打造出了镜片，有了镜片以后就有了显微镜，所以才有了现代医学；有了望远镜，才有了天文学和物理学。所以我们怎么看待这个玻璃呢？是把它当做器皿继续喝水，还是用它做成显微镜和望远镜？AI 今天做成了一个杯子，它会替代很多当下的工作，但我们依然只把它当杯子，没有用它去做真正有价值的事——找到真正的望远镜，去发现新的机会和洞察新的价值。所以我们希望能看到更多看不到的业务可能性。
举一个具体的案例：我们是怎么从业务共创的视角去思考，重塑一些产研运营的流程设计的。这是一个直播场景礼物设计的整体流程和机制。在过去我们也在用 AI，在各个环节里把 AI 集成进来。
比如当一个人构思好礼物内容创意以后，他会选择模型去生成、去抽卡，最后人去审稿——这个过程能不能重新思考？因为它还是围绕人去设计的流程，人的认知、时间和精力都是瓶颈。所以我们重新思考：人和 AI 在这件事里的边界和分工是什么样的。于是做了一些探索，发现AI可以做方向剧本、分镜、美术的专业制作，通过 AIGC的agent来完成；AI Agent Tools 能提供生成、剪辑和合成；评审、验证、评测都可以通过 Agent evaluation 来做；以及消费付费特征因子的反馈。人在这个过程中就上移到定义目标、标准和关键方向。这是一个案例，我们希望将过去业务中的流程和行为进行拆解，以 AI 为中心重新思考和设计。
在 AIGC 这件事上我们也达到了非常好的效果，包括业务效率、商业形态，还有用户参与度和生态。最后看一下当前的阶段性成果。在研发范式方面，大盘目前 L2 的需求已经成为主流范式—— L2 相对于 L1，交付周期大概缩短了20%到30%；L3 在一些运营类的特定场景里，跑出了一些稳定的实践，能看到大幅度的交付周期缩短和整体提效。在业务价值层面，我们在多个业务方向上都贡献了显著的业务收益和增量。这是我们 AI DevOps 的整体全景大图。
再往前看，前面这些历程其实一直有很多困难和波折，同时也遇到了一些关键的问题，这也是我们目前仍然在持续探索的。比如验证能力的规模化，尤其是在 C 端场景，怎么做好稳定的验证，确保稳定性、适应性，以及整个验证的效率和质量。第二个是先锋队的模式探索——在千人规模下需要有一些先锋团队先冲到前面，但这些先锋队的灵活性和未来泛化的标准化之间应该怎么平衡，也是我们仍在尝试攻克的难题。
前面我们在讲范式和组织进化，但在这场变革中，AI真正的重塑，最终落到的是每一个人。所以这里我想分享三个自己最近在问的问题。
第一个问题是关于洞察：看得见的是知识，看不见的是品味、洞见和判断。我们的组织能不能让看不见的价值被看见，给它一个位置和认可？
第二个关于远见：人人现在都能加速，大家都在追求更多新工具，更快、更及时的结果。但有没有一个瞬间能停下来看一看——稀缺的是一个能够为判断留出时间、为方向留出耐心的定力。我们的组织有没有为这份定力留出空间？
第三个是关于温度。AI 抹平了入门的门槛，很多 Junior 工程师上手都能用 AI 出活，效率也很高。但我们这一代古典工程师，很多东西是靠一行一行写出来的、靠一个一个 bug 调出来的——对代码的手感、对优雅设计的审美、对系统的敬畏、面对复杂问题时的直觉，对严谨性和确定性的坚守。这些以前是在慢慢写的过程中长出来的，当 AI 跳过了这个过程，谁给他试错的空间？谁在他犯错的时候说“没关系，这个坑我当年也踩过”？所以问题是：我们的组织有没有在追求快速产出的同时，给年轻人留出更多生长的机会？
对于这些问题，我现在还没有标准答案，但有一点越来越清晰：AI 让组织更强，而好的组织进化，也能让人的洞察、远见和温度更充分地生长。范式在变，组织在变，不论系统怎么演进，最终底色都是我们每一个工程师、每一个创造者。我们希望在这场变革中，每个人都能找到属于自己的价值和可能。希望在追求工程理性的尽头，也能活得更丰盈、自洽且无可替代。 团队介绍
快手主站技术部是负责快手 app 和快手极速版 app 的核心业务研发团队，服务于数亿用户每天时长上百分钟的使用，专注于打造极致且高效的生产、社交、消费、直播、运营、增长、房聘、孵化等业务研发体验；同时也是快手最大的技术部门之一，拥有业界资深的大前端、服务端、质量等团队，承担着核心业务需求迭代、超高并发服务开发，春节、奥运、暑期等大型活动工程技术保障，以及业界领先的基础技术建设等任务。
通过与产品、算法、设计、运营等各团队的紧密协作，主站技术践行 AI Native 理念，以数据驱动的方式，不断追求用户体验及技术架构上的最高标准，持续优化研发效率、质量和成本。一方面不断通过技术赋能业务，持续拿到业务指标上的正向收益；一方面也在积极探索最新的技术方向，产出了如 AIGC、M0、GUI-Agent、跨端动态化、端智能等业界领先的技术方案。
欢迎加入【快手技术交流群】
扫描二维码👇
点击【阅读原文】，获取讲师PPT！ 阅读原文