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

本次演讲首次披露腾讯研效的发展路径，并正式发布腾讯研效统一生态品牌——WeDev。

关注腾讯云开发者，一手技术干货提前解锁👇

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

2019年，腾讯开始系统性地建设研效工作。起初建立统一配置中心，代码托管等Oteam，把分散的平台收拢起来。2021年，腾讯成立了整个公司的研效技术委员会，这是腾讯研效发展过程中里程碑式的事件，腾讯人自此有了自己的研效主心骨和协同共建中心。后续又先后组建了运维平台、项目管理等Oteam。

2024年，AI Coding盛行不久，腾讯成立了代码智能化的统一团队，通过大模型的能力揭开腾讯研效的新篇章。经过5年多的收敛和共建，腾讯已经基本完成了统一的研发测试环境资源、统一的底层元数据和研效服务工作。但在上层研效工具层面，腾讯只是收拢了需求项目、代码开发、构建三大块，其余垂类工具更多是以互相串联的方式提升研效。

大家都知道，腾讯业务非常多样，从微信支付到王者荣耀，再到腾讯会议和元宝，其在项目管理方式、开发模式、研效工具等都有很大的差异。同时腾讯以事业群（BG）进行组织管理，这就导致每个BG都有自己的垂类工具，有的关注美术资源，有的关注灰度和A/B test等，甚至每个BG都会形成各自独有的统一协同平台。

以明星游戏为例，产研人员往往需要在十几个平台操作才能完成整个研发上线流程，工具孤岛问题随之出现。从一线员工的反馈可知，大家非常苦恼于在多个工具平台间跳转操作和获取信息：需求状态往往无法及时更新、线上运维情况无法了解等。

应对这个问题，我们采取的办法是加大各平台工具之间的串联与协同，让研效操作和数据能够在一条通畅、丝滑的信息公路上运行。

开放平台助力工具自由扩展和解耦

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

自动化引擎驱动数据灵活流转

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

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

场景化价值流落地

以微信支付融合互通为例，研发流程通过阶段区分，包括安全合规、业务建模、开发实现、检测验收、部署发布。每个阶段又分为十几个子状态，例如安全评估、需求建模、用例设计等，这些子状态往往对应了一个三方平台。以往都需要产研同学跳转到其他平台进行数据提交、单据流转，无论是跳转登录还是跳转过去后对界面和表单的熟悉，都有比较大的成本。

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

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

WeDev的定位和大厂内传统的一站式研效平台不同，它是一个生态，一个联盟，是底座工具平台统一基础上的融合互通。不仅顺应了腾讯产品研发和研效的特点，也让研效人员有了能够协同共建的平台，让更多小工具也能找到定位，为自己发声。

腾讯研效智能化的发展，从需求&项目管理、编码实现和上线运维三阶段来看，无论是业界还是腾讯内部，目前的实践都主要集中在前两个阶段：需求&项目管理和编码实现。尤其是编码阶段，近两年，用大模型打造出来的各种IDE和插件如雨后春笋，一片红海。从当前的挑战来看，需求&项目管理最大的困难还是来自于团队规模的日益扩大，以及用工复杂性所带来的各种沟通协作效率问题。虽然大家可以用特性小组等进行小规模化的管理，但在工具智能化层面，还有很多可建设性。

需求&项目管理阶段，目前还没有出现像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更和谐、更互补地发展！