Code Roulette: How Prompt Variability Affects LLM Code Generation

该论文提出了一种与具体编程任务和模型无关的评估流程，旨在量化大语言模型在代码生成中对提示词变异的敏感性，并通过实验验证了该方法的有效性。

要点

这篇论文就像是在给大语言模型（LLM）做一场"代码生成稳定性体检"。

想象一下，你有一个非常聪明的“数字厨师”（大语言模型），你给它看一张菜谱（提示词/Prompt），它就能做出一道菜（代码）。这篇论文的核心问题就是：如果你稍微改动一下菜谱上的几个字，这道菜的味道（代码）会发生翻天覆地的变化吗？

以下是用通俗易懂的比喻和语言对这篇论文的解读：

1. 核心问题：为什么“措辞”很重要？

在传统的软件开发中，人类工程师会把模糊的需求翻译成精确的规格说明书。但现在，普通人直接对着 AI 说话就能写代码。

• 比喻：就像你点外卖。如果你说“我要一份微辣的宫保鸡丁”，厨师可能做得很完美。但如果你说“我要一份稍微有点辣味的鸡丁，带点花生”，或者不小心打错字成了“我要一份微辣的宫保鸡丁”（把“鸡”打成了别的字），AI 厨师做出来的菜可能会完全不一样，甚至做出一盘“炒螺丝”。
• 痛点：不同的人背景不同，表达习惯也不同。这篇论文想搞清楚：AI 是不是太“玻璃心”了？稍微换个说法，它生成的代码是不是就面目全非了？

2. 实验方法：给菜谱“加料”

研究人员设计了一套流程，专门测试 AI 对“菜谱改动”的敏感度。他们用了三种“捣乱”方法：

1. 键盘手滑（Typos）：故意把字打错（比如把 print 打成 prnt，或者把相邻的键按错）。
   • 比喻：就像你在写菜单时手抖，把“糖”写成了“盐”。
2. 同义词替换（Synonyms）：把词换成意思一样的词（比如把“计算”换成“算出”）。
   • 比喻：就像把“微辣”改成“有点辣”。
3. 换种说法（Paraphrasing）：用完全不同的句子结构表达同一个意思。
   • 比喻：就像把“我要一份宫保鸡丁”改成“请给我来一盘鸡肉配花生，稍微带点辣味”。

然后，他们让 AI 分别用这些“被捣乱过”的菜谱做菜，并比较做出来的菜（代码）和原版菜谱做出来的菜有多像。

3. 主要发现：AI 的“脾气”大不一样

研究团队测试了四个流行的 AI 模型（GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash, Llama 3.3），发现了一些有趣的现象：

• 对“手滑”最敏感：
  如果提示词里出现错别字，AI 生成的代码会迅速变得“面目全非”。
  • 比喻：只要菜谱里有个错字，AI 厨师可能就直接开始做“黑暗料理”了，哪怕只错了一个字，菜的味道也全变了。
• 对“换说法”比较淡定：
  如果是同义词或者换种说法，AI 的表现就稳定多了，生成的代码依然很像原版。
  • 比喻：只要核心意思没变，不管你是说“微辣”还是“有点辣”，AI 厨师都能做出差不多的菜。
• 谁是“最稳”的厨师？
  Gemini 2.0 Flash 在应对“换说法”时表现最稳，不容易被带偏。
• 老题 vs. 新题（数据污染问题）：
  • 老题（LeetCode 旧题）：AI 对这些题目太熟悉了，就像背过答案的学生。哪怕你把题目改得乱七八糟，它也能认出这是那道老题，所以生成的代码很稳定。
  • 新题（LeetCode 新题或自创题）：AI 没背过答案。这时候，只要提示词稍微改一点，它生成的代码就会大相径庭。
  • 比喻：如果你考 AI 一道它做过的老题，它闭着眼都能写对；但如果你出一道它没见过的创新题，它稍微听错一点指令，解题思路就全歪了。

4. 为什么这很重要？

这篇论文告诉我们，不能盲目信任 AI 生成的代码。

