当 AI 开始辅助编程，度量代码还有意义吗？

最近我们在客户现场经常被问到，AI 时代来了，还要不要做度量。或者换句话说，既然 AI 都能写代码了，我们度量代码相关的工作还有意义吗？

这个问题在我看来是毋庸置疑的。回到度量的初心，其核心无外乎两点：第一是管理者想看清投入产出比，以此进行合理的资源调配和战略决策。第二是研发需要自证价值，这样才能安心干活。显然 AI 并不能解决这两个问题，与之相反，它的出现反而造成了更多认知鸿沟——业务觉得“写代码越来越简单了”，研发实际操作下来却并不如此。于是双方的信息不对称更严重，这种情况下度量代码的重要性反倒比以往更高了。

或许我们应该问的是，在 AI 时代，怎么把代码度量地更清楚？

代码依然是度量研发工作的根基

提到研发工作的度量大家第一时间应该想到的就是看代码，不仅仅是因为代码的数据好取，还因为代码是研发最直观的产出物以及需求开发最终的交付物，在整个研发环节起到了承上启下的作用。唯有把代码度量清楚，才可以让其他以代码为基石的指标站得住脚，避免沦为另一种形式的主观指标（如只看需求数量，没有代码参考就会导致需求往细了拆）。至于代码是人写的，还是机器写的，并不影响度量的最终结果：

首先，AI 生成的代码，无论初始形态如何，其本身及最终质量依然需要被度量和评估；其次，工程师对 AI 生成代码的审查、修改、调试和完善等后续工作，是新的、不可或缺的工作量，这部分贡献也需要得到有效衡量；最后，研发活动中的根本性问题，如研发部门与业务部门之间对投入产出的理解、对项目进度的预期等，并不会因 AI 的出现而自动消失。这样一来，客观、公正的代码度量，依然是弥合认知鸿沟、建立信任和协作的关键。

但需要注意的是，即便在现在，代码度量的过程也面临各种会影响度量客观性的问题。其中比较典型的是以下几种。

数据波动大抗干扰性差：代码行数容易受书写风格（如空行、换行、注释）影响，导致获取的数据波动性极大，无法提供有效参考；

缺少工作量评估：仅对行数变动统计，未考虑代码实现过程及成本，不同操作/类型的代码工作量差异不能很好地被识别。

统计结果不真实：缺少异常情况处理机制，开发过程的异常 Commit、重复拷贝代码、第三方库文件/自生成文件无法得到有效识别，统计结果水分大、不客观。

代码当量-目前最科学客观的代码度量单位

我们深知，不管是研发工作的度量还是整个度量体系的搭建，都需要代码作为底层基准指标来支撑。思码逸早在 18 年就开始研究代码度量的问题，提出了创新性度量指标“代码当量”，并在后续的客户实践和持续更新中获得了行业和专业机构的认可，代码当量从以下这些角度解决了代码度量的难题：

1. 语法树解析：过去用数行数统计代码工作量之所以不靠谱，是因为增减空行、换行注释这类 “表面功夫” 也会被算进去。现在我们把每次提交前后两个版本的代码都转化成抽象语法树。这就像把代码拆解成一个个语法树节点，自动过滤掉行数、空行、注释这些干扰项，精准聚焦真正有价值的有效代码变更。

2. 编辑操作加权：改动代码时，不同操作的难度不一样。比如新增代码通常比删除代码更费工夫。我们用 tree-diff 算法对比语法树的节点变化，算出最小编辑距离，判断每次改动是插入、删除、更新还是移动操作，再根据操作难度加权（新增>移动>更新>删除）。这样统计出来的工作量就能更准确反映实际编码工作量。

3. 节点类型加权：实现不同类型的代码对应的工作量也不一样。写个if判断语句，肯定比定义个字符串付出的思考要多。所以在计算工作量时，我们会给不同类型的语法树节点进行加权，确保复杂的代码类型能得到合理的工作量评估。

4. 异常 Commit 处理：有些提交可能会产生异常或不合理的工作量数据（如 Merge Commit、Cherry-pick Commit 、Revert Commit）我们会专门处理这类提交，把不合理的工作量剔除掉，避免统计结果跑偏。除此之外，当进行移库/代码库初始化时，也可配置单次提交的增删行上限以过滤掉此类提交的工作量。

