重构研发效率:AI Coding研效体系搭建与迭代之路

2023年底DeepSeek开源为行业带来了AI Coding领域的关键突破，2024年起各类AI编码工具集中爆发，腾讯音乐研发效能中心正是从这一阶段开始深度牵头腾讯音乐内部的AICoding体系建设，在工具基建、流程重构、价值度量三个维度完成了完整的落地实践。

2026年8月，在深圳举办的MTSC2026第十五届中国互联网测试开发大会上，腾讯音乐娱乐集团研发效能中心资深测开专家李娟分享了题为《重构研发效率：AICoding研效体系搭建与迭代之路》的实践案例，给行业带来了非常有价值的参考。

以下为该公司团队的分享：

PART 01 AI时代的研效新挑战——破局与反思

2024年起，Cursor、Cloud Code、通义灵码等海内外AI编码工具集中涌现，行业不再面临“没有工具可用”的问题，反而陷入了“工具太多、用不起来、价值说不清”的新困境。腾讯音乐在推进AICoding落地的过程中，总结出行业普遍面临的三重核心挑战。

AI研效的三重挑战：工具、流程、价值

从“工具可用”到“组织可用”：回答三个问题

工具碎片化、流程断层、价值难证这三重挑战，最终指向三个必须回答的组织级问题，也对应了三大建设方向：

1. AI如何安全、可控地进入企业？
   对应工具碎片化的挑战，核心是建设企业级AI工具、Agent分发能力与工具生态，先把基建搭起来，让团队有合规、好用的工具可用。
2. AI如何贯通完整研发链路？
   对应流程断层的挑战，核心是推进测试左移、自动用例生成、一站式AI研发链路，把单点能力串成全流程能力。
3. AI如何证明真正创造价值？
   对应价值难证的挑战，核心是搭建科学的度量体系，实现AI生成采集、有效代码识别，真正量化AI的业务价值。

PART 02 腾讯音乐AICoding效能新基建

本部分回应第一个核心问题：AI如何安全可控地进入企业？ 企业落地AI不是装一个插件这么简单，要跨过三道实际的门槛，才能把AI从个人工具变成组织能力。

企业级AI基建的三道门槛

要把AI真正装进企业，必须跨过工具接入、能力复用和系统治理三道门槛：

最终的目标就是通过统一接入、统一复用、统一治理，搭建完整的企业级AI工具基建。

基建全景图

腾讯音乐的AICoding基建，最终支撑起了覆盖研发全生命周期的多智能体协作模式，Q音业务线已经基于这套基建落地了全链路AI辅助开发。 从研发流程来看，AI能力已经渗透到每个阶段：

• 需求规划阶段：支持对话式需求澄清、交互Demo生成、方案规划建议、数据分析决策
• 原型设计阶段：实现自然语言生成设计图、设计图转Demo原型（D2C）
• 研发阶段：覆盖业务逻辑编码、调试提交、UI前端编码、AI游戏/特效生成、代码转换；同时支持基于技术栈的智能修复（S2C）、自动调试与反思、AI测试用例生成、AIUI/接口自动化、AI自动分析修复、项目约束自动编码、代码重构/多端转换、AI单测（AICR）
• 测试阶段：支撑存储趋势分析、服务故障定位、灰度监控
• 线上运维与运营阶段：覆盖发版管理、告警归因分析、AI反馈跟进、IOT智能客服、AI运营配置

而支撑这一切的，是完整的AI工具基建层：

• 通用Agent层：WorkBuddy、TME Claw、Knot等通用智能体
• AI编码工具层：CodeBuddy、TME Continue、Claude Code等编码工具
• AI设计工具层：Figma、可灵、Goodle Ai studio、Lovart等设计工具
• 能力平台层：TME Agent Hub、Skills市场、MCP集市、TAPD、Iwiki/腾讯文档
• 底层基建层：Knot平台、RagFlow知识库、DevOps、蓝盾、神舟、AI数据度量、模型代理、AITest、火眼、树洞、工蜂/CNB

