论文技术总结：AI 生成代码尚不可复现（Yet）：基于 LLM 的编码代理中的依赖差距实证研究

1. 研究背景与问题定义 (Problem Definition)

随着大语言模型（LLM）作为编码代理的兴起，软件开发的效率有望大幅提升。然而，AI 生成代码的可复现性（Reproducibility） 尚未得到充分探索。现有的基准测试（如 HumanEval, MBPP）主要关注代码的功能正确性，却假设运行环境已经完美配置，忽略了环境配置和依赖管理中的关键故障模式。

本研究提出的核心问题是：当开发者仅使用 LLM 提供的代码、依赖声明和说明，在干净的操作系统环境中运行时，生成的代码能否成功执行？

作者引入了**“可执行可靠性”（Executable Reliability）** 这一指标，定义为：在仅使用 AI 提供的依赖和指令的干净环境中，项目成功执行的概率。

2. 方法论 (Methodology)

2.1 实验设置

• 评估对象：三个最先进的 LLM 编码代理：
  • Claude Code Agent (Opus 4.1)
  • OpenAI Codex Agent (0.52.0)
  • Gemini Code Agent (2.5 Pro)
• 数据集：基于 100 个标准化提示词（Prompts），每个代理生成 3 种语言（Python, JavaScript, Java）的项目，共 300 个完整项目。
  • Python: 40 个提示
  • JavaScript: 35 个提示
  • Java: 25 个提示
• 提示词设计：明确要求生成“完全可复现”的代码，包含完整的依赖文件（如 requirements.txt, package.json, pom.xml）和使用说明。
• 实验环境：使用 AWS EC2 实例（Ubuntu 22.04），每次测试前重置为仅包含 91 个基础系统包的纯净环境，确保无残留依赖干扰。

2.2 三层依赖分析框架 (Three-Layer Dependency Framework)

为了量化复现失败的原因，作者提出了一个三层依赖框架：

1. 声明依赖 (Claimed Dependencies, $D_c$)：LLM 在配置文件中明确列出的依赖。
2. 工作依赖 (Working Dependencies, $D_w$)：经过手动调试（修复导入错误等）后，使代码能够运行所需的最小依赖集合（$D_w = D_c \cup D_{missing}$）。
3. 运行时依赖 (Runtime Dependencies, $D_r$)：代码实际执行时加载的所有依赖，包括所有传递性依赖（Transitive Dependencies）。

通过比较这三层，计算两个关键指标：

• 完整性差距 (Completeness Gap)：$|D_w| - |D_c|$，即 LLM 遗漏了多少依赖。
• 运行时倍数 (Runtime Multiplier)：$\rho_{runtime} = |D_r| / |D_c|$，揭示声明依赖与实际加载依赖之间的膨胀程度。

2.3 评估流程

1. 零干预执行：尝试在纯净环境中仅使用 LLM 提供的依赖运行代码。
2. 失败分析：对于执行失败的项目（31.7%），应用迭代依赖解析算法 (Algorithm 1) 进行手动调试，记录错误类型（代码 Bug、缺失依赖、环境问题等），但不计入成功。
3. 工具支持：使用 SciUnit (Python)、npm list (JavaScript) 和 mvn dependency:tree (Java) 捕获真实的运行时依赖树。

3. 关键发现与结果 (Key Results)

3.1 整体可复现性

• 总体成功率：仅 68.3% (205/300) 的项目能够在零干预下成功执行。
• 失败率：31.7% 的项目直接失败，平均每个失败项目需要 15 分钟 的手动调试时间。
• 依赖爆炸：在成功的项目中，声明的依赖与实际运行时加载的依赖之间存在巨大差距。平均运行时倍数为 13.5 倍（即声明 3 个依赖，实际运行需加载约 37 个包）。

3.2 语言差异显著

不同编程语言的生态系统复杂性导致复现率差异巨大：

• Python: 89.2% 成功率。依赖结构扁平（requirements.txt），错误信息清晰。
• JavaScript: 61.9% 成功率。npm 的自动解析有一定帮助，但嵌套依赖和 devDependencies 区分导致问题。
• Java: 44.0% 成功率。Maven 的 XML 配置复杂，传递性依赖图深，版本冲突解决困难。

3.3 代理（Agent）的隐性专长

研究发现不同 LLM 在不同语言上表现出显著的非均匀性能（未在厂商文档中公开）：

• Gemini: Python 复现率 100% (40/40)，但在 Java 上仅 28.0%。推测其训练数据偏向数据科学（Python 主导）。
• Claude: 表现最均衡，Java 复现率高达 80.0% (20/25)，显著优于其他模型。
• Codex: Python 表现良好 (87.5%)，但在 Java 上表现最差 (24.0%)。

3.4 错误类型分布

在 95 个失败项目中，缺失依赖并非主要原因：

• 代码生成错误 (Code Bugs): 52.6% (50 例)。包括文件路径错误、未初始化变量、异步处理错误、XML 格式错误等。这是导致不可复现的首要原因。
• 未处理/无法解析 (Not Processed): 16.8%。代码格式严重损坏，无法被解析或尝试运行。
• 依赖缺失 (Dependency Errors): 仅 10.5%。即 LLM 忘记声明必要的包（如 ImportError）。
• 环境冲突: 4.2%。

3.5 具体案例

一个典型的机器学习项目，LLM 声明需要 3 个包（scikit-learn, pandas, matplotlib），但实际运行时加载了 52 个包（包括 numpy, scipy, joblib 等传递依赖），倍数高达 17 倍。

4. 主要贡献 (Key Contributions)

1. 实证研究：首次系统性评估了 LLM 生成完整项目（而非代码片段）在干净环境中的可复现性，揭示了当前 LLM 编码代理在“开箱即用”能力上的严重不足。
2. 新指标提出：定义了**“可执行可靠性”，并提出了三层依赖框架**（声明、工作、运行时），量化了依赖管理的复杂性和 LLM 的盲区。
3. 揭示隐性成本：指出 AI 生成代码的失败主要源于代码逻辑错误而非依赖缺失，且存在巨大的运行时依赖膨胀（平均 13.5 倍），这对开发效率和科学可复现性构成了巨大挑战。
4. 发现模型特异性：揭示了不同 LLM 在不同技术栈上的性能差异（如 Gemini 擅长 Python，Claude 擅长 Java），挑战了“通用模型”的假设。

5. 意义与启示 (Significance)

• 对软件开发的影响：AI 生成的代码目前更像是一个“高级自动补全”工具，而非独立的开发伙伴。31.7% 的失败率和 15 分钟/次的调试成本构成了巨大的隐性技术债务。
• 对科学研究的警示：如果研究人员直接使用 LLM 生成分析脚本而不验证依赖，将加剧 AI 领域的可复现性危机，导致实验结果无法被他人复现。
• 对基准测试的改进：现有的基准测试（如 HumanEval）不足以评估 AI 编码能力，未来的基准必须包含环境配置和依赖完整性的评估。
• 未来方向：
  • 训练数据：LLM 需要基于包含完整依赖链、Docker 文件和 package-lock 的完整项目进行训练，而不仅仅是代码片段。
  • 自我修正：LLM 应具备在干净环境中自我测试、发现缺失依赖并修正代码的能力（自动化调试）。
  • 工具选择：组织应根据具体的技术栈（如 Java 企业应用 vs Python 数据科学）选择特定的 LLM 模型，而非盲目信任通用基准。

结论：AI 生成的代码在语法上可能正确，但在执行上下文（Execution Context）上往往是不完整的。在 LLM 学会指定完整的执行环境之前，它们生成的代码仍面临严重的可复现性危机。