• 信任危机：如果你和你的朋友分别用不同的话问 AI 同一个问题，你们拿到的代码可能完全不同。这会让代码维护变得很困难（就像两个人用不同的方言写同一份说明书）。
• 建立标准：我们需要知道 AI 在什么情况下会“发疯”，什么情况下比较“听话”。这有助于开发者设计更好的工具，比如当 AI 输出不稳定时，自动提示用户“请重新描述一下需求”。

5. 总结

这篇论文就像给 AI 代码生成能力照了一面X 光片。它发现：

1. AI 对错别字非常敏感，容易“翻车”。
2. AI 对换种说法相对宽容。
3. 如果 AI 背过题（数据污染），它就“装傻”；如果没背过题，它就“看人下菜碟”，稍微改改提示词，结果就大变样。

最终结论：在让 AI 写代码时，我们需要更小心地打磨我们的“提示词”，并且要意识到，即使是微小的输入变化，也可能导致完全不同的代码输出。未来的目标是让 AI 变得更“皮实”，不管你怎么问，它都能给出稳定、可靠的代码。

技术摘要

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

随着大语言模型（LLM）在代码生成领域的广泛应用，降低编程门槛并加速软件开发已成为现实。然而，生成的代码质量高度依赖于用户提供的提示词（Prompt）。

• 核心问题：LLM 对输入提示词的微小变化（变异性）有多敏感？
• 现实挑战：
  • 不同背景、教育程度和编程经验的用户，在描述同一需求时，其提示词的措辞、问题分解方式（Problem Decomposition）和概念框架（Mental Models）存在显著差异。
  • 即使是简单的文本扰动（如拼写错误、同义词替换、改写），也可能导致 LLM 生成截然不同的代码实现。
  • 这种不稳定性影响了代码审查、维护以及用户对生成代码的信任度。
• 研究缺口：现有的基准测试（如 HumanEval）通常使用静态提示词，缺乏对提示词变异性及其对代码输出稳定性影响的系统性量化评估。

2. 方法论 (Methodology)

作者提出了一套通用的 LLM 代码生成敏感性评估流程（Evaluation Pipeline），该流程独立于具体的编程任务和 LLM 模型。

2.1 核心流程

1. 定义函数：
   • $M$：LLM 模型，将提示词 $P$ 映射为代码 $C$。
   • $F$：增强函数，以速率 $r \in [0, 1]$ 对提示词进行扰动。
   • $D$：距离函数，量化两段代码之间的差异。
2. 基准建立：对原始未扰动的提示词生成 $n$ 个独立代码样本作为基准（Ground Truth）。
3. 扰动实验：将增强速率 $r$ 从 0 逐步增加到 1，生成一系列扰动后的提示词，并分别生成代码。
4. 距离计算：计算扰动后生成的代码与基准代码集之间的成对距离，聚合得到平均距离指标，以此衡量模型输出的分布变化。

2.2 提示词增强方法 (Prompt Augmentation)

研究采用了三种模拟用户输入差异的扰动方式：

1. 键盘拼写错误 (Keyboard Typos)：随机将提示词中的字符替换为 QWERTY 键盘上的相邻键（模拟打字错误）。
2. 同义词替换 (Synonyms)：利用 WordNet 数据库，随机替换提示词中的单词为同义词。
3. 改写 (Paraphrasing)：利用 LLM（如 Gemini）的翻译/改写能力，生成语义相似但词汇不同的提示词。

2.3 代码距离度量 (Output Distance Measures)

• 指标选择：使用 TSED (Tree Similarity of Edit Distance)。
• 理由：
  • TSED 基于语法树编辑距离，专门针对代码结构设计，比通用的文本相似度指标（如 BLEU、BERT Score）更能反映代码结构的差异。
  • 实验表明，BERT Score 在代码评估中存在“天花板效应”（分数普遍过高，区分度低），且计算成本远高于 TSED。
  • 注意：该研究关注的是输出的一致性（Consistency）而非正确性（Correctness）。即使生成的代码是错误的，只要结构稳定，对用户而言也是一种可预测的输出；反之，结构剧烈变化则意味着不可靠。

2.4 数据集

研究使用了三个数据集以验证泛化性：