选型：插件与CLI协同

工具形态的选型，是基于团队真实使用习惯调研得出的结论（2024年调研数据）：

1. IDE使用分布：VS Code占44%、JetBrains占26%，两者合计覆盖了70%的开发场景。编码是最高频的AI使用场景，因此必须要有IDE插件形态，让开发者在编码时可以无缝调用AI能力。
2. AI使用场景分布：IDE内编码场景只占50%，剩下50%的需求、知识、测试、交付等场景，需要跳出IDE来串联研发流程，因此需要CLI形态来做流程串联。

最终形成了同一能力内核，多入口触达的模式：插件覆盖编码环节，CLI串联研发流程，双形态协同。同一个Agent、同一份知识库、同一套Skill，既可以在IDE里用，也可以通过CLI调用，不用重复建设。

平台：从工具到企业能力

工具只是起点，真正的企业化，是补齐接入、治理、度量与扩展四大能力，打造企业级研发平台：

• 接入层：提供统一认证、统一权限、统一入口，覆盖IDE插件、CLI双入口，打通需求、编码、代码评审、测试、交付全研发节点
• 治理层：落地工具管控、内容安全、回滚机制，确保AI的使用过程、产出内容、质量标准都可控可审计
• 能力内核：沉淀对话、编辑、Agent编排等基础能力，支撑Agent、Skills、MCP等上层扩展
• 度量层：内置模型路由、上下文管理能力，实现全流程可观测、可度量
• 扩展层：对接企业底座与各类业务系统，包括模型服务、知识服务、工具市场、配置中心，打通代码、文档、业务数据

治理：一次配置多端复用

针对配置割裂、经验难沉淀、密钥有风险等痛点，腾讯音乐打造了“统一配置、自动适配、云端治理”的体系：

• 沉淀标准化Agent模板，一套配置自动适配IDE插件、MCP集市、CLI工具、研发平台等多端，实现能力复用
• 建设集团级Skills市场和MCP集市，联合各个业务线、运维等团队共建，把个人沉淀的优秀Skill、MCP变成组织公共资产
• 通过统一的Rules引擎适配多种AI工具，保障不同工具上的能力一致、多端生效

落地成果非常显著：目前已经沉淀了400多个共享型Agent，配置复用覆盖率从最初的28%提升到了100%，真正实现了可复用、可治理、可度量。 核心的认知是：自建工具只是载体，组织复用才是价值。

PART 03 AI时代研发链路变革

本部分回应第二个核心问题：AI如何贯通完整研发链路？ 很多企业的误区是：编码提效=研发提效。但实际落地中会发现，代码写得再快，流程卡壳、协同低效，整体交付也快不起来。AI时代的研发链路变革，本质是重新定义人、AI、工具、流程的分工。

变与不变：交付目标未变

AI改变了代码的生产方式，但从来没有降低复杂软件的工程交付要求。

• 变的是执行方式与知识载体
  代码生产从手写变成AI生成，经验载体从个人脑海里的隐性知识变成结构化文档，AI的输入从临场临时喂料变成阶段化上下文。这是AI擅长的部分，也是最容易看到提效的部分。
• 不变的是工程目标与责任边界
  业务的复杂度没有变，产品长期迭代的压力没有变；系统可控、质量可靠、交付稳定的工程要求没有变；工程师对结果负责的责任边界也没有变。

如果只看到“变”，忽略了“不变”，盲目放开AI使用，就会出现三个典型问题：

1. 单兵作战：AI使用经验集中在少数探索者身上，团队整体能力不均
2. 规范失控：每个人的Prompt不一样，产出风格不一致，质量不可控
3. 阶段失忆：AI不知道当前任务处于研发的哪个阶段，输出不符合阶段要求 最终的结果就是：个人提效了，但团队没有规模化落地。

能力边界：AI工具能力强≠项目研发提效

单点执行能力，不能直接外推为复杂项目的全流程自治能力。结合SWE-bench Verified、METR等行业长周期任务研究，可以得到两个明确的结论：

