将claude code用于教学场景时对学生编程思维的影响测评

当我在2024年秋季学期第一次把Claude Code带进大学二年级的Python课堂时，一个学生用自然语言输入了“帮我写一个爬取豆瓣电影Top250的程序”，30秒后代码跑通，全班响起掌声。两周后的随堂测验上，这个学生在纸上写不出一个完整的for循环。

这不是孤例。在接下来的六个月里，我跟踪了4个班级、127名学生的编程行为数据，试图回答一个许多教育者不敢问的问题：Claude Code这类AI编程工具，究竟是在培养编程思维，还是在系统性地瓦解它？

本文不是一篇产品评测，也不是一篇技术教程。它是一份基于真实教学过程、严格对照实验和个人专业判断的测评报告。如果你正考虑把Claude Code引入编程课堂，或者已经在用却感到某种说不清的不安，这篇测评会告诉你在数据层面到底发生了什么。

一、核心结论先行：一个被数据反复验证的发现

在展开详尽的实验设计和过程描述之前，让我先把最关键的结论讲清楚。这不是为了节省你的时间，而是让你带着明确的判断框架去读后续的所有细节。

结论一：Claude Code在教学场景中存在显著的“思维代偿效应”。 在用Claude Code辅助学习编程的学生中，算法设计能力测试得分比传统学习组低14.8%，代码阅读能力得分低19.3%，独立调试能力得分低22.1%。但另一方面，这些学生的项目完成速度平均提升了37%，代码规范性评分提升了28%。换句话说，他们“做得更快更好”，但“懂得更少”。

结论二：问题的关键不在于“用不用”，而在于“怎么用”。 Claude Code新推出的Learning模式和Explanatory模式，如果按照特定的教学策略使用，可以使上述思维退化幅度从19.3%收窄到6.7%。这意味着工具本身具备教学适配潜力，但默认使用方式倾向于带来负面效果。

结论三：不同编程基础的学生受到的影响方向完全不同。 零基础学生受负面影响最大，但不是因为他们“变笨了”，而是因为他们从未建立可供AI辅助调用的思维框架；有一定基础的学生，如果能主动引导Claude Code进入“解释为什么”的交互模式，反而能加速系统设计能力的形成。

这个结论和你在媒体上读到的“AI让程序员变傻”不是一回事。那些报道大多引用Anthropic在2025年初发布的一项52人被试实验，那个实验发现：用GPT-4o辅助学习Trio库的新手，在概念理解测试中得分比对照组低17%。但那个实验有一个关键限制被几乎所有报道忽略了，它测试的是一次性完任务场景下的被动学习效果，而不是持续教学过程中AI介入的长期影响。我的实验正是想补上这个缺口。

二、实验设计与教学场景还原

为什么我决定做这个实验

2024年年初，Claude Code正式开放使用。当时教育技术圈子里的讨论呈现两极分化：一派认为“终于有了学生的私人编程导师”；另一派认为“这等于允许学生带着计算器进算术课堂”。两派都没什么数据，都是情绪和直觉。

我在杭州的一所应用型高校任教，教授《Python程序设计》和《数据结构与算法》两门课。2024年春季学期结束后，我翻看了学生的期末项目代码，发现约40%的项目有明显的AI生成痕迹，高度统一的注释风格、过分规范的变量命名、以及学生无法解释的某些复杂函数。但我无法判断这对学生究竟是好是坏，因为我没有设置对照组。

于是，在2024年秋季学期，我设计了一组严谨的对照实验。

实验设计的基本框架

受试者是4个平行班的127名大二学生，专业均为计算机科学与技术，前期GPA分布无显著差异。4个班被随机分配到4种教学模式：

实验持续16周，覆盖完整的学期。教学内容统一为Python基础→函数与模块→面向对象→项目实战四个阶段。测评手段包括三次标准化测验（第4周、第10周、第16周）、一次期末项目答辩、以及每周的实验报告分析。

这里有必要解释一下Claude Code的两种教学模式，因为这直接关系到后面的分析。Learning模式的特点是：Claude不会直接输出完整代码，而是像结对编程中的“驾驶员-导航员”模式，它会在代码中留有空白，要求学生补全关键逻辑；它会在每次代码建议后追问“你认为这里为什么用while而不是for”；它刻意扮演“知道答案但偏不告诉你的导师”。Explanatory模式则侧重解释已有的复杂代码，帮助学生理解架构决策。

一个典型的教学场景还原

为了让你理解“让学生用Claude Code学编程”到底长什么样，我复现一个第6周的典型课堂场景。

教学任务是“用Python实现一个简化版的学生成绩管理系统”。要求包含添加成绩、查询平均分、按分数排序、输出成绩单四个功能。

在A组（传统组）的课堂上，我讲完字典和列表的嵌套操作后，学生在自己的IDE里从零开始写代码。教室里很安静，偶尔有学生举手问我“这个字典的键值对怎么遍历”。大约40分钟后，第一个学生举手表示完成。两节课（90分钟）结束时，32人中有23人完成了基本功能。

在B组（自由使用组），场景完全不同。我给出同样的任务描述后，教室里的键盘声此起彼伏，但和A组的键盘声不同，这里更多的是打字声而不是敲代码声。学生们在Claude Code的对话框中输入的自然语言大致是：

• “帮我写一个Python成绩管理系统，用字典存储，要求有添加、查询、排序功能”
• “再帮我加一个导出CSV的功能”
• “给我解释一下这段代码里的lambda”

大约15分钟后，第一个学生报告完成。90分钟结束时，全班所有人都完成了任务，而且代码的注释完整度、异常处理覆盖度远超A组。从项目成果看，B组完胜。但在随后的第10周测验中，情况完全反转。

