The Impact of Prompt Programming on Function-Level Code Generation

摘要
一般提示词生成的代码漏洞百出，通过提示词工程 (prompt programming / or prompt
engineering)来改善代码生成的质量
自建数据集（涉及7000余条经过提示词工程的提示词），在3个LLM上探讨代码生成的质量、相似性等。
结果：发现了一些提示词工程对于代码生成的优化无用。并且需要在质量和正确性上做出权衡

结合标题和摘要，本文探究的是提示词工程对于代码生成的影响。

结论：
1.在代码生成上提示词工程并没有想象的那么有作用
2.提供要生成的函数示例，要生成的函数类型，函数签名，能够显著提高代码生成的正确率
3.正确性和质量二者不可兼得。
后续工作：
研究代码生成的其它度量(如性能)；
探索研究结果是否适用于其它的代码生成任务（line completion, program repair, or the generation
of full applications）。

过程：自建数据集、进行实验、评估
方法：
A. Prompt Technique Combinations
5种提示词工程技术+1种（原始提示词）在3种模型上进行对比，提示词有7000余条（是用于完成200多种任务的）。
论文对这5种技术进行组合使用共得到32种+1种原始 提示词
下面是提示词示例，包含了所有的5种提示词工程技术

示例（全技术组合 P25，来自 Fig.2）：
任务描述：Convert nanoseconds to a time in fixed format.
约束：Respond with a Python function in one code block

角色设定：As a software developer who follows best coding practices for maintainability...
思维链：Think carefully and logically, explaining your answer step by step.
少样本：For example, if the input is 4523 and 3600, the output is 01:15:23-01:00...
函数签名：The function signature is: def hyrate_time (nanoseconds, tz=None)
包列表：The function has access (but does not necessarily use) the following packages: time pytz datetime

原始提示词：Convert nanoseconds to a time in fixed format.

7000多个提示词的来源：

实施时，先为 221 个任务匹配 32 种 ID 对应的技术组合模板，再填充各任务的具体信息（如专属的函数签名、包列表、少样本示例），最终生成 7072 个（221 任务 ×32 组合）Prompt。

B.CodePromptEval（自建数据库）

选择CoderEval Python dataset通过单元测试淘汰未通过单元测试的的datapoints，得到221个datapoints（包含：① 代码生成需求（如 “将纳秒转换为固定格式时间”）；② 人工编写的基准函数（ground truth）；③ 对应的测试用例（验证生成代码正确性））
通过移除代码生成需求中不相关的内容，称之为zero-shot prompt

prompt templates：

此模板动态填充，若一条提示词中不涉及某种提示词工程技术则去除该项提示词工程技术。
如仅仅使用persona和signature,则对应的提示词如下：

示例（全技术组合 P25，来自 Fig.2）：
任务描述：Convert nanoseconds to a time in fixed format.
约束：Respond with a Python function in one code block

角色设定：As a software developer who follows best coding practices for maintainability...

函数签名：The function signature is: def hyrate_time (nanoseconds, tz=None)

C. Code Generation:
通过云端部署（开源）和云端调用（非开源）两种方式进行，后者存储回答内容。输入7000多个提示词进行代码生成。

D. Evaluating the LLM-Generated Functions
(correctness, similarity, and quality)3个角度评估7000个提示词生成的代码
首先correctness，调用自建数据集中的测试代码对生成的代码进行单元测试，得出False or True，使用了断言，设定了每个函数的最长执行时间60s。
pass@1:语法、语义均正确，通过单元测试。

pass@1 衡量的是LLM 在单次生成尝试中，所产出的函数通过对应测试用例的概率，即对某一代码生成任务，模型一次生成的函数同时满足句法正确（语法有效、可运行）和语义正确（通过 CoderEval 的单元测试 / 主函数测试），则判定为 “Pass”，Pass@1 即为该类任务的通过率。
similarity衡量和自建数据库中人写的代码的相似度。
采用CrystalBLEU指标（CodeBLEU 的改进版，更严格），解决传统 n-gram 指标对 Python 关键字等 “无意义语法” 的过度匹配问题，步骤为：
预处理：移除生成函数和基准函数的签名（避免签名提示技术带来的相似度偏置）；
计算逻辑：融合 1-4 元 n-gram 特征，剔除跨函数的通用语法，同时兼顾句法相似度和语义相似度，量化生成代码与人类代码的风格、结构、逻辑契合度；
结果分析：对比不同提示技术组合下的 CrystalBLEU 得分，分析哪些技术能让 LLM 生成更贴近人类的代码。