1. 明确任务能力很强：成熟仓库里的明确Bug修复、单函数编写、代码补全这类边界清晰的短任务，AI的能力持续提升，表现很好
2. 任务越长越难：大约两小时时长的任务，成功率只有50%左右；任务边界越模糊、复杂度越高，成功率下降越快 而复杂软件的全生命周期闭环，目前行业内仍然缺少公开、可信、可复现的全自主落地案例。

从三种研发模式的效率曲线也能看出来：

• 不设限使用AI：短期编码环节效率极高，但随着项目周期拉长，复杂度上升，效率快速回落
• 合理人机分工：全生命周期中效率最优，短期编码不如纯AI快，但长期质量和交付稳定性更高
• 传统模式：效率平稳，但整体上限低

核心结论非常明确：代码生成越快，越需要流程约束、结构化知识和自动化验证。

协作重构：人决策，AI执行

真正的变革，不是让AI替代人，而是重新设计人、AI、工具和流程之间的分工，形成三层协作模式：

核心原则就是：判断与责任归人，执行与认知扩展交给AI。

流程工程：编排约束可回溯

团队规模化落地AI，靠的不是更多更好的Prompt，而是一套企业级研发控制面。 Prompt是个人的、零散的，每个工程师写的Prompt都不一样，产出质量不稳定。要做到团队规模化、标准化，就要把研发流程工程化为可执行的系统，用“敏捷节奏+阶段门禁”的思路来管理AI研发。

这套体系有几个核心特点：

• 流程分层：支持轻量流程、标准流程、团队自定义流程，适配不同复杂度的业务需求，不搞一刀切
• 核心能力：内置统一调度、人工确认、权限控制、可编排、可观测五大能力
• 核心组件：由工作流模板、多Agent研发控制面、Workspace状态机、Agent调度组成
• 资产与执行：统一管理Agents、Artifacts（阶段产物）、知识库、研发工具、质量工具、模型

最终实现的效果是：状态机约束流程走向，Artifacts承接阶段上下文，统一调度控制执行边界，做到过程可见、边界可控、全链路可回溯。

一站式研发平台：阶段产物可流转

基于研发控制面，腾讯音乐搭建了一站式研发平台，核心逻辑是：用单一职责的Agent完成每个阶段的执行，通过结构化产物和人工门禁连接下一阶段，把零散的AI能力串成完整的研发链路。

全流程一共分为7个节点：

1. 需求澄清：由澄清Agent基于业务知识库，输出结构化澄清项，拉通产品等角色线上确认，产出澄清后的需求；
2. 方案设计：由规划Agent输出Spec + 任务拆解，经过架构评审门禁后进入编码阶段；
3. 编码：由编码Agent完成代码编写，产出Code Diff，经过代码提交门禁进入评审；
4. 代码审查：由CR Agent输出审查报告和修复建议，人工审查通过后进入自测；
5. 开发自测：由自测Agent输出测试报告和修复建议，自测通过后进入测试验收；
6. 测试验收：由Testing Agent输出质量报告，质量验收通过后进入发布；
7. 发布反馈：由Ops Agent输出反馈知识，发布确认后完成闭环，知识回写沉淀。

平台不是强制统一流程，而是支持灵活配置：

• 团队差异：不同业务线、不同端可以配置自己的Agent和流程节点
• 阶段差异：每个阶段可以分别配置判断模型和执行模型
• 需求差异：支持轻量流程和完整流程切换，小需求走快速通道

最典型的提效场景是需求澄清：以前需求评审要拉产品、后端、前端、测试等多个角色开会，凑齐人就要等1-2天，沟通完的信息还容易断层。现在需求Agent会先自动扫描需求文档，把描述模糊的点、和现有设计冲突的点提前列出来，各角色在线上确认即可；需要讨论的内容自动拉群，沟通结果同步沉淀到平台和TAPD需求单上，信息不会丢失，也不用会后重复整理。