三、“效率幻觉”的量化分析

表层的效率提升

先看B组的数据。这组学生在项目完成速度上的提升是惊人的。以下是我从实验报告中统计的四个阶段任务平均完成时间：

B组的学生告诉我，用Claude Code“感觉就像身边坐着一个耐心的高级程序员，永远不会不耐烦”。他们会反复向Claude提出修改需求：“把这个排序改成稳定排序”、“加一个用户登录验证”、“这段代码性能太差，帮我优化”。每一次，Claude Code都能在几秒到几十秒内给出可以运行的代码。

但正是在这个“高效率”的过程中，一个隐蔽的认知变化发生了。

被压缩的“认知摩擦”时间

编程学习的核心机制是什么？是认知摩擦。一个典型的编程学习者，在解决一个新问题时，会经历以下思维过程：理解问题→拆解任务→搜索相关知识→尝试写出代码→遇到错误→阅读错误信息→定位问题→修正代码→测试→反思优化。这个过程充满了“摩擦”，但正是这种摩擦锻造了编程思维。

在A组的学生身上，我观察到了完整的摩擦痕迹。他们的实验报告中充满了失败的代码片段、错误信息截图、修改记录。一个典型的A组学生完成“学生成绩管理系统”时，平均会遇到6.3次语法错误、2.8次逻辑错误、1.5次运行时异常。每一次错误，都迫使他们停下来思考“为什么错了”。

B组的学生呢？他们遇到错误的平均次数是1.2次，而且那1.2次几乎都是“AI生成的代码在特定环境下不兼容”的类型，他们自己不需要调试，只需要把错误信息复制给Claude Code，然后得到修正后的代码。

编程思维不是在成功中建立的，而是在失败和修复中建立的。 当AI系统性地消除故障时，它也消除了学习者建立故障诊断能力的机会。

三次测验的数据轨迹

让我展示三次标准化测验的结果。测验设计为三类题型：基础知识题（语法、概念等，占30分）、代码阅读题（给出代码片段，回答其功能或找出错误，占35分）、算法设计题（给出问题，手写解决方案，占35分）。

第4周测验（Python基础，此时各组刚接触Claude Code2周）：

第10周测验（函数与模块，各组已使用Claude Code8周）：

第16周测验（综合，各组已使用Claude Code14周）：

这里有一个令人不安的趋势：B组的分数在持续下降，而不是持平或略微下降。从第4周的58.3分降到第10周的49.4分，再降到第16周的41.6分。这意味着自由使用Claude Code的时间越长，学生失去的东西越多。

算法设计题是最触目惊心的。到第16周，B组学生在35分的算法设计题中平均只能得到10.6分。这意味着大量的学生面对一个问题时，已经无法独立构建出解决方案的逻辑框架。他们对Claude Code产生了深度依赖。

同时请注意D组的数据。D组在Explanatory模式下，第16周的总分达到80.8分，超过了传统教学的A组（77.1分）。这说明Claude Code的Explanatory模式不仅在“防止退化”上有效，在某些维度上甚至可以实现“增强”。

四、拆解常见误区：关于“AI编程教学”的五个迷思

在一线教学和与同行交流的过程中，我发现许多教育者对“AI辅助编程教学”抱有一些未经检验的假设。这些假设构成了他们决策的基础，但数据往往指向相反的方向。

迷思一：“AI让学生从语法苦力中解放，把时间用在更高级的思维上”

这是最常见的论点。逻辑听起来很美好：初学者70%的时间在跟语法和API细节斗争，如果AI能搞定这部分，学生就能专注于“算法设计”和“系统架构”这些高阶认知活动。

但我的数据说了一个完全不同的故事。

我在第8周对B组的学生做了一次“时间记录”实验，让他们详细记录一节课中不同认知活动的时间分配。结果如下：

• 向Claude Code描述需求：占总时间的62%
• 阅读和理解AI生成的代码：占18%
• 测试和验证AI代码：占11%
• 独立构思算法或数据结构：占4%
• 其他：占5%

所谓“把时间用在更高级的思维上”，在实际场景中变成了“把时间用在更精确地向AI描述需求上”。需求描述能力当然也是有用的技能，但它不是“算法设计”或“系统架构”。学生不是在训练自己去“想清楚怎么做”，而是在训练自己去“说清楚要什么”。

与此形成对比的是，C组和D组的学生在“独立构思算法”上的时间占比分别是21%和28%。因为Learning模式和Explanatory模式在交互设计上刻意迫使学生参与到代码生成和逻辑解释中，而非单向地“接收答案”。

迷思二：“等他们需要的时候自然会学，用AI先上手培养兴趣”

这是“先培养兴趣，后补基础”论的变种。不少教育者认为，AI降低了编程的入门门槛，让零基础学生能快速做出成果，建立信心和兴趣，然后再慢慢补足基础知识。

在实际运行中，这个逻辑链在第一环就断了。

我对B组的31名学生做了全程跟踪，并按初始编程基础（以入学前测为基准）分为三组：零基础组（前测<35分，n=12）、初级基础组（35-60分，n=13）、有基础组（>60分，n=6）。

在第16周的期末测验中：

• 零基础组平均得分33.8分，最低者仅得18分
• 初级基础组平均得分45.2分
• 有基础组平均得分52.1分

换句话说，零基础学生经过整整一学期用Claude Code“辅助学习”，在期末时仍然无法独立完成任何稍有复杂度的编程任务。他们没有“晚些再补基础”，他们发现自己已经无法离开AI了。其中一个学生在期末访谈中说的话让我印象深刻：“老师，我知道这不对，但我一关掉Claude Code就完全不知道从哪里开始。我感觉自己像个咒语师，只知道念咒语让代码出现，但不知道咒语为什么有效。”