Quality 部分仅仅为能够运行的函数代码来衡量复杂度

代码复杂度：采用两个工业界通用指标，结合配对 Wilcoxon 检验和Vargha Delaney A12量化复杂度差异的显著性和效应量：
圈复杂度（Cyclomatic Complexity）：通过 Radon 工具计算，衡量代码的分支 / 循环复杂度；
认知复杂度（Cognitive Complexity）：通过专用 Python 工具计算，衡量人类理解代码的难度；
对比基准：将生成代码的复杂度与人类编写的基线函数对比，判定 “降低 / 不变 / 升高”，并量化效应量（可忽略 / 小 / 中 / 大）

---

RQ1：How do different LLMs perform on CodePromptEval?
结论：大体上无差别，差别受任务难道影响
RQ2：To what extent do different prompting techniques (and combinations of them) impact the code generation of LLMs?
RQ2.1：How do prompt techniques impact the correctness of the code?
RQ2.2：How do prompt techniques impact the similarity of the code to a human-written baseline?
函数签名（函数名、参数、返回值）有助于提升代码生成的人工相似度和准确性。
原文对于函数签名的理解：

Signature is a line of code that includes the signature of the function to generate. The signature includes the function name, the input parameters, and (optionally) the output.

RQ2.3：How do prompt techniques impact the quality of the code?
角色设定能小幅提升代码质量，但所有提示技术（包括角色设定）对代码质量的整体影响都不算显著

下面是AI内容

论文研究问题RQ1-RQ2及对应结果总结

该论文围绕大语言模型（LLM）函数级代码生成，提出两大核心研究问题（RQ1、RQ2），其中RQ2作为研究核心拆解为3个子问题，通过全因子实验、自定义数据集CodePromptEval和多维度量化分析得出结果，核心覆盖不同LLM性能差异和提示技术（及组合）对代码生成的影响两大方向，以下是各研究问题及结果的精准总结：

RQ1：How do different LLMs perform on CodePromptEval?

研究问题：不同大语言模型在CodePromptEval数据集上的函数级代码生成表现如何？
研究对象：GPT-4o、Llama3-70B-Instruct、Mistral-Small-Instruct-2409（22B）三款当前代LLM，聚焦整体通过率、失败类型、代码难度对性能的影响、核心错误分布四大维度。

核心结果

1. 整体性能接近，小幅差距：三款模型通过率均在46.9%~52.2%之间，GPT-4o表现最优（52.2%），Llama3次之（50.5%），Mistral最差（46.9%），最优与最差模型差距仅约5个百分点。
2. 性能与代码难度强相关：所有模型的通过率随代码依赖难度提升显著下降，标准库级简单任务通过率近90%，类级最复杂任务通过率仅31%_{41%；仅在自包含任务中，GPT-4o比另外两款模型领先10}13个百分点，这也是其整体性能略优的主要原因。
3. 失败类型分层：失败代码分为句法（语法错误）、语义（逻辑不符测试）、操作错误（运行时异常），其中GPT-4o句法错误率最低（0.4%），Mistral最高（1.5%）；三款模型均以操作错误为主要失败类型（28.6%~34.9%）。
4. 核心错误类型集中且存在模型差异：失败代码中最常见的错误为断言错误（AssertionError，逻辑不符预期）和类型错误（TypeError，对象类型判断偏差）；Mistral更易出现导入错误（ImportError）和命名错误（NameError），而GPT-4o和Llama3的属性错误（AttributeError）占比更高。
5. 关键结论：当前代主流LLM在函数级代码生成上的性能整体趋同，无显著优劣之分，性能表现主要受任务难度影响，而非模型本身的巨大差异。

RQ2：To what extent do different prompting techniques (and combinations of them) impact the code generation of LLMs?

研究问题：不同的提示技术及其组合，在多大程度上影响大语言模型的函数级代码生成效果？
研究前提：选取5种基础提示技术（少样本Few-shot、思维链CoT、角色设定Persona、函数签名Signature、包列表Packages），构建32种所有可能的组合，以零样本（无任何技术）为基线，从正确性、与人工代码的相似度、代码质量三个维度分析影响，并拆解为3个子问题。

RQ2.1：How do prompt techniques impact the correctness of the code?

研究问题：提示技术如何影响生成代码的正确性（句法+语义均正确，能通过测试）？
评估指标：Pass@1（单次生成通过测试的概率）、错误类型分布、多线性回归统计显著性。

核心结果