质量左移：生成即验证

AI生成代码的速度越快，质量检测就越要往前移，移到代码生成的过程中。 传统的质量保障是“开发自测→提交→检测”的后置模式，检测靠后，修复成本高；AI时代要变成“生成-检测-修复-沉淀”的质量闭环，做到生成即验证。

具体分为四层防护：

• 生成前规则约束：把P0级的编码规范、业务规则前置嵌入Prompt，从源头约束AI的生成内容
• 生成时同步自测：通过本地Hook做即时检测，P0级问题当场拦截，不用等提交后再发现
• 生成即校验：自动补充Review用例，补齐用例覆盖质量
• CI后云端检测：转测前做P0+P1+P2全面检测，搭配修复Agent自动处理可修复问题

核心逻辑是：模型和人工都可能遗漏问题，自动化验收才能提供确定性的质量证据；质量保障不再是开发完成后的检查，而是代码生成过程中的持续验证。

自动验收：知识驱动UAT自动化

研发链路沉淀下来的结构化知识，最终会成为端到端测试的高质量输入，驱动UAT自动化落地。 这套体系的核心不是单纯的“用例生成”，而是知识的沉淀与复用：

• 知识提取：从需求中识别核心需求点，输出结构化澄清产物
• 用例生成：自动生成账号要求、数据构造、用例大纲、用例步骤
• 真机执行：自动运行脚本、做验证、视觉判断、问题归因

以UI自动化为例，这是测试提效的典型场景，核心建设了三类知识：

1. 业务领域知识：把产品的业务语言（比如“艺人发消息”）转化为AI可识别、执行可落地的操作语言，明确业务概念对应的页面、控件、判断标准；
2. 页面图谱：沉淀每个页面有哪些控件、有什么能力、页面之间的跳转关系，相当于给AI一张产品的“地图”；
3. 历史缺陷与数据构造能力：把高频出问题的边界场景纳入知识，同时前置构造测试数据，避免用例因为没有数据跑不通。

执行层面采用“确定性+AI推理”双模式：

• 确定性场景：通过控件标签定位，走标准化执行路径，尽量减少模型推理，保证稳定性和执行效率；
• 动态渲染、复杂逻辑场景：通过Maestro+Midscene方案，搭配30B左右的视觉小模型，用AI的推理能力完成操作探索。

关于样式层面的视觉测试，目前是在前置的视觉审查环节独立落地，尚未与UI自动化深度融合；后续也在探索基于UI自动化的截图做抽象分析，补充样式层面的校验能力。

试点效果：提效和边界并存

一站式研发平台的试点，既验证了流程工程化的提效价值，也明确了平台的能力边界，不夸大、不泛化。

• 提效成果：各角色之间的协同时间减少了83%，试点业务的月需求吞吐量提升了56%
• 明确的能力边界：
  - 不替代TAPD、代码库和发布平台，原有核心系统的定位不变
  - 不承诺复杂项目完全自主运行，AI是辅助不是替代
  - 不将试点结果外推到所有场景，目前适配效果最好的是三天以内的需求，约占总任务量的60%

一个非常重要的洞察是：研发过程结构化之后，才具备准确度量AI业务价值的数据基础。如果流程都是零散的、线下的，根本没法衡量AI到底带来了多少价值。

PART 04 AICoding提效度量体系建设

本部分回应第三个核心问题：AI如何证明真正创造价值？ 度量不是为了做报表、做考核，而是为了发现问题、驱动优化。腾讯音乐的度量体系，经历了从工具使用到业务价值的完整演进。

度量体系从覆盖率走向业务价值

度量体系沿着四个阶段逐步演进，核心目标从“让大家用起来”，逐步走向“用得有价值”：

除了价值指标，还并行配套了成本统计体系：追踪Token消耗量、模型调用规模、实际费用，持续做成本优化，确保提效是经济可行的。

整个度量体系的设计理念是：既看过程，也看结果；既看技术，也看业务。

AI代码采集的新问题：Agent工作流让执行边界分叉