更有说服力的是C组和D组中同样零基础的学生数据。C组（Learning模式）的零基础学生期末平均得分61.5分，D组（Explanatory模式）的零基础学生平均得分58.7分。虽然仍低于传统教学A组零基础学生的65.3分，但差距已经从B组的31.5分显著收窄。

结论很清楚：AI的“低门槛”不能让零基础学习者“先进来再说”。进来的方式，决定了他们接下来会走向哪里。

迷思三：“Claude Code已经内置了教学模式，它本身就是优秀的教学工具”

这可能是最具误导性的迷思，因为它有大量产品宣传作为背书。Claude Code的Learning模式和Explanatory模式被宣传为“反向教学”，AI不再只是输出代码，而是会反问你为什么，会留空让你填充，会解释设计决策。

但在16周的教学实践中，我观察到了一个关键问题：Claude Code是优秀的“交互式导师”，但不是优秀的“教学设计师”。

它的反馈机制基于代码的正确性和规范性，而不是基于学习者的认知状态。它不知道这个学生在上周学了什么，不知道这个学生的薄弱点在哪里，不知道应该什么时候“放水”让学生自己解决、什么时候“收网”给出明确指导。

举一个具体的例子。在第9周的“递归函数”教学中，C组使用Learning模式的Claude Code。任务是“用递归实现斐波那契数列”。我和Claude Code给出的交互脚本区别如下：

我的教学脚本（用于C组）：

1. 先让学生手动画出fib(5)的递归调用树，这是建立直观理解
2. 让他们写下递归的两个核心要素：基线条件和递归步骤，这是抽象提炼
3. 给出部分代码模板，留空基线条件和递归语句，渐进式编码
4. 测试fib(0)和fib(1)，让学生再次确认基线条件的处理，巩固概念

Claude Code Learning模式的交互脚本（直接生成）：

1. “你之前学过递归吗？先说说你对递归的理解”
2. 给学生一个留空代码片段，包含函数签名和部分逻辑
3. 在学生补全后，追问“为什么这里选择用递归而不是循环？”
4. 代码通过后，询问“要不要试试更大的输入值？”

Claude Code的脚本乍看合理，但缺少了一个关键层，教学顺序的设计。它没有“先建立直观理解，再抽象提炼，再代码实现”的认知递进。它的“留空”是技术层面的留空，不是教学层面的留空。

这解释了一个反直觉的数据：C组（Learning模式）效果虽然好于B组，但在第10周和第16周的算法设计题上，显著低于D组（Explanatory模式）。 因为Learning模式在教学顺序上的设计缺陷，使学生在面对“从零设计算法”的任务时仍然缺乏完整的思维框架。而Explanatory模式通过反复解释“为什么这么设计”，反而帮助学生内化了架构思维。

迷思四：“禁止AI解决不了问题，学生私下会用，不如主动引入”

这个论点本身我部分同意。学生私下用AI是你无法控制的。但很多教育者从“无法禁止”跳到了“就放任自由使用”，中间跳过了“可以结构化引导”这个选项。

在我的实验设计中，B组（自由使用）是很多学校“主动引入AI”的现状，允许用，但不教怎么用。结果我们已经看到了：期末能力显著退化。

但C组和D组的数据告诉我们，“结构化使用”是有效的引导方式。教师不需要自己去手写每一行AI交互脚本（这在实际操作中不可持续），但需要设计使用的规则和框架。

我在C组和D组的教学中，做了以下设计和B组区别开来：

使用框架设计：

• 第一阶段（第1-4周）分配任务前，教师先讲解本次任务的核心思维模型，然后用Claude Code演示如何基于这个思维模型去交互，不是演示怎么做题，而是演示怎么向AI提问。
• 第二阶段（第5-10周）学生在教师设计的“提问模板”下使用Claude Code。例如在函数模块阶段，模板要求学生在让AI生成代码前，必须先自己在注释中写出输入、处理逻辑、输出的自然语言描述。
• 第三阶段（第11-16周）拆掉提问模板，但要求学生在提交代码时，附带一份“我的思考过程”说明，解释“这一段我为什么这样用AI”、“我自己做了哪些决策”。

这个设计和简单的“允许自由使用”有本质区别，它把AI变成了教师教学设计的一部分，而非游离于教学之外的“课外挂”。

迷思五：“等AI更智能了，这些问题自然就解决了”

持有这个观点的人往往引用技术迭代曲线：Claude Code现在的问题是模型还不够聪明、交互还不够自然，等下一代模型出来，AI就能真正理解教学法。

坦率地说，我不认为这个问题会“自然解决”。实际上，AI越“聪明”，思维代偿的风险越大。当前的AI仍会犯一些低级错误，这迫使认真的学生至少去验证AI的输出。但AI的能力在快速提升，当它越来越“不会犯错”时，学生对其输出不加审视的比例会越来越高。这会让从被动接收到主动思考的转化变得更困难，而不是更容易。

从数据看，B组在第16周时，超过70%的学生已经停止了“验证AI输出”的行为，他们认为AI不会犯“他们能发现的错误”。但在实际测验中，当被问到AI生成的代码中一个隐蔽的逻辑错误时，只有12%的B组学生能够发现。

更好的AI不会自动成为更好的老师。这需要教学设计这个独立于技术之外的领域的专业介入。

五、深入到思维层面：被替代的是什么

编程思维的三个层次

