Characterizing the Quality Profile of AI-Generated C++ in Production
Michael Tran, Fred Lewis, Kun Yang, Saksham Thakur, Aditya Kini, Aditya Patil, Milad Hashemi, Parthasarathy Ranganathan
cs.SE, cs.AI
2026-08-07
一年 352 万次提交实测:AI 生成的 C++ 更爱写显式循环、少用标准库,多吃 5-8% 算力;喂分类反馈能把静态告警降 11.1%。
AI 代码助手让工程师写得更快,这几乎没人否认。争议在另一头:这些助手写出来的代码,质量到底怎么样?此前的答案大多来自受控实验,给定 prompt、跑 benchmark、或者把模型生成的片段拿出来单独评。这种设置看不到真实工程里代码被反复改、被 review、被合进主干、最后跑在线上的全过程。生产环境才是代码真正产生成本的地方,但生产环境有可观测性壁垒,很难知道哪一行是谁(人还是模型)写的,更难把它和后来的算力开销对上。
这篇论文在一家的内部把这个壁垒拆掉了。作者团队(Milad Hashemi、Parthasarathy Ranganathan 等,从名单和「数十亿日活」的描述看基本是 Google)在一套被 review 门禁覆盖的大型 monorepo 里,对 2025 年 4 月到 2026 年 4 月整整一年的 C++ 改动作了大规模实证:352 万次提交、覆盖 1046 万行带溯源信息的 C++ 代码。核心问题是,AI 生成的代码有没有一种可识别的、能撑过 review 并在生产里兑现成成本的问题画像。
测量最关键的一步是「溯源(provenance)」。作者不是事后去猜哪行是 AI 写的,而是在工程师写代码的当下按字节级记录作者归属,再投射到最终合入的版本上。归属来源涵盖 inline 补全、对话生成、agentic 编辑和变换式编辑四种交互模式,每个功能的「AI 占比」就是归到 AI 功能上的信息字节比例。这比事后用启发式判断源归属要硬,作者也坦承同一字节上人和 AI 的功能会重叠,测量仍有歧义。
围绕这套溯源,作者搭了一个三层静态分析分类法:顶层 5 个质量属性(效率与资源、正确性与安全、可维护性、API 现代性、策略与移植),中层 15 个问题类别(比如 Copy & Allocation Overhead、Interface & Coupling Burden),底层是具体的静态检查模式。再叠一层 AST 级的源码效率分析:数循环、数标准库调用、看 move/copy、看容器插入和 map 访问。算力层面则纵向跟踪一组功能在生产里的 CPU 占比和堆内存占比。
AI 代码的份额在这年里从 29%(2025 年 4 月)涨到 69%(2026 年 3 月),C++ 单独看从 28.6% 涨到 62.8%。量级说明这不是边缘现象。
结构上 AI 的改动更大:中位改动行数 89 行对人 33 行,触及文件数 3 对 2,新代码占比 0.83 对 0.60;单函数反而更短(11 行对 15 行)。静态问题方面,AI 与人的问题率比值(>1 表示 AI 更高):
| 维度 | AI/人 比值 |
| 效率与资源 | 1.23 |
| 其中 Copy & Allocation | 1.39 |
| 其中 I/O 与格式化 | 3.16 |
| 接口与耦合负担 | 1.15 |
| 弃用 API 使用 | 1.41 |
| 正确性与安全 | 0.94 |
有个反差:正确性与安全这一项 AI 反而略低(0.94),它不是「到处都差」。真正系统性的短板集中在效率类,接口与耦合 + 拷贝与分配两类加起来占了正向绝对差距的 82%。
源码层面更直接,AI 用显式循环的频率约是人的 2 倍,调标准库的频率约 0.4 倍,容器插入和 map 访问的低效写法也都到 2 倍。翻译成白话就是 AI 更爱自己手写 for 循环,不爱用 std 算法。
review 和可靠性上,AI 改动的阻塞评论数是人的 1.92 倍,总评论数 1.39 倍,reviewer 迭代次数 1.24 倍,合入耗时 1.19 倍;sanitizer 命中和构建失败率各约 1.3 倍。回滚率 AI 反而略低(约 0.9 倍)。
最贵的是算力。到 2026 年初,AI 密集功能的 CPU 开销相对基线涨到 1.31 倍,人的功能是 1.25 倍,相对多出约 5%;内存是 1.36 倍对 1.25 倍,相对多出约 8%。在一家日活数十亿的公司,5% 的 CPU 是真金白银。
这篇的判断很具体,不是「AI 代码好坏」的笼统结论。它把短板定位到了效率这一类、定位到了「显式循环代替标准库」这一个可操作的点上。对一线团队这意味着两件事:一,code review 抓不住这些局部低效,作者专门查过 review 深度和低效代码存活率,没有明显相关,人工 reviewer 看不出来,得上游的自动化干预;二,这类问题可以喂回去修。
作者自己列了一长串局限。最关键的两条:其一,review 和算力分析都是观察性的,不是因果估计,AI 占比可能和任务难度、作者经验、review 规范混在一起;其二,无法区分这些问题是均匀分布在所有模型版本上,还是被早期较弱的版本拉高的(模型标识被脱敏)。外部有效性上,结论只来自一种语言(C++)、一个 monorepo、一套 review 门禁,迁移到别的语言或组织要打折扣。可复现性也受限,用的是企业内部数据,无法公开,只放出匿名化的分类法和聚合统计。
读下来还有一处存疑:那个 11.1% 的告警下降是在 50 个功能、450 次实现的小基准上测的,规模和生产里的 35 万次可 review 改动差了好几个量级,把它外推成「全公司能省下对应的算力」要谨慎。