推荐语
高德团队揭秘AI编程效率提升秘诀，从30%到70%出码率的实战经验分享。核心内容： 1. AI辅助编程的行业背景与量化挑战 2. 高德团队构建的AI研发效率指标体系 3. 实现70%+出码率的关键优化策略
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
本文系统阐述了在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比赛等。
整个指标评价体系建设系统方案及系统如下图，基于分层架构设计实现了从数据采集能力建设、平台能力搭建、指标数据分析的业务闭环。
主要模块包括：
在AI研发效率指标建设中，其核心能力是围绕数据的统一采集及指标体系进行搭建，在确定对应的指标体系后，我们对数据采集进相关调研及实践。
该部分主要为了采集AI会话过程中的生成的代码及会话等相关数据，数据的全面性才能让指标更丰富，当前主流的方案主要包括以下三类：
基于AI coding工具的签名方法
主要思路是基于Git提交信息中的标准化AI标识，利用Git的特性，自动在提交说明中添加AI coding签名，实现提交级的统计效果，统计粒度为提交级(commit为粒度)。详细可见[1]
IDE插件采集方案
该方案主要基于Git blame机制实现行级代码归属追踪，通过实时监听IDE编辑事件自动切换Git作者身份，结合Diff算法精确统计AI生成与人工代码相关信息，将统计粒度从"提交级"细化到"编辑级"，采用"最后修改者原则"，实现统计行级精准追踪。
本地数据库逆向方案
针对Cursor等AI编辑器，可通过逆向工程识别其存在的本地数据库文件，直接获取AI生成代码记录，实现AI生成信息的全部获取，包括AI会话历史记录、AI出码数据等所有结构信息。三种方案各有优缺点，主要对比如下：
5.2 我们的方案：
从本地数据库逆向方案到MCP协议标准化采集方案
一开始我们主要使用Cursor，主要基于本地数据库逆向方案进行数据采集和分析，初期我们主要基于Cursor提供的vscdb进行数据采集，其优点是准确度高，支持场景多（如能做到Tab信息采集、行内采集、会话信息采集等）；但缺点也很明显，比如版本变更可能回导致数据库存储结构变化、导致我们需要更新代码，同时只支持Cursor编辑单一场景。
随着集团生态发展和外部不可控因素，我们的采集思路也经历了从工具集成到智能生态、从"被动统计"到"主动优化的采集转变。
5.2.1 基于MCP协议标准化采集方案
该方案的主要思路是基于提示词强制触发+MCP执行，精确的提示词可以触发MCP的强制执行，而MCP能读取文件数据。
为什么要采用这种方案？
兼容所有IDE平台：所有AI编辑器相通的提示词和MCP，可以针对每一次AI对话或指令进行独立统计，兼容性强，可以针对大多IDE和CLI工具。
未来标准化方案：虽然由于模型质量原因或幻觉，可能会出现MCP不执行的原因，但其是一种更标准化、更可控、也更有潜力的未来方向，使得采集能力不再依赖于插件的私有实现，而是成为一种可插拔的能力。经过测试，数据采集也基本符合预期。
工程复杂度极小：实现简单，比本地数据库逆向方案复杂度大大降低。
如何用于出码数据采集？
模型型通过MCP协议，在变更文件前，调用提供的beforeEditFile工具，记录需要变更前的涉及的文件路径。
在编辑文件后，再次调用afterEditFile工具，记录需要变更后的涉及的文件路径。
对比记录开始和结束时代的文件代码差异，准确计算出本次对话的AI出码数据。
主要流程如下图：
该方案也存在一定的缺点，主要如下：
5.2.2 提示词设计及优化
在使用MCP进行自动采集数据功能之前，团队的已有规范体系存在一些问题，这些问题会影响了AI工具生成代码的质量和效率，也会导致MCP收集工具部分失效。现有规则存在以下两个问题：
为了尽可能的减少项目规则和保证规则的强制触发，我们进行了优化。最后整理出两个主要的规则，业务规则和智能采集规则设定，规则根据项目不同通过插件识别自动注入。
（1） 项目业务规则优化
业务规则基于分层分模块的结构化设计采用了知识库外置 + 动态查询的方式进行优化，采取措施如下
规则主要优化设计思路如下：
规则的策略设计如下图，只需按照以下策略针对不同的项目进行书写即可。
（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编辑器类型 |
对话方式展示 |
数据采集展示 |
Qoder |
|
|
Claude Code |
|
|
计算收集视图如下：
出码计算概览展示每个项目每个文件的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对话和交流。
参考链接：
[1]https://ostechnix.com/linux-kernel-ai-coding-assistants-rules-proposal/
针对AI绘画文字生成不准确的普遍痛点，本方案搭载业界领先的Qwen-Image系列模型，提供精准的图文生成和图像编辑能力，助您轻松创作清晰美观的中英文海报、LOGO与创意图。此外，本方案还支持一键图生视频，为内容创作全面赋能。
点击阅读原文查看详情。
粤ICP备14082021号
免费POC，
零成本试错
