💻 computer science

A Study of LLMs' Preferences for Libraries and Programming Languages

该研究首次实证分析了大语言模型在代码生成中对库和编程语言的选择偏好，发现模型倾向于过度依赖流行库（如 NumPy）并默认选择 Python，往往忽视任务的最优性，从而凸显了针对性微调与评估基准改进的必要性。

原作者： Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

发布于 2026-04-09

📖 1 分钟阅读☕ 轻松阅读

原作者： Lukas Twist, Jie M. Zhang, Mark Harman, Don Syme, Joost Noppen, Helen Yannakoudakis, Detlef Nauck

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是在给现在的“编程 AI 助手”（大语言模型，LLM）做了一次**“体检”，专门检查它们在写代码时，“选工具”和“选语言”**的习惯。

想象一下，你请了一位非常聪明的**“全能管家”**（AI）来帮你装修房子（写代码）。你只告诉他：“我想建个厨房”或者“我想建个车库”，却没说具体要用什么材料或风格。

这篇研究就是看看，这位管家在没被具体指令的情况下，会下意识地做出什么选择。结果发现，这位管家有点**“太保守”和“太随大流”**了。

以下是用通俗语言和比喻对论文核心内容的解读：

1. 核心发现：管家有严重的“路径依赖”

📚 关于“选工具”（库的选择）：只认老牌子，不看新网红

现象：当你让 AI 写数据处理或画图表的代码时，它几乎无脑地选择 NumPy、Pandas 和 Matplotlib 这几个老牌工具。
比喻：这就像你让管家去买个**“切菜板”。哪怕你只是切个苹果，他也会从仓库里搬出一套重型工业级切菜机**（NumPy），因为这是他最熟悉的工具。
问题：
- 过度使用：在高达 45% 的情况下，根本不需要用这些重型工具，AI 却非要加上。这就像用挖掘机去挖一个花盆，既浪费资源又显得笨重。
- 忽视新工具：市面上有很多更新、更快、更轻量的新工具（比如 Polars 比 Pandas 快两倍），但 AI 几乎完全忽略它们。它就像个固执的老厨师，只肯用那把用了 20 年的旧菜刀，拒绝尝试新出的智能刀具。

🗣️ 关于“选语言”（编程语言的选择）：死磕 Python，不管适不适合

现象：无论任务是什么，AI 首选 Python 语言。
比喻：这就像你让管家去**“造一辆赛车”（需要高性能、低延迟的任务，比如高频交易或系统底层开发），或者“造一座摩天大楼”**（需要高并发、多线程）。
- Python 的特点：就像一辆舒适但跑得慢的家用轿车，适合日常买菜、接送孩子（写脚本、数据分析）。
- Rust/C++ 的特点：那是F1 赛车或重型卡车，速度快、控制精准。
结果：即使任务明确要求“高性能”或“低延迟”，AI 在 58% 的情况下依然给你开了一辆家用轿车（Python）去跑 F1 赛道。更离谱的是，在需要高性能的场景下，它一次都没用过 Rust 这种高性能语言。

2. 为什么会出现这种情况？

论文认为，这就像管家**“读的书太多，但太单一”**：

训练数据偏差：AI 是在海量的互联网代码（主要是 GitHub）上训练的。因为 Python 和那些老牌库在网络上太常见了，AI 就以为“这就是全世界”。
缺乏判断力：AI 并没有真正理解“什么任务适合什么工具”，它只是在模仿它见过的概率最高的组合。它像是一个只会背“标准答案”的学生，遇到新题型就只会套用旧公式。

3. 一个有趣的“精神分裂”现象

研究发现，AI 在**“嘴上说的”和“手上做的”**经常不一致：

嘴上：如果你问它“建赛车用什么语言好？”，它会很专业地回答：“当然要用 C++ 或 Rust 啊，Python 太慢了。”（它知道正确答案）。
手上：当你真的让它写代码时，它转头就给你写了 Python。
比喻：这就像一位美食评论家，嘴上能头头是道地分析“为什么这道菜应该用松露”，但真让他下厨，他却只会做番茄炒蛋，因为他最习惯做这个。

4. 这对我们意味着什么？（利弊分析）

✅ 好处（利）：

