CL4SE：软件工程任务上下文学习基准 CL4SE: A Context Learning Benchmark For Software Engineering Tasks
首个针对软件工程的上下文学习基准，定义四种上下文类型并评估其对代码生成、摘要、审查和补丁评估的影响
前置知识
上下文学习
上下文学习（Context Learning）是大语言模型在推理时通过提示中提供的示例或相关信息来学习新任务的能力，无需修改模型参数。与需要大量训练数据且成本高昂的模型微调不同，上下文学习通过在输入提示中包含任务相关的示例、项目特定知识或决策过程，引导模型理解任务模式并生成符合预期的输出。这一机制的核心在于模型能够从少量示例中归纳出规律，并将其应用到新问题上，是现代LLM在下游任务中发挥强大性能的关键技术途径。
本文核心研究内容是上下文学习在软件工程任务中的有效性，理解这一概念是把握全文方法论的前提。
提示工程
提示工程（Prompt Engineering）是设计和优化输入提示以引导大语言模型产生期望输出的过程，主要关注提示的结构、格式和技巧。传统的提示工程侧重于如何利用模型的参数化知识，通过精心设计的问题表述、输出格式要求或少量示例来提高模型响应质量。然而，随着最新推理模型的出现，一些早期的提示技巧效果减弱甚至产生负面影响。提示工程强调的是如何更好地激活模型已有的知识，而不是引入需要学习的新内容。
本文将提示工程作为上下文工程的前身概念，理解它有助于理解研究的发展脉络和本文的创新点。
PASS@1
PASS@1 是代码生成任务的核心评估指标，衡量模型在第一次尝试时生成的代码是否能够通过所有测试用例。设 $N$ 为总代码生成尝试次数，$K$ 为第一次尝试就通过测试用例的成功次数，则 PASS@1 = K/N。这个指标反映了模型一次性生成正确代码的能力，比需要多次尝试才能成功的场景更具实际意义，因为在实际软件开发中，开发者通常期望模型能够直接给出可用的解决方案，而不是需要多次调试。
本文在代码生成任务中使用 PASS@1 作为主要评估指标，理解这个指标对于解读实验结果至关重要。
BLEU/ROUGE/BERTScore
BLEU、ROUGE 和 BERTScore 是文本生成任务的评估指标。BLEU 主要衡量生成文本与参考文本之间的 n-gram（连续词序列）精确匹配度，计算公式为 $BLEU = BP \cdot \exp(\sum_{n=1}^{N} w_n \log P_n)$，其中 $P_n$ 是 n-gram 精确率，$BP$ 是简短惩罚因子。ROUGE 关注召回率，计算重叠 n-gram 在参考文本中的比例。BERTScore 则基于预训练 BERT 模型的词嵌入，通过计算生成文本和参考文本之间的余弦相似度来评估语义相似度。BLEU/ROUGE 侧重词汇层面的重叠，而 BERTScore 更关注语义层面的相似性。
本文在代码摘要任务中综合使用这些指标来全面评估摘要质量，理解它们的区别有助于理解实验结果的深层含义。
补丁过拟合
补丁过拟合（Patch Overfitting）是自动程序修复（APR）中的一个关键问题，指修复工具生成的补丁虽然能够通过现有的测试用例，但并没有真正修复 bug，而是通过一些表面上的修改恰好满足了测试条件。这类补丁在新的测试或实际运行环境中会失败，因为它们没有理解问题的本质，只是机械地匹配测试模式。例如，一个过拟合补丁可能会删除一个导致测试失败的断言，而不是修复真正导致错误的代码逻辑。补丁过拟合是 APR 工具面临的主要挑战之一，因为它使得看起来成功的修复实际上是有害的。
本文在补丁正确性评估任务中区分正确补丁和过拟合补丁，理解这一概念对于理解该任务的实际意义至关重要。
研究动机
尽管上下文工程和上下文学习在软件工程任务中已经展现出有效性，但现有研究缺乏对不同上下文类型如何影响不同任务的系统性理解，也缺乏对这些上下文如何发挥作用的机制分析。早期研究探索了如何更有效地构建上下文示例，但没有建立 SE 特定上下文的系统分类法或分析模型如何从中学习。大多数 SE 基准测试都是任务特定的，只关注单一场景，且通常限于单一粒度级别。虽然几个基准测试考虑了上下文的作用并证明了上下文信息可以提高模型性能，但它们没有提供关于不同上下文类别如何影响不同软件工程任务的细粒度分析。此外，现有文献主要将上下文选择视为提示工程的临时组成部分，仍然缺乏对 SE 特定上下文类型的系统分类以及它们对不同 SE 任务的异质性影响的基准测试。
本文的目标是本文的目标是填补软件工程领域上下文学习的这一关键空白，提出 CL4SE（Context Learning for Software Engineering），这是第一个专门针对软件工程任务的上下文学习基准。具体而言，本文旨在定义一个精细的四种 SE 导向上下文类型分类法，并将每种类型映射到一个代表性的核心 SE 任务；构建高质量的现实世界数据集，包含来自 30 多个开源项目的 13,000 多个样本；使用九个指标在五个主流 LLM 上进行广泛评估，以剖析不同上下文类型在不同 SE 任务中的有效性。
与已有工作不同的是，本文的独特切入角度在于它不是简单地将通用的上下文学习研究扩展到软件工程领域，而是首先系统性地识别了四种 SE 特有的上下文类型——可解释示例、项目特定上下文、程序化决策上下文、正负样本上下文——并将每种类型与最匹配的核心 SE 任务（代码生成、代码摘要、代码审查、补丁正确性评估）进行一对一映射。这种任务与上下文的精准匹配使得本文能够深入探究上下文如何影响模型的推理过程和决策模式，而不仅仅是测量性能提升。此外，本文还特别关注模型在参数化知识难以提供有效指导的小众或专业化场景下的表现，这与大多数只关注主流场景的研究形成鲜明对比。
核心方法
CL4SE 的整体思路是首先通过系统性分析识别四种软件工程特有的上下文类型，然后将每种上下文类型映射到一个最能体现其价值的代表性 SE 任务，构建大规模高质量数据集，最后在多个主流 LLM 上进行全面实验评估。技术路线上，本文首先从多个编程竞赛平台和开源项目中收集数据，包括 LeetCode 的算法问题、GitHub 上 Python 项目的代码摘要对、多个知名开源项目的 PR 审查记录、以及 Defects4J 的补丁样本。然后，针对每种任务设计特定的上下文构造方式，并为代码生成任务添加可解释的推理过程描述，为代码摘要任务提供项目特定的示例，为代码审查任务保留完整的多轮对话历史，为补丁评估任务同时提供正确和过拟合的补丁样本。最后，在五个主流 LLM（Qwen3-Max、Qwen-Coder-Plus、DeepSeek-V3、GPT-Oss-120B、Claude-3.5）上使用九个指标进行评估，比较零样本设置和不同样本数设置下的性能差异。
本文的核心创新点在于提出了四种 SE 特有的上下文类型分类法，并系统性地研究了每种类型在不同任务中的有效性，这与现有研究要么只关注单一上下文类型、要么将上下文作为通用提示工程的临时组成部分形成本质区别。具体而言，可解释示例上下文强调展示推理过程而不仅仅是输入输出对；项目特定上下文强调适应不同项目的独特编码风格和命名规范；程序化决策上下文强调保留完整的多轮决策过程而不是最终决策；正负样本上下文强调同时提供正确和错误示例以建立双重参考框架。这种细粒度的上下文分类使得本文能够揭示上下文学习在不同任务认知需求下的异质性效果，例如推理密集型任务（代码审查、补丁评估）从上下文中获益远超模式匹配主导的任务（代码摘要）。
方法步骤详情
CL4SE 的方法步骤分为数据收集、上下文构造、模型评估三个阶段。在数据收集阶段，对于代码生成任务，从 LeetCode 爬取问题描述和官方解集，收集用户讨论，使用 Qwen3-Max 提取有价值的解决思路，使用 Qwen3-Coder-Plus 生成测试用例（要求多样非冗余、包含边界情况、每个问题生成 10+ 案例、标准解必须通过），经人工评估修正后得到 2,083 个有效问题，使用 Qwen3-32B 作为基线模型运行 10 次测试并用平均通过率对问题排名，选取最难的前 30% 作为测试集（636 个问题）。对于代码摘要任务，聚合 GitHub 上星数前十的 Python 开源项目，使用 TreeSitter 在函数粒度解析每个项目，记录项目、文件路径、类名、函数名、函数体和相关注释，应用保守过滤规则（排除包含 test/Test 的函数、排除 Python 魔术方法、排除无注释/文档字符串的函数、排除注释超过 500 词的函数），得到 8,225 个高质量样本。对于代码审查任务，预选 32 个知名高星 GitHub 仓库，使用 GitHub CLI 提取最近的 PR，为每个项目采样最多 5,000 个接受 PR 和 5,000 个拒绝 PR，应用过滤条件（移除审查对话数为零的样本、排除修改超过 3 个文件的 PR、排除仅修改测试用例或包含大段无关配置文件变更的 PR），得到 1,916 个有效代码审查样本（1,191 正样本、725 负样本）。对于补丁正确性评估任务，基于 Defects4J v2.0（包含 17 个开源项目的 835 个 bug），聚合近期 APR 工具生成的合理补丁，进一步挖掘释放的工件以定位额外补丁，纳入之前被识别为正确的开发者补丁以缓解标签不平衡，通过重建原始有缺陷和修复后的代码片段、去除空白和注释来去重补丁，得到总共 2,274 个合理补丁（1,169 个过拟合补丁、1,105 个正确补丁）。在上下文构造阶段，对于代码生成任务，设计两种上下文：不包含解释的上下文（仅问题描述、目标输入输出对和解）和包含解释的上下文（额外添加推理过程和解决策略解释）。对于代码摘要任务，演示示例严格从同一仓库中提取，确保项目对齐的领域知识和语言风格。对于代码审查任务，保留完整的多轮对话历史（审查者评论、作者回复、决策转折点）作为程序化上下文，而不仅仅是最终决策。对于补丁正确性评估任务，测试三种上下文设置：仅过拟合补丁、仅正确补丁、混合正确和过拟合补丁。在模型评估阶段，在 8 卡 RTX 5880 GPU 集群上进行实验，闭源模型通过官方 API 访问并发请求数设置为 32，开源模型在 8 张卡中的 4 张上部署使用 bfloat16 精度，所有模型温度设置为 0 以确保确定性输出。搜索框架使用 Langchain 结合 Chroma 向量数据库，嵌入模型采用 Qwen3-Embedding-4B，搜索过程中排除目标样本本身和时间戳晚于目标的样本以避免数据泄露。对于代码生成任务使用 PASS@1，对于代码摘要任务使用 ROUGE-1/2/L、BLEU、METEOR、BERTScore，对于代码审查和补丁正确性评估任务使用 Accuracy、Precision、Recall、F1-score。
技术新颖性
CL4SE 的技术新颖性体现在多个方面。首先，它提出了首个针对软件工程的上下文学习基准，填补了这一领域的空白，而现有的通用上下文学习基准（如 CL-Bench）主要关注一般 NLP 或广泛推理任务，不能捕捉 SE 工作流中数据的独特稀缺性和复杂性。其次，它定义了四种 SE 特有的上下文类型分类法，这比现有研究要么只考虑单一上下文类型、要么将上下文视为通用提示工程的临时组成部分更加系统和深入。第三，它构建了大规模高质量数据集，包含来自 30 多个开源项目的 13,000 多个样本，且特别保留了代码审查任务中的完整多轮对话历史，这与大多数只保留最终决策的研究形成鲜明对比。第四，它揭示了上下文学习在不同任务认知需求下的异质性效果，例如推理密集型任务从上下文中获益远超模式匹配主导的任务，以及更多上下文不一定带来更好性能（代码摘要任务在 1-shot 时达到最优，更多样本反而导致性能下降）。第五，它提出了任务感知的上下文设计原则，表明上下文学习应该根据任务的认知需求进行设计，而不是采用通用的方法。
实验结果
核心发现可以总结为以下几点：第一，上下文学习是一个稳健的范式，持续改善 LLM 在多样化 SE 任务（代码生成、代码摘要、代码审查、补丁正确性评估）上的性能，所有任务的平均性能提升为 24.7%。具体而言，代码审查获得最显著的提升（Qwen3-Max 提升 33%），其次是补丁正确性评估（DeepSeek-V3 提升 30%），代码生成和代码摘要获得适度的提升（GPT-Oss-120B 分别提升 20% 和 34%）。第二，不同任务从上下文学习中获益的程度差异显著，这表明上下文学习不是一个一刀切的策略，而应该根据任务的认知需求进行设计。推理密集型任务（代码审查、补丁正确性评估）从上下文中获益远超模式匹配主导的任务（代码摘要）。第三，可解释示例的上下文在代码生成任务中对所有模型都比无解释设置产生正面改进，DeepSeek-V3 提升最显著（5.72%），Claude-3.5（3.31%）和 GPT-Oss-120B（3%）次之，而 Qwen-Coder-Plus 和 Qwen3-Max 仅获得相对较小的收益（0.63% 和 0.15%）。这揭示了模型对示例可解释性敏感性的显著异质性：代码专业模型和零样本基线较低的通用模型对可解释上下文表现出更高的响应性。第四，项目特定上下文在代码摘要任务中在 1-shot 设置下达到明确的最佳性能，随后随着项目特定样本数的增加而单调性能下降。所有模型在 1-shot 时达到峰值，词汇指标（ROUGE-1/2/L、BLEU）看到急剧激增，而语义对齐（BERTScore）仅显示适度增益。例如，GPT-Oss-120B 的 BLEU 分数从 5.57%（0-shot）跳升至 20.35%（1-shot）（+14.78%），其 Rouge-L F1 激增 13.71%（18.96% → 32.67%），这证实了项目特定上下文有效地引导模型采用目标项目的独特术语、措辞和文档格式。相比之下，其 BERTScore F1 仅增加 2.05%（85.97% → 88.02%），这证实了 LLM 在 0-shot 设置下已经生成语义正确的摘要，项目特定上下文主要优化格式和语言一致性而不是核心意义。第五，程序化决策上下文一致性地增强代码审查性能，随着样本数从 0 增加到 5，所有模型在核心指标（Accuracy、F1）上表现出稳定的单调上升趋势，没有证据显示因过度上下文导致的性能下降。Qwen3-Max 表现出最显著的增长，Accuracy 上升 18.69%（58.19% → 76.88%），F1-score 激增 22.80%（56.39% → 79.19%）。第六，在补丁正确性评估任务中，仅正确示例优于仅错误示例，而混合设置（正确 + 错误）实现最佳性能。DeepSeek-V3 获得最大增益（Accuracy=74.48%，F1=69.66%），相比 vanilla 设置提升 12.95% F1；Qwen3-Max（80.41%，77.99%）和 GPT-Oss-120B（76.19%，71.98%）也在此设置下达到峰值性能。这证实了结合正负示例有助于 LLM 建立双重参考框架，从而理解有效模式和无效陷阱。第七，上下文的有效性强烈依赖于其与任务特定认知需求的对齐，上下文在结构匹配目标任务的认知需求时最有用，这表明软件工程中的上下文学习应该以任务感知的方式而不是任务无关的方式设计。第八，更多上下文不一定带来更好性能，在许多情况下（如代码摘要），少量的针对性上下文比大量冗余上下文更有效，这表明上下文的质量和相关性比其数量更重要。第九，上下文学习对推理密集型任务特别有价值，最强的收益出现在涉及判断、比较和多步推理的任务中，这表明上下文不仅可以塑造模型输出什么，还可以塑造它们如何推理。第十，有效的上下文既教授解决方案也教授推理过程，最信息丰富的上下文不仅仅是提供正确的输出，还暴露推理路径、决策程序和有效与无效案例之间的对比，使模型能够学习做什么以及如何做。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 代码生成（可解释示例） | PASS@1 | DeepSeek-V3: 77.99% (1-shot with interpretation), GPT-Oss-120B: 73.12% (1-shot with interpretation), Claude-3.5: 64.78% (1-shot with interpretation) | DeepSeek-V3: 72.27% (1-shot without interpretation), GPT-Oss-120B: 70.12% (1-shot without interpretation), Claude-3.5: 61.47% (1-shot without interpretation) | DeepSeek-V3: +5.72%, GPT-Oss-120B: +3%, Claude-3.5: +3.31% |
| 代码摘要（项目特定上下文） | BLEU | GPT-Oss-120B: 20.35% (1-shot) | GPT-Oss-120B: 5.57% (0-shot) | +14.78% |
| 代码审查（程序化决策上下文） | Accuracy | Qwen3-Max: 76.88% (5-shot) | Qwen3-Max: 58.19% (0-shot) | +18.69% |
| 代码审查（程序化决策上下文） | F1 | Qwen3-Max: 79.19% (5-shot) | Qwen3-Max: 56.39% (0-shot) | +22.80% |
| 补丁正确性评估（混合正负样本） | F1 | DeepSeek-V3: 69.66% (2-shot mixed) | DeepSeek-V3: 42.06% (0-shot) | +12.95% |
| 补丁正确性评估（混合正负样本） | F1 | Qwen3-Max: 77.99% (2-shot mixed) | Qwen3-Max: 71.99% (0-shot) | +6.00% |
局限与改进
作者承认的局限性包括：第一，上下文学习主要集中在高资源编程语言（如 Python），这些语言有丰富的开源代码、文档和任务特定数据。然而，低资源编程语言（如 Rust、Julia，或像 Solidity 这样的智能合约领域特定语言、硬件设计语言 Verilog）对上下文学习提出了独特挑战。由于高质量上下文示例的稀缺，低资源语言缺乏足够的任务特定上下文，这限制了有效上下文演示的构建。它们独特的语言和语法特征需要与语言特定语义的严格对齐，通用上下文工程策略无法满足。此外，在高资源语言上预训练的 LLM 存在固有的跨语言迁移差距，使得难以将上下文学习能力泛化到不同编程语言。第二，软件工程上下文学习假设静态项目上下文，其中编码约定、文档风格和决策规范在数据收集期间是固定的。然而，现实世界的软件项目是动态和不断演进的，这带来了三个关键挑战：上下文漂移（项目上下文随时间变化，使静态示例过时或产生误导）、长尾上下文稀缺（新兴边缘情况缺乏相应的历史上下文示例）、上下文可扩展性（大型项目包含碎片化的子上下文，大大增加了上下文构建和维护的难度）。这揭示了当前上下文学习方法的一个关键局限性：它们在静态项目上表现良好，但无法适应软件开发的动态演进本质。此外，本文作者的观察表明：模型对问题难度的概念并不总是与 LeetCode 数据库中的人类标签匹配，一些被标记为困难的问题很容易被模型解决，而一些简单的问题则不然。这种差异是因为经常出现在考试和技术面试中的经典问题也经常出现在各种现实世界语料库中；因此，这些问题很可能包含在模型的预训练数据中，因此模型更好地掌握了这些问题。
独立分析的弱点
从独立分析的角度看，本文存在以下弱点：第一，实验主要集中在 Python、JavaScript、SQL 等高资源编程语言上，对于 Rust、Julia、Solidity 等低资源语言的研究非常有限，这限制了本文结论的普适性。改进方向是扩展到更多编程语言，特别是低资源语言，并探索跨语言上下文迁移的方法。第二，虽然本文提到了动态和演进的上下文挑战，但没有提出具体的解决方案或实验验证如何处理上下文漂移、长尾上下文稀缺和上下文可扩展性问题。改进方向是设计动态上下文工程机制，使上下文能够随着项目的演进而自动更新。第三，本文使用的上下文检索策略主要基于语义相似度（使用 Qwen3-Embedding-4B 和 Chroma 向量数据库），这可能不是最优的，特别是在需要精确匹配或结构化理解的场景。改进方向是探索更复杂的上下文检索策略，例如基于代码结构的检索、基于任务类型的混合检索策略。第四，本文的实验主要关注单个任务上下文的效果，没有探索在多任务或复杂场景中如何组合不同类型的上下文。改进方向是研究多任务上下文学习和上下文组合策略。第五，本文没有深入分析不同模型架构（例如纯解码器模型、编码器-解码器模型）对上下文学习的敏感性差异。改进方向是进行跨模型架构的系统性比较研究。
未来方向
作者提出的未来研究方向包括：探索动态上下文工程机制，以维持上下文输入与实时项目状态之间的对齐；研究跨语言上下文迁移，以解决低资源编程语言的上下文稀缺问题；扩展到更多 SE 任务，例如需求分析、架构设计、测试生成等，以建立更全面的 SE 上下文学习评估框架。基于本文成果可以延伸的研究方向包括：研究自适应上下文选择策略，根据任务难度、模型能力、上下文可用性等因素动态选择最优的上下文类型和数量；探索上下文压缩和优化技术，以在保持上下文有效性的同时减少计算开销；研究上下文学习的理论机制，例如模型如何从上下文中归纳规律、上下文信息如何在模型内部表示和处理；开发工具和平台，帮助开发者和研究者更容易地构建和评估软件工程任务的上下文。
复现评估
本文的复现性评估如下：数据方面，本文的数据集在 HuggingFace 上公开可用（HuggingFace/tomhu/codecl），相关代码在 GitHub 上开源（GitHub/Tomsawyerhu/CodeCL），这大大降低了复现门槛。数据方面，本文构建了大规模高质量数据集，包含 13,000+ 样本，这些样本来自 30 多个开源项目，覆盖多个编程语言和多种 SE 任务，数据的多样性和规模性使得实验结果具有较好的代表性。算力方面，所有实验在 8 卡 RTX 5880 GPU 集群上进行，闭源模型通过官方 API 访问，开源模型在 4 张卡上部署使用 bfloat16 精度，这要求较高的算力资源，但对于研究机构来说是可以实现的。难度方面，本文提供了详细的实验设置，包括模型部署、参数配置、搜索框架、技术栈等细节，例如所有模型温度设置为 0 以确保确定性输出，搜索框架使用 Langchain 结合 Chroma 向量数据库，嵌入模型采用 Qwen3-Embedding-4B，搜索过程中排除目标样本本身和时间戳晚于目标的样本以避免数据泄露，这些细节使得其他研究者可以准确地复现实验。总体而言，本文的复现性较好，但需要注意 API 费用和算力资源的成本。
论文图表
这张图展示了 CL4SE 与相关概念之间的关系，包括提示工程、上下文工程、上下文学习和上下文学习（CL-Bench）。图显示提示工程是最基础的概念，上下文工程在其之上发展，上下文学习作为基本范式支撑提示工程和上下文工程。CL-Bench 将上下文学习扩展到数学、游戏等通用任务，而 CL4SE 是 CL-Bench 在软件工程领域的延伸，专注于 SE 特定的上下文学习任务。
这张图对理解论文至关重要，因为它清晰地定位了 CL4SE 在研究谱系中的位置，展示了 CL4SE 与相关概念的区别和联系，帮助读者理解 CL4SE 的独特贡献和创新点。
这张图展示了四种上下文类型与四个软件工程任务之间的一对一映射关系：可解释示例映射到代码生成任务，项目特定上下文映射到代码摘要任务，程序化决策上下文映射到代码审查任务，正负样本上下文映射到补丁正确性评估任务。
这张图对理解论文至关重要，因为它直观地展示了本文的核心方法论框架，即如何将不同的上下文类型与最匹配的任务进行映射，这是理解后续实验设计和结果解读的基础。