首次披露：腾讯研效提升背后的两大核心驱动力

腾讯首次公开研效提升的秘诀，揭秘融合互通与智能化如何成为研发效率的双引擎。

本文整理自腾讯研发管理总监杨晓俊在2025年可信云大会上发表的同名主题演讲。这也是一次难得的窗口，让我们得以窥见这家互联网巨头在研发效能领域的内功心法。

腾讯研效发展的破局之路

近几年来，腾讯通过不断整合内部研发工具，走出了一条以开源协同促进工具收敛与共建的破局之路。这条路，走得不易，但方向清晰。

2019年，腾讯开始系统性地建设研效工作。初期动作是建立统一配置中心、代码托管等Oteam，把分散的平台逐步收拢。到了2021年，一个关键里程碑出现了——腾讯成立了公司级的研效技术委员会。从那时起，腾讯人终于有了自己的研效主心骨和协同共建中心。随后，运维平台、项目管理等Oteam也相继组建。

2024年，AI Coding势头正盛，腾讯迅速组建了代码智能化的统一团队，借助大模型能力，为研效翻开了新篇章。经过五年多的收敛与共建，腾讯基本完成了统一的研发测试环境资源、统一的底层元数据和研效服务工作的搭建。但在上层研效工具层面，目前仅收拢了需求项目、代码开发、构建三大块，其余垂类工具更多还是通过互相串联的方式来提升整体效能。

腾讯研效发展痛点及解决：融合互通

工具孤岛困境

腾讯的业务有多多元？从微信支付到王者荣耀，再到腾讯会议和元宝，横跨了金融、游戏、办公、AI等多个赛道。不同业务在项目管理方式、开发模式、研效工具上差异巨大。再加上以事业群（BG）为单位的组织管理，每个BG都形成了自己的垂类工具——有的专注于美术资源管理，有的侧重灰度发布和A/B测试，甚至每个BG都有各自独属的统一协同平台。

举个例子，一位做明星游戏的产品研发人员，往往需要在十几个平台之间来回切换，才能完成整个研发上线的流程。工具孤岛问题由此而生。从一线员工的反馈来看，大家最苦恼的就是在多个工具平台间反复跳转、到处翻找信息：需求状态经常不能及时更新，线上运维情况也难以实时掌握。

应对这一困局，核心思路是加大各平台工具之间的串联与协同，让研效操作和数据能够跑在一条通畅、丝滑的信息公路上。

工具深度融合互通

腾讯内部研效数据是开放的，工具平台可以提供API、应用市场、MCP等开放能力。这些基础能力在数据及功能操作层面实现了真正的开放和扩展，既能对接和集成第三方工具平台，也能为平台自身的应用做扩展和解耦，从而为用户提供一体化、无缝的研效服务体验。

融合的另一个关键做法是自动化。只有自动化，才能驱动数据更灵活、自动地流转。我们抽象出了“触发-条件判断-执行”的自动化范式，简单说就是——“谁，在什么样的范围里，去做哪些事情”。无论是触发机制还是执行操作，都可以支持平台自身，也可以通过扩展延伸到第三方。

典型的自动化场景包括：消息精准触达（在适合的时间让正确的人员处理待办）、流程自动化（让自动化流转代替人工驱动数据）、流程规范化（让研发人员在数据节点上提供必要信息，如需求合规评审报告、测试报告等）。从运营数据来看，这些平台的实际运作效果相当可观，月调用次数都是以亿甚至十亿计。

以微信支付融合互通为例，研发流程通过阶段进行区分，包括安全合规、业务建模、开发实现、检测验收、部署发布。每个阶段又细分为十多个子状态——安全评估、需求建模、用例设计等等，而这些子状态往往对应着一个三方平台。以往，产研同学需要跳转到不同平台进行数据提交、单据流转，光是跳转登录、熟悉界面和表单，就已经是不小的成本。

融合互通的做法是，在需求详情页把这些研效阶段提炼成价值流一一对应，子状态则是其下的一个子工作项。数据呈现上，既可以通过接口拉取后直接显示在详情页，也可以通过需求详情页内部跳转，进入下方业务对象扩展区域查看更多信息。业务扩展区是一个对外开放的挂载点，如果有需要，也可以跳转到第三方平台进行更深入的操作。通过价值流这样的扩展点，各个第三方平台分散的数据和操作集中到了一起，让产研人员在单一研效平台上就能完成大部分操作。数十个扩展点实现了数据和操作的全面互通，效果立竿见影——微信支付在一年时间里，交付周期降低了45%。

腾讯发布研效统一品牌——WeDev