省心：对于新手或快速原型开发，AI 默认选 Python 和成熟库，能让人快速上手，代码也容易看懂，就像大家都用一样的工具，维修起来方便。
稳定：老牌工具通常很稳定，不容易出大错。

❌ 坏处（弊）：

性能瓶颈：如果你真的需要高性能（比如做游戏引擎、高频交易），AI 给你的 Python 方案可能会慢得像蜗牛，甚至根本跑不起来。
扼杀创新：如果所有 AI 生成的代码都用同样的旧工具，那么新的、更好的工具就永远没人用，整个软件生态会变得千篇一律，缺乏多样性。
误导用户：很多不懂技术的用户会盲目相信 AI 的选择，结果买错了“车”或“工具”，导致项目失败。

5. 总结与建议

这篇论文告诉我们：现在的 AI 编程助手，虽然很聪明，但在“做技术选型”上有点“懒”和“盲从”。

给开发者的建议：不要完全听 AI 的。如果你知道你的项目需要高性能，要主动告诉 AI：“请用 Rust 或 C++ 写”，或者检查它是否用了不必要的重型库。
给 AI 开发者的建议：需要给 AI 吃更多的“新食谱”（多样化训练数据），并教它根据任务特点做更明智的选择，而不是只会背“标准答案”。

一句话总结：
现在的 AI 写代码，就像是一个只会开家用车的司机，不管你是要去送快递、跑赛车还是搬砖，他都会把你塞进那辆熟悉的家用轿车里，并告诉你：“这车最舒服，大家都这么开。”我们需要教会他，“看菜吃饭，量体裁衣”。

这是一篇关于大语言模型（LLM）在代码生成过程中对编程语言和库（Library）选择的偏好研究的详细技术总结。该研究由伦敦国王学院、UCL、GitHub Next 和 BT 的研究人员共同完成，旨在填补现有评估仅关注代码功能正确性而忽视设计选择（如语言或库的选型）的空白。

以下是该论文的详细技术总结：

1. 研究背景与问题 (Problem)

尽管 LLM 在代码生成方面取得了显著进展，但现有的评估主要集中在代码的功能正确性或语法有效性上。然而，LLM 在生成代码时做出的关键设计决策（例如选择哪种编程语言或第三方库）往往被忽视。

核心问题：LLM 是否存在对特定技术栈的系统性偏好？这种偏好是否会导致过度使用某些流行技术，而忽略了更适合特定任务（如高性能计算）的替代方案？
潜在风险：这种偏好可能强化现有技术的主导地位，降低软件生态的多样性，甚至引导用户选择次优或不安全的解决方案（例如在需要高性能的场景下默认使用 Python）。

2. 研究方法 (Methodology)

研究团队对8 个生产级 LLM（包括 GPT-4o-mini, GPT-3.5-turbo, Claude-3.5 Sonnet/Haiku, Llama-3.2-3B, Mistral-7B, Qwen-2.5-Coder, DeepSeek-LLM）进行了实证研究。研究设计了三个主要实验：

实验 1：库偏好 (Library Preferences)

基准任务：使用 BigCodeBench（1,140 个 Python 任务），过滤掉提示中明确提及库的任务，观察 LLM 在自然语言描述下自动选择库的情况。
项目初始化任务：生成 5 类项目（数据库、深度学习、分布式计算、网络爬虫、Web 服务器）的初始代码，观察 LLM 在开放场景下的库选择。
控制变量：每个任务生成 3 次独立响应，使用默认 API 参数，避免系统提示词干扰。

实验 2：编程语言偏好 (Language Preferences)

基准任务：使用 6 个多语言数据集（Multi-HumanEval, MBXP, AixBench, CoNaLa, APPS, CodeContests），任务描述不包含特定语言要求。
项目初始化任务：设计 5 个Python 明显次优的高性能场景（如并发 Web 服务器、低延迟交易平台、系统级应用），强制 LLM 在无需指定语言的情况下做出选择，以测试其默认倾向。

实验 3：推荐一致性 (Recommendation Consistency)

目的：检查 LLM 在自然语言（NL）中推荐的技术是否与其实际生成的代码一致。
方法：让 LLM 列出最佳库或语言，然后计算推荐排名与实际使用频率排名之间的 Kendall's $\tau_b$ 相关性。