1. 仅两种技术有显著正向影响：函数签名、少样本是对代码正确性唯一有统计显著正向影响的提示技术，二者组合为最优方案（Pass@1达57.5%），单独使用函数签名也能大幅提升正确性。
2. 其他技术无显著影响，部分单独使用效果差：CoT、Persona、Packages对正确性无统计显著影响；单独使用CoT效果最差（Pass@1仅47.1%），包列表单独使用也会导致低通过率。
3. 技术组合无增益，甚至适得其反：多技术叠加不会显著提升正确性，全技术组合的效果反而不如仅“函数签名+少样本”；额外添加信息可能降低性能，如在签名基础上叠加无关技术会小幅降低Pass@1。
4. 技术对错误类型的改善有针对性：函数签名/少样本能显著减少类型错误、属性错误、导入错误；包列表虽能减少常规导入错误，但若包含LLM不熟悉的本地包，会引发幻觉式导入（导入不存在的函数）。
5. 带签名的提示失败多为逻辑错误：含函数签名的提示生成的代码，若失败多为断言错误（逻辑不符），但代码可正常运行；无签名的提示易出现句法/运行时错误，代码无法正常执行。

RQ2.2：How do prompt techniques impact the similarity of the code to a human-written baseline?

研究问题：提示技术如何影响生成代码与人工编写基准代码的相似度？
评估指标：CrystalBLEU分数（比CodeBLEU更严格，剔除Python关键字等无意义词汇，衡量词法+语义相似度）、线性混合效应回归。

核心结果

1. 所有生成代码与人工代码相似度均较低：三款模型的CrystalBLEU分数仅7.5%~16.8%，说明LLM生成的代码与人工编码思路仍有显著差异。
2. 两种技术显著提升相似度：函数签名、角色设定能显著提高生成代码与人工基准的相似度；函数签名通过限制解空间让代码结构贴近人工，角色设定引导模型遵循人工编码规范。
3. CoT的影响存在模型差异性：CoT能提升Llama3生成代码的相似度，但会显著降低GPT-4o和Mistral的相似度。
4. 少样本单独使用降低相似度，组合可缓解：单独使用少样本会降低代码的词汇相似度，但若与CoT/角色设定/函数签名组合，可将相似度提升至10%以上。
5. 技术组合整体提升相似度：叠加更多提示技术（如签名+角色+CoT）通常会小幅提升相似度，零样本的相似度为所有方案中最低。

RQ2.3：How do prompt techniques impact the quality of the code?

研究问题：提示技术如何影响生成代码的质量（仅评估通过测试的正确代码）？
评估指标：代码坏味道（Pylint检测）、圈复杂度（Radon）、认知复杂度（cognitive-complexity），通过Wilcoxon检验、Vargha Delaney A12量化效果大小。

核心结果

1. 核心权衡关系：正确性与代码质量此消彼长
   • 提升正确性的技术（函数签名、少样本）会导致代码坏味道更多、圈复杂度更高（如71%的少样本生成代码缺少描述性文档字符串）；
   • 对正确性无增益的技术（CoT、Persona、Packages）能显著减少代码坏味道，降低复杂度，提升代码可维护性。
2. 角色设定的质量价值：指定“遵循最佳编码实践的软件开发者”角色，能小幅提升代码质量，但会以轻微降低正确性为代价。
3. 所有技术均不会提升代码复杂度：LLM生成的代码复杂度均不高于人工基准，要么与人工代码持平，要么略低；无任何提示技术组合会导致代码复杂度上升。
4. 模型对复杂度的影响大于提示技术：提示技术对代码复杂度的影响仅为小效应，而模型本身的差异更显著——Llama3生成的代码圈复杂度和认知复杂度显著低于GPT-4o和Mistral，是三款模型中生成代码最简洁的。
5. 零样本也能生成低复杂度代码：无任何提示技术的零样本方案，生成的代码复杂度也低于人工基准，与CoT/Persona的效果相近。

RQ2 整体核心结论

1. 提示技术对当前代LLM函数级代码生成的整体影响有限，最佳与最差提示组合的正确性差距仅约10个百分点，无需过度强调复杂的提示编程；
2. 函数签名/少样本是最有价值的提示技术，核心作用是提供函数接口上下文，但会限制模型的“创造性”；
3. 提示技术存在正确性与可维护性的固有权衡，无单一/组合技术能同时提升这两个指标；
4. 提示技术的效果存在模型差异性，需针对不同LLM定制提示策略，而非通用方案；
5. 多技术组合无协同效应，甚至会相互抵消优势，建议按需选择单一/少量组合，避免过度叠加。

