🤖 AI

Learning to Code with Context: A Study-Based Approach

本文通过一项在大学游戏开发课程中开展的用户研究，调查了学生在整个软件生命周期中如何利用生成式人工智能工具，并评估了一个基于检索增强生成技术、具备仓库感知能力且本地部署的语言大模型助手在提供上下文关联支持方面的有效性。

原作者： Uwe M. Borghoff, Mark Minas, Jannis Schopp

发布于 2026-06-25

📖 1 分钟阅读☕ 轻松阅读

原作者： Uwe M. Borghoff, Mark Minas, Jannis Schopp

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

大局观：AI 时代的编程教学

想象一下，在一所大学的课堂上，学生们就像是一支建筑师和建造者组成的团队，任务是从零开始构建一个复杂的视频游戏。这就是一门“编程项目”课程。通常情况下，这些学生通过亲自动手来学习构建，但现在，他们的口袋里多了一个强大的新工具：生成式 AI（例如 ChatGPT 或 GitHub Copilot）。

慕尼黑联邦国防军大学的研究人员想要回答两个重大问题：

目前学生们究竟是如何使用这些 AI 工具的？
我们能否构建一个更出色的 AI 工具，它能真正理解学生正在构建的具体游戏，而不是仅仅靠猜测？

第一部分：“西部荒野”研究（学生们的自然行为）

首先，研究人员观察了当学生们在使用免费、公开的 AI 工具且不受限制时会发生什么。他们要求 38 名学生在项目完成后填写了一份调查问卷。

研究结果：

“文本”与“代码”的分野： 学生们非常喜欢用 AI 来处理文字工作。这就像拥有了一位超快速的秘书，可以起草需求文档、编写用户手册，或者解释一段代码可能在做什么。
“幻觉”问题： 当涉及到为他们的特定游戏编写实际代码时，AI 经常会迷失方向。想象一下，你向一位旅行社代理人询问如何预订前往一个尚未存在的城市的航班。AI 会自信满满地编造出与学生实际项目不符的细节。
“上下文”缺失： 最主要的问题是，公开的 AI 工具并不了解学生正在处理的特定“蓝图”（源代码）。它们就像是一个试图修理法拉利，却拿着福特汽车手册的机械师。AI 会建议一些并不匹配或在学生的程序中根本不存在的零件。

结论： 学生们大量使用 AI（89% 的人都在用！），主要目的是节省编写文档和解释概念的时间。但当他们尝试利用 AI 来构建实际的游戏时，由于 AI 并不知道他们的具体项目，他们往往不得不去修正 AI 犯下的错误。

第二部分：“本地图书管理员”实验（全新的解决方案）

研究人员意识到，公开的 AI 工具就像是缺乏特定细节的“通用知识”百科全书。

运作方式（类比）：
把公开的 AI 想象成一个才华横溢但失忆的作家。他们知道如何写代码，但不知道你具体的房子长什么样。

研究人员构建了一个本地图书管理员。

图书馆： 他们将学生整个游戏的完整代码和文档放入了一个私有的、本地的图书馆（即“仓库/Repository”）。
图书管理员： 这个 AI 助手运行在校园内的一台电脑上（为了隐私）。在回答问题之前，它不仅仅是靠猜；它会去图书馆查找与问题相关的精确蓝图和代码文件，并阅读它们。
结果： 现在，当一名学生问：“我该如何给飞船添加音效？”时，图书管理员会查看图书馆中实际的飞船代码，并给出一个完美契合的答案，而不是胡编乱造。

实验过程：
他们针对两个特定任务测试了这个“本地图书管理员”：

任务 A： 改变游戏中飞船的外观（从方块变为 3D 模型）。
任务 B： 添加可以开启或关闭的背景音乐。

他们测试了不同的 AI “人格”（不同的模型）以及不同的设置（AI 应该是更具创造力还是更严谨）。

研究结果：

上下文即王道： “本地图书管理员”在提供符合项目实际情况的答案方面表现得好得多。因为它有真实的蓝图可以查阅，所以不会像以前那样频繁编造虚假代码。
“金发姑娘原则”设置（恰到好处）： 他们发现，如果 AI 太过“有创意”（随机性高），它就会再次出现幻觉。如果它太“严谨”，则会显得枯燥。中间地带的设置效果最好。
规模并不总是决定一切： 有趣的是，最大的、最强大的 AI 模型并不总是最好的。一个中等规模的模型实际上做得非常好，而最小的模型则难以理解复杂的指令。
一个顽固的缺陷： 即便有了“图书管理员”，AI 有时也会忘记更新特定的“资源列表”（比如忘记在游戏的菜单中注册一个新的声音文件）。这种现象在几乎所有模型中都出现了，这表明这是一种难以改掉的习惯，而不仅仅是缺乏知识的问题。

