AI出码率70% 的背后：高德团队如何实现AI研发效率的量化与优化 - 链载Ai

随着AI技术的快速发展，AI辅助编程已成为提升研发效率的重要手段，也是不可逆转的编码新方式。AI编程工具也从原本根据上下文自动生成补全代码片段发展到以Cursor为首的各种AI编辑IDE及CLI工具，这些工具将编码效率提升至前所未有的高度。在这一背景下，国内外许多公司都在宣传AI工具帮开发者提升多少效率，但问题是如何通过指标准确衡量这些工具带来的研发效率提升呢？同时由于不同的AI编程工具各具特点和功能，也会为指标衡量带来挑战，主要聚焦为两点：无统一的指标量化体系及AI工具多样化带来统计数据挑战，如下图所示：

过去几个月，围绕建立统一的数据采集和指标体系这一核心问题，我们从零搭建AI统一数据采集能力，覆盖团队同学使用AI工具，定义了AI出码率等核心指标，逐步构建了AI效率研发指标体系。通过持续迭代优化，实现从指标量化到问题识别、再到工具使用效果优化的数据驱动闭环。

在定义指标过程中，我们主要遵从真实性原则，以最终提交到Code平台代码作为有效代码的衡量标准，因为只有这样，才能保证代码的质量和流程规范。在这个原则基础上，通过分析团队成员的Git提交数据以及采纳AI生成代码的情况，来评估AI编程工具的使用效果和研发效率提升情况。具体指标定义如下：

AI出码率主要用于衡量AI工具生成的代码在最终提交代码中的有效占比。主要定义如下：

AI采纳行数：统计周期内AI生成中与commit提交逐行的匹配得到的代码行数。

commit的代码总行数：统计周期内用户Git提交记录的代码总行数。

以AI出码率为核心质量指标，围绕其我们建立了一些其他指标进行分析与参考，一些其他指标如下：

针对整个高德信息工程团队和前端团队进行指标统计，团队成员AI Coding主要以使用的编辑器为Cursor和Qoder为主。以我所在前端团队整个8月指标统计为例，最终效果如下：

团队的整体出码率从30%上升至70%以上(6月-8月)，基于效率体系相关指标计的统计情况，我们进行了相关分析及优化，主要包括：

整个指标评价体系建设系统方案及系统如下图，基于分层架构设计实现了从数据采集能力建设、平台能力搭建、指标数据分析的业务闭环。

在AI研发效率指标建设中，其核心能力是围绕数据的统一采集及指标体系进行搭建，在确定对应的指标体系后，我们对数据采集进相关调研及实践。

该部分主要为了采集AI会话过程中的生成的代码及会话等相关数据，数据的全面性才能让指标更丰富，当前主流的方案主要包括以下三类：

主要思路是基于Git提交信息中的标准化AI标识，利用Git的特性，自动在提交说明中添加AI coding签名，实现提交级的统计效果，统计粒度为提交级(commit为粒度)。详细可见[1]

该方案主要基于Git blame机制实现行级代码归属追踪，通过实时监听IDE编辑事件自动切换Git作者身份，结合Diff算法精确统计AI生成与人工代码相关信息，将统计粒度从"提交级"细化到"编辑级"，采用"最后修改者原则"，实现统计行级精准追踪。

针对Cursor等AI编辑器，可通过逆向工程识别其存在的本地数据库文件，直接获取AI生成代码记录，实现AI生成信息的全部获取，包括AI会话历史记录、AI出码数据等所有结构信息。三种方案各有优缺点，主要对比如下：

一开始我们主要使用Cursor，主要基于本地数据库逆向方案进行数据采集和分析，初期我们主要基于Cursor提供的vscdb进行数据采集，其优点是准确度高，支持场景多（如能做到Tab信息采集、行内采集、会话信息采集等）；但缺点也很明显，比如版本变更可能回导致数据库存储结构变化、导致我们需要更新代码，同时只支持Cursor编辑单一场景。

随着集团生态发展和外部不可控因素，我们的采集思路也经历了从工具集成到智能生态、从"被动统计"到"主动优化的采集转变。

5.2.1 基于MCP协议标准化采集方案

该方案的主要思路是基于提示词强制触发+MCP执行，精确的提示词可以触发MCP的强制执行，而MCP能读取文件数据。

5.2.2 提示词设计及优化

在使用MCP进行自动采集数据功能之前，团队的已有规范体系存在一些问题，这些问题会影响了AI工具生成代码的质量和效率，也会导致MCP收集工具部分失效。现有规则存在以下两个问题：

