🤖 AI

AI-Assisted Help-Seeking Trajectories in Programming Education from an SRL-Informed Perspective

本研究利用基于自我调节学习（SRL）的框架分析了入门级编程课程中由人工智能辅助的求助轨迹，结果表明，尽管学生主要将人工智能用于反应式故障排除而非自我调节的问题解决，但这些交互模式显著影响了代码提交的数量，尽管并未直接影响任务得分。

原作者： Boxuan Ma, Huiyong Li, Gen Li, Li Chen, Atsushi Shimada, Shin'ichi Konomi

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

原作者： Boxuan Ma, Huiyong Li, Gen Li, Li Chen, Atsushi Shimada, Shin'ichi Konomi

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

想象一下，你正在学习烹饪一道复杂的菜肴。你有一份食谱，但你总是把大蒜烧焦，或者放了太多的盐，或者漏掉了某个步骤。在过去，你可能必须等待厨师走过来帮你，或者你可能会因为觉得不好意思而不敢开口询问。

现在，想象一下你的身边坐着一位速度极快、知识渊博的副厨（生成式人工智能）。你可以低声问一个问题，他会立即告诉你如何修复烧焦的大蒜或如何切洋葱。

这篇论文是一项研究，探讨了 71 名大学生在学习使用 Python 进行编程（即“烹饪”）时，是如何使用这位“AI 副厨”的。 研究人员不仅仅是在统计学生寻求帮助的次数；他们想观察寻求帮助过程中的“故事”。学生们是提前做好了计划吗？他们是否陷入了修复微小错误的死循环？还是他们只是索要了整份食谱并直接照抄？

以下是他们利用简单的类比得出的研究结果：

1. 主要发现：“救火队员” vs. “建筑师”

研究人员发现，大多数学生把 AI 当作救火队员，而不是建筑师。

救火队员（反应式）： 学生主要在出问题之后才使用 AI。他们写代码，代码报错了，然后问：“为什么这里会出现红色的错误信息？”或者“修复这一行。”
建筑师（主动式）： 极少有学生在开始之前利用 AI 进行规划。他们很少询问：“构建这个程序最好的方式是什么？”或者“你能解释一下这个概念吗，好让我理解得更透彻？”
隐喻： 这就像大多数学生在等到房子着火时才打电话给 AI，而不是在设计一座防火房屋之前就打电话请 AI 帮忙。

2. 五种“求助习惯”（轨迹）

研究人员将学生的互动行为分为五种不同的模式，就像人们在迷宫中导航的不同方式：

“一击即中”（快速修复）： 学生问一个问题，得到一个答案，然后继续下一步。
- 类比： 你问：“鞋带怎么系？”AI 展示给你看，你系好了。结束。
- 发现： 这是最常见的习惯（超过一半的时间）。有趣的是，有时这只是一个快速修复，但有时是一个聪明的学生在问：“有没有更好的系鞋带的方法？”（这是一件好事！）。
“调试执念”（死循环）： 学生卡在一个微小的错误上，不断地要求 AI 反复修复它，而不改变自己的方法。
- 类比： 你试图打开一个罐头。你问 AI：“怎么打开它？”AI 说：“转动盖子。”你尝试了，失败了。你再次询问：“还是打不开！”AI 说：“再用力点转。”你又试了一次。你这样重复了 10 次。
- 发现： 这些学生在精力投入上是最“昂贵”的。为了得到同样的结果，他们提交代码的次数是“一击即中”型学生的两倍多。他们陷入了试错的循环，依赖 AI 来代替他们思考。
“概念构架”（规划者）： 学生在编写任何代码之前，先询问规则或概念。
- 类比： 在烹饪之前，你会问：“‘文火慢炖’是什么意思？”或者“我该如何安全地切洋葱？”然后你才开始烹饪。
- 发现： 这些学生效率很高。他们先理解了基础知识，因此后期的错误较少。
“目标导向”（任务达人）： 学生直接跳到构建解决方案的阶段，要求 AI 编写代码或修复特定部分，以便快速完成任务。
- 类比： 你说：“给我做一个三明治，”然后 AI 就把它做好了。你只需要检查味道对不对。
- 发现： 这对于拿到分数是很高效的，但研究人员担心学生可能并没有学会如何亲手制作这个三明治。
“模式切换”（灵活的学习者）： 学生最初使用一种类型的帮助（比如修复错误），但随后意识到自己不理解其中的概念，于是转向询问解释，然后又回到修复工作。
- 类比： 你尝试打开罐头，卡住了，接着问“为什么这个罐头这么难打开？”（概念），得到了答案，然后再次尝试。
- 发现： 这种情况很罕见，但它展示了最高水平的“自我调节”学习——当原有的策略不起作用时，能够调整策略。

3. 大大的惊喜：成绩 vs. 努力程度