核心总结

论文得出结论：虽然 AI 是帮助学生编写文档和理解通用概念的绝佳工具，但如果它试图在没有“察言观色”（即缺乏项目上下文）的情况下构建特定软件，它就会感到吃力。

通过构建一个能够直接访问项目代码和文档的 AI（即“本地图书管理员”），研究人员证明了 AI 可以成为一个更加可靠的伙伴。它不再靠猜测，而是开始提供准确的、具备上下文感知能力的解决方案。

下一步计划是什么？
研究人员计划将这个“本地图书管理员”转变为真正的导师。与其只是给出答案，他们希望 AI 能引导学生解决问题，帮助他们学习“如何”解决问题，而不是仅仅把现成的方案塞给他们。这能确保即使在有 AI 辅助的情况下，学生们依然能掌握必要的技能。

技术摘要：学习编程中的上下文应用：基于研究的方法

问题陈述

生成式人工智能工具的快速兴起正在改变软件开发，迫使软件工程教育进行调整。虽然学生经常使用通用型 AI 工具（如 ChatGPT、GitHub Copilot），但他们在将这些工具应用于结构化、团队协作的软件项目时，往往会遇到显著的局限性。具体而言，通用型模型缺乏对特定项目上下文的感知，包括私有源代码、项目文档以及特定领域框架（如 jMonkeyEngine）。这导致了“幻觉”、代码生成不准确以及集成失败，尤其是在学生试图利用 AI 进行代码理解和实现而非仅仅是文本生成时。此外，人们也担心存在“技能退化”的问题，即过度依赖 AI 可能会阻碍独立解决问题能力的培养。核心挑战在于开发一种能够提供有意义的、具备上下文感知能力的辅助系统，而不是简单地提供现成的解决方案，同时还要在满足数据保护约束的前提下进行本地化部署。

研究方法

作者在大学编程项目课程中采用了两阶段实证方法，在该课程中，学生团队使用 Java 和瀑布模型开发 3 维多人在线游戏。

第一阶段：用户研究（定量与定性）

背景： 在 2024 年 10 月至 12 月学期期间进行，共有 38 名参与者（约占该班级总人数的 78%）。
数据收集： 在最终的项目演示期间，通过基于技术接受模型（Technology Acceptance Model）的结构化问卷进行调查。研究评估了 AI 在四个阶段的使用情况：准备、分析、设计以及编码与测试。
重点： 研究调查了学生在哪些任务中使用了 AI、感知的帮助程度、节省的时间以及遇到的具体挑战（例如：缺乏上下文、结果不准确）。

第二阶段：案例研究（仓库感知型 LLM 助手）

系统设计： 为了解决第一阶段发现的上下文局限性，作者开发了一个本地部署的、具有仓库感知能力的（repository-aware）大语言模型（LLM）助手。
架构：
- 检索增强生成 (RAG)： 系统采用双路径接地机制（dual-path grounding mechanism）。
  1. 文档级 RAG： 通过语义嵌入检索相关的项目文档和辅助材料。
  2. 代码级查找： 使用只读的 GitLab API 工具（file_path_finder、get_content_from_file、get_methods）根据用户查询检索特定的源代码文件和方法签名。
- 部署： 系统运行在配备 NVIDIA DGX-H100 服务器的 Docker 容器中。它利用 vLLM 进行模型服务（兼容 OpenAI API），并使用 Open WebUI 作为聊天界面。
  数据隐私： 本地化部署确保了数据控制权和可复现性，解决了机构的数据保护要求。
评估：
- 任务： 使用了来自 Battleship 项目“准备”阶段的两个代表性任务：(1) 根据长度添加 3D 舰船模型；(2) 实现背景音乐控制。
- 变量： 研究进行了“采样扫描”（改变 temp、top_p、min_p）和“模型扫描”（测试了从 7B 到 236B 参数量不等的六种模型，包括 DeepSeek-Coder、Mistral 和 Qwen 系列变体）。
- 分析： 生成的输出根据包含 12 类错误的“缺陷目录”（Defect Catalog）进行分析（例如：幻觉、工具误用、鲁棒性不足、缺失资源条目）。

