AI出码率70%+的背后：高德团队如何实现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对话效率。

• 使用时长信息：记录工具实际使用时间，评估工具粘性。

• Tab补全相关：用来观测Tab在整个出码率中的占比。

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

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

• 针对AI不适用场景进行优化：及时发现在开发需求中，AI效果不佳的环节和项目类型，通过rule沉淀、结合MCP工具进行文档查询，提示编码效率及场景优化。

• 持续调整工具使用策略：通过指标数据反馈，循环改进AI工具使用策略，比较不同AI编程工具和使用方式表现，推荐交互友好、出码效率高的编码方式。

• 沉淀AI工具使用最佳实践：及时总结高效使用AI工具的方法和经验模式，助力新人快速提升开发效率。比如邀请出码率高的同学进行团队分享、组织相关AI Coding比赛等。

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

主要模块包括：

• 多IDE基础插件建设：通过插件化方式实现对各种AI编辑IDE(Cursor、Qoder等)的适配，进行插件能力建设。插件核心能力包括：

• 采集能力：包括本地库读取(Cursor)、指标数据收集(Tab采集、AI会话数据采集、AI出码数据采集等)、数据处理及上报等能力；为不同的开发工具提供统一的数据上传处理服务。

• 本地适配：针对每个IDE，建立对应的适配（Cursor、Qoder、AoneIde等）机制。

• AI驱动的核心能力建设：

• 规则管理：根据项目类型、IDE类型动态注入项目规则，实现规则动态注入和智能生成。

• MCP集成：通过插件动态注入MCP配置，基于MCP实现部分IDE出码数据自动采集和文档自动查询。

• 平台及指标

• 平台能力：实现对采集数据的持久化存储，提供定时任务调度能力、计算出码指标及对外提供数据服务。

• 指标展示：基于平台提供服务，展示个人出码指标、团队指标等，同时提供部分数据分析能力。

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

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

 基于AI coding工具的签名方法

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

 IDE插件采集方案

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

本地数据库逆向方案

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

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

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

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

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

为什么要采用这种方案？

• 兼容所有IDE平台：所有AI编辑器相通的提示词和MCP，可以针对每一次AI对话或指令进行独立统计，兼容性强，可以针对大多IDE和CLI工具。

• 未来标准化方案：虽然由于模型质量原因或幻觉，可能会出现MCP不执行的原因，但其是一种更标准化、更可控、也更有潜力的未来方向，使得采集能力不再依赖于插件的私有实现，而是成为一种可插拔的能力。经过测试，数据采集也基本符合预期。

• 工程复杂度极小：实现简单，比本地数据库逆向方案复杂度大大降低。

如何用于出码数据采集？

• 提示词触发：书写每次会话能强制执行MCP Tool的规则（提示词在以下章节），规则可以通过插件自动注入或手动注入。

• MCP执行与收集：

• 模型型通过MCP协议，在变更文件前，调用提供的beforeEditFile工具，记录需要变更前的涉及的文件路径。

• 在编辑文件后，再次调用afterEditFile工具，记录需要变更后的涉及的文件路径。

• 对比记录开始和结束时代的文件代码差异，准确计算出本次对话的AI出码数据。

   主要流程如下图：

该方案也存在一定的缺点，主要如下：

• 数据统计无法保证完全统计，可能丢失： 依赖于用户使用提示词调用，可能会由于模型质量、提示词过多导致模型幻觉，从而执行失效，无法追回数据。

• 无法做到无感采集：不能无感地统计所有AI出码代码，MCP tool执行会有工具会有提示。

5.2.2   提示词设计及优化

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

• 主要的规则都沉淀在IDE中，很多属于强制执行规则，存在规则冗余和冲突的现象。

• 信息过载严重会干扰AI判断。

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

（1） 项目业务规则优化

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

• Rule只保留核心协作逻辑，规范统一存储在知识库中。

• 通过MCP文档查询工具实现文档动态精准查询。

• 针对某些业务场景不需要的规则类型，按需获取信息，避免过载。

规则主要优化设计思路如下：

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

（2） 智能采集规则设定

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

MCP 自动数据采集规则

# 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  指标计算流程

主要流程如下：

• 数据准备阶段：主要是获取Git数据和AI出码数据，进行预处理工作。

• 代码匹配分析阶段：主要工作是基于AI出码数据和Git数据进行有效行匹配。

• 指标计算阶段：针对不同维度、不同版本的出码率指标进行统计，获取分析数据。

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

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

• 基础统计阶段指标V1：基于AI代码被采纳行数进行计算与git提交数据进行计算，git提交数据会去除一些特殊标注文件，如项目配置(package.json等）、依赖包(node_modules等)。但可能会受噪声影响，如项目脚手架自动生成代码等会被计入。

• 优化过滤阶段V2：该指标降低大规模重构对指标的影响，过滤删除文件等信息，是个人日常分析的较好选择。

• 分位数增强版：该指标是一种基于统计学分位数理论的评估方法，通过历史数据的分布特征来参与V1或V2出码率计算，去除异常值影响，主要用作适合团队趋势分析等。

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

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