你可能会认为那些使用 AI 最“聪明”（规划者或灵活学习者）的学生会获得最好的成绩。

现实情况： 每个人的成绩大致相同。因为计算机评分系统允许学生反复提交代码直到运行成功，所以几乎每个人最终都拿到了分数。
真正的区别： 区别在于他们为了达到目标付出了多少工作量。
- “调试执念”（死循环）型的学生平均需要提交代码 12 次。
- “一击即中”型的学生平均只需提交 5 次。
- 教训： AI 帮助每个人通过了考试，但对某些学生来说，它变成了一个拐杖，让整个过程变得更长、更令人沮丧。

4. 这意味着什么？

论文得出结论：关键不在于学生是否使用 AI，而在于他们如何使用 AI。

如果一名学生只是反复修补错误（就像一个只会在引擎坏掉时反复拧紧松动螺栓，却不去修理发动机的机械师），他们可能会通过课程，但他们并没有学会如何开车。
如果一名学生利用 AI 来理解规则、规划步骤并检查自己的工作，那么他们就是在将 AI 作为真正的学习伙伴。

总结： “教育价值”不在于最终的分数（因为大家的成绩都一样），而在于旅程本身。这项研究表明，我们不仅要教学生如何向 AI 寻求答案，还要教他们如何利用 AI 进行规划、理解和反思，而不是仅仅在惊慌失措时用它来修复破碎的代码。

技术摘要：基于自我调节学习（SRL）视角的编程教育中 AI 辅助求助轨迹研究

1. 问题陈述

在入门级编程教育中，初学者经常在语法、控制流和错误诊断方面遇到深层的认知不确定性。传统的支持机制（如答疑时间、论坛）往往无法提供及时的个性化协助，导致学生理解浅显且问题解决能力发展不足。虽然生成式人工智能（特别是大语言模型）通过提供即时、个性化的支持为解决规模化问题提供了可能，但也带来了教学风险。人们担心学生可能会将问题解决的步骤“卸载”给 AI，从而陷入“元认知懒惰”，即依赖工具进行推理，而非发展自身的调节能力。

现有的研究主要关注 AI 使用的频率、生成代码的正确性或通用的可用性。然而，在理解学生——AI 求助行为如何随时间演进方面存在显著空白。具体而言，目前对于这些交互的序列结构（轨迹）以及它们是反映了自我调节学习（SRL）过程（计划、监控、反思）还是反应式故障排除，仍知之甚少。本研究旨在超越静态的使用指标，分析在 AI 支持的编程任务中，求助行为随时间变化的动态演进过程。

2. 研究方法

2.1 背景与参与者

本研究在某国立大学的一门 Python 入门本科课程中进行，涵盖了两个学期（2024 年夏季和 2025 年夏季）。

参与者： 共有 166 名一年级学生报名。最终用于分析的样本为 71 名在课程期间至少生成了五次提示词（prompt）的学生。
课程结构： 课程包含 14 个课时，涵盖 57 个编程任务，涉及变量、字符串、函数、条件语句和循环。
AI 工具： 学生可以使用一个连接到 GPT-4o 的定制 Web 界面进行实时交互。所有对话均被记录。

2.2 数据来源

分析整合了两种互补的追踪数据源：

自动化评估提交记录： 通过 CodeRunner 插件收集了 71 名学生（对应 57 个任务）的 17,190 次代码提交记录。这些日志提供了任务得分（基于通过测试用例的数量，分值为 0–5）和提交尝试次数。
学生–AI 对话日志： 从 635 个对话会话中提取了 1,290 个特定于任务的提示词。与课程任务无关或在练习时间之外提交的提示词被排除在外。

2.3 分析框架与编码

研究采用了 SRL 启发式分析框架（图 1）来解释求助行为。

编码方案： 提示词被编码为 10 个细粒度类别，并归入四个主要功能角色：
- 概念类（Conceptual）： 澄清概念、语法或需求（例如：概念提问、问题理解）。
- 实现类（Implementation）： 构建解决方案或生成代码（例如：代码生成、实现提问）。
- 调试类（Debugging）： 解释错误、修正代码或验证输出（例如：错误解释、代码修正）。
- 反思类（Reflective）： 解释运行中的代码或寻求优化（例如：代码解释、代码优化）。
信度： 两名研究人员通过共识编码实现了 92.7% 的评分者间一致性 ( $\kappa = .88$ )。
轨迹分析：
- 序列分析： 使用滞后序列分析（Lag sequential analysis）和桑基图（Sankey diagrams）来检查不同轮次间提示词类别之间的转换。
- 基于尝试层级的分类法： 开发了一个基于规则的分类法，将整个任务特定的会话分为五种轨迹模式：
  1. 单次型（One-shot）： 单次提示。
  2. 调试持续型（Debugging-Persistence）： 三次或更多次连续的调试提示。
  3. 概念构架型（Conceptual-Framing）： 以概念性求助开始的会话。
  4. 性能导向型（Performance-Oriented）： 仅由实现和调试类求助组成的会话。
  5. 模式切换型（Mode-Shifting）： 涉及不同求助模式之间转换的会话（例如：从调试转向概念）。

