LOC
Lines of Code
代码行数 · 软件工程中最古老也最具争议的度量指标
- 定义
- LOC（Lines of Code）是DevOps领域的专业术语。LOC 通过统计源代码文本行数来衡量软件项目的规模，是软件工程中历史最悠久的度量方式之一。
最后更新：2026-03-29
什么是LOC？
LOC 通过统计源代码文本行数来衡量软件项目的规模，是软件工程中历史最悠久的度量方式之一。它常被用于成本估算（如 COCOMO 模型）和项目规模对比，但因为「写更多代码 ≠ 更高产出」，长期以来饱受争议——尤其在 AI 编程工具普及后，这个指标的失真问题被进一步放大。
- 变体众多：物理 LOC 含空行和注释，逻辑 LOC（SLOC）只计可执行语句
- AI 时代争议加剧：有团队用 AI Agent 将周产出从 1 万行飙到 100 万行，但维护成本同步暴涨
- 常见衍生单位 KLOC（千行代码），用于 COCOMO 等经典估算模型
LOC详解
LOC 起源于上世纪 60-70 年代的软件工程实践，最初用于估算项目工作量和成本。它有两种主要计数方式：物理 LOC 统计所有文本行（含注释和空行），逻辑 LOC/SLOC 只统计包含实际语句的行。LOC 的核心问题在于构造效度极低——它衡量的是「体积」而非「价值」，一个精巧的算法可能只需 20 行，而一段冗余的复制粘贴可以轻松产出 2000 行。2025-2026 年，随着 AI 编程工具大规模普及，LOC 作为生产力指标的荒谬性被彻底暴露：AI 可以轻松生成海量代码，但缺乏验证框架的代码生成本质上是在批量制造技术债务。
公式提示
KLOC = LOC ÷ 1000；常用于 COCOMO 成本估算公式：工作量 = a × (KLOC)^b
LOC的应用场景
正式定义
通过统计程序源代码文本行数来度量软件规模的量化指标。
应用场景
- 软件项目规模估算与成本预测（COCOMO 模型）
- 代码库增长趋势监控
- 不同语言/项目间的粗粒度规模对比
常见误区
- LOC 越多 ≠ 开发者越高效，精简的代码往往质量更高
- LOC 不能跨语言直接对比，Python 一行可能等于 Java 五行
- AI 生成的高 LOC 不代表高产出，可能只是在批量制造技术债务
实际案例
📌 AI Agent 的 LOC 幻觉
2026 年初，某团队宣称用 AI Agent 将每周代码提交量从 1 万行提升到 100 万行，且团队成员已数月未打开 IDE。这一案例迅速引发行业讨论——产出百倍增长的背后，维护成本和代码质量如何保障成为核心质疑。
📌 GitClear 大规模代码分析
GitClear 对 110 个开源仓库、超 75 万次提交的分析显示，原始变更行数与实际有效代码贡献之间存在巨大漏斗损耗，进一步证明 LOC 作为生产力指标的局限性。
LOC的参考来源
关于LOC的常见问题
- LOC 和 SLOC 有什么区别
- LOC 通常指物理行数（含空行和注释），SLOC 只统计包含实际代码语句的行。实际使用中两者经常混用，具体含义取决于工具和团队约定。
- 为什么不应该用 LOC 衡量开发者生产力
- LOC 衡量的是代码体积而非价值。优秀的重构可能减少数千行代码，而复制粘贴能轻松膨胀行数。用 LOC 考核会激励写冗余代码，与工程目标背道而驰。
- AI 时代 LOC 指标还有用吗
- 作为规模参考仍有一定价值，但作为生产力指标已基本失效。AI 工具可以轻松生成大量代码，LOC 与实际产出的关联性进一步断裂。