为了尽可能的减少项目规则和保证规则的强制触发，我们进行了优化。最后整理出两个主要的规则，业务规则和智能采集规则设定，规则根据项目不同通过插件识别自动注入。

业务规则基于分层分模块的结构化设计采用了知识库外置 + 动态查询的方式进行优化，采取措施如下

规则的策略设计如下图，只需按照以下策略针对不同的项目进行书写即可。

该部分的规则主要是为了保证每个项目中都遵守。针对不同IDE可能配置的位置和方式有差异，比如Qoder，没有用户规则，只能配置在项目规则中，所以采用了基于插件进行规则注入的方式，让用户无感。主要的规则建设如下：

# MCP 自动数据采集规则 (强制执行)
## 核心原则-**有文件内容变更**→ 必须记录-**无文件内容变更**→ 不需要记录
## 触发条件-**文件内容变更操作前**: 使用 write, search_replace, MultiEdit, create_file, delete_file 等会修改文件内容的操作前 → 调用 `beforeEditFile`-**文件内容变更操作后**: 文件变更完成后 → 调用 `afterEditFile` -**每次对话结束**: 每轮对话结束时 → 调用 `recordSession`
## 操作分类### 需要MCP记录的操作（文件内容变更）- `create_file` - 创建新文件-`delete_file`- 删除文件-`search_replace`- 搜索替换内容-`edit_file`- 编辑文件内容-其他任何会修改文件内容的操作
## 执行流程```# 纯对话（无文件变更）对话结束 → recordSession
# 文件内容变更操作 beforeEditFile → [文件变更操作] → afterEditFile → recordSession
# 只读分析操作（不触发MCP）[读取分析操作] → 分析结果 → recordSession```
## 强制要求-**100%覆盖**: 不允许任何遗漏或跳过-**严格配对**: 每次beforeEditFile必须有且仅有一次对应的afterEditFile调用，不允许遗漏、跳过或合并操作-**会话一致**: 整个对话开始时应确定一个统一的sessionId，并在所有后续对话轮次操作中保持该ID不变-**绝对路径**: 必须列举所有涉及文件的绝对路径
## 违规处理-**即时检测**: 每次文件操作后立即自检配对完整性-**强制纠正**: 发现遗漏立即停止并补充缺失调用-**重新执行**: 违规操作必须重新执行整个流程
## 常见违规案例1.**合并记录**: 将多次操作合并到一次afterEditFile ❌2.**遗漏配对**: beforeEditFile后未调用对应的afterEditFile ❌3.**跳过记录**: 直接进行文件变更操作而未调用MCP工具 ❌4.**路径错误**: 使用相对路径而非绝对路径 ❌5.**错误触发**: 对只读操作（如read_file）也调用beforeEditFile/afterEditFile ❌

5.2.3 采集数据效果

AI采集数据目前在Cursor中还使用本地数据库逆向方案，在Claude Code、Qoder中使用的是基于规则触发+MCP自动采集方案。通过将两种方案结合，我们能支持大多数的AI编码工具，虽然可能会有一定的缺失率，但总体在可接受范围内。

出码计算概览展示每个项目每个文件的AI出码情况，同时可以针对单文件进AI出码详情查看。

出码率指标统计主要是在收集数据后，进行的定时任务计算，主要包括数据准备阶段、代码匹配分析阶段、指标计算阶段。

5.3.1 指标计算流程

5.3.2 构建多维度的AI出码率指标

对于AI出码率这一核心质量指标，在不同时期，我们也进行了系列优化，针对不同场景进行数据分析和使用，指标发展变化如下图：

不同的AI编程工具有各自的特点，但与他们协作的方式始终是围绕需求任务拆解和命令执行。AI研发效率指标体系的构建，可以帮我们看清楚AI编程工具的在开发中真实数字。

更为关键的是出码率作为指标体系中的一个关键点，被定义成我们大团队的整体目标，其与我们整体发展方向高度契合，能够实时观测到团队的AI coding化程度，同时出码率也发挥了强大的牵引作用，将团队成员从被动接受AI编码转向主动探索AI编码。通过持续的实践和反馈，逐步建立起团队成员对AI编码的信心和依赖，最终变成日常工作习惯。最终在不到3个月的时间内，整个大团队完成了从传统手工编码到AI辅助编码的转变，这种快速转型不仅提升了开发效率，更重要的是每个人都学会与AI对话和交流。

AI编辑器类型	对话方式展示	数据采集展示
Qoder
Claude Code

出码计算概览	文件详情