AI 写的代码真的活不长吗？20 万个代码单元的答案

关于 AI 生成代码有一条流行叙事：合得快、扔得也快，所谓一次性代码，维护负担只是被推迟到上线之后集中爆发。这个说法直觉顺滑，但一直缺大规模数据的检验。存活分析研究 Will It Survive（arXiv 2601.16809，作者 Musfiqur Rahman 与 Emad Shihab，2026 年 1 月提交、EASE 2026 在审；近日因企业工程博客重新引用而回到讨论热点）给出了相反的答案：AI 写的代码不但不短命，反而活得更久。

怎么测的

方法是把代码当代码库里的生命体做存活分析：201 个开源项目、超过 20 万个代码单元，按署名区分 agent 与人类作者，追踪每个单元此后是否被修改、何时被修改、被哪类修改动过。这个设计直接检验一次性代码假设的预言，即 AI 代码应当更快被删除或重写。

四组数字

核心结果站在直觉对面：agent 所写代码的行级修改率比人类低 15.8 个百分点；被修改的风险比低 16%（风险比 0.842，p 值小于 0.001）。分类型看差异更有意思：AI 代码被纠错的修正型修改比例略高（26.3% 对 23.0%），人类代码则有更多适应性修改，说明两类作者的代码被动的理由不同。研究还很诚实地给了效应量提示：类别关联强度 Cramer V 只有 0.116，且不同 agent 之间的差异大于 agent 与人的差异，把 AI 代码当同质群体下结论会失真。预测侧的发现同样值得记：用文本特征预测哪段代码容易被修改，AUC 0.671 尚可用；预测修改什么时候发生，宏 F1 只有 0.285，基本测不准，作者解读为修改时机主要由外部组织因素决定。

怎么读这份研究

作者的结论句值得原文级转述：瓶颈可能不在生成质量，而在治理代码长期演进的组织实践。对工程团队的操作含义有三条：其一，别再拿代码来源当质量代理指标，AI 占比高不预示维护灾难，人类代码也没自带免疫；其二，评审资源应投向修正型修改高发的模块，而不是无差别盯 AI 产出；其三，修改时机测不准这件事反过来提醒管理者：代码的命运主要由团队流程决定，想改善存活质量，改流程比换模型有效。边界也要交代：样本是开源项目，企业闭源环境未必复现；存活更久也不直接等于价值更高，只是反驳了速朽叙事。引用这份数据时，把 1 月的提交时间与近日翻红的来龙去脉讲清楚，比直接甩结论更有说服力。