2.4 表现指标

编程表现通过两个指标进行评估：

任务得分： 最终获得的得分（0–5）。
过程成本（Process Cost）： 达到解决方案所需的代码提交次数。

3. 关键结果

3.1 求助提示词的分布

调试占主导地位： 调试是最频繁的类别，占所有提示词的 67.0%。其中，错误解释（EI）和代码修正（CC）是最常见的具体编码。
缺乏反思： 反思类求助仅占提示词的 1.6%。概念类和实现类求助分别占 14.6% 和 16.8%。
反应式特征： 数据表明，学生主要将 AI 作为即时故障排除的反应式辅助工具，而非用于有计划的、自我调节的问题解决。

3.2 序列模式与轨迹

在调试中停滞： 序列分析显示，学生经常停留在调试类别中。调试类内部的自转换显著升高（ $z = 6.1$ ），而跨类别转换（例如：概念 $\to$ 调试）则经常受到抑制。
轨迹模式：
- 单次型 (53.1%)： 最常见的模式，以单次调试请求为主。
- 性能导向型 (19.2%)： 多轮交互仅专注于实现和调试。
- 调试持续型 (12.6%)： 具有持续、重复调试尝试的会话。
- 概念构架型 (9.0%) 和 模式切换型 (6.1%) 较少见。

3.3 与表现的相关性

任务得分： 五种轨迹模式之间的任务得分没有显著差异（ $p = .950$ ）。大多数学生无论采用何种交互模式都能获得高分，这可能是由于可以多次提交代码的原因。
代码提交（过程成本）： 在代码提交次数方面发现了显著差异（ $p < .001$ $p < .001$ ）。
- 调试持续型 需要最高的提交次数（平均值 = 11.90），显著高于单次型（平均值 = 4.82）或概念构架型（平均值 = 5.91）。
- 单次型 和 概念构架型 模式与较低的过程成本相关。
稳健性： 调试持续型较高的提交次数在简单任务和困难任务中均成立，表明是该模式本身而非任务难度驱动了过程成本的增加。

3.4 案例说明

定性案例展示了这些模式对 SRL 的影响：

调试持续型： 学生经常针对微小的格式问题进行“尝试与修复”循环，而未能诊断底层规则。
概念构架型： 学生在编码前澄清概念，从而实现了高效的验证。
模式切换型： 学生成功地从调试转向概念性问题，展示了灵活的调节能力。
单次型： 虽然通常是反应式的，但部分单次提示也被用于反思性优化（例如：询问替代实现方案）。

4. 主要贡献

SRL 启发式分析框架： 本研究引入了一个将提示词层级的编码与概念、实现、调试和反思性支持联系起来的框架，并通过自我调节学习（SRL）的视角进行解读。
识别轨迹模式： 研究超越了聚合使用统计数据，识别出五种不同的、反复出现的求助轨迹（单次型、调试持续型、概念构架型、性能导向型、模式切换型）。
区分过程与结果： 研究表明，虽然 AI 支持的轨迹不会显著影响最终的任务得分（由于多次提交的机会），但它们在过程成本（提交次数）上存在实质性差异。
反应式使用与调节式使用的证据： 研究结果提供了实证证据，表明许多学生将 AI 用于反应式故障排除（陷入调试循环），而非用于有计划的、自我调节的问题解决，这凸显了“元认知懒惰”的特定风险。

5. 意义与主张

本文认为，AI 支持在编程教育中的意义不仅在于学生是否使用 AI 或使用 AI 的频率，而在于他们在解决问题过程中其求助轨迹是如何发展的。

重构 AI 使用的定义： 研究指出，高任务得分并不一定意味着有效的学习或高效的问题解决。通过“调试持续”轨迹（高过程成本、反应式）完成任务的学生，其学习体验可能与通过“概念构架”轨迹（低过程成本、计划导向）完成任务的学生截然不同。
教学启示： 作者建议，教学干预应侧于关注交互的结构。AI 系统和教师应旨在检测并中断“修复导向循环”（调试持续型），通过引导概念性反思或自我解释，而非仅仅提供下一个修正方案。
研究范围限制： 作者承认了局限性，指出本研究是在单一入门课程中进行的，且分析依赖于追踪数据（提示词和提交记录）而非直接测量内部认知状态。他们并不声称特定的轨迹模式会导致更好的学习结果，而是认为这些模式代表了具有不同相关过程成本的、截然不同的调节结构。

总之，本文认为，支持学生从重复的调试请求转向概念澄清和自我解释，对于使 AI 辅助的编程支持符合自我调节学习的目标至关重要。