大语言模型代码生成提示指南：一项实证研究 Guidelines to Prompt Large Language Models for Code Generation: An Empirical Characterization
通过迭代优化实验提炼10条代码生成prompt改进指南，并验证其实际应用价值
前置知识
Zero-shot Prompting
零样本提示是指不提供任何示例的情况下，直接通过自然语言指令让大语言模型完成任务的方法。在代码生成场景中，开发者只需描述函数的功能需求，LLM就会根据其训练知识生成相应的代码实现。这种方法的优势是简单快捷，但也容易因为描述不够精确而导致生成的代码不符合预期。
本文研究的核心就是如何优化zero-shot prompt，使其能够生成正确的代码，理解这一概念是理解全文研究目标的基础。
Prompt Engineering
提示工程是指设计和优化输入给大语言模型的文本提示，以获得更准确、更符合预期的输出。它包括选择合适的指令措辞、提供必要的上下文信息、定义输出格式等多个维度。好的prompt engineering可以让同一个模型在相同任务上产生截然不同的结果质量。
本文的目标就是为代码生成场景提供系统化的prompt engineering指南，这是全文的研究主题。
Test-driven Optimization
测试驱动优化是一种通过运行测试用例来验证代码正确性，并根据测试失败的反馈信息来迭代改进代码的方法。在本文中，作者将这一思想应用于prompt优化：先用prompt生成代码，运行测试，如果失败则根据错误信息优化prompt，直到生成的代码通过测试。
这是本文方法论的核心创新点，作者通过这种自动化的方式收集了大量prompt优化的实际案例，为提炼指南提供了实证基础。
Code Generation Benchmarks
代码生成基准测试是用来评估LLM代码生成能力的标准化数据集。本文使用的三个benchmark各有特点：BigCodeBench包含1140个真实世界Python任务，涉及139个库；HumanEval+和MBPP+分别扩展了经典的HumanEval和MBPP，将测试用例数量增加了80倍和35倍，提供更严格的正确性验证。
这些benchmark是本文实验的数据来源，了解它们的规模和特点有助于理解实验结果的统计意义。
研究动机
尽管大语言模型已被广泛用于代码生成任务，但开发者在编写prompt时缺乏具体的、针对软件开发场景的指导。现有研究主要关注通用prompt优化技术（如ProTeGi、PromptAgent等），这些方法将prompt优化视为黑盒操作，通过强化学习或搜索算法自动调整prompt，但它们没有为开发者提供可理解、可操作的具体指南。此外，软件开发的prompt有其特殊性——需要包含技术栈信息、函数规格说明、输入输出格式、异常处理需求等特定元素，这些都超出了通用prompt优化的范围。研究发现，即使是微小的prompt元素缺失（如未说明某个异常场景、变量名不一致）都可能导致生成的代码无法通过测试。
本文的目标是本文的目标是通过实证研究建立一套针对代码生成的prompt优化指南体系。具体来说，作者希望通过自动化实验收集prompt优化的实际案例，从中提炼出可复用的改进模式，并通过从业者调查验证这些指南的实际使用情况和感知有用性。研究旨在回答三个核心问题：(1) 哪些信息应该包含在prompt中以最大化代码生成成功率？(2) 这些指南在多大程度上反映了开发者的实际做法？(3) 从业者如何看待这些指南的有用性？
与已有工作不同的是，本文的独特切入角度在于它不是提出新的自动化优化算法，而是从实证出发，通过让LLM自己学习如何改进prompt来发现哪些改进是有效的。这种方法的核心洞察是：如果一个prompt经过迭代优化后能够生成正确的代码，那么对比原始prompt和优化后prompt的差异，就能发现哪些信息是代码生成所必需的。与现有工作相比，本文更注重生成可理解的、人类可操作的指南，而不是一个不透明的优化系统。
核心方法
本文的方法可以概括为一个「由失败驱动的学习过程」。想象一下，你让一个学生解数学题，他反复做错，然后你告诉他错在哪里，他逐渐学会了正确的解法——本文把这个过程中学生学会的东西（即prompt应该包含什么信息）提取出来。具体来说，作者首先用基准测试中的原始prompt让LLM生成代码，筛选出那些LLM总是失败的任务；然后通过迭代优化过程，让LLM根据测试失败的反馈改进代码，直到通过测试；最后让LLM对比原始prompt和最终成功的代码，自动生成一个改进后的prompt。通过对比原始prompt和改进prompt的差异，作者提炼出了10条具体的优化指南。
本文的核心创新点不是提出新的优化算法，而是设计了一个巧妙的「prompt考古学」方法来发现有效的改进模式。关键洞察在于：如果给LLM提供测试失败的反馈，它能够通过迭代生成正确的代码，那么这个过程中积累的经验——即哪些信息缺失导致了最初的失败——可以通过让LLM分析前后prompt的差异来显式提取。这不同于传统的prompt优化方法（如梯度下降或强化学习），那些方法产生的优化结果是不可解释的；而本文的方法产生的是一组人类可读的、可复用的指南。
方法步骤详情
方法分为五个主要步骤：(1) 初始代码生成：从BigCodeBench、HumanEval+、MBPP+三个benchmark中选取任务，使用GPT-4o mini、Llama 3.3 70B、Qwen2.5 72B、DeepSeek Coder V2四个模型各生成10次代码，筛选出所有10次都失败的任务。(2) 代码优化迭代：对失败任务进行最多5轮优化，每轮将原始prompt、之前生成的代码和测试错误信息提供给LLM，让它生成新的代码，直到通过测试。(3) Prompt优化：将整个优化过程中积累的信息（原始prompt、所有失败的代码和错误、最终成功的代码）提供给LLM，让它生成一个改进后的prompt。(4) 验证：用改进后的prompt重新生成代码10次，如果至少有一次通过测试，则认为优化成功，记录prompt_original和prompt_optimized配对。(5) 手动分析：三位作者分工分析627个成功优化的案例，通过diff文件识别prompt中的具体改进点，经过讨论和合并，最终形成10条指南。
技术新颖性
本文的技术新颖性体现在三个方面：首先，方法论上采用「由LLM自己发现改进模式」的思路，而非人工定义或黑盒优化，这使得发现的指南具有实证基础；其次，研究设计上将代码优化过程和prompt优化过程分离——先通过代码优化收集成功案例，再通过prompt优化提炼改进指南，这种两阶段设计避免了直接优化prompt可能带来的过拟合问题；最后，评估上不仅分析了自动优化的结果，还通过50位从业者的调查研究验证了指南的实际价值，形成了从「机器发现」到「人类验证」的完整闭环。
实验结果
本文的核心发现可以归纳为三个方面。首先，在指南提取方面，作者从627个成功优化的prompt案例中提炼出10条改进指南，其中应用频率最高的是算法细节（57%的案例），其次是I/O格式（44%）和更多示例（24%）。这表明，对于代码生成任务，让LLM理解具体的算法逻辑和数据格式是最关键的。其次，在从业者使用情况方面，调查显示参与者最常使用的是I/O格式规范（44%在超过50%的prompt中使用）和前置/后置条件（23%），而较少使用更多示例（24%）和断言性语言（9%）。一个有趣的发现是，虽然更多示例的使用率不高，但88%的从业者认为它非常有用或有用，这说明存在认知与实践的差距。第三，在感知有用性方面，I/O格式（88%认为有用）、前置条件（78%）和更多示例（74%）被认为最有价值，而变量提及一致性（42%）和条件清晰性（42%）被认为相对较不重要。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| HumanEval+代码生成 | 至少一次通过的任务数 | GPT-4o mini: 145, Llama: 132, Qwen: 134, DeepSeek: 134 | 总任务数163 | GPT-4o mini表现最佳，通过率89% |
| MBPP+代码生成 | 至少一次通过的任务数 | GPT-4o mini: 265, Llama: 248, Qwen: 258, DeepSeek: 276 | 总任务数375 | DeepSeek表现最佳，通过率73.6% |
| BigCodeBench代码生成 | 至少一次通过的任务数 | GPT-4o mini: 715, Llama: 680, Qwen: 651, DeepSeek: 705 | 总任务数1140 | GPT-4o mini表现最佳，通过率62.7% |
| Prompt优化成功案例 | 成功优化的实例数 | GPT-4o mini: 153, Llama: 192, Qwen: 200, DeepSeek: 145 | N/A | Qwen优化成功率最高 |
局限与改进
本文存在几个重要的局限性。首先，研究仅针对Python语言，虽然作者声称指南是语言无关的，但不同编程语言可能有特定的prompt优化需求（如静态类型语言的类型注解、系统编程语言的内存管理说明等），这些在本研究中未被覆盖。其次，使用的benchmark（BigCodeBench、HumanEval+、MBPP+）主要是函数级别的代码生成任务，对于更大规模的软件开发任务（如类设计、模块架构、多文件项目）的适用性存疑。第三，从业者调查的样本量为50人，且主要来自作者的专业网络，可能存在选择偏差，尤其是缺乏非常资深的开发者（仅3人有超过10年经验）。第四，研究没有验证指南的实际效果——即按照指南优化prompt后，代码生成的成功率是否真的提高了，这是一个重要的实证缺口。
独立分析的弱点
从独立分析的角度，本文存在几个值得关注的弱点。第一，方法论上的循环论证风险：prompt优化指南是由LLM自己生成的，然后又用LLM来评估这些指南的有用性，这可能导致系统性偏差——LLM可能偏好那些符合其自身思维方式的改进模式，而这些模式不一定对人类开发者最有效。第二，实验设计上的温度问题：作者使用temperature=0来减少不确定性，但这与实际开发场景不符，开发者通常使用更高的温度以获得更多样的输出。第三，指南的优先级问题：10条指南的应用频率差异很大（从1%到57%），但作者没有提供一个清晰的决策框架告诉开发者在有限的prompt长度下应该优先应用哪些指南。改进方向包括：(1) 进行对照实验验证指南的实际效果；(2) 建立一个基于任务特征的指南推荐系统；(3) 将研究扩展到其他编程语言和更大规模的任务。
未来方向
作者在论文中提出的未来方向包括：扩展研究到其他编程语言和任务类型，进行控制实验评估指南的实际效果，以及开发自动化工具来分析prompt并建议改进。基于本文成果可延伸的方向更多：首先，可以将10条指南转化为一个prompt质量评分系统，自动检测prompt中缺失的关键元素；其次，可以研究不同指南之间的交互效应——某些组合可能比单独应用更有效；第三，可以探索个性化指南，即根据开发者的经验水平和任务类型推荐不同的改进策略；第四，可以将指南集成到IDE或代码助手工具中，实现实时的prompt优化建议。
复现评估
本文的复现条件相对友好。作者提供了完整的复制包（replication package），包含调查问卷、实验数据和分析结果。实验使用了4个公开可访问的LLM（GPT-4o mini、Llama 3.3 70B、Qwen2.5 72B、DeepSeek Coder V2）和3个公开benchmark，这些都是可获取的。算力需求方面，需要调用这些LLM进行大量生成（每个任务10次初始生成+最多5次优化迭代+10次验证），对于GPT-4o mini和DeepSeek需要API访问权限，对于Llama和Qwen可以在本地部署（需要足够的GPU内存）。复现的主要挑战在于：(1) 人工分析627个prompt差异需要大量时间和多评估者协作；(2) LLM的版本更新可能导致结果不可完全复现；(3) 调查研究需要招募足够数量的从业者。总体而言，技术复现难度中等，但完整复现（包括人工分析和调查）需要较大的人力投入。
论文图表
展示了一个具体的prompt优化案例（MBPP+任务ID 99，使用GPT-4o mini），上方是原始的简短prompt，下方是优化后的详细prompt，高亮显示了新增的内容如负数处理、零值处理等。
这张图提供了prompt改进的具体实例，让读者直观理解优化到底是什么样的——从模糊描述到精确规格说明的转变。