完成研效平台收拢、各工具融合互通等基础工作后，腾讯研效取得了阶段性成果。今年5月，腾讯正式推出研效统一品牌——WeDev。这无疑是腾讯研效史上的又一个重要里程碑。

WeDev的定位与其他大厂传统的一站式研效平台不同。它不是一个工具，而是一个生态、一个联盟，是在底座工具平台统一基础上的融合互通。它既顺应了腾讯产品研发和研效的特点，也让研效人员有了可以协同共建的平台，让更多小工具找到了自己的位置和发声的机会。

腾讯研效核心驱动力：智能化

从需求&项目管理、编码实现到上线运维这三个阶段来看，无论是业界还是腾讯内部，智能化实践目前都集中在前两个阶段。特别是编码阶段，近两年大模型打造的IDE和插件层出不穷，已是一片红海。但需求&项目管理阶段的挑战更大——团队规模日益扩大，用工复杂性带来的沟通协作效率问题尤为突出。虽然可以借助特性小组等方式进行小规模管理，但在工具智能化层面，仍有大量可建设的空间。

需求&项目管理阶段

在需求&项目管理阶段，目前还没有出现像Cursor、Windsurf这样的杀手级工具，更多还是基于老牌项目协作平台进行场景化的AI提效。腾讯内部也是如此。早期，我们曾试图用大模型做需求润色、扩写，甚至代替产品人员写PRD，但实际效果并不理想。原因很简单——无论是需求设计还是代码编写，本质都是创造和创新，而这恰恰不是现阶段大模型所擅长的。

基于业务团队经常出现“一页纸需求”的痛点，我们与团队合作引入了AI需求评审。通过规则和大模型评分的方式，结合流程卡点，促使产品人员把需求写得更详细。同时，借助知识库、名词库协助业务团队实现场景落地。另一个典型案例是，在大团队中，我们经常遇到这样的情况：一个紧急的bug单不知道该分给谁——谁有能力处理？谁有时间处理？这个人是否在休假或开会？这时引入AI，一方面可以拉通人员的休假和会议信息，另一方面可以用大模型分析每个人的技能强项、负责模块、当前负载等，从而找到最合理的处理人。

AI在研效领域的另一落地形态是专家型AI助手。其中最大的难点在于如何让AI助手充分理解用户的真实意图。比如这样一个问题：“帮我查下詹姆斯这个汇报周期实现的高优先级需求，并将结果发送给我”——詹姆斯是谁？汇报周期指的是哪几天？这时候，AI助手需要根据项目的独有知识库，将问题准确拆解，并规划成名词解释、查询、总结、消息发送等多个Agent，在与用户简单互动确认后，完成整个任务。

编码实现阶段

在编码实现阶段，腾讯通过向员工提供代码AI服务CodeBuddy来提升研效。我们将这个服务分为三个层次：产品功能层、代码PaaS层和基础模型层。

产品功能层包括代码补全和技术对话，为开发者提供编码建议。同时还有代码生成Agent和单测Agent，以智能体的方式驱动代码生成。

代码PaaS层是充分发挥底层大模型能力的催化剂。做开发的同事都知道，写代码之前需要花费大量时间理解上下文——需求描述、代码仓库结构、之前的提交记录等，这些前期工作直接决定了需求的完成度和质量。AI智能体也是如此。PaaS层只有做到这一点，才能真正像团队成员一样去工作、去思考。从这个角度看，PaaS层生成的代码正确率要求极高。目前，我们在单测代码生成上进行了探索，通过自动化沙盒进行“运行-修复”的正反馈循环，正确率提升了6%。

基础模型层则支持混元、开源模型和外部闭源模型的灵活接入。

目前，AI Coding的关键指标都是基于实际生产环境得出的。对比2024年与2025年初的代码提交数据，高频使用AI Coding的用户月均代码产出增长了21%。至于AI Coding最大的挑战，在于如何让Agent像一名真正的开发者——这可以说是研效领域的“图灵测试”，也是我们仍在持续深耕的方向。

近几年，腾讯内部研效最大的驱动力就是融合互通与智能化。无论是个人产出还是组织提效，都取得了一些实实在在的提升。但在当前的大环境下，大部分研效从业者可能还在纠结于这样一个矛盾：不做研效，无法证明自己的价值；做了研效，效率提升了，是不是反过来革了自己的命？

对此，我们的判断是：前两次工业革命对人类的影响也绝非一朝一夕之功。AI需要像润滑剂一样，渗透到研效的每一个环节。所有关注AI研效的人，应当有更多的包容和耐心。更重要的是，AI研效不应以降本裁员为出发点——效能提升的真正价值，是让团队有余力去做更多的探索，让产研团队与AI更和谐、更互补地发展。