我最初的假设是，AI 的影响应该能从 Linux 内核的增长中看出来。如果编程助手让产出代码明显变得更容易，那么增长曲线最近这一段也许会明显变陡。Linux 的历史足够长，可以把这个预期画出来看看。

我测量了 113 个发布版本的源码快照，从 2005 年 3 月的 v2.6.11 一直到 2026 年 8 月的 v7.2，并在图中标出了每个版本。纵轴是 SLOCCount 根据同一组模型参数，估算重新开发各版本代码库所需的人年。这是从代码规模推算出来的指标，不是实际工时记录。

内核确实增长了很多。但我没有看到自己预期中的近期加速。

113 个 Linux 内核发布版本的估算工作量，从 2005 年 3 月的 4,492.75 人年上升至 2026 年 8 月的 37,633.03 人年。近期版本继续增长，但没有明显、持续的加速。
每个点代表一个发布版本的源码快照，大版本和两个端点已突出标出。点击图表可查看全部版本标签；也可以下载 PNG 图片和原始 CSV 数据。图中横轴为日期，纵轴为估算工作量，单位是人年。

估算值从 v2.6.11 的 4,492.75 人年上升到 v7.2 的 37,633.03 人年，约为原来的 8.38 倍。这个倍数说的是工作量估算值。模型是非线性的，不能把它说成代码行数增长到了原来的 8.38 倍。

中间的增长速度并不固定。曲线在 2018 年前后变得平缓，在其他一些时段则上升得更快。我没有看到的是：最近几年出现一次清晰、持续的向上转折，让 AI 的影响一眼可见。

横跨二十年的图可能掩盖变化，所以我又比较了几个区间的平均增量。我以样本中 2018、2020、2022 和 2024 年各年的最后一个发布版本为分界，最后一个区间截至 2026 年 8 月的最终观测。这些只是便于比较的日历分界，并不代表内核开发者开始使用 AI 的时间。

CSV 中的日期 版本区间 估算工作量增量（人年） 每日历年的增量（人年）
2018-12-23 至 2020-12-13 v4.20 至 v5.10 3,562 1,804
2020-12-13 至 2022-12-11 v5.10 至 v6.1 5,689 2,854
2022-12-11 至 2024-11-17 v6.1 至 v6.12 3,716 1,920
2024-11-17 至 2026-08-16 v6.12 至 v7.2 2,940 1,685

最后一列的算法是：先用间隔天数除以 365.2425，得到经过的年数，再用估算值的变化量除以这个年数。表中数值在计算完成后四舍五入到整数人年。这些是基于代码规模的估算值的变化率，不能用来推算有多少工程师在开发内核。

在这些区间中，2020 年末到 2022 年末的平均增量最大，后面两个区间反而慢一些。这不能证明 AI 让开发变慢了，但也很难指着这组数据，说最近出现了明显的代码增长爆发。这是描述性的比较，不是正式的趋势突变检验，也不是对 AI 影响的因果估计。

测量方法需要解释一下。我用一个 Python 脚本枚举正式发布版本的标签，提取每个标签对应的源码树，再运行 David A. Wheeler 的 SLOCCount。SLOCCount 排除空行和注释，按照自身的语言识别和文件筛选规则统计源码行数。默认规则还会过滤内容重复的文件，并尝试排除自动生成的代码。所以，这里测量的是该工具所识别的发布版本源码树，而不是某台机器实际编译进内核的代码。

脚本对每个版本都传入 --effort 4.646 1.12，对应的 COCOMO 工作量计算公式为：

estimated person-years = 4.646 × (KSLOC ** 1.12) / 12

KSLOC 表示统计到的源码行数，以千行为单位。保持参数不变，可以让不同版本使用同一把尺子，但这并不能验证绝对工作量估算是否准确。系数缩放纵轴，指数改变曲线形状。尤其是，即使每年新增的代码行数固定不变，随着代码库变大，模型给出的工作量增量也可能越来越大。

CSV 中的日期采用 UTC 提交日期，缺失时退回到标签日期。早期的 v2.6.11 是一个没有可用时间戳的树标签，所以脚本补入了已记录的发布日期：2005 年 3 月 2 日。每一行描述的是那个快照中现存的代码，并没有累计所有曾经写出、后来又被替换或删除的代码。

这一区别直接影响结果的解释。AI 助手可以帮助开发者理解子系统、诊断缺陷、编写测试，或者用更小的实现替换更大的实现。它也可能让同样数量的代码用更少的时间完成并被接受。这些变化都可能有价值，却未必让这条曲线变陡。在 COCOMO 参数固定的情况下，只要统计到的源码规模相同，工作量估算就相同，与代码究竟怎么写出来无关。

开发流程的其他环节也可能构成限制。如果代码审查、测试或集成限制了最终进入发布版本的内容，代码生成变快就未必能让发布源码树增长得更快。新增和删除也可能相互抵消。这些只是影响可能没有在图中显现的几种解释；仅凭增长曲线无法区分它们。

因此，我能支持的结论很具体：在这项以发布版本为单位的 Linux 内核增长测量中，我没有发现明显与 AI 有关的加速。 这次初步分析考察的是发布版本的规模。底层 Git 历史还有更多值得研究的内容：提交频率、贡献者活跃程度、补丁大小、代码增删量，以及不同子系统中被接受的变更类型。提交说明也可能保留审查者署名，或明确披露 AI 的辅助使用情况。如果这些记录能提供有用的证据，我们会再回来研究。

这里提供 CSV 数据、统计脚本和 gnuplot 脚本，供检查或复用。要重新绘图，把 CSV 和 gnuplot 脚本下载到同一目录，然后运行：

gnuplot plot-linux-effort.gnuplot

要重新统计源码，可以向 Python 脚本传入 --repo /path/to/linux 和 --fetch-tags。脚本需要 Git、SLOCCount、Python 3.9 或更新版本，以及有足够内存容纳临时源码树的 Linux 或 macOS 环境。数据使用 David A. Wheeler 编写的 SLOCCount 生成。

我最初的假设预期曲线会出现明显的转折。图里没有，我不能自己画上去。