核心贡献

上下文局限性的实证证据： 用户研究提供了定量数据，证明虽然学生大量使用 AI 处理文档和需求（文本密集型任务），但由于通用型工具缺乏项目上下文，他们在代码理解和实现方面面临显著困难。
仓库感知型助手架构： 本文展示了一个具体的实现方案，即一个本地部署的、基于 RAG 的助手，它将文档检索与代码级的仓库查找相结合。该系统旨在将响应锚定在实际的项目构件之上。
面向 AI 教育的缺陷目录： 作者定义了一个包含 12 种常见缺陷类型的特定目录，这些缺陷是在 LLM 与软件仓库交互时观察到的，为 AI 在教育环境中的行为提供了定性分析框架。
参数与模型敏感性分析： 研究提供了关于采样参数（特别是温度和 min_p）以及模型规模如何影响特定缺陷（如幻觉）发生频率的实证发现。

结果

用户研究发现

采用率： 89.4% 的参与者使用了 AI 工具。采用率在“编码与测试”阶段最高（33/38 人），在“设计”阶段最低（10/38 人）。
帮助程度： AI 在“准备”和“编码与测试”阶段被评为“有帮助”或“非常有帮助”，特别是在文档编写和代码生成方面。然而，在“设计”阶段，其被评为最没帮助（通常是“中立”或“没帮助”），主要是因为 AI 无法生成准确的图表（类图、序列图、状态图）。
挑战： 主要问题包括“结果不准确”、“缺失上下文”（AI 不了解特定的项目代码或 jMonkeyEngine 等框架）以及“幻觉”（生成不存在的方法）。
感知： 尽管存在挑战，24 名用户认为 AI 为他们节省了大量时间，且大多数人表示有意在未来的项目中继续使用 AI。

案例研究发现

上下文的有效性： 与用户研究中观察到的通用型工具相比，仓库感知型助手生成的输出始终更符合项目结构。将响应锚定在实际的仓库构件中减少了集成问题。
缺陷模式：
- 幻觉： 仍然是最频繁出现的缺陷（在 14/15 个采样配置中出现），尤其是在高温度（ $T=1.0$ ）下。然而，系统的文件检索能力通常允许在后续轮次中进行自我修正。
- 缺失资源条目： 一个在几乎所有模型和配置中都反复出现的缺陷，即模型在成功检索相关文档后，仍未能注册新的资源（例如本地化键值）。这表明存在“检索到行动之间的鸿沟”。
- 采样参数： 配置为 $T \approx 0.5$ ， $top\_p = 0$ （或较低值）的配置最为稳定，产生的缺陷最少。高温度结合过滤机制往往会增加错误率。
模型性能：
- 模型规模与成功率之间并不存在线性相关关系。24B 的 Devstral-Small-2505 产生了高度可用的输出，而 7B 的 Mistral-7B 则无法在没有大量后续操作的情况下完成任务。
- 极大型模型（如 235B）提供了详细的推理过程，但在集成保真度方面并不比中型模型表现得更一致。
- 所有模型中一个共同的问题是，无法有效地利用检索到的上下文来执行特定动作（例如向资源文件写入内容），这表明工具集成是一个独立于模型规模的瓶颈。

重要性与主张

本文主张，集成上下文感知检索（特别是仓库锚定）是使 AI 对软件工程教育变得有用的关键步骤。作者认为，虽然通用型 AI 工具在处理基于文本的任务时很有价值，但如果没有访问项目特定构件的权限，它们在代码实现方面是不够的。

研究表明，本地部署的、具有仓库感知能力的助手可以减轻通用型 AI 的“集成弱点”，产生更连贯且可复现的输出。然而，作者对当前技术的现状保持审慎，承认：

即使有了 RAG，幻觉和工具误用依然存在。
图表生成和视觉设计仍然是 AI 支持较弱的领域。
技能退化是一个风险；因此，提出的未来方向不是一个为学生解决问题的 AI，而是一个提供提示并引导独立解决问题的“导师”。

这项工作的意义在于，它从评估通用的 AI 工具转向了工程化地评估和开发特定上下文的 AI 助手，这些助手既尊重数据隐私，又符合教育目标，为这类系统如何整合进软件工程课程提供了蓝图。