3. 主要发现与结果 (Key Results)

A. 库偏好：过度依赖成熟库，忽视新兴技术

过度使用流行库：所有 LLM 都强烈倾向于使用广泛采用的库（如 NumPy, pandas, Matplotlib）。
- 在 45% 的基准任务中，LLM 使用了 NumPy，但地面真值（Ground Truth）解决方案中并不需要它。
- 在库选择上，LLM 表现出对“旧”库的偏好，忽视了高增长的新兴库。例如：
  - 计算任务：58% 使用 pandas，而增长更快的 Polars 未被使用。
  - 可视化任务：Matplotlib 和 seaborn 占主导，Plotly 使用率极低。
  - Web 服务器：Flask (2010) 使用率 88%，而更现代的 FastAPI (2018) 仅 9%。
多样性匮乏：尽管 Python 生态有数万个库，但每个 LLM 在数百个任务中使用的独特库数量极少（仅 32-39 个）。

B. 语言偏好：Python 的默认霸权

基准任务：在所有基准测试中，Python 是绝对主导语言，占比 90% - 97%。
高性能场景：即使在 Python 明显不适合的场景（如低延迟交易、系统级应用、高并发服务器），Python 仍然是 58% 情况下的首选语言。
- Rust 在需要高性能的项目初始化任务中一次都未被使用。
- 这表明 LLM 优先考虑熟悉度和流行度，而非任务的具体适用性（如内存安全、执行效率）。

C. 推荐与实现的不一致性

弱信号：LLM 在自然语言回答中推荐的技术与其实际生成的代码高度不一致。
统计显著性：在库任务中，仅部分领域（分布式计算、网络爬虫）存在中等相关性；在语言任务中，没有任何显著相关性。
矛盾现象：在 40 个语言选择案例中，LLM 推荐的语言与实际使用的语言仅匹配 7 次。例如，LLM 在 NL 中可能推荐 Rust 或 C++ 用于高性能任务，但在生成代码时仍默认使用 Python。

4. 主要贡献 (Key Contributions)

首个实证研究：首次系统性地量化了 LLM 在代码生成中对库和编程语言的偏好模式。
揭示偏差：证明了 LLM 存在强烈的“成熟度偏差”（偏好旧库）和"Python 偏差”，即使在任务需求不匹配时也是如此。
揭示不一致性：发现 LLM 的 NL 建议不能作为其代码生成行为的可靠预测指标。
开源资源：发布了代码、数据集和完整结果（GitHub: llm-code-bias），以促进后续研究。

5. 意义与影响 (Significance)

正面影响

原型开发加速：默认使用 Python 和成熟库降低了认知负荷，提高了代码的可读性和互操作性，有利于初学者和快速原型设计。
标准化：促进了代码在不同开发环境中的兼容性和可复现性。

负面影响与风险

生态同质化：LLM 可能形成反馈循环，合成更多相同的数据，进一步巩固少数库和语言的统治地位，抑制技术创新和多样性。
次优选择：用户（尤其是非专家）可能盲目信任 LLM 的默认选择，导致在需要高性能、内存安全或特定领域优化的场景中使用不合适的技术栈。
公平性缺失：可能边缘化使用非主流语言或新兴库的开发者和社区。

未来方向建议

针对性微调：需要对 LLM 进行针对性微调，使其能根据任务上下文（如性能要求）选择最合适的技术。
数据多样化：训练数据应包含更多样化的技术栈，减少单一语言（Python）的过度代表。
新评估基准：建立新的评估基准，不仅衡量代码正确性，还要衡量技术选型的适宜性和多样性。
提示工程：研究表明，通过思维链（Chain-of-Thought）或强制排序的提示工程，可以在一定程度上改善语言选择的一致性，但效果有限。

总结

该论文揭示了 LLM 在代码生成中存在的系统性偏差：它们倾向于“安全”和“流行”的技术选择，而非“最优”选择。这种偏差可能导致软件生态系统的多样性下降，并阻碍新技术的采用。研究呼吁社区关注这一现象，通过改进训练数据、模型设计和评估标准，构建更加平衡、上下文感知且多样化的代码生成系统。