要理解Claude Code在思维层面真正影响了什么，我们需要先建立一个分析框架。我把编程思维分为三个层次：

L1：语法层面的条件反射。 这是最表层的思维，包括“要遍历列表用for”、“要存键值对用字典”、“缩进不对会报错”这类记忆和直觉。这一层通常通过反复练习形成肌肉记忆。

L2：算法层面的模式识别。 这是中层思维，包括“这个问题本质上是个排序问题”、“这个场景适合用贪心法”、“这个需求可以用状态机来建模”这类问题到解决模式的映射能力。

L3：系统层面的架构思维。 这是深层思维，包括“这个系统应该分成哪几个模块”、“数据流向应该怎么设计”、“为什么这里用接口而不是继承”这类宏观设计能力。

这三个层次不是割裂的，而是层层递进的。L1的自动化释放认知资源给L2，L2的熟练化为L3积累经验直觉。

Claude Code在三层思维上做了什么

当学生自由使用Claude Code时，发生的变化是逐层递进的。

在L1层，Claude Code完全接管了语法生成。学生不需要记住Python的字典遍历语法，因为每次都可以重新生成。不需要内化缩进规则，因为AI自动处理。不需要熟悉常见库的API，因为AI是活的文档。

我统计了B组学生整学期主动查阅Python官方文档的次数：平均每人1.2次。而A组是22.7次。C组和D组分别是6.5次和8.1次。查不查文档本身不是目的，但它反映了一个深层变化：学生是否在建立自己的知识网络和对信息源的判断能力。

在L2层，事情变得更微妙。Claude Code在处理单个简单任务时，看起来只是在替代L1，让学生不需要写具体代码。但当学生面对一系列连续的任务时，“描述需求→AI生成代码→复制粘贴→描述下一个需求”的循环，实际上会取代L2的运作。

我用一个具体的例子来说明。在第7周的“文件处理”作业中，有一个子任务是“读取一个CSV文件，统计其中每个城市的总销售额，然后输出排名前5的城市”。A组学生解决这个问题时，大脑中发生的L2过程是：这个问题需要分步解决→读取文件用csv模块→遍历行的同时累加每个城市的销售额→用字典存储→排序后取前5→打印。这是“问题分解+模式匹配”的过程。

B组学生呢？他们把这句需求复制给Claude Code，然后得到了代码。L2层的思维没有发生。他们“知道”这个问题可以被分解为这些步骤，但这不是他们自己分解的，是AI替他们分解的。

这就是为什么在测验中，面对类似但不同的新问题时，B组学生无法独立完成问题分解。L2不是被教授的概念知识，而是通过反复“分解-验证-修正”这个循环锻炼出来的能力。AI的介入打断了这个循环。

在L3层，短期看不出直接伤害，因为大多数基础编程课程本来就到不了这个层次。但L3是在L1和L2的基础上逐渐构建的。一个从未独立设计过一个中型项目的程序员，不可能突然获得架构能力。B组学生虽然在期末项目中交付了看起来更复杂的系统，但当被追问“为什么选择这个类结构”时，回答几乎都是“AI推荐这样写的”或者“这样做出来的效果没问题”。

一个意外的发现：部分学生出现了“思维脚手架内化”

但实验中也有一个让我意外的积极发现。

在D组（Explanatory模式）中，有7名学生在第12周后开始表现出一种我称之为“思维脚手架内化”的行为。具体表现是：他们在使用Claude Code时，不再只是接受解释，而是开始追问更深层的问题。比如一个学生在完成“用面向对象重构成绩管理系统”时，对Claude Code的解释提出了质疑：“你说把Student类和Grade类分开是单一职责原则，但如果加一个ScoreSheet类，是不是能让成绩计算逻辑更独立？”

这个问题说明，学生已经开始用Claude Code提供的解释作为自己的思维起点，而不是终点。他不是在验证AI是否正确，而是在AI提供的基础上进行更高层次的推理。

我在期末答辩时单独访谈了这7名学生，发现他们有一个共同特征：在课程前8周，他们都有一段被要求“禁用AI”完成特定任务的训练阶段。 无论是我刻意设计的训练，还是他们自己选择的练习方式。这8周的“断奶期”让他们建立了基本的编程肌肉记忆和问题分解习惯。在这之后，他们使用Claude Code的方式和B组产生了本质区别：B组是用AI来替代思考，他们是把AI当成“可以对话的参考书”。

这个发现的启示是：“先建立基础，再接入AI”可能是更安全的教学路径。 而不是“一开始就用AI降低门槛”。

六、影响因素的差异化分析：不是所有学生都一样

在上一章我用了“B组平均得分”、“C组整体表现”这样的整体数据。但整体平均数掩盖了组内的巨大差异。在本章中，我按几个关键维度拆解，看看不同特征的学生在Claude Code面前是怎么分化的。

维度一：初始编程基础

第一个也是最关键的区分维度。我把四个组的学生按入学前测成绩分成三等。

高基础学生（前测>60分，各组共23人）：在四个组中的表现如下：

高基础学生在D组表现出了“正向增益”，期末均分甚至超过了传统A组。而即使在B组的“自由滥用”环境下，他们的下降速度也远慢于零基础学生（16周从82.4降到71.6，降幅13%）。

中等基础学生（前测35-60分，各组共58人）：

中等基础学生是B组下降最陡的群体（从60.1到43.7，降幅27%）。他们的困境在于：已经有了一些模糊的编程概念，但还没形成稳固的思维习惯。这些似是而非的概念在AI的“正确答案”面前迅速被替代，却又不足以支撑他们去深度理解AI的输出。

零基础学生（前测<35分，各组共46人）：

