前智能体时代，代码当量的主要价值包括三个维度：
- 比代码行更准确地度量代码复杂度规模；
- 与相关指标结合度量人效、质量等；
- 作为基础指标校准需求交付相关统计。
新的 AI 原生软件开发时代，代码当量在上述维度的价值依然成立，并且更加彰显。
- 准确度量代码复杂度规模是代码治理的基础
是不是代码都靠 AI 生成之后，度量代码规模就变得不再重要了呢？
- 如果是“日抛”或者“月抛”的项目，的确无所谓；否则，基本原则应当是，AI 写的代码与人写的代码同等对待，不应因为代码是 AI 写的而降低观察、评测、控制标准，相反应当加强。
- 从本质出发，代码写的快慢与代码如何治理是两件事情，如果因为 AI 写代码快，就降低代码治理的标准，实则是背道而驰。
- 代码复杂度规模是我们认知项目进展、变更量、产出效率的最直接的手段，也是观察项目所处阶段、质量水平、可控程度的基础（参见第 2 条）。代码当量在剔除传统噪音、避免统计失真外，加入了对 code churn 的处理，AI 短时间内大幅度增删代码的行为会做归并。
- 结合相关指标度量人-智协作效率与质量
- 同时适用于 AI 原生和非 AI 开发的指标包括千当量问题/缺陷/事故率，用以衡量相同变更规模下的质量保证水平。分母采用代码当量才能让统计结果可信，例如开源项目实验反映各个软件版本间如果采用千行 bug 率会呈现数据跳跃无法反映实际水平的问题。
- AI 原生开发模式及转型过程中，初始阶段可通过统计词元（token）量推动团队使用 AI；之后的阶段，团队应开始关注代码词元比，即产出代码当量与投入词元量的比值。代码词元比越高，代表 ROI 更好、智能体更具自主性、人-智交流协作更高效，毕竟词元背后是真金白银的成本。
- AI 原生开发模式及转型过程中，工程师的关注点应逐步从代码转为规约（spec），即对用户需求和系统设计的规范化条目化描述。为此，我们可以计算规约代码比，即规约变更项数除以代码当量。AI 转型过程中，规约代码比应逐步提高，但过高会让规约代码一致性保证面临挑战，项目维护成本增高。研发团队可着眼项目自身情况，从时间等维度进行观察、对比和调整。
- 衡量业务价值交付所必须的需求统计
不论是否采用智能体、是否转型 AI 原生，软件工程最终都以完成需求的方式交付业务价值，而业务方永远希望排队的需求能更多、更快地完成。因此，对需求价值流的统计依然是最重要的结果指标。而每个需求的颗粒度或复杂度各异，单算个数会让结果的准确度大打折扣。有团队在尝试使用 AI 对需求复杂度做预估，但大模型靠读需求描述猜复杂度好比“快思考”，永远比不上真正实现中的“慢思考”，会存在很大幻觉；以往人都难以预估准确，包括使用功能点（FP）方法，不是上了 AI 就自动解决问题，还要占用紧张的词元配额。所以，在需求完成后通过代码当量做“决算”依然是最经济准确的途径。AI 时代利用规约驱动实践，采用需求对应的规约项数和实现后的当量加权平均，作为需求复杂度或颗粒度指标，是无需额外人力和词元成本同时又足够准确的评估方法。
因此，需求吞吐率/交付周期需要控制需求颗粒度（或大小/复杂度），或者根据需求颗粒度进行校准。
- 如果需求规约已经条目化了，即采用类 EARS 的模式表达（参见 GEARS），那么条目数可以作为一个需求颗粒度的指标（注：规约规范化条目化的过程同样可借助 AI 完成）。只有在这样的框架下，才能采信 AI 输出的准确度。需求颗粒度可以结合规约项数以及实现对应的代码当量，采用加权平均等简单算法。
- 如果需求还没有表达成规约，在传统开发模式下，应用需求对应代码当量作为需求颗粒度的一部分指标，和 AI 根据需求描述的评分结合，才能让结果变得可靠。