5. 重复代码处理：代码里经常会出现重复内容，可能是函数内重复、函数间重复，或者跨文件批量修改重复。这些完全一样或相似度很高的代码如果都 100%计算工作量，显然不合理。当识别到这三种类型会进行相应降权或忽略，避免重复劳动被过度计算。

6. 异常文件处理：

   第三方库依赖：良好的工程实践是通过包管理器安装依赖，而不是把第三方库的源码直接拷贝到代码库中。对于包管理器引入的依赖，我们不会分析；对于直接拷贝到代码库的，我们提供了灵活的文件路径过滤功能，并预设了常见的固定目录（如 vendor 等）。（同时针对 JS 的第三方库，单独做了文件名索引过滤）。

   自生成文件：比如 Swagger、Cython 等都可以自动生成文件，这些文件的内容不是人工编写的，也不该算工作量。我们根据文件名和文件内容特征进行扫描并把它们从统计中排除。规则可根据实际需求调整。

7. 当量汇总计算：最后对所有被编辑的节点的加权结果进行求和之后，即为本次提交的代码当量，并在系统中记录本次提交涉及的文件/函数行数变动、当量等信息，方便后续检验追溯。

当量之外，依然需要人工审查

当然，任何效能度量手段都不可能是完美的，代码当量本身存在一些边界，导致有些特殊情况无法应对，需要人工参与审查。例如

• 非正常使用第三方库的源码：当引用第三方库源码不规范时（如将三方文件拷贝至其他目录），需要用户手动配置路径进行排除。尽管也可以考虑建立广泛的第三方库索引的方式，但索引范围有限，算力消耗过大，性价比不高，得不偿失。

• 跨库重复：受限于分析性能（每跨一个库服务器资源翻倍时间增加），暂不支持跨代码库的重复判断。

• 不重复却无意义的代码：代码当量提供的是静态分析，只能看到代码结构，没法理解业务逻辑，很难判断这些代码有没有实际用处。我们建议用户配合定期的 Code Review 来排除干扰。

• 本可以简洁高效的代码：当量统计的是已经实现的代码，无法识别代码的好坏。即便因为编码经验问题，导致代码不够简洁高效，也会按实际改动计算工作量，因此当量计算的结果并不等价于研发能力，评价代码价值需要结合更多维度的指标共同判断。

• 对同一段代码不停进行增删：每次代码变动都可能蕴含开发思考和调整，无法判断这种操作是否有意义（如代码重构），所以也会计入工作量统计。这时候也需要 Code Review 的介入，确保最终交付的代码质量。

• AI 自动补全或生成的代码：度量的目的是客观评估开发工作量，都是为达成开发目标服务。即便代码是 AI 生成的，也无需特别区分。并且我们也应该鼓励大家使用 AI 提升效率，当量也可用于验证 AI 对开发效率的提升效果。

如何用好代码当量？

代码当量在解决了研发工作度量体系中最重要的数据基准问题，不仅能帮我们打开开发过程的黑盒，也能串联起整个研发环节的度量，让传统的度量指标更有参考意义，同时还能根据交付结果倒推研发过程，在各种工作场景下真正做到让“数据说话”。

以下两个场景为例：

对齐交付指标，让交付结果有意义改进有方向

当量可用于衡量需求大小和代码规模：评估交付工作量时，当量作为需求颗粒度评估单位对各团队工作量进行校准（工作量评估更准确），关联需求开发过程，进一步识别开发过程效能卡点。评估交付质量时，当量作为分母替换传统千行 bug 率用于质量评估（质量评估更客观），关联 bug 与当量，进一步识别开发过程质量薄弱点。

建立数据为导向的价值评定体系

当量可作为投入产出基准：评价研发时，当量作为研发资源投入与其他成本单位关联共同验证业务是否获得预期结果、核心资源投入分布是否符合预期。评价管理者时，当量作为核心产出用于评价团队效率及管理水平是否存在可优化空间。

结语

在当下这个 特殊的节点，人们难免会质疑原有的度量模式是否过时。程序员写代码的方式在变，但业务方的需求却没有改变，管理者仍然需要看清在这个过程中哪些程序员在快速有效的交付价值。代码当量能清晰呈现程序员的真实贡献，为资源调配提供可靠依据，最终弥合分歧，让团队专注于创造真正有价值的产出。在 AI 辅助开发的未来，建立这样透明、公正的度量体系，比以往任何时候都更为重要和迫切。

如果您想进一步了解代码当量，请联系我们，我们将提供一对一咨询服务：https://fs80.cn/r8t45j