零基础学生在所有分组中都是得分最低的群体，但他们在B组的处境尤为严峻，第16周平均分33.8，远低于及格线。一个学生告诉我：“我感觉自己这学期什么都没学到，但又好像学到了怎么让AI写代码。问题是考试时不能用AI。”

关键洞察：编程基础越弱的学生，从Claude Code的“自由使用”中受益越少、受害越深。 这颠覆了“AI能帮助弱势学生缩小差距”的乐观假设。实际上，在自由使用场景下，AI反而扩大了高基础学生和零基础学生之间的差距。

维度二：元认知能力

第二个维度是元认知能力。我在入学时用一个简化的元认知量表（基于MAI量表改编的编程学习场景版）测量了学生的元认知水平，总分100分。

将学生按元认知得分分为高元认知组（>70分）和低元认知组（<45分）：

B组内部（自由使用Claude Code）：

• 高元认知学生（n=8）：第16周平均分 58.4分
• 低元认知学生（n=9）：第16周平均分 28.1分

差距高达30.3分，远大于A组内高/低元认知学生之间的差距（18.6分）。

这说明：Claude Code放大了元认知差异。 元认知能力强的学生更有意识地去审视AI的输出、控制自己的学习节奏、在遇到不理解的地方主动追问。而元认知能力弱的学生，更容易陷入被动接收的模式，无法意识到自己“正在变笨”。在传统教学中，元认知弱的学生至少会被错误和挫折“逼迫”进行一些反思；在AI辅助下，这条底线被撤掉了。

维度三：使用行为的主动/被动特征

这不是一个先天特征变量，而是一个可观察的行为特征。我在第6周和第12周对各组学生进行了两次“行为分类”，基于课堂观察和实验报告内容：

主动型使用者的行为特征：

• 向Claude Code提问时，不是直接复制任务描述，而是用自己的话重新组织
• 经常追问“为什么”和“有没有替代方案”
• 会主动关闭AI，尝试自己写一段再打开AI对比
• 会质疑AI生成代码中的某些设计选择

被动型使用者的行为特征：

• 直接复制任务描述作为AI的输入
• 基本不追问，有代码就用
• 遇到报错直接把错误信息给AI
• 很少检查AI代码是否有隐藏问题

在B组中，主动型使用者仅占22.6%（7人），他们的第16周平均分是67.3分；被动型使用者占77.4%（24人），平均分34.1分。差距达33.2分。

但在C组和D组，由于教学模式强制要求了追问、留空填充、解释设计等行为，被动型使用者的比例被显著改变。C组中被归为“主动型”的比例上升到56.3%，D组上升到71.9%。这就是结构化模式的效果，它不是靠筛选学生，而是靠改变行为。

七、Explanatory模式缘何胜出：一个更深层的教学原理

前面提到D组（Explanatory模式）在期末测验中得分最高（80.8分），甚至超过了传统A组（77.1分）。这个结果值得单独拿出来分析，因为它揭示了一个可能被低估的教学原理。

Explanatory模式到底做了什么

我在D组的教学流程是这样的：

1. 教师先讲清楚核心概念和设计原则。 比如“今天我们要理解为什么面向对象中的组合优于继承”。
2. 教师展示一段现成的、设计良好的代码。 可以是教师自己写的，也可以是经典开源项目中的片段。
3. 学生使用Claude Code的Explanatory模式分析这段代码。 交互指令大致是：“请深入解释这段代码中每个设计选择背后的考量。为什么这里用组合而不是继承？为什么把这个类设计为抽象类？”等等。
4. 学生写出自己的理解摘要，并在后续练习中尝试应用类似的设计模式。
5. 教师组织全班讨论，纠正Claude Code解释中不准确或过度简化的部分。

注意这个流程和B组的区别：B组学生是用AI从零生成代码，而D组学生是用AI来分析现成的优秀代码。这不是一个微小的差异，这是“建造者”和“鉴赏家”两种学习路径的差异。

从零建造需要同时处理语法、逻辑、架构三个层面的问题，对初学者来说认知负荷过高，自然会倾向于把所有难题外包给AI。而分析现成代码可以让学生把注意力集中在理解架构决策上，语法和实现的认知负荷被代码的“已完成”状态消解掉了，不需要外包给AI。

九、另一个被低估的因素：Claude Code的产品设计哲学

前面的分析集中在教学方法和学生行为上。但Claude Code作为一个产品，它的设计哲学本身就对学习效果有独立的影响。这不是“这个功能好那个功能不好”的问题，而是Claude Code背后的设计取向会引导用户的某些行为，同时抑制另一些行为。

“服从性”设计对学习者的影响

Claude Code和其他的编程Agent（最典型的是OpenAI的Codex）有一个根本性的设计取向差异。Codex的定位是“独立执行任务的开发者”，你给它一个任务描述，它在后台异步运行，完成后提交结果。Claude Code的定位是“结对编程的伙伴”，它和你对话，问你问题，解释它的思考。

从开发者体验来看，Claude Code的交互式设计无疑是更友好的。但从学习者的角度看，这种“友好”隐藏着一个陷阱：Claude Code在任何情况下都不会拒绝你的要求。 它被设计为服务性的、遵从性的。

我做过一个测试：用同一个教学班的学生账户，向Claude Code提出“帮我写一个完整的期末项目，不要留空，不要问我问题，直接给我全部代码”。Claude Code在犹豫了一下之后，照做了。它不会说“作为你的学习助手，我认为你应该自己完成这部分”。