要度量AI的贡献，第一步就是要准确采集AI生成的代码。这件事在早期很简单，但随着Agent能力的升级，出现了新的挑战。 传统的采集模式是“单会话、单目录”：默认代码修改都在当前会话、当前目录下，会话结束对比一下文件变化就行。但进入Agentic Coding时代后，父Agent会拆分任务，调度多个Subagent在不同的Worktree中并行修改、提交，一次任务的执行是分叉的。

这就带来了传统采集方式的盲区：

• 代码可能在另一个git目录、另一个分支，甚至提交后工作区已经clean了，主仓的基线看不到变更
• 子Agent共用父会话，缺少独立的基线，没法精准对应每次修改
• 不能全盘扫描所有工作区，会误采人工修改的脏文件

核心问题的本质是：采集对象不再是“会话目录”，而是本次Turn（任务轮次）实际创建或触达的所有Worktree集合。

现方案：工具级实时采集+生命周期双层对账

针对这个问题，腾讯音乐设计了“以Turn为身份，以touched Worktree为范围，以Subagent Stop / Parent Stop为恢复点”的双层对账采集方案。

具体执行分为四步：

1. Turn建基线：用户提交Prompt时，创建baseline_id锚定本轮任务边界；首次触达文件时建档，保存当时的HEAD和dirty状态，记录第一笔修改前的真实起点
2. PostToolUse实时采集：工具每次修改后都触发采集，低延迟获取文件diff、Bash checkpoint，标记已采集文件，拿到直接证据
3. 子Agent对账：Subagent执行结束停止时，按agent_id单独对账，提交和未提交的变化都能恢复
4. Parent Stop兜底：父任务结束时做最终兜底，补偿缺失的Post事件、异常退出的场景，去重后统一上传

这套方案有几个核心优势：

• 不漏采：覆盖committed、dirty、untracked三种状态，就算Worktree clean了也能恢复变更
• 不误采：只处理本轮任务触达过的Worktree，不会干扰人工修改的其他文件
• 可恢复：任何中间节点缺失，最终都有Parent Stop兜底
• 可扩展：适配apply_patch、Bash编辑、文件写入等各种AI修改方式

最终统一输出“AI修改文件 + unified diff”，进入后续的有效行匹配流程。

AI代码有效性：先定义有效行，再识别AI贡献

AI生成了很多代码，但最终要回答：哪些真正进入了线上代码库？ 这件事不能直接拿生成量和代码库做对比，要先定义清楚“什么是有效的代码”。

核心逻辑就是：先过滤噪声，再逐层提高匹配精度，保证结果准确的同时兼顾性能。

AI入库率推导：跨平台数据关联

有了代码行维度的数据，还要往上关联到需求和版本，才能回答业务层面的问题。 通过跨平台数据关联，把代码、AI生成数据、需求版本系统串成同一条数据链：

• 数据来源：Git API（repo+commit+文件+行粒度）、AI数据采集库（repo+文件+AI行）、需求与版本系统（版本+repo+commit）
• 统一主键：repo / commit / file / line
• 关联逻辑：代码行关联AI生成行 → Commit关联版本 → 版本关联需求

最终可以算出两个核心指标：

• 需求AI入库率：某个需求对应的代码中，有多少是AI生成的
• 版本AI入库率：某个发布版本中，AI生成代码的占比

这就最终回答了那个核心问题：AI生成的代码，有多少真正进入了线上。

洞察：代码提效≠交付提效

基于完整的度量数据，团队得到了一个非常关键的洞察，也打破了很多人的固有认知：

• 已经被数据验证的价值：AI的使用广度和深度持续提升，试点团队的需求覆盖率达到80%，需求AI入库率达到90%以上；
• 没有被数据支撑的结论：“AI用得越多，月需求完成量越高”——这个说法不成立。数据显示，AI使用强度增加，但需求吞吐量并没有显著变化。

