借助智能体 AI，从 7 年缩短到 7 天

作者 Ghazi Triki 2026年8月12日 · 阅读约需 4 分钟

本文目录

如果您曾盯着一张 COCOMO II 电子表格，看着它为一个团队两个迭代就交付的项目预测出 33 个日历月，那么您已经明白问题所在：当今生产中使用的每一种估算模型，都是在这样一个世界里校准的：开发人员逐行敲代码，切换上下文要付出代价，日历在下午 5 点就停止走动。 那个世界已经不复存在。我们最近从零开发了一款规模达 286 KLOC、672 个文件、包含多个子系统的应用，涵盖协议层、数据层、渲染引擎和平台集成，并在 7 天内完成了可供测试的 Alpha 版本。整套模型（COCOMO 基本/中级/后体系结构模型、功能点、SLOC 基线、Putnam/SLIM）给出的预测中位数为 30.3 个日历月。生产力倍数的中位数为 4,240 倍。即便是最保守的基线（复杂系统每人日 25 行 SLOC），偏差也达到 1,433 倍。模型本身没有错，错在用法。下文将逐一拆解各模型的估算，介绍基于同一作者的实证校准，并梳理 2024 至 2026 年随机对照试验（RCT）文献对智能体 AI 究竟在哪些环节压缩工期、又在哪些环节无能为力的结论。

打破所有估算的项目

在 RIADVICE，我们最近开发了一款复杂且功能丰富的应用，它需要在分布式架构中协调多个子系统。由于市场需求要求全新的实现，我们将其构建为原生跨平台环境，以单一代码库覆盖移动端和桌面端。代码库本身说明了它的规模：

286,662 行 SLOC（约 286 KLOC），分布在 672 个源文件中
总变更量 1,329,399 行：新增 862,488 行，删除 466,911 行
在 7 个实际开发日内提交 700 次，完成首个可供测试的 Alpha 版本
完整的国际化支持，覆盖数十种语言区域
多个彼此毫不相关的子系统，包括协议处理、数据管理、渲染和平台集成，全部针对目标环境从零构建

这不是一层封装，也不是简单的换皮，而是从底层开始的原生实现，旨在满足现有方案无法满足的市场需求。在写下第一行代码之前，我就在项目中接入了一款自研分析工具，随着代码库的增长，持续对其运行整套业界标准的软件工作量估算模型。目的很坦诚：衡量经典模型的预测与 AI 辅助交付的实际产出之间的差距。结果并非四舍五入的误差，而是量级上的断裂。

估算模型的预测与实际情况对比

该工具运行软件工程文献中所有主要的估算模型：COCOMO 基本模型（有机型、半独立型、嵌入型）、COCOMO 中级模型（半独立型和嵌入型，已调校）、COCOMO II 后体系结构模型（已调校）、功能点、SLOC 生产率基线以及 Putnam/SLIM，并采用原始文献公布的常数，按项目类型进行校准。

估算模型	预测工作量	预测日历工期	相对实际的加速倍数
COCOMO 基本模型（有机型）	913 人月	33.3 个月	2,282 倍
COCOMO 基本模型（半独立型）	1,696 人月	33.7 个月	4,240 倍
COCOMO 基本模型（嵌入型）	3,200 人月	33.1 个月	8,000 倍
COCOMO 中级模型（半独立型，已调校）	1,259 人月	30.4 个月	3,148 倍
COCOMO 中级模型（嵌入型，已调校）	2,376 人月	30.1 个月	5,940 倍
COCOMO II 后体系结构模型（已调校）	1,703 人月	30.3 个月	4,257 倍
功能点（粗略估算）	17.9 人月	7.5 个月	45 倍
SLOC 生产率基线（每人日 25 行 SLOC）	573 人月	573.3 个月	1,433 倍
Putnam/SLIM	跳过（工期不足 30 天，T 4/3 项发散）	不适用	不适用

所有模型的生产力倍数中位数为 4,240 倍。 即便是最保守的模型，预测的交付时间也比实际情况长约 1,400 倍。最乐观的功能点模型仍预测需要 7.5 个日历月，比实际的 7 天长 45 倍。按照这些模型，该项目本应耗时 7 个月到 47 年不等。而 Alpha 版本 7 天就已可供测试。

模型之间的分歧高达 50 至 8,000 倍

这些模型彼此并不一致。在同一个代码库上，预测结果从 17.9 人月到 3,200 人月不等，相差 178 倍。SEAA 2013 基准研究在 51 个真实项目上评估了 COCOMO II、SEER-SEM、SLIM 和 TruePlanning，发现平均相对误差幅度（MMRE）为 50% 至 100%。2023 年一项基于 COCOMO NASA 数据集的评估发现 MMRE 接近 1.0，PRED(0.25) 为 0.0，没有一个项目的估算落在 25% 误差范围之内。这些模型从未针对 AI 辅助项目而设计。但即便考虑到模型本身的不准确，差距之大也说明某种结构性的变化已经发生。

关于智能体 AI 与开发者生产力，研究究竟说了什么

