AI 智能编码对软件研发生产力的影响（度量）

本文主要通过了解度量，以及如何进行研发效能度量，进而阐述了AIGC对于软件研发产生了什么影响，AI工具相关的度量指标。

​

理解度量

度量从三个层次进行，分别是能力与行为指标、交付效能指标和业务结果性指标：

• 能力和行为指标：反映了技术团队的技术研发行为和能力，属于一种控制型指标，旨在指向可改进的内容。
• 交付效能指标：有助于了解当前研发的交付效能状况，在产品研发团队中，代理业务结果性指标来表现技术团队的成果。
• 业务结果指标：反映了业务的真实成效。

因此，从企业外部的角度来看，需要衡量的是业务结果性指标；从技术团队外部的视角来看，需要评估的是对业务需求响应的效率指标；而技术团队内部改进的依据，则需参考具体的能力和行为指标。 基于这一基本的概念共识，研发效能或IT生产力，就是通过交付效能指标进行度量的维度。

​

研发效能及其度量

研发效能衡量了技术团队持续、快速并高质量交付价值的能力，主要通过速度、吞吐量和质量三个维度来评估。

• 速度：从需求确认到上线的时间周期。
• 吞吐量：在既定人员配置下单位时间内的完成需求数量。
• 质量：产品发布后的水平。

由于软件开发涉及多方协作，研发效能尤为关键。改进措施包括优化协作流程以减少阻塞等待，并提高单个工序的速度和质量。

​

AIGC对于软件研发的影响

在AIGC时代，大模型对软件编程领域产生了显著影响，良好的代码数据结构便于训练成大语言模型，同时开发者大部分时间用于编程活动。因此，评估编码效率应聚焦于开发活动本身，可以从组织层面量化开发效率和开发者主观评价等两个方面进行评估。通过开发速度（代码变更创建至提交时间）、满意度（主观调研结果）和质量（缺陷密度）这些指标，可以衡量大模型对开发效率的提升效果。

​

满意度及个人效率改进主观调研

从对开发人员使用 Qoder CN 的效果的1124份有效问卷中得出：

• 编码工作效率提高：受访者给予了4分以上的评价。
• 保持心流工作状态：71%的受访者给予了4分以上的评价。
• 减少重复代码的编写：77%的受访者给予了4分以上的评价。
• 减少浏览器搜索次数：77%的受访者给予了4分以上的评价。

​

编码的控制性指标（行为和能力）

​

行为指标

如下图所示，展示了开发者在日常工作中使用大模型进行相关工作的次数占比。通过这一数据，能够更清晰地了解具体的开发行为是否与团队的实际期望一致。在此，AI触发的时机在一定程度上反映了开发者日常行为的占比，然而这一数据并不精确。可以借助其他调研途径，以获取更多维度的数据。

​

能力指标

开发速度：AI生成的代码总量 / 单位代码的编写时长。

• AI生成的代码总量：对比人工编写与AI生成的部分。
• 单位代码的编写时长：可以基于当前研发任务的完成时长，即从创建一个分支到完成代码提交所需的时间。
• 主观判断的效率提升。
• 主观判断的满意度提升。

质量：单位变更代码的缺陷数量以及变更代码的缺陷密度（后置统计）。

• 缺陷的属性需包含被引用的代码模块。

​

AI工具的技术指标

​

结果性

• AI生成占比（a.k.a PCW percentage-code-written）：该技术指标反映了AI生成最终代码的比例。当绝大多数代码由人工智能生成而非人工编写时，预计将显著缩短研发任务的完成时间。
• 有效回答：生成的内容是否具备实用性，用户在正常使用过程中能够轻易感知。该部分指标的收集主要来源于用户的交互数据。系统在推送内容后，每条回答均配有一个点赞和点踩按钮，用户可以通过该按钮反馈该推送内容是否具备实用性。

​

技术性

需要相应地针对AI生成的代码占比进行度量。

• AI生成建议采纳率：该技术指标反映了生成代码建议的有效性。
  • 生成代码建议展示次数。
  • 生成代码建议被采纳次数。
• CPO（每次触发机会的生成字符数Characters per opportunity）。
  • 触发率（尝试Attempt rate）。
  • 展示率（反馈Feedback rate）。
  • 接受率（接受Acceptance rate）。
  Copy

  Characters per opportunity = Attempt rate * Feedback rate * 
      Acceptance rate * (Avg Num Tokens / Acceptance) * 
      (Avg Num Characters / Token)
  
  | 参数 | 说明 | |---|---| | 尝试率（Attempt Rate） | 每当用户在编辑器中执行操作（如输入或删除代码）时，AI有机会提出建议，这一过程的频率通过尝试率来衡量。未尝试提供建议的原因可能涉及延迟或需通过上下文过滤器来决定是否进行尝试。 | | 反馈率（Feedback Rate） | 从上下文检索到网络开销及模型推理，建议提出过程中存在明显延迟。若延迟过高，开发者可能在等待期间执行新操作并获得新建议。此外，即便建议完成，也可能因置信度不足或触发抑制过滤器等原因未展示给开发者。反馈率则衡量了最终呈现给开发者并可进行人工反馈（接受或拒绝）的建议。 | | 接受率（Acceptance Rate） | 开发人员对AI提出的编码建议的接受率是一个常被引用的指标，反映了开发人员实际采纳建议的比例，但接受率高并不一定意味着这些建议在开发人员看来是优质的。 | | 平均每次处理的标记数（Avg Num Tokens / Acceptance） | 在相同条件下，长建议和短片段的价值量有所不同。大型语言模型（LLM）以标记（一般为一小段字符）为单位处理输入和生成输出，因此平均每次处理的标记数可以反映接受建议的价值量。 | | 标记的平均字符数（Avg Num Characters / Token） | 开发人员在使用AI智能编码时，面对的是文本而非标记，而不同的语言模型（LLM）可能采用不同的标记器，这意味着若每个标记产生的字符更多，则该模型实际生成的代码量更大。因此，每个标记的平均字符数成为衡量这一现象的关键指标。 |
• RAG的效果指标。
  • 有用性：指生成内容的实际应用价值，用户在正常使用过程中能够明显感知。此外，这一部分的指标收集来源于用户交互数据。系统推送后，每条回答均配备点赞和点踩的功能。
  • 上下文支持率：指在生成内容中，检索到的上下文信息所占的比例。这一指标用于评估最终结果中应用了多少来自知识库的检索内容。
  上下文支持率 = 有检索到的上下文信息进行支撑的生成内容 / 总的生成内容。检索到和问题意图关联程度较强的上下文片段与检索到全部上下文片段的占比，用于评估检索到的上下文信息质量。上下文有效率 = 与问题强相关的上下文片段/检索到的全部上下文片段。最后计算出上下文效率和上下文支持率的调和平均数 H（调和平均数的计算方法是将所有数值的倒数求和，然后再取这个和的倒数，受极端值影响较小）H=a+b2ab​。然后后台每一条问答，都会有a，b，H三个指标数据进行标记。

​

行为分析

整体的采纳率或AI生成占比可能受到的影响因素包括：

• 某门语言存在较大偏差。
• 某位开发者存在较大偏差。

因此，需要根据语言和开发者进行分布统计。建议整体数据分析采用众数或85%控制线，也可继续采用平均数，但需对方差较大的用户进行识别，以深入分析其原因。