1. LeetCode (Old)：经典 LeetCode 题目（可能存在数据污染，模型在训练集中见过）。
2. LeetCode (New)：2025 年 3 月发布的 LeetCode 新题（确保未出现在训练集中）。
3. Our Dataset：作者自建的 22 个开放式任务（涵盖模拟、算法、数据科学等），无标准答案，旨在模拟真实世界的复杂需求。

3. 主要贡献 (Key Contributions)

1. 评估流程：提出了一种测量 LLM 代码生成对提示词变异性敏感度的标准化评估流程。
2. 多模型敏感性分析：对四种主流 LLM（GPT-4o mini, Claude 3 Haiku, Gemini 2.0 Flash, Llama 3.3 70B）进行了广泛的实验评估。
3. 开源资源：公开了实验代码、自建数据集及评估工具，供社区复现和扩展。
4. 揭示数据污染影响：通过对比新旧 LeetCode 数据集，量化了数据污染对模型鲁棒性的虚假提升作用。

4. 实验结果 (Results)

4.1 不同增强方法的影响

• 拼写错误 (Typos)：影响最大。所有模型在扰动率 0.0 到 0.6 之间，代码相似度（TSED）迅速下降。当扰动率较高导致提示词难以阅读时，代码结构发生根本性改变。
• 同义词与改写 (Synonyms & Paraphrasing)：影响较小。模型对这类语义保持但词汇变化的扰动表现出较强的鲁棒性。代码相似度下降缓慢，且幅度较小。
• 模型稳定性差异：
  • Gemini 2.0 Flash 和 GPT-4o mini 在零扰动下表现出极高的稳定性（温度设为 0 时输出几乎一致）。
  • Llama 3.3 和 Claude 3 Haiku 即使在零扰动下也表现出较高的内部变异性。

4.2 数据集差异与数据污染

• LeetCode (Old)：模型表现出最低的敏感性。由于题目在训练集中，模型能识别出微弱信号，即使提示词被大幅修改，仍能生成相似代码（鲁棒性高，但可能源于过拟合/记忆）。
• LeetCode (New)：敏感性有所上升，但在提示词修改 50% 之前，模型仍保持较好的稳定性。
• Our Dataset (自建)：表现出最高的敏感性。
  • 即使是未修改的提示词，生成的代码相似度也较低（约 0.7）。
  • 仅修改 10% 的提示词，代码相似度即跌破 0.5。
  • 这表明对于非标准、开放式的真实任务，LLM 对提示词的微小变化极其敏感。

4.3 统计显著性

Friedman 检验和 Kruskal-Wallis 检验证实，增强速率对代码相似度有显著影响（$p < 0.001$），且不同数据集之间的敏感性分布存在显著差异。

5. 意义与启示 (Significance)

1. 建立信任：量化 LLM 的敏感性有助于用户理解何时需要提供更多引导（如追问、细化约束），从而建立对生成代码的信任。
2. 指导开发实践：
   • 提示词工程（Prompt Engineering）不仅仅是追求“最佳提示词”，还需要考虑提示词的鲁棒性。
   • 在构建代码生成管道时，可能需要引入后处理技术（如基于距离的平均化）来正则化输出，减少因用户措辞不同导致的代码差异。
3. 基准测试的反思：
   • 现有的基于旧题的基准测试（如 LeetCode Old）可能因数据污染而高估模型的鲁棒性。
   • 未来的评估应更多使用新鲜、开放式的任务，以反映模型在真实场景下的表现。
4. 未来方向：
   • 从单次交互扩展到多轮对话场景的敏感性评估。
   • 结合功能测试（Functional Testing）与结构分析，区分“良性多样性”与“有害的不稳定性”。
   • 研究不同背景用户（如非专业程序员 vs 专家）的提示词差异对模型输出的具体影响。

总结

该论文通过引入“代码轮盘”概念，系统性地揭示了 LLM 代码生成对提示词变异性的高度敏感性，特别是在处理非标准任务时。研究强调了提示词微小变化可能导致代码实现巨大差异的风险，并呼吁在评估和部署 LLM 代码生成工具时，必须将鲁棒性和一致性作为核心指标，而不仅仅是代码的正确性。