4,240 倍这个数字非常极端，我不想夸大其词。从零搭建的脚手架会推高变更量，SLOC 也只是衡量价值的一个粗糙指标。因此，我们来看看经过同行评审的文献。Copilot 类助手带来的提升有限但真实。 Peng 等人（2023）发现，使用 AI 结对编程助手的开发者完成任务的速度快了 55.8%（95% 置信区间：21% 至 89%）。微软、埃森哲与一家《财富》100 强企业联合开展的随机对照试验（2025）是迄今规模最大的研究（n=4,867），发现完成任务数增加了 26%。谷歌的内部随机对照试验（2024）发现任务耗时缩短约 21%。国际清算银行（BIS）与蚂蚁集团的实地实验（2024）测得初级员工的代码产出增加 55%。坦诚的结论是：在合适的任务上提升 1.26 至 1.56 倍。 真实存在，但谈不上颠覆。智能体 AI 则处于完全不同的量级。 Cognition 在 2025 年对 Devin 的年度回顾中报告了客户成果：ETL 迁移提速 10 倍，Java 版本迁移提速 14 倍，安全修复提速 20 倍。Nubank 报告称，在一项此前估计需要上千名工程师、耗时数年的数百万行代码重构中，效率提升 12 倍，成本节省 20 倍。我们的移植项目正好落在这一区间：提交直方图显示在 22:00、00:00 和 01:00 出现密集的提交高峰，这正是智能体驱动会话的典型特征。反面证据同样真实。 Metr.org 在 2025 年开展的随机对照试验（16 名资深开发者，在成熟项目上完成 246 项任务）发现，AI 使完成时间增加了 19%，也就是说，在熟悉的代码库上，AI 反而拖慢了资深开发者。2026 年一项针对 807 个采用 AI 工具的 GitHub 仓库的双重差分研究（He 等人，MSR ’26）发现，开发速度的提升是“短暂的”，而代码复杂度的增加却是“持久的”，并最终导致长期的减速。论文标题已说明一切：Speed at the Cost of Quality（以质量换速度）。共识是：AI 对从零开发和结构化开发帮助很大，对代码补全类任务帮助有限，而在成熟代码库上可能损害开发速度。 质量债务是真实存在的。

模型为何失灵：三大结构性转变

经典模型的所有成本驱动因子中，没有一项能描述“开发者拥有一个从不休息、能把整个代码库装在上下文里的自主智能体”。以下三项转变压缩了工期曲线：

打字瓶颈已经消失。

模型假设相当一部分工作量是机械性的：样板代码、脚手架、重复性重构、本地化资源以及其他结构化数据。在这次移植中，大量内容都是高度规则的文本和连接代码，智能体可以批量生成或转换。即便是原本需要手写的代码，如脚手架、构造函数、平台胶水代码，如今也是成批生成，而不是逐行敲出。

上下文切换的成本正在消失。

人在协议层、数据层和渲染引擎之间切换时，每次都要付出重新加载上下文的代价。而一个已经读过全部 672 个文件的智能体只需付出一次。在如此规模的代码库上，这种不对称会迅速累积放大。

日历不再是瓶颈。

模型通过人员配置方程将人月换算为日历月，而这一方程假设的是人类的工作日。智能体会话可以通宵运行。提交直方图显示，从 07:00 到 01:00 产出持续不断：每天活跃 18 小时，而不是 8 小时。

基于同一作者的实证校准

参数化模型之间的分歧达到数个数量级，因此我还进行了一项跨项目的实证校准：在同一生态系统中的另外三个生产仓库上，比较我本人采用智能体 AI 工具前后每人日的代码变更量：

项目	AI 之前每人日变更量	AI 时代每人日变更量	倍数
项目 A（负载均衡器）	673	2,056	3.1 倍
项目 B（报告服务）	239	2,127	8.9 倍
项目 C（处理服务）	1,322	982	0.7 倍
汇总（平均值／中位数）	不适用	不适用	4.2 倍／3.1 倍

同一作者、同一领域、真实的维护工作。实证倍数为 3 至 9 倍，远比从零开发得出的 4,240 倍保守，与已发表的智能体 AI 研究结果的上限相吻合。其中一个项目甚至变得更慢：收益取决于任务，并非普遍适用。

这对项目规划意味着什么

如果您仍在用未经校准的模型和每天 25 行 SLOC 的基线来估算软件项目，那么在 AI 辅助的工作上，您的估算会偏差一到三个数量级。以下是我们在 RIADVICE 的做法：

以自身历史数据进行校准。 比较您自己在使用 AI 前后每人日的代码产出。这样做成本更低、更真实，得出的 3 至 9 倍区间也能在项目计划中站得住脚。
区分从零开发与维护工作。 智能体 AI 的倍数在从零开发和结构化开发中最大，在成熟代码库的维护中最小（有时甚至为负）。不要对两者套用同一个数字。
为质量债务预留预算。 AI 带来的速度伴随着复杂度的持续上升。规划一个加固阶段并做好度量：在每次发布时跟踪圈复杂度，并运行复制粘贴检测。
估算整条曲线，而不只是前段。 如果 10 倍的速度提升让缺陷密度翻倍，那就不是真正的 10 倍提升，而是以更长的稳定收尾期为代价把进度提前。

结论

一个所有估算模型都认为需要 7 个月到 47 年的项目，在 7 天内就完成了可供测试的 Alpha 版本。4,240 倍的中位数倍数不应成为任何人的项目计划。但它清楚地表明，压缩复杂软件开发工作量的那股力量，也正在压缩其工期。已发表的研究显示，AI 带来的效果从 1.26 倍的小幅提升到 20 倍的跃升不等，在成熟代码库上存在负回报的真实风险，还会带来可度量的质量代价。那些告诉我们这个项目需要几十年的模型，至今仍在企业的估算表格中运行。问题不在于智能体 AI 是否改变了项目工期，研究已经给出了答案。问题在于，您的估算实践是否跟上了这些证据。如果您的数字仍然来自一个 1981 年基于 COBOL 和汇编语言校准的模型，那么是时候重新校准了，至少不要再相信它打印出来的日程表。