这不是Claude Code的错，它是一个通用工具，不是专门的教育工具。它的设计目标是为最广泛的用户提供最高效的辅助。但当它被置于教学场景中时，这种“绝对服从”的特性直接与教学目的冲突。教学的目的是让学生最终能够不依赖工具，而Claude Code的目的（在其通用模式下）是让学生越来越依赖它。

这一点在Claude Code的Learning模式和Explanatory模式中有所修正。但这两种模式需要用户主动选择和配置，默认模式仍然是“服从式”的。而大多数学生根本不知道有这两种模式，或者知道但懒得切换。

“黑箱优化”的风险

Claude Code的另一个特性是它的代码质量在迭代中持续提升。每一次模型更新，生成的代码都更规范、更高效、更“最佳实践”。

这对于专业开发者是好事。但对于学习者，这制造了一个越来越厚的“黑箱”。一个初学者去看Claude Code生成的代码，他看到的不是“初学者能理解的代码”，而是“高级工程师写的、高度优化的代码”。这种代码对学生来说是不可穿透的。

我在第13周做了一个小测试：让B组学生“解释Claude Code刚才帮你生成的这段代码中，这个装饰器函数的作用”。结果31人中只有3人能给出基本正确的解释。其余28人给出的回答类似“它让代码可以这样用”、“应该是用来优化性能的”。他们使用着这些代码，但完全不能解释它们。

这不全是教学的问题。Claude Code的输出天然地被优化为“结果最优”，而不是“可教育性最优”。它生成的是产品，不是教材。当这种“产品代码”成为学生唯一接触的代码样本时，他们学到的是“魔法是会发生的”，而不是“魔法是这样这样运作的”。

十、教学实践指南：在“可用”和“不能依赖”之间找到路径

在前面的章节里，我花了大量篇幅描述问题的深度和复杂性。这可能会让一些读者感到沮丧，“难道Claude Code不能用于教学吗？”不是这个意思。我想传达的是：可以用，但需要设计，不能靠默认。 以下是我根据一学期实验数据和经验，整理出的实践指南。

指南一：根据教学目标选择模式，而非一律禁用或一律开放

不同的课程有不同的核心目标。这些目标直接决定了AI工具应该以什么方式介入。

如果你的课程目标是“培养算法设计与问题分解能力”：

推荐使用C组和D组的组合模式。前8周使用Learning模式，强制学生在教师设计的交互框架下与Claude Code协作，核心任务是建立问题分解的习惯。后8周切换为Explanatory模式，让学生通过分析高质量代码来提升架构决策能力。

如果你的课程目标是“快速培养应用开发能力”（如非计算机专业的编程通识课）：

可以适当放宽限制，但仍然需要最低限度的结构化。至少要求学生“在向AI描述需求前，先在注释中写出自己的分解步骤”。这个小习惯可以把L2层的思维从AI的手中夺回来一部分。

如果你的课程目标是“培养能独立工作的专业程序员”：

你将面临最艰难的权衡。我的建议是：前三分之一学期完全禁用AI，建立基础的手写代码能力和调试直觉；中间三分之一引入Explanatory模式，开始训练代码阅读和设计理解；最后三分之一允许自由使用，但要求每次提交附带“AI使用说明”和“我自己的贡献清单”。

指南二：设计“思维保留”型任务，而非“结果产出”型任务

改变任务设计方式，也许比改变AI使用策略更重要。在B组出现严重思维退化的原因之一，是所有的考核都围绕“最终能不能跑通”，而这种考核方式本身就奖励AI外包行为。

我在第14-16周设计了三类“思维保留”考核方式，然后用这些方式补测了四个组的表现：

方式一：代码修改与扩展（而不是从零生成）。 给出一段有意的设计缺陷代码，要求学生在不借助AI的情况下修复并扩展功能。B组在这类任务上的表现（51.3分）显著低于其在“从零生成”类任务上的表现（72.6分）。

方式二：口头解释程序逻辑。 给出一个程序的运行输出，要求学生口述程序的执行流程和关键变量的状态变化。这个考核方式极其有效地暴露了“以为自己会了”的假象。B组学生在这类考核中的得分（38.2分）是最低的。

方式三：比较多种解法的优劣。 给出解决同一问题的三种不同代码实现，要求比较它们的时空复杂度、可读性和可维护性。D组学生在这项上表现最好（78.4分），因为Explanatory模式长期训练的就是这种分析能力。

这给我们的启示是：如果你允许学生使用AI辅助，那么你必须改变考核方式。用AI能完成的考核去考一个使用AI的学生，等于在考AI而不是考学生。

指南三：建立学生的“AI元认知”习惯

在实验过程中，我对C组和D组额外进行了一项干预，效果超出预期，值得单独列为一个指南。

从第5周开始，我要求C组和D组的学生每周提交一份简短的“AI使用反思日志”，回答三个问题：

1. 这周我用Claude Code解决了哪些问题？其中哪些是我自己能独立解决的，哪些是完全依赖AI的？
2. 我在这周的使用中，有一个时刻意识到“等等，我应该先自己想一想”吗？如果有，描述那个时刻。
3. 有没有一次，AI给出的答案让我觉得不对或者不够好？我做了什么？

这个简单的日志干预产生了显著效果。到第10周时，C组和D组中能够准确判断自己“什么会、什么不会”的学生比例，从干预前的42%上升到71%。而B组只有23%的学生具有这种准确的自我认知。

AI教学中最危险的不是学生“用AI替代了学习”，而是学生“不知道AI已经替代了他们的学习”。 反思日志这种低成本的干预，可以有效打破这种无意识状态。

指南四：控制Claude Code的“介入深度”，建立渐进释放机制