论文中研究的 5 种提示技术（few-shot learning、Chain-of-Thought、persona、function signature、list of packages）

Few-shot Learning（少样本学习）
核心定义：通过提供少量 “输入 - 输出” 示例，让 LLM 无需微调就能理解任务逻辑和输出格式，快速适配目标代码生成需求（论文 3.A 节）。
论文中的实现方式：
每个示例遵循 “若输入为 X，则输出为 Y” 的自然语言描述格式，不直接提供完整函数代码（避免冗余）；
每个任务固定提供 2 个示例，分别覆盖 “典型场景” 和 “边缘场景”，确保覆盖核心预期行为；
示例由 3 位作者共同设计并验证正确性，避免主观性导致的引导偏差。
核心作用：隐含传递函数的输入输出格式、参数处理逻辑，帮助 LLM 减少对任务意图的误解，显著提升代码生成的正确性（RQ2.1 关键结论）；但单独使用会降低代码与人工基准的相似度，需与其他技术组合缓解。
2. Chain-of-Thought (CoT，思维链)
核心定义：引导 LLM 在生成代码前 “分步推理”，明确解决问题的逻辑步骤，避免直接输出结果导致的逻辑跳跃或错误（论文 3.A 节）。
论文中的实现方式：
采用 “Zero-shot CoT” 模式（不预先指定具体推理步骤），仅通过提示 “Think carefully and logically, explaining your answer step by step”，让模型自主生成推理过程；
推理过程与代码生成分离，先输出逻辑步骤，再给出代码块，确保推理对代码的引导作用。
核心作用：帮助 LLM 梳理复杂逻辑（如时间格式转换、条件判断嵌套），减少语义错误；但单独使用对正确性提升有限（Pass@1 仅 47.1%），且对不同模型影响有差异 —— 提升 Llama3 的代码相似度，却降低 GPT-4o/Mistral 的相似度（RQ2.2 结论）。
3. Persona（角色设定）
核心定义：为 LLM 指定特定角色，使其从该角色的视角和行为准则出发生成代码，强化代码的风格一致性和质量属性（论文 3.A 节）。
论文中的实现方式：
固定角色为 “遵循最佳编码实践的软件开发者”（具体描述：“As a software developer who follows best coding practices for maintainability such as avoiding code smells and writing simple and clean code”）；
角色描述放在提示开头，优先引导模型的编码准则，再补充其他技术信息。
核心作用：显著提升代码质量—— 减少代码坏味道（如缺少文档字符串、不必要的 else 语句）、降低认知复杂度；但存在 “质量 - 正确性” 权衡，使用后代码通过率会轻微下降（RQ2.3 关键结论）；同时能提升代码与人工基准的相似度（RQ2.2 结论）。
4. Function Signature（函数签名）
核心定义：明确提供待生成函数的 “接口信息”，包括函数名、输入参数（含默认值）、可选返回值，直接限定函数的核心结构（论文 3.A 节）。
论文中的实现方式：
从 CoderEval 基准的人工代码中直接提取原生签名，确保准确性（如 Python 示例：def hyrate_time(nanoseconds, tz=None)）；
签名作为独立模块插入提示，位置在角色描述和任务目的之后，避免与其他信息冲突。
核心作用：
直接限定函数的参数数量、名称和默认值，大幅减少 TypeError（类型错误）、ImportError（导入错误） 等运行时错误（RQ2.1 结论）；
限制模型的解空间，显著提升代码与人工基准的相似度（RQ2.2 结论）；
与少样本组合为 “最优正确性方案”（Pass@1 达 57.5%），但会增加代码复杂度和坏味道（RQ2.3 权衡关系）。
5. List of Packages（包列表）
核心定义：提供函数运行环境中可访问的库 / 模块列表，明确依赖资源，避免模型因未知依赖导致的导入错误或功能缺失（论文 3.A 节）。
论文中的实现方式：
通过解析原始代码的 import 语句，提取依赖的本地模块和外部库（如time、pytz、datetime）；
提示描述明确标注 “函数可访问但不必使用”（“The function has access (but does not necessarily use) the following packages”），避免模型强制导入未用到的库（减少 W0611 代码坏味道）。
核心作用：
减少因依赖未知导致的导入错误，帮助模型正确调用辅助函数（如时间处理用datetime）；
若列表包含 LLM 不熟悉的本地包，可能引发 “幻觉导入”（尝试导入不存在的函数），需谨慎筛选包列表（RQ2.1 补充结论）；
单独使用对正确性提升有限，但与 CoT、persona 组合可减少代码坏味道（RQ2.3 结论）