这项由南京理工大学、南京大学等多个知名高校联合开展的研究发表于 2026 年 2 月的国际会议论文，文章编号为 arXiv:2602.23047v1，有兴趣深入了解的读者可以通过该编号查询完整论文。
要理解这项研究的意义，我们不妨把写代码比作做菜。当你想做一道新菜时，最好的方法是什么？当然是先看看别人怎么做，学习一些成功的例子，然后再动手。同样的道理，当我们让人工智能帮我们写代码、检查代码或者总结代码功能时，如果能给它提供一些"示例菜谱"作为参考，它就能做得更好。
这种给 AI 提供示例和背景信息来提升表现的方法，就像给厨师提供食谱一样，被称为"上下文学习"。就像一个好厨师能从不同的食谱中学到精髓并应用到新菜品中，AI 也能从我们提供的示例中学习，然后更好地完成新任务。
然而，就像不同类型的菜需要不同的烹饪技巧一样，软件开发中的不同任务也需要不同类型的"食谱"。写一个全新的程序和检查现有代码的错误是完全不同的工作，就像做蛋糕和炒菜需要的技巧截然不同。
研究团队发现了一个有趣的现象：目前的研究就像是随便给厨师几本食谱，不管他要做什么菜，都用同样的参考材料。这显然是不合理的。做中餐时参考法式料理食谱，做甜点时却看炒菜教程，效果当然不会好。
因此，这个研究团队决定深入探索这个问题。他们想要搞清楚：对于软件开发中的不同任务，到底应该给 AI 提供什么样的"食谱"最有效？
一、四种神奇的"食谱"类型
研究团队就像美食专家一样，仔细分析了软件开发这个"厨房"，发现了四种完全不同的"烹饪场景"，每种都需要专门的"食谱"类型。
第一种叫做"可解释示例"，就像详细的分步骤烹饪教程。当 AI 需要写全新的代码时，仅仅看到问题和答案是不够的，就像学做菜只看到原料和成品图片，却不知道中间的制作步骤。研究团队发现，当给 AI 展示完整的思维过程——比如"为了解决这个问题，我首先考虑这样做，然后发现需要那样调整"——AI 就能更好地理解如何处理复杂的编程挑战。
第二种叫"项目特定上下文"，这就像每个餐厅都有自己的招牌风味。同样是写代码注释，谷歌公司的风格和微软公司的风格可能完全不同。当 AI 要为某个特定项目写代码说明时，如果能看到该项目以往的注释风格作为参考，就能写出更符合项目传统的内容，就像新厨师需要学会餐厅的特色口味一样。
第三种叫"程序化决策上下文"，这像是展示完整的品菜过程。在餐厅里，主厨不是一口就决定这道菜合不合格，而是先尝味道，再看摆盘，最后综合判断。同样，审查代码也不是一个简单的对错判断，而是一个包含多轮讨论、逐步分析的过程。通过展示这些完整的决策过程，AI 能更好地理解如何进行代码审查。
第四种叫"正负示例上下文"，就像同时展示成功菜品和失败案例。只告诉厨师"这样做是对的"还不够，还要告诉他"那样做是错的，原因是..."。当 AI 需要判断代码修改是否正确时，同时看到好的修改和坏的修改对比，能帮助它建立更准确的判断标准。
二、精心设计的"厨艺大赛"
为了验证这些不同"食谱"的效果，研究团队组织了一场规模宏大的"厨艺大赛"。他们精心准备了超过 13000 个"比赛题目"，涵盖了 30 多个知名开源软件项目，就像准备了各种不同菜系的比赛题目。
这场比赛包含四个不同的"比赛项目"。第一个是"代码生成大赛"，就像要求参赛者根据客户需求创作全新菜品，这里收集了 636 个编程难题，从简单的算法实现到复杂的数据结构操作，难度分为简单、中等、困难三个级别。
第二个是"代码总结大赛"，类似要求厨师为自己的菜品写一份简明扼要的说明书。研究团队从 10 个著名 Python 项目中收集了 8225 个代码片段及其对应的功能说明，这些代码涵盖了从实用小工具到复杂业务逻辑的各种类型。
第三个是"代码审查大赛"，就像请资深厨师评判其他厨师的作品。团队从 32 个知名代码仓库中收集了 1916 个真实的代码审查案例，每个案例都包含完整的讨论过程和最终决定，分为通过和拒绝两类结果。
第四个是"补丁正确性评估大赛"，相当于判断一道菜的"改良版"是真的改进了还是只是看起来好。这里使用了 2274 个代码修补案例，其中一半是真正修复问题的好补丁，另一半是看似有用但实际有隐患的坏补丁。
三、五位"评委"的精彩表现
研究团队邀请了五位来自不同"厨艺学校"的顶级"评委"来参加这场比赛：来自阿里巴巴的 Qwen3-Max 和 Qwen-Coder-Plus，来自深度求索的 DeepSeek-V3，来自 OpenAI 的 GPT-Oss-120B，以及来自 Anthropic 的 Claude-3.5-Haiku。这些"评委"有的擅长通用任务，有的专精于代码相关工作，有的是开源模型，有的是商业产品。
比赛结果令人振奋。当这些 AI"评委"没有任何参考"食谱"时，表现只能说是中规中矩。但当给它们提供了合适的"食谱"后，就像给厨师提供了祖传秘籍，表现立刻有了飞跃性提升。
整体而言，使用合适上下文的 AI 比没有参考的 AI 表现平均提升了 24.7%，这个提升幅度相当可观。更令人惊喜的是，不同类型的任务确实需要不同类型的"食谱"，这验证了研究团队的基本假设。
四、"可解释示例"让代码生成更聪明
在代码生成这个"创作新菜"的比赛中，研究团队发现了一个有趣现象。当 AI 只能看到问题描述和最终代码时，就像厨师只看到原材料清单和成品照片，往往难以理解中间的制作过程。
但当研究团队为 AI 提供了"可解释示例"——详细展示了解题思路和步骤分析后，情况发生了戏剧性变化。DeepSeek-V3 的表现提升最为显著，代码通过率从 73.90% 跃升至 77.99%，提升了 5.72 个百分点。Claude-3.5 也有不错的进步，提升了 3.31 个百分点。
更有趣的是，不同 AI 对这种"详细食谱"的反应截然不同。那些原本就很强的 AI，如 Qwen3-Max，已经掌握了足够的编程知识，额外的解释反而可能造成干扰，提升幅度相对较小。而那些专门针对代码训练的 AI 或基础能力较弱的 AI，则从详细解释中获益良多，就像经验不足的厨师更需要详细的烹饪指导。
研究团队还发现，给 AI 提供示例的数量也有讲究。不是越多越好，而是有一个最佳平衡点。大多数 AI 在看到1-2 个详细示例后就能达到最佳表现，再多的示例反而会造成信息冗余，影响效果。这就像学做菜时，掌握一两个经典做法就足够举一反三，看太多不同版本的食谱反而容易搞混。
特别值得注意的是，这种效果在不同难度的问题上表现不一。对于简单问题，AI 本身就能处理得不错，额外的解释作用有限。但对于中等难度的问题，详细解释的效果最为明显，这些问题有一定复杂性，但又不会复杂到连解释都难以理解。至于那些极难的问题，即使有详细解释，AI 仍然难以完全掌握，这提醒我们 AI 能力仍有边界。
五、"项目特色"让代码注释更贴心
在代码总结这个"写菜品说明"的比赛中，研究团队验证了一个重要观点：每个软件项目都有自己的"口味偏好"。就像川菜馆和粤菜馆的菜品介绍风格完全不同一样，不同软件项目的代码注释也有各自的传统和习惯。
实验结果清晰地显示，当 AI 能够参考同一项目中的其他注释风格时，生成的代码说明确实更符合该项目的传统。最有说服力的例子来自 GPT-Oss-120B：在没有项目特定参考时，它的 BLEU 评分只有 5.57 分，但看到一个同项目的注释示例后，评分立刻跃升到 20.35 分，提升幅度达到惊人的 14.78 个百分点。
这种提升主要体现在词汇选择和表达风格的一致性上。AI 学会了使用项目特有的专业术语、命名习惯和描述风格，就像新员工逐渐适应公司的沟通文化一样。但有趣的是，从语义理解角度衡量，AI 生成的注释在准确性方面并没有显著提升，这说明 AI 本身就能理解代码功能，项目特定上下文主要帮助它调整表达方式。
研究团队还发现了一个"少即是多"的规律。给 AI 看一个同项目的注释示例就足够了，看更多的示例反而会产生负面效果。这可能是因为过多的参考会引入相互矛盾的信息，就像同时参考太多不同风格的写作范本会让人无所适从。
不同 AI 对项目特定上下文的敏感度也不相同。通用型 AI 如 GPT-Oss-120B 和 Claude-3.5 从项目特定信息中获益更多，它们更善于快速适应新的风格要求。而专门针对代码训练的 AI 如 Qwen-Coder-Plus 虽然也有提升，但幅度相对较小，可能是因为它们已经内化了一些常见的代码注释模式。
六、"决策过程"让代码审查更专业
代码审查这个"品菜评判"比赛展现了最令人惊喜的结果。与其他任务不同，这里 AI 的表现随着示例数量的增加而持续提升，没有出现信息过载的负面效应。
最典型的例子是 Qwen3-Max，它的准确率从 58.19% 稳步提升到 76.88%，提升幅度达到 18.69 个百分点，而 F1 评分更是从 56.39% 跃升至 79.19%，提升了 22.80 个百分点。这种持续改善的模式说明，代码审查确实是一个需要丰富经验和多样化判断标准的复杂任务。
深入分析发现，程序化决策上下文主要帮助 AI 提高了"发现问题"的能力。许多 AI 在没有参考时倾向于过于宽松，容易放过一些潜在问题。但当它们看到完整的审查讨论过程后，学会了更仔细地检查代码，找出那些最初可能忽略的问题点。
有趣的是，不同 AI 的改进重点不同。Qwen3-Max 和 Claude-3.5 主要提高了召回率——也就是发现问题的能力，而保持了较高的准确性。DeepSeek-V3 则表现出更均衡的提升，在发现问题和准确判断之间找到了更好的平衡。
专门针对代码训练的 Qwen-Coder-Plus 虽然也有改进，但提升幅度相对较小。这个现象提醒我们，代码审查不仅需要技术知识，还需要理解人际交往和团队协作的复杂性，而这些"软技能"可能更适合通用型 AI 来掌握。
研究结果还显示，5 个示例是这类任务的最佳数量，这反映了代码审查决策的复杂性需要接触多种不同的情况和讨论模式才能形成准确的判断能力。
七、"正反对比"让补丁判断更准确
在补丁正确性评估这个"改良菜品评判"比赛中，研究团队验证了一个直观但重要的发现：同时展示好例子和坏例子确实比只展示单一类型更有效。
实验设计巧妙地比较了三种情况：只看坏补丁示例、只看好补丁示例，以及同时看好坏补丁对比。结果显示，正面示例的效果普遍好于负面示例。以 Qwen3-Max 为例，只看好补丁时准确率达到 79.36%，只看坏补丁时为 74.48%，说明"学习正确做法"比"学习避免错误"更直接有效。
但真正的突破来自正负示例的结合。当 AI 能同时参考一个好补丁和一个坏补丁时，DeepSeek-V3 的表现最为亮眼，准确率达到 74.48%，F1 评分达到 69.66%，比没有任何参考时提升了 12.95 个百分点。这种"对比学习"帮助 AI 建立了更清晰的判断标准。
分析不同 AI 的表现模式发现了有趣的差异。所有 AI 都保持了很高的准确性——也就是说，它们判定为好补丁的通常确实是好的，很少出现误判。但在"发现能力"方面差异较大，这种差异主要通过召回率体现出来。
专门针对代码训练的 AI 如 Qwen-Coder-Plus 虽然保持了极高的准确性（93% 以上），但在发现有问题补丁方面相对保守，可能错过一些潜在问题。相比之下，通用型 AI 虽然准确性稍低，但在发现问题方面更加敏感，能够识别出更多需要注意的情况。
这种模式反映了一个重要现象：判断补丁正确性需要在"宁可错杀"和"绝不放过"之间找到平衡。过于保守可能放过问题补丁，过于激进可能拒绝有用的修改。正负示例的对比恰好帮助 AI 找到了这个平衡点。
八、意想不到的发现和启示
这项研究揭示了几个出人意料的发现。首先是"专业不等于全能"现象。人们可能以为专门针对代码训练的 AI 在所有编程任务上都应该表现最佳，但实际情况更复杂。在需要复杂推理和人际理解的任务（如代码审查）中，通用型 AI 反而表现更出色。这提醒我们，软件开发不仅是技术活动，也是社会活动。
其次是"少即是多"的普遍规律。除了代码审查这种特别复杂的任务外，大多数情况下1-2 个精心选择的示例就能达到最佳效果，更多示例反而产生干扰。这个发现对实际应用很有价值，意味着我们不需要准备大量示例，关键是选对示例类型。
第三个有趣发现是不同 AI 的"学习偏好"截然不同。有些 AI 从详细解释中获益良多，有些则更喜欢简洁示例；有些 AI 善于学习风格偏好，有些则专注于技术准确性。这种差异性为未来的 AI 应用提供了新思路——也许我们应该根据具体任务来选择最合适的 AI。
研究还发现了一个重要的边界效应：对于极简单或极困难的任务，上下文学习的效果都不明显。简单任务不需要额外帮助，困难任务则超出了当前 AI 的能力范围。这提醒我们要合理设定期望，上下文学习是强大的工具，但不是万能药。
九、未来的挑战和机遇
尽管这项研究取得了显著成果，但研究团队也诚实地指出了当前方法的局限性。最大的挑战之一是"小众语言困境"。目前的研究主要针对 Python 这样的热门编程语言，但对于 Rust、Julia 或者智能合约语言 Solidity 这样的小众语言，很难找到足够多的高质量示例来构建有效的上下文。
另一个重要挑战是"动态变化问题"。软件项目是活的，会不断演进。今天有效的代码风格明天可能就过时了，新出现的编程问题可能没有历史示例可参考。当前的方法假设项目特性相对稳定，但实际情况要复杂得多。
研究团队特别提到了三个具体的技术挑战：上下文漂移（项目风格随时间变化），长尾情况稀缺（新奇问题缺少参考），以及上下文可扩展性（大型项目包含多个子项目，每个都有不同特色）。
然而，这些挑战也指向了未来的研究机遇。研究团队建议探索动态上下文工程机制，能够实时适应项目变化。也可以研究跨语言上下文迁移技术，让从热门语言学到的知识能够应用到小众语言中。
更深层次地，这项研究为人工智能的发展提供了新的思路。与其一味追求更大更强的模型，不如考虑如何让现有模型更好地利用外部知识和上下文信息。这种"外脑"式的增强可能是未来 AI 发展的重要方向。
说到底，这项研究的价值不仅在于提升了 AI 处理编程任务的能力，更在于揭示了一个重要原理：不同的任务需要不同的支持方式。就像好厨师需要掌握各种烹饪技法一样，优秀的 AI 也需要学会针对不同情况采用不同的学习策略。研究团队构建的 CL4SE 基准测试就像是为 AI 设立的"厨艺等级考试"，不仅能评估当前能力，还能指导未来的改进方向。
归根结底，这项研究告诉我们，让 AI 更好地理解程序员的工作并不是简单的技术问题，而是需要深入理解软件开发这个复杂活动的各个层面。当我们能够为 AI 提供恰当的"烹饪指南"时，它们就能成为程序员更好的助手，让软件开发变得更高效、更可靠。有兴趣深入了解这项研究细节的读者可以通过论文编号 arXiv:2602.23047v1 查询完整论文。
Q&A
Q1：CL4SE 基准测试包含哪些具体的编程任务？
A：CL4SE 基准测试包含四个核心编程任务：代码生成（636 个编程难题，涵盖算法和数据结构）、代码总结（8225 个来自 10 个知名 Python 项目的代码注释对）、代码审查（1916 个来自 32 个开源项目的真实审查案例）、以及补丁正确性评估（2274 个代码修补案例，一半好补丁一半坏补丁）。
Q2：为什么专门针对代码训练的 AI 在某些任务上反而不如通用 AI？
A：研究发现专门的代码 AI 在技术准确性方面很强，但在需要复杂推理和理解人际协作的任务（如代码审查）中表现不如通用 AI。这是因为软件开发不仅是技术活动也是社会活动，需要理解团队沟通和协作模式，而通用 AI 在这些"软技能"方面更有优势。
Q3：给 AI 提供多少个示例效果最好？
A：研究显示"少即是多"，大多数任务中1-2 个精心选择的示例就能达到最佳效果。只有代码审查这种特别复杂的决策任务需要 5 个示例才能达到最佳表现。提供过多示例反而会造成信息冗余，影响 AI 的判断能力。