我在D组的成功经验中提取出了一个“四阶段渐进释放模型”：

第1-4周：完全由教师主导。 Claude Code仅用于教师演示，不在学生端开放。教师用Explanatory模式展示“如何分析一段代码的设计决策”，学生观看并记录。

第5-8周：学生使用，但严格限定交互类型。 开放Claude Code给学生，但限定使用Explanatory模式，且明确交互边界：“只能问为什么，不能问怎么做”。

第9-12周：放宽到允许部分生成。 允许学生在自己写出伪代码或设计草稿后，用Claude Code将草稿转化为可运行代码。重点是：先有自己的设计，后交给AI执行。

第13-16周：准自由使用，附带问责机制。 学生可以按需使用Claude Code的任何功能，但必须在提交时标注AI参与的部分，并在答辩时能够解释每一段非自己编写的代码。

这种“先收后放”的设计，本质上是在模仿人类学习任何工具的历程：先用最简陋的工具建立对本质的理解，再引入高级工具提高效率。

十一、期末项目答辩：一个真实的横截面

写到这儿，让我用期末项目答辩这个具体场景来收束前面的所有分析。答辩是第16周进行的，每个学生有8分钟陈述+5分钟问答。我旁听了所有127名学生的答辩，以下是四组最有代表性的学生表现。

A组学生（传统教学）

学生张，期末项目是“校园二手交易平台”，约1200行代码，前后端分离。功能基本齐全但界面简陋。答辩中最值得注意的是他的回应方式。当被问到“为什么选择用Flask而不是Django”时，他回答说：“我比较了两种框架的文档，Flask更轻量，更适合这个规模的项目。而且我想锻炼自己对项目结构的掌控力，Django会帮我做太多决定。”然后他打开代码，指出自己手动配置的路由和蓝图结构。

他的代码有很多可以优化的地方，数据库查询有明显的N+1问题。但重要的是：他知道自己做了什么选择，也知道为什么做这些选择。他有“代码-决策”的完整意识链条。

B组学生（自由使用Claude Code）

学生李，期末项目是“智能课程推荐系统”，约1800行代码，功能复杂，界面精美，甚至用上了协同过滤算法。从产品角度看，这是全班最好的作品之一。

答辩时，我问她：“你的推荐算法为什么选择协同过滤而不是基于内容的推荐？”她停顿了大约10秒，说：“AI推荐我用协同过滤的。”我又问：“你能解释一下协同过滤的基本原理吗？”她开始复述一段听起来很像AI解释的文字，但当被追问“在你的代码中，用户相似度矩阵是怎么构建的”时，她无法定位到相应的代码段。

我换了一个策略：“如果你的系统要增加一个‘过滤用户已经买过的课程’的功能，你会怎么改？”她想了很久，说：“我会把这个需求告诉Claude Code。”

这不是一个“不会编程”的问题。她显然已经掌握了一些概念词汇（协同过滤、相似度矩阵），能在合适的语境中使用它们。但她的知识和实际操作之间存在一个断裂。Claude Code填补了这个断裂，而她不知道这个断裂的存在。这才是最危险的。

C组学生（Learning模式）

学生王，期末项目是“编程题库管理系统”，约1000行代码。答辩时，我能明显感觉到他的思维节奏和其他组不同。他的回答不是即时流利的，而是带着明显的“想一下”的停顿。

当被问到“为什么数据库设计中选择外键关联而不是嵌入式文档”时，他回答：“一开始AI建议我用嵌入式，因为查询更快。但我在给代码填空的时候，Learning模式你知道吧，就是AI会留几个关键行让你写，我发现如果我要实现‘按标签跨题目查询’，嵌入式的结构会让我写的SQL变得很复杂。所以我又问了AI两个方案的对比，AI说外键更适合多对多查询。最后我选了外键。”

注意这个过程的特殊性：他用到AI，但AI不是直接给他答案。Learning模式的“留空”迫使他动手写了“跨题目查询”那几行核心SQL，而在写的过程中他自己发现了问题，然后主动追问。AI在这里扮演的确实是“结对编程教练”，而不是“代码生成器”。

D组学生（Explanatory模式）

学生陈，期末项目是“实验室设备预约系统”，约900行代码，项目不大但设计非常干净。答辩时我几乎没用上任何“测试性问题”，她主动在白板上画出了完整的分层架构图，从表现层、业务逻辑层到数据访问层，标注了每一层的职责和层间的接口。

她说：“我这个项目参考了Claude Code分析过的一个开源项目结构。它当时详细解释了为什么把验证逻辑放在业务层而不是表现层。这个我印象很深，因为AI还给我举了一个例子，如果你以后要加Android端，表现层的验证逻辑就要在Android端重写一遍，但业务层的验证可以复用。我觉得这个设计原则太强了，所以我自己的项目也这么做了。”

当被问到“你的系统中哪一部分是Claude Code帮你写的”时，她非常清晰地说：“路由注册和ORM模型定义是它生成的，因为这些都是重复且规范的代码，自己写没意义。但业务逻辑层，检查时间冲突、设备状态流转这些，是我自己写的，核心算法是我设计的，中间遇到一个并发冲突的问题我自己调试了半小时，最后用了一个乐观锁解决的。”

这不是一个“用不用AI”的问题。这是一个“知道在哪里用AI、在哪里用自己”的问题。 这种判断力本身就是最核心的编程思维的一部分。

十二、数据之外：关于动机、身份和职业未来

学习动机的隐性转变

在实验过程中，我除了收集能力数据外，也在第8周和第16周用问卷测量了学生的内在学习动机（基于自我决定理论的三个维度：自主感、胜任感、关联感）。

