一般提示词生成的代码漏洞百出，通过提示词工程 (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：

示例（全技术组合 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?
角色设定能小幅提升代码质量，但所有提示技术（包括角色设定）对代码质量的整体影响都不算显著