核心结论：AI当前最确定的价值，是降低开发工作量；但仅靠编码环节提效，无法带来需求吞吐量的提升。这也是为什么要做一站式研发平台、要重构流程——因为编码提效之后，角色协同就变成了新的瓶颈。

一站式研发平台试点效果

针对“协同瓶颈”这个洞察，团队通过三个结构性动作重做了协作链路，也拿到了明确的效果：

1. 流程编排：把线下协同搬到线上，用平台串起全流程
2. 测试左移：质量验证前置，减少后期返工
3. UAT自动验收：用知识驱动自动化测试，提升测试效率

最终拿到了三个关键结果：

• 编码提效后，角色协同成为新瓶颈
• 一站式研发平台让角色间协同时间减少了83%
• 试点业务的月需求吞吐量提升了56%

也沉淀出三条最核心的经验：

1. AI让我们敢于重做流程，Agent让前置对齐与并行成为可能
2. 度量必须可归因，要从效率指标逐步走向业务指标
3. AI让我们敢于重做协同模式

度量-洞察-优化-再度量的正向飞轮

整个AICoding研效体系，最终形成了“度量→洞察→优化→再度量”的正向飞轮：

1. 度量：从覆盖率开始，逐步扩展指标，搭建起四层指标体系
2. 基建：配套建设工具能力、数据采集、版本关联能力，支撑度量落地
3. 关键洞察：通过度量发现核心问题——编码提效≠交付提效
4. 优化：针对问题做流程编排，重新定义人机协同和角色协同
5. 再度量：验证优化效果，持续迭代指标和体系

最核心的认知是：度量不是目的，洞察和优化才是；度量和基建是一体两面，互相驱动，形成正向飞轮。

PART 05 人机协同总结和展望——重构生产方式

回顾整个建设过程，腾讯音乐的AICoding研效体系，是从基建、链路、度量三个维度逐步搭建和迭代的，最终目标是重构研发的生产方式：

AICoding的演进不会止步于研发环节，未来会沿着三个方向持续延伸，下一步腾讯音乐团队将继续在“重塑组织形态、打破研发边界、改写业务边界”等方面进行深度探索。用科技，让音乐有无限的可能。

以上就是本次分享的全部内容。

现场QA精选

提问：想了解前端自动化测试的交互是怎么实现的？是用坐标点击还是用到了大模型的推导能力？另外Computer Use这类能力有没有落地？还有样式层面的自动化测试有什么方案？

回答： 首先交互定位上，我们没有用坐标方案——坐标的兼容性很差，换个设备、换个分辨率可能就跑不通了。对于有明确标签的确定性控件，我们都是通过控件标签来定位执行，保证稳定性。

然后是大模型和Computer Use相关的能力，我们采用的是Maestro+Midscene的方案，分两种场景：

• 回归用例、确定性场景：尽量走标准化的标签执行路径，减少模型推理，保证执行效率和稳定性
• 新需求、动态渲染、复杂逻辑场景：会用到30B左右规模的视觉小模型，通过它的AI Act能力做逻辑判断和操作探索，相当于轻量版的Computer Use能力

最后是样式层面的测试，目前样式相关的视觉审查是在前置环节独立落地的，还没有和UI自动化深度融合；后续我们也在探索，基于UI自动化执行时的截图做抽象分析，把样式校验的能力也整合进去，目前还在探索过程中。

AI Native测试工程实践：用知识图谱与大模型重构仓储机器人调度系统的端到端测试工作流

告别低效工单排查：拆解Agoda落地AI智能运维的完整迭代路径

软件开发九大反直觉趋势：那些“标准答案”正在失效

为什么Go是AI辅助软件工程的理想语言

开源工具｜把自己伪装成蓝牙鼠标，跨平台控制Android/iOS/鸿蒙--BlueHIDFlow开源方案

汽车软件质量迎来新国标：测试、OTA与缺陷管理进入全生命周期

《“人工智能+软件”专项行动实施方案》印发，对从业者意味着什么？

在金融支付系统中实施混沌工程：企业ECS部署的经验教训