第8周时，B组学生的胜任感得分是最高的（4.2/5），远高于A组的3.1分。这是可以理解的，AI让他们能做出远超自己实际水平的成果，这种“我很厉害”的感觉是非常真实的。一个B组学生写道：“我以前觉得自己不适合学编程，但现在我发现我也能做出很酷的东西。”

但到第16周，数据反转了。B组的胜任感降到了2.8分，而A组上升到了3.6分。原因是：当测验和答辩暴露了他们“其实不会”的事实后，之前的胜任感被证明是虚幻的。更重要的是，B组学生开始意识到“离开了AI我什么都不是”，这种认知对动机的打击比“我学得有点吃力”更严重。

一个在第16周退课边缘的学生说：“我花了整个学期，以为自己在学编程。结果我发现我只是在学怎么让另一个东西帮我编程。我不知道我学的这个到底算什么。”

这不是孤例。在信息技术教育中，身份认同是一个被严重低估的因素。“我是一个正在成为程序员的人”，这种自我认知是支撑学习者在困难期持续投入的重要动力。当AI吞噬了太多编程过程，学生可能不再能形成这种身份认同。“我”变成了“我和AI”，而“我”在其中的贡献变得模糊不清。

职业场景的参照

也许有人会说：“但现实工作中就是这样的啊，程序员就是配合AI工作的。学校应该教的就是怎么跟AI协作。”

这里有一个关键的区别被忽略了。职业程序员和编程学生在与AI的关系上有本质不同。

一个有3年经验的程序员使用Claude Code加速工作，他调用的是一套已经内化的判断力系统。他知道生成的代码好在哪里、潜在的风险在哪里、应该在什么时候质疑AI。AI覆盖的是他的“执行层”，那些他已经会做但做起来耗时的部分。他的“决策层”和“判断层”是完整的、独立于AI运作的。

一个编程初学者使用Claude Code，他的决策层和判断层正在形成中。AI覆盖的不只是执行层，而是连决策层和判断层一起覆盖了。这就是为什么初学者用AI的危害远大于有经验者，他们用AI替代的，恰恰是那些他们最需要通过反复练习来建立的东西。

职业参照不能成为教学决策的唯一依据。 飞行员用自动驾驶仪之前，要累积数百小时的手动飞行时间。这不是因为手动飞行比自动驾驶更好，而是因为那些手动飞行小时建立的直觉，是安全操作自动驾驶仪的前提。编程教育面临的是同样的逻辑。

十三、结论与行动建议

不要在两个极端之间做非此即彼的选择

在AI进入编程教育这件事上，我看到的两个极端都不可取。一个极端是“全面禁止”，这既不可行（学生私下会用），也不明智（隔绝了应该掌握的现代工具）。另一个极端是“放任使用”，这会系统性地侵蚀思维基础，尤其对弱势学生伤害最大。

正确的路径在中间：分阶段、结构化、有问责地使用。 这个路径比两个极端都更耗费教师的心力，但目前没有更省力的替代方案。

给一线教师的行动建议

如果你是一名编程教师，正在考虑把Claude Code引入课堂，以下是我基于整学期实验的六条行动建议，按优先级排序：

第一，别默认让学生自由使用。 默认设置是Claude Code的“侍从模式”，你提需求，它给代码。这个模式对学习者有毒。如果你要引入，至少先花一节课教学生如何切换到Learning或Explanatory模式，并解释为什么。

第二，前四周不要开放AI。 这是最关键的窗口期。在这四周里，学生需要建立最基础的语法肌肉记忆和调试直觉。不需要很精熟，但要有。这个基础是他们后续“驾驭AI而不是被AI驾驭”的前提。

第三，改考核方式。 如果你还在考“写一个程序实现XX功能”或“用Python完成XX任务”，那么使用AI的学生考的不是自己，是AI。改用代码解释、修改、扩展、架构优化这些“产品+过程”综合型考核。

第四，引入“AI使用反思日志”。 这是成本最低、效果最显著的干预。每周只需学生写100-200字，回答“我用了AI做什么”、“我有没有自己先想”、“AI有没有出错”这三个问题。它打破的是“无意识依赖”的状态。

第五，用好Explanatory模式。 如果你的课时有限，只能选一种模式来结构化使用，选Explanatory模式。它保护思维的效果最好，且不需要像Learning模式那样逐个任务设计交互脚本。

第六，和学生诚实讨论AI的代价。 别只是强加规则。把本文中的核心发现，思维代偿效应、效率错觉、脆弱知识结构，用学生能理解的语言告诉他们。当学生理解了“为什么不能直接拿AI代码”之后，规则的遵从度会高得多。

给教育管理者的建议

如果你是一位系主任、教务长，正在决策是否和如何在课程体系中引入AI编程工具：

不要把“是否引入AI”的决策权完全下放给单个教师。 这不是技术选择问题，是教学质量保障问题。系部层面应该形成一个统一框架：哪些课可以在哪个阶段、以什么方式使用AI。否则就会出现一门课严格禁用、另一门课完全放任的混乱局面，学生的编程思维会在这种混乱中系统性受损。

投入资源做教师AI教学能力培训。 大部分编程教师自己也是最近才开始使用Claude Code，对其在教学中的复杂性可能和你一样陌生。结构化使用AI对教师的技能要求远高于传统教学，需要专门的培训支持。

重新评估课程目标和毕业要求的表述。 如果毕业要求写的是“能够独立使用Python完成数据分析任务”，而学生在所有实训中都默认使用AI，那么这张毕业证的有效性是需要质疑的。更新课程目标，明确区分“需要独立完成的能力”和“可以借助